You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though cargoes have no geolocation metadata and the addresses of desktop/Android gateways are opaque, a compromised courier could alter the app to log additional metadata which -- if combined with external data sources -- could help reveal the identity of the user, their location and/or the services being used.
Consider this concrete example: Say Twitter supports Relaynet and a political dissident at large uses it via Relaynet to post a tweet. A repressive regime that managed to compromise the courier app used to send the cargo containing the tweet could, theoretically, use the creation time of the tweet to narrow down the private gateway where the cargo originated. This would be possible by having the courier app log the time and location of each private gateway it found in the route, and the time when each cargo was delivered to the public gateway (and to make the correlation more accurate, the courier could space out the delivery of each cargo).
Describe the solution you'd like
I don't think there can be a single change that solves this problem, but rather a series of changes. At the very least, the following should be done:
Public gateways should be required to batch the delivery of parcels that arrived in cargoes. Better yet, the batch should be assigned randomly to each parcel. We'd just need to make sure that we're not letting parcels expire due to this measure.
Gateways should be required to rotate their keys relatively often (the private address of a gateway is derived from its public key; much like Bitcoin addresses). But not too often as that'd make routing harder.
I'd previously considered requiring private gateways to deliver and collect cargo that doesn't belong to them whilst connected to a courier. However, this may not be a workable solution:
A repressive regime that compromises the courier app could also distribute "honeypot cargo" so they can identify private gateways collecting cargo besides their own. To counter this, we'd have to get public gateways to output some kind of "manifest" file where they list the private addresses of the gateways for which the courier is collecting cargo, but then this would cause routing issues in large-scale deployments where "sorting facilities" are used.
Executive summary
Even though cargoes have no geolocation metadata and the addresses of desktop/Android gateways are opaque, a compromised courier could alter the app to log additional metadata which -- if combined with external data sources -- could help reveal the identity of the user, their location and/or the services being used.
Consider this concrete example: Say Twitter supports Relaynet and a political dissident at large uses it via Relaynet to post a tweet. A repressive regime that managed to compromise the courier app used to send the cargo containing the tweet could, theoretically, use the creation time of the tweet to narrow down the private gateway where the cargo originated. This would be possible by having the courier app log the time and location of each private gateway it found in the route, and the time when each cargo was delivered to the public gateway (and to make the correlation more accurate, the courier could space out the delivery of each cargo).
Describe the solution you'd like
I don't think there can be a single change that solves this problem, but rather a series of changes. At the very least, the following should be done:
I'd previously considered requiring private gateways to deliver and collect cargo that doesn't belong to them whilst connected to a courier. However, this may not be a workable solution:
Related issues
The text was updated successfully, but these errors were encountered: