I really hate articles like this. What is the actual vulnerability? It sounds like this guy was using a mobile device on his bare physical Internet connection, and then relying on this "encrypted Swiss messaging app" to keep him safe from the FBI. So it sounds like this is either a simple vulnerability in "Telegard", or at least a vulnerability in how this guy thought Telegard was supposed to work.
And you might be thinking that people shouldn't have to worry about all these details, so they're unnecessary in a news article for general consumption. Except focusing on details is exactly what the article is encouraging with its target of "push notifications", but its description of the mechanism isn't specific or actionable. Cue endless folk security advice to "disable push notifications" with no recognition of their specific info leaking properties.
Personally if I was going to maintain a persistent online nym actively posting evidence of things against most everyone's morals and generally antagonistic to law enforcement, I would use TOR and an operating system that wasn't designed by a surveillance company rather than thinking that some commercial off the shelf app made me invincible. Then again how is this really different than back in the day when people would ignore that IP addresses could identify them. It was great fun to go into pedophile IRC channels, paste a bunch of real names pulled off of poorly configured terminal servers, and watch the panicked disconnects.
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.
It 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.
> Many apps offer push-alert functionality because it gives users a fast, battery-saving way to stay updated, and few users think twice before turning them on.
I don't remember ever having to turn on one of those things. I have to do the exact opposite and go into the settings of almost all apps and disable notifications. This is not even related to privacy, as much as annoyance as all the apps want you to be "engaged", from chat pings (which are sometimes essential), to pushing ads through.
>Unlike normal app notifications, push alerts, as their name suggests, have the power to jolt a phone awake — a feature that makes them useful for the urgent pings of everyday use. Many apps offer push-alert functionality because it gives users a fast, battery-saving way to stay updated, and few users think twice before turning them on.
As a very basic user of a smartphone (Android) with relatively few apps, please ELIF how do I determine the current permissions for such notifications on my phone, in case I want to turn them off.
If you go to the settings, there should be a notification category, which then contains another menu "App Notifications" where you can see all the apps that are allowed to receive notifications, but I don't know if this will stop google play services to receive these identifiers.
I use GrapheneOS, so I don't have any google play services running, but for the apps where I need notifications I use https://unifiedpush.org/ (only a few apps implement it) and I host my own https://ntfy.sh server.
Would disabling all notifications for an app via the iOS settings app also stop push notifications? Or do they keep working in the background without showing pop-ups?
Push notifications is a core ability of the OS that cannot be turned off. If none of your apps have notifications enabled they will still get push notifications but just not raise an alert (kinda like what happens in Do Not Disturb mode). To completely disable notifications you would need to edit the mobile operating system to remove the code that establishes and maintains a connection with the Apple Push Notification System (APNS) or the Google equivalent. This is exactly what Graphene OS does: the Google push notification code was removed from the Android open source code base. Result: no push notifications and longer battery life (because there's not a process constantly staying in touch with a notification server).
I have a couple of apps that are out there, right now, that use the Apple iOS notifications system (I write native Swift apps).
One of the apps, is the end-user one. That does not subscribe to external notifications. I only use the notifications system to badge the app icon, if there are things that need to be addressed. The badge is only affected, when the app is being run.
The other app, is an admin dashboard for that app (It uses a server-based system to manage user accounts). That subscribes to APNS, so we get alerted, when new signup requests come in.
The end-user app has a notifications panel in the Settings app, and you can specify that it not badge the app icon, but that makes no difference, in terms of privacy, because nothing is ever sent to the server.
The dashboard app actually registers the device ID, when registering for push notifications. Apple is probably aware of the device ID, and likely uses it, internally for stuff, but as an app developer, I only care about it, when one of the dashboard users signs up for push notifications. In that case, I store the ID into my own database, and use it to send push notifications to the device.
I suppose there may be some built-in OS services, that use APNS behind the scenes, but I'm not aware of them.
But Apple knows where all its devices are, and how to reach them (which is why it's a bad idea to buy a stolen iPhone). APNS is just an exposed SDK, to piggyback on it. I don't think there's any way to avoid them knowing where your phone is, unless you choose to use a [non-Apple] system that doesn't have any of those types of services.
servers run by Apple and Google, which can hand them over at law enforcement’s request
If you have a smartphone you are being tracked. If you don't you're being tracked as a NACK which raises alarms. Four people in an elevator with three phones means those get additional scrutiny.
I saw this one and had seen the previous one about using wifi to see through walls really surprised we never saw any opensource projects attempting to replicate the research
I was kinda wondering that myself... unless the implication that there is a camera or other "smart tech" in an elevator that knows how many humans are in the car and this data is being consumed in real time by someone who cares.
In that case, tracking by smartphone is superfluous. They already got the location data through entirely different means, and they'd know there were four people in there even if none of them had a smartphone on them.
I wouldn’t be surprised if this was parallel reconstruction. They might have used this approach to mask a honeypot they have or a much simpler tracing scheme because this approach is time consuming and complicated dealing with a warrant to multiple companies in sequence.
It’s super easy actually. You can just send the warrant (via a pdf) to apples security portal. That’s it, they verify and then email back the info encrypted. They then email a decryption key a few days later.
This process is used all the time. Facebook/ Meta has an easy law enforcement portal that does the same thing (same for Snapchat, etc).
If anything they would use parallel construction and setup pretend documentation on old school investigation… they would want to hide that all these crimes are essentially solved via easy to access phone data.
Why would you assume that? It is routine to issue warrants to multiple companies, and issuing a warrant to companies like Apple, Google, or Verizon is nothing like the others. They have entire divisions whose only job is to validate them service LEO requests. Ive heard the cell providers have APIs for them.
I can see this being hard and time consuming the first time around, but I’m sure now it’s just routine.
I've long thought that these notification mechanisms are bad for privacy&security, and that the platform vendors either didn't care enough, or wanted to exploit the information themselves.
> said an investigation had revealed that the Justice Department had prohibited Apple and Google from discussing the technique.
That could complicate having a discussion about the problem.
Also, guessing from the quote that, even if a platform vendor wanted to fix this privacy&security problem, they'd be asked or compelled not to.
(Side note: Occasionally, you see an epic bug report or support thread with lots of people incredulous about why something isn't being fixed, and the vendor is silent. I usually guess that the inaction and silence is due to corporate triage, misalignment, or dysfunction, and that no one has the guts/decency to respond to all the people. The quote above suggests that the true explanation for silence by the platform vendor on a particular bug/support ticket could actually be that the paranoid conspiracy theorists guessed correctly.)
Yet another thing I like about Graphene OS: no push notification support at all. Unexpected side benefit: I can go two days between battery charges which also means the overall life of the battery before it cannot hold a charge anymore will be extended significantly.
Snapchat is an app I found quite nefarious with push notifications. They have 'screen on' as the default notification mode for all their messages.
I currently use two phones with notifications turned off for Snapchat. However, the notification settings get reset if I use it on my other device. I don't use Snapchat altogether, but the other day, they sent me an SMS mentioning that I have a few unread messages. So scummy and so stupid!
And you might be thinking that people shouldn't have to worry about all these details, so they're unnecessary in a news article for general consumption. Except focusing on details is exactly what the article is encouraging with its target of "push notifications", but its description of the mechanism isn't specific or actionable. Cue endless folk security advice to "disable push notifications" with no recognition of their specific info leaking properties.
Personally if I was going to maintain a persistent online nym actively posting evidence of things against most everyone's morals and generally antagonistic to law enforcement, I would use TOR and an operating system that wasn't designed by a surveillance company rather than thinking that some commercial off the shelf app made me invincible. Then again how is this really different than back in the day when people would ignore that IP addresses could identify them. It was great fun to go into pedophile IRC channels, paste a bunch of real names pulled off of poorly configured terminal servers, and watch the panicked disconnects.