In order to ensure only the app communicates with the server, it should be possible to authentication.

In the feat/server_authentication branch (3176a966f94c6c5feec1e39b61531714a1b24c4e) I've implemented this in a modular way.

The workflow of this is:

1. The specific authentication to use is specified in KeyServer.plist
2. There is now an auth endpoint required on the server in order to use token validation
3. Forks can easily create their own authentication module (and these can be merged back in)
4. If the app receives a 401 Unauthorized and authentication is configured, then it will request a token from the server
5. App will store and retrieve the token automatically
6. The server auth endpoint should read the bearer token from the HTTP headers and act accordingly. Likewise, the other endpoints should validate this token. The token format is not specified.

(currently only "receipt validation" option is available, which submits the App Store receipt to the auth endpoint)

Add support for expires_at (#29 and #46); breaking change to key submission: each key element is now an object instead of a string. This is so additional data can be included with each key if necessary.

Related to #48, the current method of returning keys in base 64 encoded JSON won't scale as well it should.

The API should be updated as follows:

• [ ] Ability to return application/octet-stream the infected keys. Either the server can decide to return this or the client can ask for it
• [ ] Update the app to handle binary data

Before jumping into this, some issues need to be addressed:

• [ ] How will since the since data be returned?
• [ ] How will the deleted_keys be returned?
• [ ] In #51, this could a new parameter in the JSON returned from infected endpoint. How would this be included in a binary stream?

I propose it be implemented something like the following:

• [ ] Include the since data in the response headers
• [ ] A header which includes:
  • [ ] The version number,
  • [ ] The number of keys / size of the key payload
  • [ ] The number of deleted keys / size of the key payload
  • [ ] The length of a key (16 bytes in the spec)
• [ ] Each key in the format: key data + UInt32. The specs indicate the key data is 16 bytes

I'm wondering why you chose base64 encoding for downloading keys, e.g. in your OpenAPI spec and in the client code.

When downloading a large set of diagnosis keys, using base64 is not size efficient. Because the length of a DiagnosisKey is 20 bytes (16 bytes for the key, 4 bytes for the ENIntervalNumber), and 20 is not a multiple of 3, the encoded output needs padding added so it's a multiple of 4 (ref). The length of a base64 string for one DiagnosisKey would be 28 bytes (example).

Example of how this affects the size of data transfer:

• Each DiagnosisKey consists of 20 bytes: 16 bytes for the TemporaryExposureKey, and 4 bytes for the ENIntervalNumber.
• Let's say 100.000 users each uploaded 14 days of keys, so the keyset on the server is 100.000 * 20 * 14 = 28.000.000 bytes = 28 MB.

Encoding 28 MB as a Base64 string would takeceil(28.000.000 / 3) * 4 = 37.333.336 bytes = 37,3 MB to download. That's an increase of 33%. Given a broad user base, this can impact both CDNs, government proxies and individual users with small mobile data plans.

I would suggest changing the content type of the download endpoint to application/octet-stream; e.g. a binarystream. I'm working on a reference server for Apple/Google's framework, which uses this strategy: https://github.com/dstotijn/ct-diag-server

Note: For uploading, it's a non-issue, because the content length will always be small; at most 14 days worth of data per upload, e.g. 20 * 14 = 280 bytes. Using Base64 encoding would make it: ceil(20 * 14 / 3) * 4 = 376 bytes (slightly more than 33%). But of course this size increase would hardly make a difference.

I've made the Ruby implementation of the key server available on a demo server. You can point the BaseUrl in KeyServer.plist to https://trace-privately-demo.herokuapp.com/api. Here's a GIF of it in action built against 21323284a722ae2ce4d8a7f39049e9eb077d1520.

There's currently no authentication or ~protection~ on the server. It's using a free tier on Heroku. It's limited to 10,000 rows in the database and the server "sleeps" after not being used for 30 minutes (Delay when booting up, but completely automatic). It will be locked down a little more after https://github.com/tatey/trace_privately/issues/12 and https://github.com/tatey/trace_privately/issues/4 are implemented.

You can access the admin section yourself by going to https://trace-privately-demo.herokuapp.com/.

Update: Server is now rate limiting API clients to 10 requests per minute. You'll get a 429 if you make too many requests.

This contains the changes to app and the mock framework to use the ExposureNotification framework.

Note that you need the following entitlement to actually use the real framework, which must be manually given to you by Apple.

com.apple.developer.exposure-notification entitlement

On smaller devices, the stackview became too large, causing layout constraint errors. Moving the view into a scrollview allows the stack to grow and fixes the layout on smaller devices.

This may not scale if you have to ping every single client with a push notification, but it may be useful way to wake up people's phones for exposure checking.

Hey Quentin, kudos on your work on this, I'm loving following along and really hope government(s) take advantage of it!

I just wanted to suggest a couple of minor UX improvements based on a quick look at the most recent screenshots. I know it's only a proof of concept but here are my thoughts anyway :)

• It's not immediately obvious to me that the orange "You May Have Been Exposed" button is tappable, because that phrase isn't a verb. Maybe you could align the text to the left and add a little arrow on the right? Or add a "tap for more info" sub-label?

• You could change "Privacy" to say "Privacy Info" and make it a blue text link instead of a grey button. As it is the buttons being different heights looks a little odd.

• The "Submit Diagnosis" button being at the bottom of the screen is very far away from the explanatory text. Could move it up like the "Next Steps" button?

• The red exposure info box ("April 18...") has the same style as a button, but I presume it's not tappable?

Add shortcuts to start, stop and check stays of tracing.

Provide detail or sample shortcut for “leaving home”. Doing it in this manner means location tracking is not required.

GPS tracking could make for a useful addition to this app, but it would likely be controversial.

I'm going to use this thread to discuss how this could possibly be implemented in a sane and useful way.

Hi there!

I've been working on a server reference implementation based in the Swagger file. I'd love your help with testing and keeping it compatible moving forward.

It can be found here: https://github.com/kevinrmblr/traceprivately-server

There's some open ends, such as limits on updating daily keys and updating the related data, but mostly it should be ready:

• It saves the form fields (as plain text) alongside the batch
• Saves the risk level
• Calls support both plan JSON and MessagePack

I also left room to submit data in the auth call, so a token can be added, like a PushToken or a DeviceId token. Depending on the app setup, it'll either require this or also accept an empty body (which is currently the default to be compatible with the iOS app), an auth body could look like this:

{
	"strategy": "IOS_DEVICE_ID",
	"token": "SOMETOKEN"
}

Let me know your thoughts!

Since a submission now has a risk level associated with it, in theory the authorities could adjust this (say from "very low" to "very high" after they learned you were on a cruise ship).

The key server should then serve this key up again and the client apps should update their cache.

Daily, every 2 days, whatever..

Include an option to disable this, otherwise the user may completely disable notifications and therefore miss the important "exposed" notification

After an approved positive diagnosis, user device should continue to submit keys on following days. This is allowed by an authenticated device with a previous submission ID.

Since the subsequent keys are associated with an existing submission, to avoid having to re-approve the diagnosis each time, the server can simply accept up to 1 key per day for that submission (for X number of days beyond the initial submission).