Google’s new beacon privacy pushes Eddystone deeper into the web experience
One emerging element of the new-look web operating system is the beacon, and Google’s Eddystone project is a good example of a technology which, though open source, it controls, and which handles an important element of user behavior behind the scenes, regardless of the individual OS. The Eddystone beacons currently run with Android and iOS but could be adapted for any platform, and more importantly, they can broadcast messages to smartphones through the Chrome browser without the need for a specific app. Support for Eddystone is built into the ‘Nearby’ API, available to developers from Google Play Services, or from GitHub under the Apache 2.0 licence.
The latest addition to Eddystone is ephemeral ID (EID) frames, which will allow developers to create better protected applications that use the proximity technology. Eddystone has received strong support from the industry since its launch last July – with the new features already being supported by Gimbal, Blesh, Sensoro and a Samsonite briefcase.
Currently, the beacon ecosystem is fragmented and many individual beacons require their own related apps. But if the beacon becomes a central element of the OS, the door would really be opened to developers. It would remove the need to download so many apps to handle each interaction, and more importantly, it would provide an option in the system settings to toggle on/off beacon functionality.
The beacons work by pushing frames to listening devices, typically smartphones. The new EID function allows the beacon to communicate directly to its owner without letting the outside world know that a communication has taken place. Without any identifiable data being broadcast, thanks to its 128-bit AES encryption, the idea is that the two devices can remain shielded from whomever might be trying to intercept those communications.
Ephemeral refers to the software function that randomizes eight digits of the EID, scrambling the numbers on a timed basis that can be scheduled to change every second, or up to every nine hours. When the pairing is initially established between the beacon and the owner, they share a key that generates the scrambling, so that they can communicate once the EID starts transforming. This means that intercepted EIDs will expire if they are captured, which should make the system safer – assuming no one can break that initial key.
Privacy like this would be a major benefit to other applications, like those involving the smart home or a connected workplace, as those types of transmissions will need to be protected.
The time synchronization service is currently provided by Google, although adopters of the open source platform would be able to code their own if required. In addition to the new EID frame, a 128-bit Universally Unique ID (UUID) frame lets the beacon identify itself to the app on the smartphone. This interaction most commonly used by beacons aiming to provide location data to an app that triggers a behavior on the phone. Examples would include in-store positioning apps that would push contextual info to the user via their smartphone.
The UUID frame is limited by the requirement for the app to know to listen out for that specific UUID to trigger an action, which makes its usage rather one-dimensional. With the URL frame, the beacon can broadcast a URL to the in-range devices, which then points the user to a specific web-page. That URL can be configured to match the specific beacon, so that a user can follow the URL to learn about the location the specific location – with examples being weather station feeds, mass transit timetables, or traffic alerts, which are more suited to quick interactions.
The last frame type is more for the beacon’s owner or maintainer. Called Telemetry Mode, this frame pushes the usage and battery data from the beacon to the device that will backhaul that information to a central dashboard.