Google adds a secure beacon feature to its Eddystone beacon format to enable private interactions
Ron Amadeo / Ars Technica :
Context & Ripple Effects
Eddystone began in mid-2015 as Google's open-source, cross-platform alternative to closed Bluetooth LE beacon formats, and by February 2016 Chrome 49 on Android was set to surface notifications from nearby smart beacons as part of an IoT research pilot. That rollout exposed the format's core tension: a beacon that broadcasts a fixed identifier to every passing phone is also a tracking beacon.
This addition answers that directly by giving Eddystone a secure mode built for private interactions, turning the open format launched last July into something deployers can use where the broadcast itself must not leak identity.
First-order effects
- Beacon deployers building on Eddystone can now run proximity experiences where only parties registered with Google can resolve the transmitted identifier, instead of exposing one static, publicly scannable ID.
Second-order effects
- With Chrome's Android beacon notifications pending and privacy now addressable inside the open format itself, rival proprietary beacon stacks lose their main differentiator — cross-platform reach versus controlled identity — forcing them to compete on ecosystem rather than on the raw protocol.
Third-order effects
- The move fits a recurring Google pattern of pushing cryptographic identity out to the edge: months later the company shipped the Verified Access API to cryptographically validate Chrome OS device identity for enterprises, and years on it pledged E2EE for Google Authenticator after researchers flagged unencrypted 2FA sync — proximity infrastructure, device fleets, and auth flows converging on the same assumption that any signal touching an untrusted radio needs crypto built in.
The trend: Proximity and IoT signaling is moving from plaintext broadcasts toward cryptographically protected identities, with platform vendors like Google baking the trust layer into open formats themselves.