Categories
english

Apple, please continue to enforce decentralization in Contact Tracing

The topic of decentralized versus centralized Contact Tracing is currently being debated fiercely.

PEPP-PT partner Inria proposes a centralized approach, where data about infected people is matched to their contacts on a central system. A group of experts working on a fully decentralized approach named DP-3T are warning the public about the obvious bad implications of centralized solutions for privacy.

Given the potential for abuse that centralized implementations open up, at the end of this post, I am going to suggest a small addition to Apple’s preliminary specification, which would completely prevent the currently envisioned centralized solutions on the OS level.

Apple enforces decentralization on the device

Luckily, Apple’s iOS mobile operating system has prevented third party apps from continuously background scanning Bluetooth Low Energy (BLE) advertisements for a long time. Therefore, contact tracing leveraging BLE is not going to happen without Apple’s support. App developers simply cannot build it.

On April 10th, 2020, Apple and Google have announced to work on interoperable contact tracing features which will become parts of their mobile operating systems.

The preliminary Apple specifications released so far are crystal clear: iOS Contact Tracing will be decentralized.

It’s as simple as this: As per the API documentation, at no time any app will ever have access to the contact history IDs.

The only information exposed to apps for “positive” contact events is:

  • The number of contacts.
  • How long the contact was in proximity. Minimum duration is 5 minutes and increments by 5 minutes: 5, 10, 15, etc.
  • The time when the contact occurred. This may have reduced precision, such as within one day of the actual time.

But never any IDs of any contacts “seen”.

Consequently, the centralized implementation suggested by Inria is not going to happen on iOS devices. Thanks god.

What about the server?

Apple specification mandates, that Diagnosis Servers must not store any meta data with the IDs uploaded by confirmed diagnosed users. [Emphasis added by me.]

Right now, the concrete mechanism how apps are supposed to upload diagnosed IDs to these servers is outside the scope of the Apple specification.

I would love to see Apple (and Google) to expand the scope of the specification to handle these uploads on the operating system level!

In case a user is confirmed diagnosed, the following would happen (draft):

  1. For every app using contact tracing features, iOS allows users to manually enter (or override) the Diagnosis Server address through the built-in iOS Settings apps.
  2. In case the diagnosed user decides to provide her data, the app requests the operating system to upload the IDs.
  3. The OS will access the IDs without ever exposing them to the app and upload to the Diagnosis Server according to an Apple defined interface with absolutely zero meta-data attached. It’ll use the Diagnosis Server address set in step 1. An OS level dialog keeps the user informed about the upload and the server address used.

This would effectively decouple the ID uploads from any potential additional meta-data generated and sent home by the app in parallel.

It would also

  • allow multiple and many (trusted) third parties to offer Diagnosis Relay Servers,
  • provide technology savvy users with means to run their own relay servers, provided e.g. by open source initiatives,
  • facilitate largely distributed setups with federated servers using a standardized interface for interoperability.

Apple could also add a certificate infrastructure, which would allow additional control over who could run Diagnosis Servers and Diagnosis Relay Servers.

iOS would reject the upload of IDs to unverified Diagnosis Servers.

Users wanting to run their own relay servers, could use individual certificates made available to them via iCloud. Their personal Diagnosis Relay Servers can only receive uploads from devices associated with their iCloud account.

This would in no way make server development more complex or time consuming, since in the most simple scenario, a government organization could just develop a single service adhering to Apple’s defined upload interface, receive a certificate from Apple and operate it.

I would love to hear from the community at large and also contribute to any open source efforts around Diagnosis Relay Servers. You can find me on Twitter.

By Ralf Rottmann

Founder of leading German IoT Solution Provider grandcentrix. Partner at Rottmann Ventures and R13W. Views here are my own.

Leave a Reply

Your email address will not be published. Required fields are marked *