Will Google’s Eddystone EID be Viagra for the Bluetooth Beacon Ecosystem?

This new Google standard has very significant implications for almost every player in the proximity market. We review the Eddystone EID announcement and explore seven of its likely effects – along with the occasional digression into adolescent humor:

Performance problems can be an embarrassing topic of conversation, whatever the context. The beacon ecosystem has been burning the candle at both ends. Creating 300+ location and proximity businesses can take it out of you (see www.proxbook.com) and the enormous expectations can create performance anxiety. Over 10 billion beacons by 2020 (according to Gartner) is enough to put anyone off their game.

This new Google standard has very significant implications for almost every player in the proximity market. We review the Eddystone EID announcement and explore seven of its likely effects – along with the occasional digression into adolescent humor:

So maybe Google’s Eddystone EID can help with this beacon Ecosystem Dysfunction (ED) issue.

There has been an issue at the center of this problem that is taboo. Frankly it’s been hard to talk about, because when we do, the excitement wears off. The mood killer is “standards”, or lack of them. The beacon ecosystem has been suffering from partitioning of the industry by proprietary manufacturer specific APIs. Apple’s iBeacon works across manufacturers but has huge gaps, especially around management and security. Few of the parties involved have wanted to acknowledge the issue, but until you do that, it’s hard to take action to solve it.

Venues, developers and solutions providers should care. There are three reasons why standards problems can create beacon ED, which manifests itself as a disappointing level of performance, as measured by the number of large production deployments (versus pilots). Excessive dwelling in pilot projects is an indication of a lack of confidence, which kills performance.

1. When developers write apps for a particular beacon vendor’s proprietary APIs, they are locking themselves into a particular platform. Most venues investing in Bluetooth beacons want to control who accesses them. The APIs developers have to use to control this conditional access are completely non-standard. The iBeacon standard is silent on the topic. In many cases developers are getting locked into the fortunes of startups. If the startup goes under, that’s bad news for the project and the career of whoever funded it. If these startups are successful and they get bought by a big company, app developers and venues are playing Russian roulette with the company they will be doing business with after the acquisition. It’s possible there may be a conflict of interest between your business and the acquiring company.
2. If you like your vendor’s beacons, you had better like their fleet management system too. Currently if you buy a vendor’s beacons, you are automatically locking into using their tools for tracking and configuration.
3. There is no standards approach to aggregating and sharing access across beacon providers. Imagine the mobile phone business before you could roam across networks. When your telco didn’t have cell towers where you needed coverage, users would be unhappy and the telcos would be earning a lot less money. We are in a similar situation with small islands of beacons, none of which have established critical mass from a network point of view. If you want an app to work across different retailers and DMAs (regional markets) standards would make achieving this scale a lot easier.

Google Eddystone EID takes major steps to addressing all three of these issues. The standard, which was introduced last week, has implications beyond what many have discussed so far.

First, how does this latest version of Eddystone compare with Apple’s iBeacon? Remember those old cell phones the size of bricks that were used back in the 80s (think Michael Douglas in Wall Street), that’s iBeacon 1.0, compared with the Star Trek communicator, that’s Eddystone.

OK maybe there’s a little exaggeration, but the point is when iBeacon came first (over 2 years ago!) it was a historic breakthrough, similarly Michael Douglas looked pretty cool with that amazing breeze block cell phone, but Eddystone has developed the idea and gone so much further

Before we look at what the implications of Eddystone EID are, let’s recap on what it is. In our book “Beacon Technologies, A Hitchhiker’s Guide to the Beacosystem” we describe EID is a “beacon conditional access” standard. You need conditional access if you want to control who sees your beacons, deny access to competitors, charge your partners for their use of this asset, while avoiding privacy and fraud issues.

With EID the identifier of a beacon is changed periodically, so that unless you have access to a key, the identifier appears to be random and meaningless. By default, the change varies around every 8.5 seconds (although this can be adjusted). So if someone scans the beacon and tries to use that identifier again after a few seconds the original beacon will have changed what it’s broadcasting and provide no basis for identification, unless you have the key to unlock the encrypted identity or are using the Eddystone cloud service to resolve it to the unencrypted ID, which remains consistent over time.

While an increasingly large number of beacon vendors have “rotated” the UUID’s of their beacons as a way of avoiding unauthorized tracking and forgery of beacon IDs, the effectiveness of their approaches have varied. Stories abound of schemes with obvious flaws, like rotating a limited number of IDs, using a single key for the whole network or failing to randomize the beacon’s MAC address. The Google approach has used the full power of the Google brains trust, with a team of Israeli cryptographers using a mind numbing amount of mathematics to establish the efficacy of their solution (read section two of https://developers.google.com/beacons/eddystone-eid-preprint.pdf if you have problems with going to sleep at night). The first firewall of protection in Eddystone EID is a firewall of sleep inducement for any bad guys trying to understand the cryptography. Google have done their homework to make sure the solution doesn’t sacrifice response times for security, with an approach that scales up to the 10 billion beacon level that Gartner predicts for 2020.

The piece of the Eddystone announcement that many news organizations have failed to give adequate coverage to, is the standardization of the management interface for beacons. For the first time there is a public specification of the Bluetooth GATT commands that can be used to configure a beacon for any of the Google Eddystone frame types. GATT is a standard command set that Bluetooth beacon profiles for other devices such as heart monitors are built on.

EID takes us a big step towards beacon owners (such as retailers and other venues) being able to buy their beacons from Beacon Vendor A and using the tools from Vendor B to manage them. This is new.

What does this have do to the business of beacon vendors? If they are selling beacons as a loss leader with a view to making money from beacon management services, they had better make sure their beacon management is top notch.

For venue owners, the risk of investing in beacons goes down. They can potentially source beacons from two vendors, with a single management system taking care of both.

The beacon management business gets a lot more attractive; suddenly you don’t have to invest in making beacons and winning the best beacon battle. Your total addressable market goes from just your beacons, to all vendors that make Eddystone beacons. Most of the top beacon vendors announced support for EID at the time of the announcement. So we can expect some of the larger providers of network management infrastructure (CA, IBM, Cisco & HP) to pile more investment into this area. Beacon management likely gets included into the management of other network and compute nodes. All this is good for potential investors in beacons.

This isn’t all bad for the smaller guys making beacon management solutions either. They can move fast and have the experience to grow into this bigger market. As their investors consider their exit strategy, all these enterprise management companies become attractive potential acquirers.

Exciting – if this doesn’t get an entrepreneurs blood flowing faster, what will? Let’s get back to the main point of EID.

Sometimes the venue owner and the app owner are one and the same, but increasingly the apps using beacons will come from third parties, not just the venue owner.   This is a good thing. Imagine the PC industry if every vendor had their own incompatible OS – what state would the software industry be in today? It would have been crippled. That’s the situation we had with beacons.

For beacon app developers, their total addressable market just got a lot bigger, so we should expect more investment in beacon apps. This is good because despite all the beacons being deployed, the quantity of quality apps has been surprisingly small. This provides the market incentive for more investment and better apps.