[FEAT] read only access to injected Rolling Proximity Identifier

[giovannicandotti]

Is your feature request related to a problem? Please describe it. It's not a problem, could be an usage enhancement

Describe the solution you'd like A simple BLE scanner can collect Rolling Proximity Identifier of nearby people May be that later on, some of these RPI are injected (TEKs, indeed, if I have understood properly) in the "public list" of dangerous contacts. If it is possible to read these lists, and check against scanned RPI lists, it would be possible to signal the event also to people who had not Immuni installed or active, but where nearby in that period. I think of huge company buildings: if someone was near the entrance/exit in a period when an RPI was logged, the company can advice also employees who have not the Immuni app active.

Describe alternatives you've considered None

Additional context Read only access needed to TEKs lists, and some info on how to recreate the RPI

[xelhark]

That's an interesting concept!

I must admit, I never really thought about it.

On one hand, I think this could be really useful, especially in context where there is a low smartphone penetration (retirement homes / kindergartens etc.. )

On the other though, if the number of such devices were to increase, at some point you would end up with a situation similar to the paparazzi attack.

In any case, this is already possible by simply installing Immuni on a device, and keeping the device in a fixed spot (i.e: the entrance of the building).

If that device were to signal a potential contact, then it would be possible to alert people who are often nearby the building.

Note that currently there is no way of knowing exactly which RPI triggered the notification, as Apple/Google APIs do NOT provide that information for privacy reasons. This means that you would simply have a very rough estimate (like what day the contact happened) but not much more.

[giovannicandotti]

Please forgive my ignorance about the process and the data exchanged with Apple/Google I (think I can) assume that:

• if infected, I upload TEKs and timeIndex (sort of timestamp)
• those TEKs and time index are made available to all users, to be downloaded on own smartphone
• after downloading, the RPIs are locally evaluated and compared against recorded lists

BY your message, I’m wrong of some points; otherwise it’s possible to identify the period of a scanned RPI, and to signal to people nearby in that moment.

The advantage to have this feature out of the smartphone is about the opportunity to integrate with existing systems. In a company-service perspective (multi-site, country wide), not a “paparazzi” one - to be avoided

Many thanks for your time

Giovanni

On 3 Jun 2020, at 09:44, Gabriele Platania notifications@github.com wrote:

That's an interesting concept!

I must admit, I never really thought about it.

On one hand, I think this could be really useful, especially in context where there is a low smartphone penetration (retirement homes / kindergartens etc.. )

On the other though, if the number of such devices were to increase, at some point you would end up with a situation similar to the paparazzi attack https://github.com/oseiskar/corona-sniffer.

In any case, this is already possible by simply installing Immuni on a device, and keeping the device in a fixed spot (i.e: the entrance of the building).

If that device were to signal a potential contact, then it would be possible to alert people who are often nearby the building.

Note that currently there is no way of knowing exactly which RPI triggered the notification, as Apple/Google APIs do NOT provide that information for privacy reasons. This means that you would simply have a very rough estimate (like what day the contact happened) but not much more.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/immuni-app/immuni-backend-exposure-reporting/issues/10#issuecomment-638022355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6N5S5TB42SQNBZCMR7KD3RUX5OVANCNFSM4NQWMNXQ.

[xelhark]

You are correct, the system does work the way you mentioned, except for this part:

it’s possible to identify the period of a scanned RPI, and to signal to people nearby in that moment.

The Google/Apple APIs are specifically designed to avoid being able to trace back the source of the contact to a single TEK / RPI. Immuni does not have access to the specific TEK (or RPI) that triggered the contact notification, it only handles aggregate information, therefore it's impossible to narrow down the source of the contact to anything but a specific day.

What I meant in the previous message is that opening the APIs to a use case similar to what you are suggesting would also make the system more vulnerable to paparazzi attacks and similar issues.

[ivanvisconti]

You are correct, the system does work the way you mentioned, except for this part:

it’s possible to identify the period of a scanned RPI, and to signal to people nearby in that moment.

The Google/Apple APIs are specifically designed to avoid being able to trace back the source of the contact to a single TEK / RPI. Immuni does not have access to the specific TEK (or RPI) that triggered the contact notification, it only handles aggregate information, therefore it's impossible to narrow down the source of the contact to anything but a specific day.

What I meant in the previous message is that opening the APIs to a use case similar to what you are suggesting would also make the system more vulnerable to paparazzi attacks and similar issues.

Opening the API gives more powerful to the contact tracing system designer that can therefore end up with a better design (and also with a worse design obviously if the designer is not competent enough). For instance with access to the received RPIs one can heavily mitigate REPLAY attacks and can protect the privacy against paparazzi attacks; this has been shown already in the literature.

[immuniopensource]

Hi @giovannicandotti. We are soon going to close this issue. The proposed enhancement—which also has some additional risks, as previously pointed out by @xelhark—is beyond the scope of Immuni at present.

We trust that you appreciate the reasoning behind this decision. Should Immuni’s scope change in the future, we may reconsider this idea.