[hn_throwaway_99]

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 lot (most?) testing these days is from private providers.

[Reelin]

Why wouldn't the patient provide their framework info (if they so chose) at the time of sample collection? Then the medical authority could report it to the local government on the patient's behalf in the event of a positive test. Other end users then decide which (if any) "reporting authorities" to pull data from and check against.

This also seems to address Moxie's concern about public location data being necessary (unless I've missed something). If I only pull all the positive tests from my local county or state, that should hopefully be a small enough dataset to be manageable even on fairly resource constrained low end devices.

[ehsankia]

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.

[Reelin]

> 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 and require whatever authentication they'd like for it. A local government, a hospital, the Red Cross, etc. The framework becomes nothing more than a decentralized protocol that can potentially even be repurposed for other novel uses.

For the decentralized approach, bear in mind that there's nothing preventing a third party from hosting and managing a distribution server on behalf of someone else. So (for example) the CDC could host a server (and handle authentication) for a state or county government that didn't feel up to the task.

Another example, say the local hospital has their own database (possibly hosted by the state or Google or whoever). They can feed their (authenticated, locally collected) data to a local authority (the city or county), which only needs to accept data from trusted institutions (ie all the hospitals in the area). They can in turn feed this inherently trustworthy data to a state system, and so on. If each entity in this hierarchy makes their dataset publicly available, then users can independently decide which datasets are relevant to them (perhaps they traveled recently?) and check them on a daily basis.

[ehsankia]

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.

[fabian2k]

The media reports about the german version of this include getting a one-time code from the health authorities that you have to enter into the app to mark yourself as infected.

As far as I understand, the proposal from Google and Apple is about the underlying framework, but you can set up additional controls a level above in the app and the server infrastructure. So it's likely by design that it doesn't address the issue as the solutions to ensuring only verified cases can trigger alerts must be specific to the local circumstances.

[VectorLock]

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."

[krcz]

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.

[Reelin]

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 access to the outside world.

[lasdfas]

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.

[Reelin]

In an open model, the extent to which abuse is possible would be determined entirely by the authentication requirements (or lack thereof) imposed by the entity operating the server the user selected. That being said, another commenter linked to a set of specifications (https://news.ycombinator.com/item?id=22836871) which seem to indicate that (at least on iOS) the data source is determined entirely by an app that the user chooses to run on top of the framework.

[tastroder]

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.

[krisoft]

> in Germany, like many other European countries, this becomes a non-issue.

What do you mean by that? The protocol, as published, doesn’t have a role for the central authority. Even if the German state knows that mrSick tested positive and mrPrankster did not, how would the diagnosis server reject the keys published by mrPrankster? They are by design resistant to de-anonymization. In fact the German state can’t even know if a specific key reported as positive for covid belongs to a german resident or not.

[tastroder]

My main point is that the protocol as published is completely unrelated to the prank scenario, that's simply out of scope. The protocol does not prescribe who is able to report certain Diagnostic Keys that have tested positive. In a centralised deployment, that is likely under the current German reporting chain for infectious diseases, mrPrankster has no capability to falsely report a positive test result. You have a trustworthy central stakeholder that can provide a ground truth. At the very least it could be designed to be revocable (a step that would be necessary for false positive test results anyway).

[krisoft]

> “simply out of scope” (of the protocol)

But it is in-scope for the framework, would you say not? If we want to evaluate the privacy aspects its important to understand the whole system.

First you said it’s a complete non-issue, and now you say actually we need to tweak things here and there in a serious fashion. That’s fine.

> “The protocol does not prescribe who is able to report certain Diagnostic Keys that have tested positive.”

It heavily implies though that it is a decision by the user. It says the keys never leave the phone, it also says that the keys with the users consent gets uploaded. Maybe what they actually meant is that the keys get uploaded alongside a signed cert of the local health authorities. Or that when you get tested the health authorities extract something from your phone and they themselves report using that. But it very much sounds like this is also a very important part of the protocol then.

[tastroder]

I don't feel like I'm contradicting myself there. Yes, the scenario of pranks would be in scope for the overall system or framework, sure. Pointing it out as a leakage / flaw of the proposal by Apple and Google is counterproductive though in my mind since a) it can be easily tackled in those other parts of the framework and b) we don't even have a specific single framework to talk about on that particular matter so it makes little sense to spread FUD about it.

> But it very much sounds like this is also a very important part of the protocol then.

That might be arguing semantics honestly, the protocol as published suggests restrictions that are beneficial to the end user's privacy, sure. It otherwise does not dictate any particular government, country, or region where the keys are supposed go in case of a positive test results or how they should be verified / handled. That in my mind would again fall into the category of the overall framework that we do not have. What we have is a manual system that is ineffective and hard to scale. What this adds is a privacy aware method to tackle a tiny part of a digital supplement to this manual system.

That's why I'm so insistent on the in scope / out of scope, sorry if that comes across harsh but I don't feel it's particularly productive to construct hypothetical overall threat models based on this very limited technical proposal. Scenarios such as malicious distributions of tests are much better looked at in the context of a full framework proposal. I can come up with dozens of threat models that include unrelated things, that doesn't mean it's particularly responsible to share those imho. We're the technical audience that can grasp this, pointing out potential shortcomings is fine but they should be grounded in reality.

[JMTQp8lwXL]

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.

[sneak]

It doesn’t need to be everyone involved in opting in to tracing, or everyone notified to comply with the self-isolation recommendations to reduce the r0. It works even with only partial penetration of the populace.

[awinter-py]

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