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:

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.


Mind Commerce

Nice article Stacey and thank you for covering this area. We feel that this will be a pretty important area as referenced by our quote from 2013:

” There is a great potential for Google in M2M/IoT. Just as RFID can be used to create presence detection, tracking, etc., and association between real-world items with Web-based objects such as URL’s, Google can employ the use of M2M for virtual control of real-world objects.”

I can send you more from that coverage topic if you are interested to network and share some thoughts on the subject matter.


Of course it’s going to be some kind of Url system. How could it not be? What Google seems to be actually talking about here is using current technologies such as Blue Tooth 4 Low Energy to establish client/server usage paradigms. To that end the idea of a model where the devices cannot track passive passage is ideal to me. There will be no stopping the gleaning of some amount of data once you choose to connect. But there is no reason eveything needs to be able to track me should I not choose to do so.
Well – there are reasons. But they benefit business models and not me as a user necessarily.

Brad Canham

Interesting piece Stacy. As a monitoring service Dotcom-Monitor is positioning for IoT monitoring with an Ipv6-enabled monitoring infrastructure and other technology enhancements, including mobile. The monitoring marketplace implications of IoT — with a 10x-100x expansion in Internet devices — are significant to say the least. The assumption is monitoring of key devices will correspondingly drive a need for additional monitoring of many types, but especially network monitoring that “interconnects” from one end of the IoT end user experience to the other end.


I have a feeling this URL is going to turn out to be appstore://com.equipmentmaker.devicetype … vendors can’t resist lock-in.

Dmitry Sotnikov

Likely a few major platform emerge and equipment makers will have to be players in their ecosystem, rather than all create their own. They’d obviously love to – but this is extremely hard to pull off. Think about smartphone app stores. Apple has theirs, Microsoft is trying to get theirs going, but all Android-phone manufactures just stick with the Google’s – Amazon being the only exception.

Comments are closed.