Browsing Google Chrome and the Physical Web

Google Chrome Physical Web URL

Chrome 57 has launched, and with it in-browser support for the Physical Web. Now, when a user goes to conduct a search or enter a web URL, any nearby Physical Web addresses will appear just below the address bar as seen in the above graphic.

It adds another piece to the proximity puzzle – allowing your browser to show nearby URLs when you go to enter a Web URL or go to conduct a search.

Use Cases for Chrome URLs

Being able to see nearby Physical Web URLs in your browser suggests some interesting use cases/value propositions:

Closing the Gap on Physical Web Objects – in the world of the Physical Web you walk up to a “thing” and use it. In general, their use case is for that “thing” to include a Physical Web icon. You need to know that the object has a URL attached to it. This is usually accomplished through physical-world icons/signage. You then need to know to “pull down” on a notification tray to see it.

By adding Physical Web URLs to your browser search/address bar, there’s another path to making sure users will more easily be able to “see” that URL.

Show-rooming – Retailers still struggle with ‘show-rooming’ – where users will be shopping, say, for a fridge and go online to compare prices when in the store. By attaching a physical web beacon to the fridge, the retailer has a last chance to catch the user’s attention with a link of their own.

In the Home – This is, perhaps, where beacons can truly start to merge over with the connected home. Device makers (say, the Nest thermostat) can embed a Physical Web broadcast. Now, your thermostat, connected TV or other device can offer up a manual, support hotline or other information as an available link in your browser – and possibly bypass the need for a custom app.

Bluetooth in the Browser

Things start to get really interesting when you take into account the fact that Chrome also supports Bluetooth connections.  By allowing Chrome to connect to nearby Bluetooth devices, you can create use cases where a Physical Web signal leads to a web URL. The web URL leads to a page with support for Bluetooth connectivity.

(We should note that Bluetooth proximity and Bluetooth connectivity are two entirely different things!)

Google does a deep dive on this capability and provides libraries for Angular, Node and Polymer.

We can envision use cases where you approach a fitness machine in a local gym, it has a Physical Web logo, a Physical Web URL shows up when you search in Chrome, and the web page it takes you to can connect to the machine and read out heart rate or other information.

Go Chrome, or Go Physical Web?

This addition to the “proximity pathway” is great. But it adds another layer to an already confusing set of instructions for consumers.

One interesting question: when you’re creating an in-location sign/symbol or marker to let consumers know there is a nearby URL, should you flag it as Physical Web, or Chrome?

I’ve been wondering whether the Chrome logo wouldn’t be a better way to go. It bridges Android and iOS, is a recognized symbol, and is WAY easier to explain.

Because when the current instructions look like THIS, wouldn’t THIS be easier to understand?

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Have you engaged yet with a Physical Web URL via Chrome? What use cases do you think we’ll see? And do you think the Physical Web icon will be a driver of adoption, or will we see other ways to promote these new features?

Drop a comment below, or pop me a note on Twitter.

Content Creator or “Business Builder”? Drop Me a Line

On a side note, we’ve been partnering with content creators, publishers and entrepreneurs of all stripes. We’ve been building out tools to bring proximity channels to new markets. If you’d be interested in learning more, don’t hesitate to drop me a note – doug (at) fidgets.net . Our mission is to help content creators,  publishers, entrepreneurs and companies to build new revenue streams on the Internet of Things.

Advertisements

Google Updates Terms of Service for the Physical Web

Google has updated its Terms of Service for Chrome to clarify the use of the browser as part of the “Physical Web“.

The update, which coincides with the release of beacon detection in Chrome browsers for iOS (with Android support expected in the coming days), clarifies that users won’t be sharing personally identifiable data from their device when they connect to a beacon that broadcasts a URL.

Specifically, the update, which went live on July 21st, informs users that:

If you enable the feature in your device’s Today view, you can use Chrome on your iPhone or iPad to discover objects around you that are broadcasting web addresses as part of the Physical Web. When you use this feature, Chrome sends the web addresses broadcast by these objects to a Google server to find the title of the web page and help rank the results. The information sent to Google to provide this feature does not include any personal information from your device.

Now, it’s not to say that Google isn’t using the data about which URLs are being pinged, and you need to consider your use of location services as well:

If you use Chrome’s location feature, which allows you to share your location with a web site, Chrome will send local network information to Google Location Services to get an estimated location. Learn more about Google Location Services and enabling / disabling location features within Google Chrome. The local network information may include (depending on the capabilities of your device) information about the wifi routers closest to you, cell IDs of the cell towers closest to you, the strength of your wifi or cell signal, and the IP address that is currently assigned to your device. We use the information to process the location request and to operate, support, and improve the overall quality of Chrome and Google Location Services. The collected information described above will be anonymized and aggregated before being used by Google to develop new features or products and services, or to improve the overall quality of any of Google’s other products and services.

But the update is welcome news on the privacy front.

It might not solve the problem of beacon spam if we’re suddenly flooded with millions of the little devices as we wander around the neighbourhood, but it’s somewhat assuring to know that Google isn’t sending personal information back to its servers just because your Chrome browser heard an Eddystone beacon as you walked through the mall.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Google Eddystone Jumps into the Browser on iOS


Your browser will now connect to ‘cookies’ in the physical world – beacons, which can now broadcast a Web URL as part of Google’s new Eddystone protocol.

And Google is planting its flag on iOS devices first.

By launching beacon support within Chrome, Google is effectively bypassing the gatekeepers at Apple and providing support for beacon detection “without an app” – because the app is the browser.

Having said that, Google won’t exactly be spamming you with messages. Instead, if you’re near an Eddystone beacon, you’ll need to be using the Google Today widget in your notification center (or it will need to be refreshing).

And yet, by planting this flag in iOS, Google has a relatively confined audience to test the Physical Web – and bringing that capacity to Android (in, perhaps, a far richer format) isn’t far behind.

While the percentage of users who have installed of Chrome on iOS devices isn’t known, it’s not insignificant, and likely ranges somewhere around 10%+, representing 10s of millions of users.

The larger win will be when Google launches similar support for Android, likely in the coming days.

But beyond the installation numbers is something perhaps even more compelling – because with beacons, Google will have a way to conceivably “ping you” to open a Chrome browser that you rarely use. While not currently how they’ve designed it (they limit the notices to an active Notification Center view) it won’t be long before they take the functionality further.

Google Goes Out for Launch

It took a while, but Google launched a full beacon development framework this past week. The framework included the open source Eddystone specification for beacon broadcasting, along with a host of tools and integrations.

The project was a grand slam, perhaps shockingly so, (depending on your view of how well Google promotes itself and how well it handles documentation and design).

Apple launched its iBeacon framework with barely a whisper at its World Wide Developer Conference in 2013. It then did very little to evangelize or explain the technology and created endless market confusion (perhaps intentionally), both over what an iBeacon actually IS, how it differs from the Apple software SDKs, the difference between an iBeacon and BLE, and how it would integrate across the larger Apple ecosystem.

Since then, Apple did very little to expand the protocol. It added beacon support to Passbook, thus allowing “app-less interactions”, and it recently announced it would further extend engagement through Apple Wallet and its iAd platform.

But Google has taken a page from what you might typically think of as the Apple playbook – creating a tightly integrated system of software and services to allow rapid development and deployment of a new technology.

Additionally, it did pre-launch outreach to a few select companies, who are now beating the drums as if they’ve joined the Google empire, and it managed its press relations, publicity and self-promotion as if Marissa Mayer still worked there.

And now, its followed up the success of the Eddystone launch by planting its flag inside iOS, letting the Chrome browser detect beacons and pushing you messages even in the absence of what you normally think of as an ‘app’.

The Physical Web

What makes this possible is the unique broadcasting packet of the Eddystone beacon protocol, called the Eddystone-URL. It allows you to:

  • Broadcast a URL from your beacon instead of an ID number
  • By broadcasting a URL, you can bypass the need for an app to “parse” the meaning of a beacon’s unique ID number
  • You can thus leverage existing Web resources and simply point the user to a Web URL
  • With this capability, the potential to bypass the app layer entirely is made possible, and with Google now launching support via Chrome, you’ll be able to pop a “URL beacon” on your wall and let the Web do the rest

Back to Basics on Beacons

For those who are just joining us, a beacon is a relatively ‘dumb’ device that is based on an open Bluetooth specification. A beacon broadcasts a signal, and when your phone “hears” that signal, it can act on it.

In a traditional beacon, the signal typically consists of a unique identifier and a bunch of extra ‘keys’. When your phone (via an app) hears this identifier, it can make a decision on how to act, usually by referencing a cloud-based service which provides it instructions on what kind of content to display.

Eddystone, however, incorporates the Physical Web as one of its broadcast signals.

The Physical Web was originally one of those “in my spare time” projects at Google (most of which remain experiments and are never brought into its main business). The premise of the Physical Web was simple: rather than build a NEW infrastructure for beacon content, why not just leverage Web development?

By broadcasting a URL, your “app” wouldn’t need to go to a cloud server or otherwise parse the meaning or purpose of the ID number that the beacon broadcasts. Instead, you can just open a browser.

Eddystone lets you broadcast a URL (it also has more “traditional” beacon broadcast formats, which are still needed for richer/native type app experiences) and it’s this capacity which makes Chrome the natural choice for broader “beacon detection” without the need for an app.

The Pros and Cons for Retailers and Brands

As I wrote yesterday, Eddystone is a big win for anyone who wants to create some kind of interaction with consumers based on proximity.

It’s just a beacon, after all, and by producing a robust suite of software tools for Android, we now have an easier and better way to deploy beacon experiences to Android devices.

But beyond the beacon itself, there will be some strategic decisions to make.

Because Google didn’t just launch beacon support. It also launched a suite of accompanying APIs and integrations – and whether you decide to use them will have as much to do with your views on who owns and should monetize the data in your venue and about your customers, and how important it is to achieve new ‘reach’.

Integrate with the Physical Web and your customers are now using a Google product and that product will now have access to data about where your customers are and what kinds of “physical world Web sites” they’re connecting with (although it promises not to share any personally identifiable information from your device).

Integrate with Places, Nearby or its Proximity API and there are other decisions to make.

But this all points to a larger message: that the tools for reaching customers have just become richer, that the era of the app as the primary driver of mobile engagement is coming to an end. You’ll now have more and more tools to reach consumers based on proximity and that’s a very good thing.

And, strangely, and for today anyways, if you want to test out Google’s Physical Web, you’d better get out your iPhone first.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Well….wow huh? What do you think? Call me impressed.

Google, Chrome and Open Beacons: Devices as URLs


It’s rare that you hear about proximity beacons without the name iBeacon being attached. Apple has built its own preferences and standards for how Bluetooth Low Energy (BLE) devices be deployed to a ‘proximity’ specification, and has built a portfolio of patents around user experiences.

Yet in spite being associated with Apple, we’re still talking BLE, and often the differences between different companies is as much about philosophy as it is a technical specification or capability.

And it isn’t just Apple versus the rest of the world. Google itself can have competing views of beacons with different approaches from the Android or Chrome teams.

Google-Beacon

For Chrome, Beacons Are URLs

For some time now, we’ve been following efforts by Chrome to create a new paradigm for beacons, one based on a more open standard than Apple. The approach is best summarized in a talk planned for the ThingsExpo in Santa Clara this November.

During a talk by Scott Jensen at the event, a quarter-sized beacon will be handed out to 100 or so attendees which acts as a gateway to the Web. Check out the event in November:

“The physical Web uses Bluetooth low energy beacons to broadcast an URL wirelessly using an open protocol. Nearby devices can find all URLs in the room, rank them and let the user pick one from a list,” according to Scott.

Each device is, in effect, a gateway to a web page. This  unlocks entirely new use cases so devices can offer tiny bits of information or simple interactivity. Imagine smart posters, bus stops, dog ID collars, vending machines, or interactive kiosks, all universally accessible without installing additional apps.

The beacons are slightly larger than a quarter and serve as type of “maker kit” so anyone can prototype this new interaction style. Scott will demonstrate the beacons during his session, and hand out sample working beacons to the first 100 in attendance.

But the efforts at Chrome shouldn’t be confused with Android, say, or Google Now, wearables or (for all we know) driverless cars.

One standard – Bluetooth LE. But as many use cases as there are folks hacking away to make cool stuff happen.

Toronto Dsrupted – Join Us!

Vidya Nagarajan of Google Chrome for Enterprise is one of the presenters at the Dsrupted Conference being held in Toronto September 17th. If you’re interested in beacons, digital signage and the next generation of ‘screens’ you should join us.

Share Your Thoughts

Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Is a more open approach to beacons the future? If beacons initiated actions on “The Web” will that have a larger impact than triggering native apps? Drop us a comment below.