4 ms·

Google did claim that the identifiers are ephemeral. They may be hard to access but they aren't ephemeral. This sets up the possibility of post-hoc attacks. Su

Google did claim that the identifiers are ephemeral. They may be hard to access but they aren't ephemeral. This sets up the possibility of post-hoc attacks. Sure, if you get root, all bets are off generally, but now if you get root, you can figure out identifiers used before you got root, which isn't what Google said was possible.

deleted 6y ago
[deleted]
PossiblyDog 6y ago
The identifiers are ephemeral. About 10 minutes for a given RPI (what gets broadcast over Bluetooth), 1 day for a TEK, and 14 days of local TEK history. The generated RPIs aren't retained, and the TEKs - which can be used to re-derive the RPIs - never leave the device unless you choose to report a diagnosis. All of this is destroyed after 14 days. This report doesn't change any of this. I recommend reading the GAEN cryptography spec: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf https://blog.google/documents/69/Exposure_Notification_-_Cry... The issue here is that privileged apps that are bundled with the OS could snoop on the system log to capture new RPIs when they're generated in real-time. Which isn't great... but privileged apps can already do much worse. If one of these apps is malicious, they could just log your GPS position directly (for example). Heck, an application with root could just read the 14-day TEK history directly off disk. Once we're talking privileged apps and processes running as root, all bets are off. You need to be able to trust the device's firmware.
- deleted 5y ago
  [deleted]
- lurkerasdfh8 5y ago
  > but privileged apps can already do much worse. If one of these apps is malicious One of these apps (google play service) downloads Ads non stop, mine wifi and gps data and send to a central server, etc. All against user wishes ...or even knowledge! At which point do you draw the line for an app to be malicious?
  - chc 5y ago
    In this case, "malicious" clearly means "interested in misusing the private data under discussion."

deleted 6y ago

[deleted]

PossiblyDog 6y ago

The identifiers are ephemeral. About 10 minutes for a given RPI (what gets broadcast over Bluetooth), 1 day for a TEK, and 14 days of local TEK history. The generated RPIs aren't retained, and the TEKs - which can be used to re-derive the RPIs - never leave the device unless you choose to report a diagnosis. All of this is destroyed after 14 days. This report doesn't change any of this. I recommend reading the GAEN cryptography spec: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf https://blog.google/documents/69/Exposure_Notification_-_Cry... The issue here is that privileged apps that are bundled with the OS could snoop on the system log to capture new RPIs when they're generated in real-time. Which isn't great... but privileged apps can already do much worse. If one of these apps is malicious, they could just log your GPS position directly (for example). Heck, an application with root could just read the 14-day TEK history directly off disk. Once we're talking privileged apps and processes running as root, all bets are off. You need to be able to trust the device's firmware.

deleted 5y ago
[deleted]
lurkerasdfh8 5y ago
> but privileged apps can already do much worse. If one of these apps is malicious One of these apps (google play service) downloads Ads non stop, mine wifi and gps data and send to a central server, etc. All against user wishes ...or even knowledge! At which point do you draw the line for an app to be malicious?
- chc 5y ago
  In this case, "malicious" clearly means "interested in misusing the private data under discussion."