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

21–30 of 113 posts

Re: First look at Apple/Google contact tracing framework

#21

Post by krcz »

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…

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.

Re: First look at Apple/Google contact tracing framework

#22

Post by yellow_lead »

daenz wrote: post #16

An important question here is: will this framework go away once the pandemic is over? Something tells me it won't.

I'm sure we'll be told how "it really made a difference" regardless of if it did, and how "we'll need it for the next one."

Re: First look at Apple/Google contact tracing framework

#23

Post by VectorLock »

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…

Looking at the Google doc it looks like they're going to restrict it to some "medical authorities"

"In order to be whitelisted to use this API, apps will be required to timestamp and cryptographically sign the set of keys before delivery to the server with the signature of an authorized medical authority."

Re: First look at Apple/Google contact tracing framework

#25

Post by femto113 »

The system doesn't need to ship every key to every phone, much more compact structures like Bloom filters could be used instead. If we assume about 1000 positives per day and each positive uploading 14 days of keys at 4 keys per hour that's a bit over 1 million keys per day. A Bloom filter with a false positive rate of 1/1000 could store that in about a megabyte. Phone downloads the filter each day and checks its observed keys, and only needs to download the actual keys if there's a potential match.

Re: First look at Apple/Google contact tracing framework

#26

Post by krcz »

> So first obvious caveat is that this is "private" (or at least not worse than BTLE), until the moment you test positive. > At that point all of your BTLE mac addrs over the previous period become linkable.

Linkable over the period of 14 days. Or even linkable during one day - each day means new key, so linking between these might be attempted only on basis on behavioral correlations.

What to do with such data? Microanalysis of customer behaviors? It won't be possible to use such data for future customer profiling, as it won't be possible to match the history with identifiers after the infection. This data is practically worthless.

Re: First look at Apple/Google contact tracing framework

#27

Post by VectorLock »

femto113 wrote: post #25

The system doesn't need to ship every key to every phone, much more compact structures like Bloom filters could be used instead. If we assume about 1000 positives per day and each positive uploading 14 days of keys at 4 keys per hour that's a bit over 1 million keys per day. A Bloom filter with a false positive rate of 1/1000 could store that in about a megabyte. Phone downloads the filter each day and checks its obs…

Nothing prevents the user from pushing the checking to some trusted service as well, if they so choose. If they trust the service then they'd upload their seen keys to a checking service, rather than downloading the whole set of diagnosis keys. The important part is the decision is in their hands.

Re: First look at Apple/Google contact tracing framework

#28

Post by VectorLock »

redis_mlc wrote: post #10

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

I think thats what makes it even more important to have something like this. That way people who aren't presenting symptoms, and can't get tested, can find out if they have contacts and then quarantine. And testing will get more and more pervasive as that technology develops.

Re: First look at Apple/Google contact tracing framework

#29

Post by krcz »

femto113 wrote: post #25

The system doesn't need to ship every key to every phone, much more compact structures like Bloom filters could be used instead. If we assume about 1000 positives per day and each positive uploading 14 days of keys at 4 keys per hour that's a bit over 1 million keys per day. A Bloom filter with a false positive rate of 1/1000 could store that in about a megabyte. Phone downloads the filter each day and checks its obs…

You need just one key per day, 15-minutes ids can be generated based on this. Bloom filter might be still useful though.

Re: First look at Apple/Google contact tracing framework

#30

Post by JMTQp8lwXL »

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…

It also assumes that if you get a notification of having been near a COVID positive individual that you'll be prudent enough to self isolate.
Post reply on HN