Deactivating 'at risk' accounts - why deactivate? what features are deactivated?

[ArchanaaSK]

Specification states that users accounts that receive 'at risk of exposure' message will be deactivate.

Exposure Status Request: App queries (pull mechanism) the \exposure status" of its user by probing regularly the server with its EBIDs. The server then checks how many times the App’s EBIDs were flagged as \exposed" and computes a risk score from this information (and possibly other parameters, such the exposure duration or the user’s speed/acceleration during the contact). If this score is larger than a given threshold, the bit \1" (\at risk of exposure") is sent back to the App and her account is deactivated, otherwise the bit \0" is sent back. Upon reception of this message, a notification is displayed to the user that indicates the instructions to follow (e.g., go the hospital for a test, call a specific phone number, stay in quarantine, etc.)

UNA (\User A Notified"): this flag indicates if the associated user has already been notified to be at risk of exposure (\true") or not (\false"). It is initialized with value \false". Once set to \true", the user is not allowed to make any additional status request. The flag can be reset if the user can prove that she is not at risk anymore (for example by proving that she got a test and the result was negative).

Scenario 1. Does deactivating also disable the app from sending EPIDs collected in the future (After receiving 'at risk message')? An app user 'at risk' may continue to meet people (i.e. receive HELLO messages from other users) either knowingly or unknowingly when they are at risk. How are these HELLO messages collected? It is not clear how 'at risk' user interacts with other users.

Scenario 2. Does deactivating at risk accounts delete their data? For example, if an 'at risk' user A is diagnosed to be infected, is there provision for user A (whose account is deactivated) to send its LocalProximityList to Srv? Assuming that the list has valid IDs (within the advised 14 day period).

What does deactivation of an account imply? Does the 'at risk' user app lose functionality in all its stages - proximity discovery, declaration of contact pseudonyms of a user diagnosed with covid-19, exposure status request.

Based on the above two scenarios, I fell phase 1 and 2 of the protocol should still be active in 'at risk' users for accurate proximity tracing using ROBERT.

[ArchanaaSK]

Section 7 of specification mentions the following:

If _ESRREPLY_A;i is set to "1": App_A keeps broadcasting HELLO messages but stops sending ESR REQUEST requests to the server.

It is clear that HELLO message broadcasting is still happening and exposure status request is denied for 'at risk' users. It is not clear if HELLO messages collection and infected user declaration is still enabled.

[PRIVATICS-Inria]

Thanks for your question. Deactivating accounts means that the app cannot perform Exposure Status Request - ESR (at least temporarily) but the other functionalities of the app can remain active. This restriction will prevent a malicious user to learn by whom it was exposed through repeated ESR.

Note that this mechanism does not totally prevent the risk since a malicious user may re-install the application and perform a new ESR. This risk is mitigated, if not removed, by the proof-of-work mechanism we propose. However the CNIL opinion (last paragraph of p. 10) may require us to be more strict on this aspect though.