Live data from Hacker News

Apple and Google partner on Covid-19 contact tracing technology

apple.com

271–280 of 484 posts

Re: Apple and Google partner on Covid-19 contact tracing technology

#271

Contact tracing has a time and place, and it's early in isolated outbreaks. The cat is out of the bag at this point and thinking we're going to contact trace our way to safety is a false promise. You'd have to be naive and short-sighted to accept their pinky-promise of privacy-first in this context.

That's literally what both Iceland and South Korea rely on. Neither country has SIPs (Iceland even has primary schools open) and the peak is behind them.

(Iceland's outbreak is at about the same infection rate as the Bay Area if you estimate with hospitalizations/deaths. Daegu was significantly worse than the Bay Area per capita).

Re: Apple and Google partner on Covid-19 contact tracing technology

#272

There is surprisingly little discussion about the actual spec here. It looks really good to me! - Advertisements change every 15 minutes, are not trackable unless keys are shared. - The only central bit is a repository of "infected" daily keys. - No knowledge about contacts is shared with a central authority. Nothing is shared unless you are infected and decide to share your keys, which are only valid for one day. I…

> I don't see how you could have a real argument against this unless you are a privacy extremist. The authors of DP-3T (which seems quite similar to this spec) have a huge list of privacy caveats in their whitepaper [1], in section "5.4 Summary of centralised/decentralised design trade-offs". I haven't seen any analysis on how the Apple/Google spec prevents those problems. [1] https://github.com/DP-3T/documents/raw/m…

The Apple/Google design drops this DP-3T requirement:

2) Enable epidemiologists to analyse the spread of SARS-CoV-2

So anything in that table with epidemiologists is gone.

The remaining caveats are pretty boring:

To do so, the attacker uses strategically placed Bluetooth receivers and recording devices to receive EphIDs. The app’s Bluetooth broadcasts of non-infected people and infected people outside the infectious window remain unlinkable.

...

On the other end, a proactive tech-savvy person can abuse any proximity tracing mechanism to narrow down the group of individuals they have been in contact with to infected individuals. To do so they must, 1) they keep a detailed log of who they saw when. 2) they register many accounts in the proximity tracing system, and use each account for proximity tracing during a short time window. When one of these accounts is notified, the attacker can link the account identifier back to the time-window in which the contact with an infected individual occurred.

So, yeah, these vulnerabilities still exist and have been pointed out on this thread... but I find it hard to care about these at all.

Re: Apple and Google partner on Covid-19 contact tracing technology

#273

Earlier quoted context omitted.

For starters, I would assume that most people's daily rotating keys could easily be fingerprinted based on identifiable patterns of movement that could be picked up by any number of municipal devices people come into contact with throughout the day. In order for contact tracing to work as advertised, each person's device has to keep a log of daily ids that they contacted that has a TTL of at least a few weeks. That m…

The Daily Tracing Key cannot be "easily fingerprinted" since it does not leave the device (see page 5). Your LE threat model seems like grasping at straws, the majority of users already have location services enabled anyway, people breaking the law would have to change exactly nothing from the common practice of not bringing your phone when committing crimes.

I miss-spoke. I meant to say the rolling proximity identifier could be tracked and fingerprinted.

Furthermore, it's not the same as a phone's location implicating you in a crime. It's a persistent log of your in-person social network that can be reverse engineered every time you get arrested or go through customs at the airport.

Re: Apple and Google partner on Covid-19 contact tracing technology

#274
This is a good thing, and I think in the absence of this solution we would see intrusive solutions backed by governments and mandated by law. I do have two questions:

Is there a plan to verify test results? Are public health authorities in small countries/regions expected to build and maintain an app and a server from scratch?

Re: Apple and Google partner on Covid-19 contact tracing technology

#275

Earlier quoted context omitted.

They're not the same and I think Google/Apple's is a bit better. In DP3T the infected person shares a single daily key from which all future daily keys can be derived. In Google/Apple's each daily key is HKDF derived from a master key and they are not linkable. Infected people share the relevant daily keys from their infection period. THat's more data to push around, but it is better for privacy. It means that contac…

> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Edit: This actually turns out to be correct, but your conclusion: > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infec…

I see: SK_(t) = H(SK_(t-1)), where SK_(t) is the secret key for day t.

This seems to align with the statement that knowing the key for one day (i.e. once it is uploaded following diagnosis) allows one to derive all future keys. Is there another section I am missing?

Edit: clarified that daily keys are shared post-diagnosis, to trace prior contact.

Re: Apple and Google partner on Covid-19 contact tracing technology

#276

There is surprisingly little discussion about the actual spec here. It looks really good to me! - Advertisements change every 15 minutes, are not trackable unless keys are shared. - The only central bit is a repository of "infected" daily keys. - No knowledge about contacts is shared with a central authority. Nothing is shared unless you are infected and decide to share your keys, which are only valid for one day. I…

In widely distributed and important spec like this it may be useful to look for what is conspicuously absent or unstated, rather than simply reading the precise positive language.

To my mind this phrase under 'Privacy Considerations' in the Cryptography Specification stands out:

"A server operator implementing this protocol does not learn who users have been in proximity with or users’ location unless it also has the unlikely capability to scan advertisements from users who recently reported Diagnosis Keys."

That phrase explicitly mentions that server operators cannot learn about user proximities.

What I reckon may be unstated there is that it could be possible for adversaries with sidechannel / network monitoring capability to learn those kind of details about users (i.e. internet, cell data, and other data network operators).

If such a side door did exist, it would seem in the public interest to be aware of the scope of the availability of that data, especially given the potential (physical, social) vulnerability and risk of those users.

I'd also like to be proven wrong about the possibility of such sidechannel attacks by anyone who understands the spec in more detail.

[1] - https://covid19-static.cdn-apple.com/applications/covid19/cu...

Re: Apple and Google partner on Covid-19 contact tracing technology

#277

Earlier quoted context omitted.

> I don't see how you could have a real argument against this unless you are a privacy extremist. The authors of DP-3T (which seems quite similar to this spec) have a huge list of privacy caveats in their whitepaper [1], in section "5.4 Summary of centralised/decentralised design trade-offs". I haven't seen any analysis on how the Apple/Google spec prevents those problems. [1] https://github.com/DP-3T/documents/raw/m…

The Apple/Google design drops this DP-3T requirement: 2) Enable epidemiologists to analyse the spread of SARS-CoV-2 So anything in that table with epidemiologists is gone. The remaining caveats are pretty boring: To do so, the attacker uses strategically placed Bluetooth receivers and recording devices to receive EphIDs. The app’s Bluetooth broadcasts of non-infected people and infected people outside the infectious…

> The app’s Bluetooth broadcasts of non-infected people and infected people outside the infectious window remain unlinkable.

The group of non-infected people is getting smaller and smaller. The infectious window is presumably weeks long (times the number of diseases this system will track). These risks don't seem that easy to downplay, even before we get into the "security concerns" section.

Re: Apple and Google partner on Covid-19 contact tracing technology

#278

Earlier quoted context omitted.

They're not the same and I think Google/Apple's is a bit better. In DP3T the infected person shares a single daily key from which all future daily keys can be derived. In Google/Apple's each daily key is HKDF derived from a master key and they are not linkable. Infected people share the relevant daily keys from their infection period. THat's more data to push around, but it is better for privacy. It means that contac…

> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Edit: This actually turns out to be correct, but your conclusion: > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infec…

GP is correct, but it doesn’t matter much. They were referring to daily key, not the EphID (RPI in the Apple/google spec).

DP3T specifies that SK _t = H( SK _{t-1} ). In that design, you share the daily key from when you started to become infectious, and then the subsequent ones can be computed. Then you go into quarantine, stop being infectious, and (see spec) create a new random daily key going forward (or delete the app).

In the A/G proposal, daily keys can’t be correlated, and you share the daily key for each day you were infectious.

The end result seems pretty much the same for me.

Re: Apple and Google partner on Covid-19 contact tracing technology

#279
post #3

Google announcement: https://www.blog.google/inside-google/company-announcements/...

There's a presentation linked at the bottom which explains in brief how contact tracing will work:

https://blog.google/documents/57/Overview_of_COVID-19_Contac...

Apple and Google should have included the chart in their announcements, IMO. It illustrates the process in a way that's easier to understand than text alone.

Re: Apple and Google partner on Covid-19 contact tracing technology

#280
post #278

Earlier quoted context omitted.

> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Edit: This actually turns out to be correct, but your conclusion: > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infec…

GP is correct, but it doesn’t matter much. They were referring to daily key, not the EphID (RPI in the Apple/google spec). DP3T specifies that SK _t = H( SK _{t-1} ). In that design, you share the daily key from when you started to become infectious, and then the subsequent ones can be computed. Then you go into quarantine, stop being infectious, and (see spec) create a new random daily key going forward (or delete t…

The difference is that you can continue tracking a person indefinitely, even after they are no longer infectious. It requires explicit user action to avoid that (opt-out vs opt-in).
Post reply on HN