Difference to Singapore's BlueTrace/TraceTogether

[ReichertL]

How does the described protocol differ from the BlueTrace/TraceTogether Whitepaper ( https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf ) which was released some time ago?

Parts that are the same in BlueTrace and ROBERT:

• Relies on an mobile app communication with a trusted backend server
• Contact of non infected users are stored locally
• Contacts of infected users are communicated to the health authority / server
• Pseudonyms are generated by the server and are linkable for the server
• Pseudonyms are ephemeral and distributed via Bluetooth
• Contact Tracing is done on the server allowing the server to determine who interacted with one-another and thereby leaking the social graph. It also leaks to the server who in particular is at risk. This information could be used to enforce quarantine and goes against voluntary nature of contact tracing approaches in Europe
• Federation between countries and different organizations was also proposed and implemented by BlueTrace

The only difference I can spot so far, is that no BlueTrace/TraceTogether requires people to provide a phone number. But this is not essential to their design.

ROBERT also does not explain how an infected user can upload the PoximityList to the server without leaking its identiy in form of it's permanent identifier or in form of a verification token. BlueTrace uses authorization codes to determine if an upload legitimate. This helps the health authority to deanonymize other users.

[guillon]

I agree, it is essentially the same protocol as BlueTrace. I would say with respect to anonymization of the users, hence user (same as user's phone number)<->networkid maps and networkid<->messages maps:

1. knowing that ISPs can recover user<->networkid maps
2. knowing that trusted entities must be trusted in not using for other purpose networid<->messages maps, or not store these entries at all (the simplest solution)

It is more fair, imho, when no specific transport protocol is recommended, feasible and enforced on the client app, to explicitly mention that from the trusted entity point of view the phone number is known and correctly managed (used only for the purpose and deleted) as well as other sources of identification such as networkid - the source IP for instance-. This is equivalent, and without probabilistic obfuscation of the network id it is false to say that user's are anonymized to the trusted entity simply by the ROBERT protocol. This is a problem not in the scope of the ROBERT protocol, it is a problem of the tansport protocol.

Of course, the phone number is a direct identification of the user, hence it causes a more important issue in case of leak of the trusted entities information and it should not be transmitted as it is not necessary.

My points if that can be useful are:

• I really support ReichertL comment and hence, one should reuse implementations an cumulated experience of what they've done,
• one should focus on proving that the BlueTrace proposal is actually an implementation of the ROBERT protocol + some other useless metadata if so, which will be very useful for focusing on the implementation and the point before
• the critical point of the transport protocol must be addressed in order to gain trust, if not already done, by:
  • specifying clearly and implementing it in the clients. For instance use the independent Tor network to probabilistically hide the network id.
  • or otherwise explicilty mention, that if the client does not take himself countermeasure to hide its networkid, he has to trust the central entities with respect to the non-exposure of this networkid.

[DenisLafontTrevisan]

+1

[superboum]

This is a problem not in the scope of the ROBERT protocol, it is a problem of the transport protocol.

It can be considered as being part of the scope of the ROBERT protocol. I am thinking to "Untraceable electronic mail, return addresses, and digital pseudonyms" from David Chaum:

A technique based on public key cryptography is presented that allows an electronic mail system to hide who a participant communicates with as well as the content of the communication - **in spite of an unsecured underlying telecommunication system

This article is the genesis of all existing mixnet and onion routing solutions, the most well known being Tor.

[ReichertL]

This aspect is discussed in issue #6.

[guillon]

This is a problem not in the scope of the ROBERT protocol, it is a problem of the transport protocol.

It can be considered as being part of the scope of the ROBERT protocol.

Yes Indeed. Sorry the ambiguous assertion. It can be included in the Robert scope, but I assumed it was not in the "initial intended" scope of Robert which does not currrently specifies everything down to the transport layer. The networkid exposure to the trusted entity should be explained more clearly and optionally solved. In Robert protocol or another part of the whole solution.

This is indeed discussed more lengthtly in #6 (which mixes several discussions in addition to the sole networkid issue).