
TracePrivately – open-source sample app using Apple's contact tracing framework - prawn
https://github.com/CrunchyBagel/TracePrivately
======
devit
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).

~~~
yegle
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.

~~~
Reelin
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.

~~~
yegle
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.

~~~
Reelin
> 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.

~~~
yegle
According to the previous announcement, we should know more about the
implementation details sometime in mid-May.

------
diebeforei485
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]).

1\. [https://medium.com/macoclock/we-need-to-talk-about-
airpods-p...](https://medium.com/macoclock/we-need-to-talk-about-airpods-
pro-4bbd2533e031)

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

~~~
conroy
My understanding is that to mark yourself as Covid+, you’ll need a code from a
health care provider.

I agree that allowing self diagnosis would ruin the entire system.

~~~
emptybits
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_ *

[1]
[https://github.com/CrunchyBagel/TracePrivately/blob/master/T...](https://github.com/CrunchyBagel/TracePrivately/blob/master/TracePrivately/Localizable.strings)

~~~
odensc
> 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]

[1]: [https://www.wired.com/story/apple-google-contact-tracing-
str...](https://www.wired.com/story/apple-google-contact-tracing-strengths-
weaknesses/)

------
exprez135
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?

~~~
londons_explore
But license it GPL, and governments won't use it at all...

~~~
JoshTriplett
A few private companies are allergic to GPL; there's no particular reason
governments would be.

~~~
vageli
> 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.

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

~~~
vageli
Gotcha, seems like we just have different definitions of private and using.

