Yesterday, Google announced Eddystone-EID, a more secure advertising frame (data) that provides for beacons that can’t be spoofed and hence can exchange information more securely and privately.
While beacon spoofing isn’t yet a problem, it’s great that Google is pre-empting a problem that’s bound to become more prevalent as beacons are used as IoT devices. Eddystone-EID is an alternative to UUID rolling as provided by a few platform providers such as Estimote.
From what we understand, Eddystone-EID relies on a “resolution service such as Proximity Beacon API” that implies it currently needs a working network connection and http – that many indoor scenarios lack. It will be interesting to see how reliable and quick this will be. A key metric for many of our clients is beacon detection time and anything that slows this down or makes it less reliable will be impractical. Let’s hope Google has had thoughts on how to make the ‘resolution service’ local to the phone. At the moment, the implementation seems to require cloud resolution of ephemeral ids. However, the research paper, on which Eddystone-EID is based, does mention an Extension: Offline Resolution by Non-Owners.
Google also announced a new Eddystone Configuration GATT Service . At the moment, each beacon manufacturer needs to write an app that allows their beacons to be configured. A common Configuration GATT Service means one app could be used to configure all beacons. However, things won’t be so simple.
It’s our expectation that it will take a long time before Eddystone-EID and the Eddystone Configuration GATT Service become commonly available. As with Eddystone itself, many beacon manufacturers will probably delay implementation until they see there’s a market demand for these new capabilities. Google tellingly mentioned 15 manufacturers, ‘will’ rather than ‘do’ support these new features. Even now, most beacons don’t support Eddystone-TLM yet.
Meanwhile (and even into the future), there will be a mix of old and new beacons that will complicate comprehension thus further. Also, all this only covers Eddystone. iBeacon beacons will still need their own individual manufacturer configuration apps and as beacons supporting Eddystone tend to be a subset of those supporting iBeacon (rather than the other way around) it’s likely we will still have many different configuration apps.
Looking top-down, most rollouts still use iBeacon rather than Eddystone so these new initiatives are likely to have little short-term affect. However, with Eddystone gaining features faster than iBeacon, given time, it might tip the balance and help it become more popular.