Governments Spying on Apple, Google Users Through Push Notifications (reuters.com) 33
Unidentified governments are surveilling smartphone users via their apps' push notifications, a U.S. senator warned on Wednesday. From a report: In a letter to the Department of Justice, Senator Ron Wyden said foreign officials were demanding the data from Alphabet's Google and Apple. Although details were sparse, the letter lays out yet another path by which governments can track smartphones. Apps of all kinds rely on push notifications to alert smartphone users to incoming messages, breaking news, and other updates. [...] That gives the two companies unique insight into the traffic flowing from those apps to their users, and in turn puts them "in a unique position to facilitate government surveillance of how users are using particular apps," Wyden said.
He asked the Department of Justice to "repeal or modify any policies" that hindered public discussions of push notification spying. In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications. "In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
He asked the Department of Justice to "repeal or modify any policies" that hindered public discussions of push notification spying. In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications. "In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
I resist the terminology (Score:1, Interesting)
Re:I resist the terminology (Score:5, Informative)
If it's initiated by the remote end, it's push. If it's initiated by your end, it's pull. Nobody said anything about force the way you used the word.
Re: (Score:2)
Resistance is useless. It's push... In more ways than one.
The app "receiving" the notification has no connection active to the notifying service. Neither does the phone. The phone receives it from its vendor's servers.
The application doesn't know about the notification until you activate it (depending on development profile used, it may get a bit of CPU time to process the message).
It's an absolutely insane system*, requiring all protocols to be stateless. IMAP? XMPP? IMAP is big enough to have gotten an ex
Re: (Score:2)
The app "receiving" the notification has no connection active to the notifying service. Neither does the phone. The phone receives it from its vendor's servers.
So something does have an active connection.
Re: (Score:2)
So what? It's "pushed" through the phone to the app. The app didn't poll for it.
Re: (Score:3)
I know, but there is absolutely a connection. The server knows about the device and it knows where it is so it can deliver messages to it. That's a connection.
Re: (Score:2)
Ok, I don't see what the point is that you're trying to make... Please elaborate. Is it about my bad formulation of
> The phone receives it from its vendor's servers.
Which would better be: The phone OS receives it through a connection to its maker's servers.
The point is the app isn't proactive in the notification process, making it a push notification.
Re: (Score:2)
The point is to be technically correct, the best kind of correct! :D
Re: (Score:1)
No, the server doesn't know where the device is. It doesn't need to know. The server only has an address to which it sends the notification. The telcos handle the delivery...and they do know where the devices are.
Re: (Score:3)
> Thus IMO, "Push" implies some sort of subversion of the protocol
What? What protocol?
Do you mean etiquette?
No protocol is being subverted.
If you don't like push infrastructure - fine - etiquette is almost all opinion.
But you don't get to reject a word in usage because you don't like what that word describes.
That's the way to Babyl.
If anything is being subverted it's that push mandates violate privacy. That's why you'd best download the Signal APK from signal.org and not Play Store.
Re: (Score:2)
The GPP is right IMHO. "Push" used to be something you did over a conventional Client request -> Server -> response protocol.
The most common example was with HTTP. Rather than having the client poll, request -> server responds with 204 (or similar) -> client *sleeps* -> repeate
Some things started to work like this:
Client request
Server beings response, ie sends only headers
Either we near the time out and the server completes an empty response or something happens server side and the response
Re: (Score:3)
Re: (Score:2)
For cloud-delivered notifications (Score:3)
For people wondering "how does this work" - most mobile app developers push their notifications via the cloud via services like Firebase. It is these services that would allow the government to snoop on your notification stream.
Notifications that are local to the device, I don't see how they could see those unless you are signed into a service like iCloud.
Re: (Score:2)
Re: For cloud-delivered notifications (Score:1)
A Good Dose of STFU (Score:2)
Re: (Score:3)
AFAIK plenty of apps will still send those notifications, your phone just filters them out.
Meaning it is still possible to spy on them.
Re: (Score:2)
Re: (Score:2)
I do the same thing! Disable or remove notification rights and kill the app from running in the background. Though I do this in the name of power management. :)
Can't use up juice if they aren't running in the first place.
Re: (Score:2)
> Though I do this in the name of power management
That's not how any of this works... (speaking for iOS)
Not allowing socket connections in the background (Score:5, Informative)
This is possible for iOS because any app that supports incoming notifications when it isn't in the foreground has to go through Apple's servers. iOS apps can't keep a socket connection open in the background, so some component needs to run on a server and send notifications to the phone via Apple's servers. That gives a very convenient point for intercepting and spying on al the notifications.
As an aside, it also makes it hard to make any kind of communication application without charging subscription or usage fees. Consider an IRC client for iOS. Unless you want it to disconnect every time it's put in the background, the actual IRC client needs to run on a server, with the iOS app connecting to it and fetching messages when it's activated. To support notifications for messages when the app isn't in the foreground, the server component has to send the notifications via Apple. Running the server component costs money, which likely means a subscription model, and Apple demands 30% of the subscription revenue. It's shit for developers and users.
Re:Not allowing socket connections in the backgrou (Score:4, Insightful)
I don't have modpoints now, so I'm commenting.
You don't have to go as far as IRC: IMAP IDLE isn't implementable on iOS either. email! iOS borked email...
When I set up my XMPP server, it took me many evenings to understand this, and by extension why any stateful protocol is not implementable on iOS.
One more thing: to use Apple's push notifications, AFAIK you're required to have an Apple developer account. So developing an app not tied to a specific service is not really possible. Alternative clients? nope. (Without the client's developers running a notification relay server... Tigase does that for their XMPP client.)
Re: Not allowing socket connections in the backgro (Score:2)
Read what I said again (Score:3)
I didn't say Apple charges for push notifications. I said that any iOS app that needs to show notifications for incoming messages when it isn't in the foreground (e.g. a mail client, an IRC client, an XMPP client) requires a component running on a server to send the push notifications via Apple. Running something on a server isn't free, so you'll need some way to recover the costs, e.g. with a subscription model or with ads.
If Apple allowed iOS apps to watch a socket in the background (which I understand
Re: (Score:2)
Re:Read what I said again (Score:4, Informative)
Consider a client for a standard protocol like IMAP, XMPP or IRC. You want to make a client for one of these protocols that can connect to any server that implements that protocol in a standards-compliant manner. You are not running your own IMAP/XMPP/IRC server, you only want to make a client application for a standard protocol that anyone can use with a standard server.
If you make a client for one of these protocols that runs as an application on a Mac or PC, it can connect to the IMAP/XMPP/IRC server, and keep a socket connection open while it's in the background. If a new message arrives, the application can display a notification to the user. They can then activate the application to read the new message. There's no need for the application developer to run any server components. The user can use the application with any server that implements the standard protocol. The only connection is between the application running on the user's PC/Mac and the server they want to use. You can sell the application for a one-time payment or give it away for free, as there's no ongoing cost to you when people use it.
If you make a client as an iOS application, you cannot keep socket connections open while the application is in the background. If the application is the only component you supply, this means that for IMAP or XMPP, the user will not be notified of new messages when the application is not in the foreground; for IRC it's worse, as messages are ephemeral, so the user will only see messages sent while the application is in the foreground.
To get around this, you need to have some component running elsewhere (on a server of your own) that connects to the actual IMAP/XMPP/IRC server and sends notifications to the user via Apple. Running this is an ongoing cost, so you can't practically sell an application for a one-time payment or give it away, or you'll end up with more users than you can support. There's also a potential security issue, because your server component needs to authenticate to the IMAP/XMPP/IRC server they want to use, so they need to trust you with credentials.
Re: (Score:2)
I believe the notification solution was a compromise with the cellular providers. They didn't want a whole bunch of devices holding IP connections open on their network. In the beginning even the notification channel Apple had was a negotiated capability and they still had to reset the connection at least every 24 hours. The early billing systems were each data connection was a call on the system. You could see in your bill about one data call a day with a boatload of data that lasted all day long.
The simpl
Re: (Score:2)
disabled notifications (Score:2)
All my friends said I was weird for disabling notifications all can suck it now, lol!
Re: (Score:2)
All my friends said I was weird for disabling notifications all can suck it now, lol!
I'm not sure if that is as helpful as you think.
Disabling apps from notifications may mean you get fewer nags in notification center, but doing so just tells your device to forego its instructions to add an entry to your notification area and play the notification sound (or vibrate or flash the LED or whatever).
That doesn't mean that Firebase isn't receiving the contents of an app's notification contents and sending it to your phone, which is where this MitM is happening.