Some pros and cons of Google’s plan to give every “thing” a URL

Always be scanning. That’s the future of the smartphone in Google’s new program designed to bring interoperability to the internet of things. The plan, announced Thursday by Scott Jensen working as part of the Google Chrome group, involves giving every device the equivalent of a URL that could be read by the phone without having to open an app.

From a user perspective, it means you’d be able to call up a list of nearby connected objects and select the one you want to interact with from a ranked list. From there, the user selects the URL of the device he or she wants and the full experience for that device loads. Today it’s a web page, but eventually that experience could be anything from information to a transaction.

This makes tremendous sense when you consider that much of the value of the internet of things isn’t about engagement, but about conveying information quickly and easily. It also means that the traditional business models around engagement don’t make sense, which is why everyone is trying to vacuum up and control streams of data.

How the Physical Web would work

With that in mind, let’s go back to the Physical Web plan as laid out in the Github documentation. [company]Google[/company] has released an open source version of a Bluetooth beacon app that can run on iOS or Android handsets (that have the supporting hardware). The software lets the phone scan for available devices, but when it finds them it doesn’t notify the user unless the user asks for the information. At that point, the user might request the data or interact with a transit schedule nearby or a vending machine.


As for privacy, especially given that any device broadcasting bluetooth or Wi-Fi signals can share a lot of detailed information about a user, the documentation says that the way the app is implemented attempts to protect a person’s privacy until they click on a URL to share information with a device. From the documentation:

[blockquote person=”” attribution=””]Our current URL broadcast method involves a bluetooth broadcast from each beacon. The user’s phone gathers this info without connecting to the beacon. This ensures the user is invisible to all beacons, meaning a user can’t be tracked simply by walking past a broadcasting beacon. This was very much by design to keep users silent passage untrackable. However, once the user does click on a URL, they are then known to that website.

The search agent on the phone may keep track of which devices the user taps on so they can improve the ranking in the future. Of course, this too needs to be discussed and then possibly offered to the user as an option so they are in control of how this information is stored.[/blockquote]

Google is choosing URLs today because they are the mainstay of the web and interoperable, but it also mentions that some companies might try to do this with a URL plus some sort of additional identifier going through a private server. This would add security benefits and help with authorization. It might make sense in a hospital setting, for example, where only certain people should interact with connected patient gear.

The pros, cons and a bunch of questions

There’s a lot to like about this approach, but Google isn’t the only one thinking about a URL-style model for people to interact with the internet of things. I’ve spoken with [company]Dyn[/company] about using DNS (the domain name system) and variations of a URL for addressing things, and a company called The Wireless Registry has actually implemented a private URL system for connected devices.

So there is plenty of precedent for such an operation. But it also comes with a number of weaknesses — the most notable being that it assumes a person-to-device interaction. While there is huge value in people interacting with the objects around them, there is even greater value in giving objects enough intelligence to interact with each other. Based on the contextual information that Google Now takes in to pick and choose new cards to show me, I assume Google understands this, which is why I expect more to come with this system tied to context.

Another problem is how to name the billions of connected things. Andrew Sullivan, the director of architecture at Dyn, told me this week that one might use a single URL for your house — such as 2234northshoredrive.whatever — that might be provided by an ISP or another service. Behind that URL your connected devices would get subdomains. I plan to cover his plan in more depth next week, but it has a similar URL focus to Google’s.

However, in the technical overview of Google’s plan, it looks as if the URL names will be very short. Google proposes an eventual translation service, but the current version doesn’t have one.

There are also questions to ask about the points of weakness and control in Google’s Physical Web. The translation service could be one. Others include how the URLs are ranked (the current version uses the signal strength of the nearby beacons). A third is the URL translation.

Today URLs can be translated by the domain name servers owned by ISPs, service providers like [company]Open DNS[/company] and Dyn and big companies like Google or [company]Microsoft[/company] that all go back to the root servers that govern the whole naming system. Many providers use the information gleaned by DNS requests to sell ads or charge for faster and premium versions of the service.

Would that model work for things? Would we want it to? In some ways, since the user can choose DNS providers, they have an element of control. But DNS can introduce latency and other user experience challenges depending on how it is pulling websites. I assume if people are on the go there will be less tolerance for that. If every thing has a URL, who will issue that URL?

There are tons of questions to be asked about this service, but I’m also glad that we’re finally getting to a point where people are proposing architectural solutions for the internet of things that recognize that having a million proprietary networks split off by incompatible protocols or radios isn’t going to build an internet of anything.