I don't quite understand why Apple and Google are releasing an API instead of a single system application.
This is going to create a gigantic mess as governments with limited software development competence slowly release incompatible and partially broken applications, while Apple and Google could just deploy a single solution via a system update.
Also, it's much easier to make it mandatory if it's a system app (and obviously it needs to be mandatory to be useful).
> and obviously it needs to be mandatory to be useful
That's not only not-obvious, I don't even believe it's true. Contact tracing is useful even if only 50% of the population uses such a system. (Remember, not everyone even has a smartphone.)
It would be business suicide to force such a choice on users. I'd throw my iPhone into the nearest river if a system update forced it upon me, even if I trust the system and would have opted in.
The governments each want their own app so data isn't shared with other governments, so either Apple sends out 100+ versions of an iOS update, or, they expose an API and let the governments ingest it into an app that they control, which adds privacy for the user by making it opt-in.
But no data is shared with the government, so there isn't any data that gets shared with "other governments".
All that is shared is a randomly generated key that can only be used by other smartphones to determine if any of the ids that they have collected come from the key.
The only time your keys are uploaded, is when you are infected. The assumption is that if you are infectious certain privacy needs to forgo to protect others.
In fact this is over simplification. The only key that will be uploaded is partial of the daily tracing key (called Diagnosis Key in the specification).
Most importantly, there's no location or timestamp involved or needed. Once this Diagnosis Key is uploaded, every client (anyone who wants to know if they are potentially infected) will periodically download the batch and see if your phone has seen any of the Rolling Proximity Identifiers, and when.
Your use of the word partial could lead to confusion. The Diagnosis Keys are a subset of the Daily Tracing Keys for the days youre contagious. You then upload these Daily Tracing Keys and associated day numbers.
Also you are incorrect about the involvement of a timestamp. The protocol uses DayNumbers to track the specific day a Daily Tracing Number was used.
In terms of privacy, small-scale adversaries can deanonymize infected users that have uploaded their [keys by keeping logs] of and limiting who they have come in close contact with.
On a large-scale, adversaries in control of large Bluetooth receiver networks (such as cities performing traffic analysis) can now track the movements of individual infected users over the course of a day. One could argue that this is already being done to track anyone with bluetooth enabled.
In addition, the process of uploading to the backend server could alert adversaries monitoring your network that you (the device using your IP address, uploading to the server IP address) have tested positive for the virus.
I recommend that you look at other contact tracing protocols that circumvent some of these issues by decrease or eliminating the linkability of identifiers, allowing users to censor records uploaded, and encourge the use of network-anonymization.
Right, and there’s no possible abuses this could be used for, of course — no way this data can ever be deanonymized, right? What I object to is putting this all into an automated system for everyone, infected or not. If there’s a way to generate a diagnosis key, there’s a way to spoof it, and that can be used to infer contacts for the non infected.
You may have a point when it comes to the infected, but even then, giving Apple or Google this type of information is putting far too much trust and power into too few hands.
I don't understand it either but that doesn't lead me to leap to a conclusion that Apple's and Google's expert cryptographers and system architects don't know what they are doing. I instead blame my own current ignorance, and look forward to gaining more understanding.
But yes as a user, personally I'd prefer to use and trust an app supplied by my OS provider, mandatory or not, built in to the OS or not (and plenty of Apple apps are optional after-the-fact downloads, so it need not be a forced download unless there are reasons for that that overcome all the negatives).
The system is intended to be annonymous and can't have any user registration or authentication.
How can you validate when someone report they are infectious, the Diagnostic Key is indeed from a legit iOS device? If you can't validate it, this can be easily abused (attacker generate a huge list of Diagnosis Keys and upload, claiming to be infected, and causing a wave of public panic)
My understanding is that there must be some internal/proprietary API from Apple that they are using to validate this, and there's no other vendor except Apple to develop such an API to mitigate the abuse risk.
This is misguided. As you note, the system is anonymous and can't have any registration or authentication. Moreover, an Apple or Google specific API for validation would prevent interoperability of other (future) implementations including any free and open source (ie actually verifiable) ones.
Therefore, all authentication must be done on the receiving end by deciding which data sources to trust. This should be fairly straightforward because when a healthcare provider performs testing they are in a position to collect any keys from you at the same time. They are then the ones trusted to accurately report keys, which should be fine since we already trust them both to accurately report test results and to safeguard patient privacy.
Importantly, such a decentralized design allows for cooperative framework implementations, competing app implementations, and multiple data sources. Google or Apple could run a data server, your local government could run a data server, etc. Even more interestingly, such a framework could be repurposed for other less critical uses later as a form of privacy-preserving mutually opt-in contact discovery. Non-essential use of the framework might even ensure that people keep it running all the time, so that the data is ready and waiting the next time a novel pathogen appears.
What you describe is not in conflict with the Apple/Google proposed solutions. Or rather, it (the part of reporting and aggregating on the server side) is not part of the proposed solution.
When tested positive, to which server the diagnosis keys are reported to can vary depending on the platform and app. It could be reported via a goverment approved app, or reported to Google/Apple provided server. As long as Google/Apple aggregate the diagnosis keys across multiple servers (or even multiple servers across multiple countries), we still take the full advantage of this contact tracing framework.
> What you describe is not in conflict with the Apple/Google proposed solutions.
I didn't mean to suggest that it was. Rather, I was objecting to your earlier claim that there must be an internal and proprietary Apple API used to validate diagnosis keys and that only Apple could mitigate the abuse risk.
> As long as Google/Apple aggregate the diagnosis keys across multiple servers
There's nothing that inherently requires Google or Apple involvement here (although realistically I assume they will end up providing the majority of the servers as a service). All implementations and services including the framework, any apps, and the data server can be done completely independently (if desired) and still interoperate with any Apple or Google provided implementations. That's what's so great about a decentralized system.
They should only accept infection reports that are signed with a trust chain terminating with an Apple/Google internal CA, and sign keys provided by governments with their root CA.
Alternatively, the system could be configured to connect to the "infected keys server" run by the local government(s), as determined by the countries of the cell network the user connected to in the last 30 days.
Other protocols have suggested that uploads be governed by authorization codes provided by health-care providers. Another suggests having providers digitially sign records uploaded to the server too.
With a sufficiently large key that attack you're proposing is effectively impossible (people would notice the yottabytes or however many you need to pull it off).
Although you still do need to protect against people making false claims.
I was thinking the same thing, are we going to have a mess of contact tracing apps and services with the similar analogy of the incompatibility with differing messaging protocols?
> Also, it's much easier to make it mandatory if it's a system app (and obviously it needs to be mandatory to be useful).
That might work in the case of Apple, Google Pixel and (some) Android One devices where the firmware is (often) manufacturer controlled. Outside of the Google Play Services approach good luck trying to deploy a new Android feature to all the devices out there.
What you describe is how iOS was first released. Anyone who wanted to build an app would use progressive web apps. Every native app was controlled by Apple only. This was loathed by developers and corrected in a later release.
Given the steady recurring posts here on HN and elsewhere about hoping that Apple will open up to third-party app selections for email/browser/etc. someday, suggesting that Apple control the only Covid app on their platform is contradictory to that goal.
It doesn't have to be governments. 3rd parties can build these systems either by themselves or paid for by governments and several governments can use/buy the same system. Also, these (some of these) can hopefully be open source apps, too. Pretty important as there will be privacy concerns (rightfully) which can hurt in two ways. First: the concerns could be real and the data collection could be problematic. Second: whether or not the first is the case, this may prevent a lot of people installing it.
If it's a mandatory update that sidesteps the second issue, but then it could hurt Google's and Apple's image. Also, could cause serious problems with the EU (think GDPR). Even if they really can't get any meaningful and sensitive data out of it, they would be running the risk of an investigation.
I actually turned off auto update on my iPhone and Apple Watch. I'm going to wait for people on here, and other security experts, to analyze the binaries to see what the new stuff really does prior to installing it.
Apple has screwed up software updates before (eg. AirPods Pro[1]).
This is great. My only worry is that people shouldn't be allowed to self diagnose Covid-19. It will lead to trolls and cause tons of people self isolating unnecessarily, then eventually not using it once they realize the abuse. Maybe have the sever validate the diagnosis or have the person required to enter a code signed by the server's private key.
A quick scan of the linked project suggests no such healthcare provider code is required. The source[1] suggests the flow is literally: "I Have COVID-19" -> "Are You Sure?" -> "Click OK", and that's that.
Anyways, I take this project to be a proof of concept. One would hope that governments will have healthcare professionals replacing the self-diagnosis step. * hope *
> A quick scan of the linked project suggests no such healthcare provider code is required.
That's why this is a sample app and not the actual application that public health authorities will be using.
See below:
"A representative from Apple and Google's joint contact-tracing project said that their system similarly envisions that patients can't declare themselves infected without the help of a health care professional, who would likely confirm with a QR code." [1]
Sure, you can report any arbitrary key as positive. I can even do it right here on HN; my positive key that I just made up is "0d d8 cb 25 8a 88 aa df 6a 33 17 5f 59 ad fd bf"!
... now what? Someone has to aggregate that key (along with all the other flagged ones) somewhere, and then end users have to voluntarily choose to download the keys from that source and check for themselves if they came into contact with it. So you would have to get someone to accept your self reported positive key, and then convince a bunch of end users to trust that (apparently untrustworthy) data source.
I expect that most databases will require some sort of authentication from a healthcare provider or known laboratory before they will accept a key from an end user.
Yes, just a concept. Developer tweeted about issues with government’s plan and then spent part of a day building a concept to show how it should be done, then fleshed it out to share code publicly.
If the Rolling Proximity Key is not recorded by other users (e.g. the abuser haven't put their device in a high human traffic location and intentionally broadcast your RPK), attacker uploading Diagnosis Keys will not cause any effect.
If the abuser took the effort to place a device and broadcast RPK for a while, then upload the Diagnosis Keys, I'm hoping Apple or Google have a way to validate the requests is from a legit device and thus abuser would have to have a lot of devices to game the system.
One note: the README lists one of the objectives as to "Remain open source for independent verification", but the project is licensed under the MIT license. Since it's being designed to be a turn-key solution for governments to use, wouldn't this allow them to distribute closed-source and (potentially maliciously) modified versions?
1. You can't put GPL'd apps on the Apple App Store, because the terms conflict. For instance, you cannot redistribute an app you've received from the App Store. (At best you can use code with a specific waiver e.g. https://github.com/mobile-shell/mosh/blob/master/COPYING.iOS .)
2. It seems a tiny bit optimistic to expect a malicious government to abide by copyright law.
I think the goal of making this open-source is to enable third-party review to avoid innocent mistakes, not to allow you to audit that the code hasn't been maliciously and intentionally modified. There isn't a great way to audit that the binary you download from the App Store matches specific source, for instance.
> A few private companies are allergic to GPL; there's no particular reason governments would be.
Many large, public (as in publicly-traded) companies also have an aversion to GPL. Most enterprises that have a technology review board or legal review of software dependencies (aka any regulated industry) have a dislike for GPL in customer-facing services.
"private companies" as opposed to "government-run", not as opposed to "publicly traded".
And no, "most" enterprises aren't averse to GPL code for usage. They certainly will have policies about making their own software depend on it, but that's different from simply using it, which was the original topic here.
This is going to create a gigantic mess as governments with limited software development competence slowly release incompatible and partially broken applications, while Apple and Google could just deploy a single solution via a system update.
Also, it's much easier to make it mandatory if it's a system app (and obviously it needs to be mandatory to be useful).