Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First look at Apple/Google contact tracing framework

twitter.com

Post reply on HN
Print view View original

51–60 of 113 posts

Re: First look at Apple/Google contact tracing framework

#51

Post by lasdfas »

Reelin wrote: post #38
krcz wrote: post #21

Earlier quoted context omitted.

Don't these providers need to be registered somewhere? It should be easy to reach them and provide with either code generator software or even printed one-time codes for database addition.

Why use a centralized model? Allow users to subscribe to a data source so that any entity can push their own dataset. This is also important because it keeps the framework usable under a variety of adverse and unusual circumstances. An aid organization operating in a disaster zone or impoverished area could make use of such a framework without needing permission from a higher authority or even reliable internet acces…

Because it can abused. The easier you make it upload, it also allows bad actors to upload invalid data to cause people to go into quarantine unnecessarily. It only works well if you can trust the data, so I think it should error on the side of validating the data instead of openness.

Re: First look at Apple/Google contact tracing framework

#52

Post by ehsankia »

Reelin wrote: post #48
ehsankia wrote: post #45

Earlier quoted context omitted.

My understanding too was that there was a middleman involved in collecting and distributing the keys, to avoid people spamming the system. You want to be 100% sure it's a positive, and not put the trust in the user. Otherwise random people could just say they have it. The local government would have to submit the keys as you mention and act as moderators for that region.

> The local government would have to submit the keys as you mention and act as moderators for that region. There's a big difference between a centralized and decentralized model here. * Centralized, there's a single (or only a few) worldwide APIs that you need approval to work with. This also hinders interoperability of different end-user app implementations. * Decentralized, anyone can set up a distribution server a…

It doesn't really matter who hosts the database. I specifically was talking about middleman, as in someone who confirms the person is infected and then takes care of passing 14 days of keys to the server. Where the server is isn't really relevant here, just that the end-user doesn't have direct access to it.

Re: First look at Apple/Google contact tracing framework

#53

Post by lilyball »

est31 wrote: post #18
lilyball wrote: post #14

Earlier quoted context omitted.

> My guess to why Google/Apple didn't introduce rough location (like US state or county) into the system was to prevent journalists from jumping onto that detail and sensationalizing it into something it isn't (Google/Apple grabbing your data). Both companies operate the most popular maps apps on the planet as well as OS level location services that phone home constantly so they are already in possession of that data…

Do you mean this? > To protect user privacy, this data is associated with an identifier that rotates at the conclusion of a trip, not with the user’s Apple ID or any other account information. Rotating the ID at the conclusion of the trip makes it harder for Apple to piece together a history of any user’s activity over time. https://www.apple.com/privacy/docs/Location_Services_White_P... I think it's a nice gesture,…

What you quoted is specifically about traffic collection. I don't know where to find a definitive source on this now, but Apple used to have a marketing page that said

> When you use Apple Maps, your route from A to B is fragmented into scrambled sections on Apple servers because nobody else should know your entire route. Not even us. In fact, we don’t even know who requests a route.

My recollection was that the device itself sends multiple requests in chunks to get the route, but I don't know if this is accurate or if it's just fragmented on the server prior to any data retention.

In any case, the point is that Apple very intentionally discards data that can be used to track you, and anonymizes what they do retain. While yes, it's very likely that Apple could figure out where you are if your device is set to use Apple services and they wanted this info, they've set up their services to make it as difficult as possible for them to figure this out.

Re: First look at Apple/Google contact tracing framework

#54

Post by olliej »

Let's just answer these

* Use stationary beacons to track someone’s travel path

Doesn't work because there's no externally visible correlation between reported identifiers until after the user chooses to report there test result.

* Increased hit rate of stationary / marketing beacons

Doesn't work because they depend on coherence in the beacons, and the identifiers roll every 10 or so minutes. Presumably you'd ensure that any rolling of the bluetooth MAC also rolls the reported identifier.

* Leakage of information when someone isn’t sick

The requests for data simply tell you someone is using an app - which you can already tell if they're using app.

The system can encourage someone to get tested, if your app wants to tell people to get tested, then FairPlay to that app (though good luck in the US).

- Fraud resistance

Not a privacy/tracking concern, though I'm sure devs will have to do something to limit spam/dos

Re: First look at Apple/Google contact tracing framework

#55

Post by olliej »

est31 wrote: post #9

Note that years ago, Moxie has studied a similar problem of how to let users know if their contacts use Signal or not without uploading the whole address books like e.g. WhatsApp does [0]. It's similar because in both instances you want to "match" users in some fashion using a centralized service while keeping their privacy. He ruled out downloads of megabytes of data (something that the Google/Apple proposal would i…

Increasing the lifetime for what are currently "daily keys" reduces the precision of the contact reporting - e.g. your example of a week means that a positive user would need to report at least 3 weeks of keys, so someone can now do correlation over 3 weeks instead of X days.

There's no inclusion of location data as that has no value - the only thing that this protocol cares about was whether you were in the vicinity of someone who has tested positive for cover-19, and so suggest you get tested. Knowing where you are/were has no value for that purpose.

Re: First look at Apple/Google contact tracing framework

#56

Post by awinter-py »

hn_throwaway_99 wrote: post #20

Regardless of the technical issues with this, I think the "prank" issue Moxie brings up is much more serious. We've already seen the phenomenon of "Zoom bombing", I can imagine "tracer bombing" would be a much more serious issue. The only way I could see this working is that if when you enter a positive result you have to enter some sort of secret key from the testing authority, but that's totally not tenable given a…

singapore centralized the reporting with TraceTogether / bluetrace, and call out fraud risk in their whitepaper

Re: First look at Apple/Google contact tracing framework

#57

Post by tshaddox »

grandmczeb wrote: post #11
redis_mlc wrote: post #10

Can somebody address the issue that we have almost no testing ability in the US?

We’re testing like 140k per day with over 2.5M tests total. Obviously more would be better but that’s hardly “almost no testing ability.”

It’s very close to “almost no testing ability” if you want to routinely test people who don’t have symptoms so that people can actually leave their homes sometime before a vaccine.

Re: First look at Apple/Google contact tracing framework

#58

Post by tastroder »

Reelin wrote: post #40

Is there an official document somewhere? Also, how does it compare to DP-3T? ( https://github.com/DP-3T/documents ) ( https://ncase.me/contact-tracing/ ) Edit: Apple's preliminary specification was linked in another HN comment. ( https://covid19-static.cdn-apple.com/applications/covid19/cu... )

More technical links in here: https://news.ycombinator.com/item?id=22836871

Re: First look at Apple/Google contact tracing framework

#59

Post by tastroder »

hn_throwaway_99 wrote: post #20

Regardless of the technical issues with this, I think the "prank" issue Moxie brings up is much more serious. We've already seen the phenomenon of "Zoom bombing", I can imagine "tracer bombing" would be a much more serious issue. The only way I could see this working is that if when you enter a positive result you have to enter some sort of secret key from the testing authority, but that's totally not tenable given a…

Many of the issues moxie brings up either don't apply universally or are unrelated to the part this specification touches upon.

Maybe it helps to bring up a non US perspective here: in Germany, like many other European countries, this becomes a non-issue. We have central authorities that can greenlight a positive test result or invalidate wrong results, immediately making the prank argument completely hypothetical. The question as to why this should be centralised is easy, because it already is. I'd honestly expect the reporting chain in the US not being to dissimilar from this, at least at the state level.

It's also important to note that all of this only supplements the existing, regularly manual, workflow of contact tracing. A very laborious and error prone task, especially in regions with a large number of infections. These techniques take a massive load off of a certain part of the health system that is notoriously underdeveloped because it's not really needed in this quantity in normal times.

Re: First look at Apple/Google contact tracing framework

#60

Post by antpls »

Again, this solution _cannot_ work and it is a _threat_ to a permanent loss of privacy.

This is like the government and the adtech companies sleeping in the same bed, without any other power opposition in the balance.

1) The "solution" is created by a monopoly of 2 american private corporations.

2) It can only work reliably if everyone wear an (Apple or Android) phone at all time, and consent to give data

3) You are not necessarily infected if you cross an infected in the street at 5 meters. This will have too many false positives and give fuzzy information to people

4) It doesn't help people who are infected and _dying_

It just _doesnt make sense_. To me, it looks like electronic voting, but worse. No one can understand how it works, beside experts.

Today it is reviewed, but then the app will be forgotten and updated in the background with "new features" for adtech.

We are forgetting what we are fighting : a biological virus. All effort should go toward understanding the biological machinery of the virus and the hosts, in order to _cure_ the virus. We should be 3D printing ventilators, analysing DNA sequences, build nanorobots and synthesis new molecules.

Post reply on HN