2 ms·
I think the actual vulnerability is a way to connect a pseudonymous account on a third-party messaging service with the real-name account associated with a pers
by tetromino_ 3y ago
I think the actual vulnerability is a way to connect a pseudonymous account on a third-party messaging service with the real-name account associated with a person's phone OS.
FBI orders an "anonymous" messaging service to give them the Google and Apple push tokens that the service created and stored on its backend for some pseudonymous user when that user first registered through a smartphone app.
Then the FBI goes to Google and Apple and orders them to hand over the gmail or iCloud ID associated with that push token.
Which implies there are only 2 workarounds:
* for a user - use a burner phone with a burner Gmail/iCloud ID and all forms of sync and cloud backups disabled
* for privacy-focused messaging services - do not generate push tokens without an explicit user request. Tell the users about the privacy risk. And if a user opts into push notifications, frequently delete existing tokens, purge them from all logs and backups, and generate new ones.
- mindslight 3y agoIt feels like that is very similar to ordering a messaging service to give up a user's IP address usage, and then asking Google/Apple for user IDs associated with that IP address at the appropriate times. The apparent differences being removing the shred of plausible deniability from shared IPs, and not having to correlate times. Still if you're leaving Google-account-sized breadcrumbs while trying to remain anonymous, I'd say you've already lost. The third (or really first) workaround is to use a personal computer with libre operating system rather than one designed by a surveillance company. Then you can skip this dynamic where entire OS subsystems have been designed around users being plainly identified.