Idea: How Smart Kitchens Should Work

Why would someone want to configure their blender for Wi-Fi?  Or upgrade the firmware of their toaster over? Or replace their perfectly working microwave because their refrigerator does not support it anymore? It is unlikely that someone would want to do these things but this seems to be  the direction where smart kitchen appliances are heading with the Internet of Things. 

For the "Internet of Things" many of these "things" are just low powered computers put in a device and then connected to the user's home network.  This means that they have the same basic needs as a computer, tablet, smartphone, etc. in that they need to be:

• Authenticated so they have a secure connection
• Able to protect themselves against malicious traffic
• Patched when flaws or vulnerabilities are discovered
• Upgraded to support new features

These are very important tasks but they are not something users like to think about and probably not something they want to do with their blender, toaster oven, microwave, etc..  Despite all the benefits of smart appliances one does not want to wait for their smoothie to blend because of an installing patch or have that new game on their tablet decide that their baked potato should be very, very well done. To solve this problem I suggest the creating a smart kitchen instead.

Rather then having each appliance on the home network individually, have only a dedicated computer in the kitchen on that network.  This computer could then treat the other appliances like a private network and would be the only interface between them and devices on the other network.  It alone would need to be configured and would also have a firewall just like a regular computer in addition to managing all the patching to ensure that the kitchen operates smoothly. 

A critical benefit is also that the computer can be the primary point of interaction.  Therefore, when cooking a roast when the user opens up the their recipe the oven would preheat, the timers would automatically be set and anything else they need would be configured and ready to go.  Also as it is a standard computer it would be possible to install new kitchen applications to increase functionality as well as browsing the Internet, using email, etc. when additional information is needed.

The main hurtle is that standards need to be established to ensure compatibility among vendors but I imagine that would be easier convincing people to enter a WPA2 password on their blender, toaster oven, microwave, etc..

The Future of eCommerce

Today shopping on the Internet is essentially the same as shopping with a catalog in that you are simply seeing lists of items with descriptions.  As you shop you add items you want to a "shopping cart" that is essentially just a product list and when you are ready to place the order you fill in your contact and billing information on a form.  While doing this on a website is much more easier and accurate  than using older methods of ordering, such as the telephone, I think that new technologies have the potential to make this a much better experience. Specifically, virtual reality devices like the Microsoft HoloLens could radically change  the online shopping experience and perhaps even bring relief to failing "brick and mortar" stores.

Imagine this scenario: a person wants go shopping online at a technology store that also exists as a brick and mortar chain.  Rather then head to a web browser, they launch their favorite shopping application that works with their virtual reality headset.  They put on the headset and they are standing in front of a virtual simulation of the physical location where they normally go.  After walking through the door a cart is automatically provided and they start their shopping trip by walking around the store.

When they get to a product they are considering, they reach for it and a virtual version of the box appears floating in front of the its peers on the shelf.  After grabbing the floating product, they start examining it, flipping it over to reading the back. They decide to buy this item so they place the product in their cart.  They repeat this with another product but after deciding not to buy it they place the box near the shelf where it was floating and let go.

As they finish their shopping trip and are ready to complete the purchase of their items, they head for the checkout counter.  When they arrive the cart disappears, its contents tallied, and the customer is    prompted for their billing information. After providing it, as well as a shipping address, they receive a receipt and shipping information so they know when their order will be delivered.  They then walk through the exit door and back to the virtual street or virtual mall.

On another visit, as the inventory on the virtual shelves is the same as that stores physical shelves, they remember they really need ink and it looks like the store going to run out again as they were out of luck last time they needed ink.  They are also enthusiastic to look at the new monitors more closely so they decide to take the time to head down to the physical location.  While they have only visited it a handful of times, their hundreds of visits online mean they know the location of every product with their eyes closed.

Is this possible today? There are already technologies available to do the sensing and virtual reality display in addition to screen based first person virtual reality that is as old as first person games.  Moreover, there could be different ways of presenting the virtual store that is familiar to the layout but more efficient then a full simulation, such as an interactive map.  Technology is causing the physical world and the virtual world to move closer and stores will need to respond to ensure customers have the best shopping experience.

Idea: Add .localhost,.lan,.vpn,.ian and .wan to the DNS standard

An important part of the IPv4 protocol is that there are ranges of addresses that are reserved and cannot be used on the Internet.  These include the localhost address 127.0.0.1 and the ranges for LANs, such as the address in 192.168/16 that are commonly used with retail Internet routers when assigning LAN addresses.

These addresses are critical in making the Internet work since they allow the Internet to easily coexist with private networks, especially when using standard devices.  For example, every router sold by a company can have an admin address of 192.168.0.1 without interfering with other routers of the same brand. However, while there is support for naming devices on a network, a major problem is that unlike with IP addresses, DNS does any robust conventions to prevent conflicts with internal networks.

This lack of naming rules has caused problems as new top level domains are conflicting with names of internal resources and disrupting access. Before administrators only had to worry about a small set of conflicts, such as “com” or “ca” but now that anything can be a TLD, any name could potentially conflict with something on your network.  In addition, the .local TLD does not seem to be robust enough to help this situation.

To solve this and perhaps promote more consistent naming of resources, network administrators and standard bodies should consider adopting the following TLDs:

.localhost

• This already exists and would continue to refer to 127.0.0.1 alone.
• Subdomains could point to 127.0.0.1 or to another 127/8 address, but nowhere else.

.lan (Local Area Network)

• These would only point to LAN addresses, such as the 192.168/16 addresses.
• Lookup would only take place within the LAN, never consulting DNS servers on the Internet.
• “lan” itself could point a designated device, such as one providing DHCP services.
• A device could be responsible for its own name and can subdomain that name for resources available though that device.
• There could also be a way to define domain trees that are managed independently of the devices they point to, such as on the device with the DHCP server.

.vpn (Virtual Private Network)

• As a synonym for .lan, this would exist mainly to make it easier for the user to understand where their resource is located. For example, a computer at a head office named files.mycompany.vpn makes more sense than files.mycompany.lan since the server is might not be in the user`s local area network.

.ian (Internet Area Network/Internal Area Network)

• This would indicate that the domain namespace is defined using user controlled DNS servers or host computers.
• The IP addresses can be any valid IP address.
• Public DNS servers should not return information about a .ian domain unless the .ian address is acting like a proxy server.

.wan (Wide Area Network aka the public Internet)

• This would explicitly say the address of the resource your want in on the public Internet and not a localhost address, LAN or VPN.
• This would be a valuable safeguard in some cases, such as security or in the event of overloaded names not named with the above conventions.
• An administrator could also use this like a telephone outside access code and require all public addresses require .wan, as if “wan” is the name of a proxy server.

In the event there is not an extension the best default would to be assuming an implicit .wan it there is a period in the name and .lan/.vpn/.ian if it is a single name.  For these addresses, it would be up to the administrator or user to determine the best naming scheme to avoid and  resolve addresses issues.

I feel that using this naming scheme would make DNS more robust and  would allow for its future expansion, such as naming devices in the Internet of Things.