Hacker News Reader

Comment by petedoyle | Hacker News Reader

This is huge. A limiting factor has been iOS not being able to (on purpose, for privacy, and battery life) do BLE scanning (edit: or advertising, thanks Slartie) in the background. I imagine this will enable that for specific apps, and I have high confidence privacy will be well-implemented by Apple's involvement (edit: see tastroder's comment for technical docs). Having a single, well-designed spec for Bluetooth advertisement will prevent a world where there are different contact tracing apps, none of which can see each other. Doing this at the platform level will enable enough density of installs to make this effective at scale.

View on HN

The even bigger obstacle was apps not being able to broadcast beacon signals while they are in background. You could devise workarounds for the scanning problems, but this particular problem of having to be able to continuously advertise your beacon signals did not have a workaround AFAIK. The "workaround" was requiring people to have the tracing app active in foreground all the time, which obviously sucks from a UX perspective and means nobody will do it.

That's why this involvement is really huge and welcome! And besides clearing out existing arbitrary API limitations, Apple's involvement in potential protocol design for such tracing technology is a welcome addition in my view as well, because in contrast to Google, Apple at least earned a modicum of trust when it comes to putting the privacy interests of their customers first.

Also excited because they can likely push both advertisement and scanning into the BLE chips themselves, letting the rest of the system (CPU, etc) sleep. Big win for battery life.

You can, in fact, do BLE scans in the background on iOS. It's tricky and requires some workarounds, like basically everything related to background tasks in iOS.

Source: Providing apps with that functionality.

Which workaround you use?

While background scanning is limited you can key off iBeacon devices via the location framework. This allows your app to wake up when certain devices are near.

Thinking this might be different. I've been curious what the BLE packet structure might look like. Looks like there's 16 bytes of unique id needed for the "Rolling Proximity Identifier" in the spec. Typically iBeacon would have 16 bytes of unchanging UUID, and 4 bytes that can change: https://support.kontakt.io/hc/en-gb/articles/201492492-iBeac....

Could probably flip it to be a 4 byte prefix (to identify this packet for contact tracing), followed by 16 bytes of the Rolling Proximity Identifier, but not sure if the underlying hardware (the BLE chips) can do low-power matching on a pattern like that. Something only Apple and Google could make work, so this is exciting.

(Or, it could be iBeacon to wake, then making a connection to fetch the Rolling Proximity Identifier. Though, in my experience, not requiring a connection will be more reliable in practice, especially for Android.)

Exactly, this is an important narrative. I've read the spec and I'm really positive (hmm). This could be a game-changer for dealing with the pandemic in a systematic way.

Of course you can do BLE scanning in the background on iOS. It works much better than Android and is very reliable.

they're short term ids, setup to explicitly prevent linking to any other hardware characteristics, etc

Reply on news.ycombinator.com