Notifications endpoint leaks meta-data about check-ins.

The api/v3/notifications/traces endpoint returns a list of trace IDs that were transferred to health departments. It currently simply fetches a list of LocationTransfer objects from the database and joins matching LocationTransferTrace objects to them, which are then returned in a list (https://gitlab.com/lucaapp/web/-/blob/master/services/backend/src/routes/v3/notifications.js).

This is problematic as it reveals meta-data about the trace IDs that makes them vulnerable to re-identification / correlation attacks. Since the endpoint preserves the grouping of the LocationTransferTrace objects, an adversary can deduce which trace IDs occur together. If the adversary can also inject check-ins into the system (which is feasible), he can use those to map trace IDs to locations and check-in times. He can also deduce correlations between trace IDs, which might be useful for re-identifying individuals in the data.

In addition, the ORM might implicitly return a sorted list of trace IDs (which seems to be the case based on polling the endpoint many times), which can also allow an adversary to estimate the timestamps belonging to individual trace IDs.

To mitigate this kind of attack I would recommend to de-duplicate trace IDs in the endpoint and randomize their position in the list. It might also be desirable to limit the update interval of the published list in order to defend against difference attacks in which an adversary observes changes to the values returned by the endpoint to deduce correlations between trace IDs.

The following image illustrates the problem with data returned by the live endpoint: