Apple Change Causes Scramble Among Private Messaging App Makers (theinformation.com) 40
A change Apple is making to improve privacy in an upcoming version of its iPhone operating system has alarmed an unlikely group of software makers: developers of privacy-focused encrypted messaging apps. The Information (paywalled): They warn the change, which is already available in public test versions of iOS 13, could end up undermining the privacy goals that prompted it in the first place. The Information previously reported that the technical change Apple is making to its next operating systems, iOS 13, has sparked concern at Facebook, which believes it will have to make significant modifications to encrypted messaging apps like Facebook Messenger and WhatsApp to comply. But a much wider group of developers of encrypted messaging apps -- including Signal, Wickr, Threema and Wire -- is scrambling to overhaul their software so that key privacy features continue to work. Apple told The Information on Wednesday in a statement that it is working with the developers to resolve their concerns. "We've heard feedback on the API changes introduced in iOS 13 to further protect user privacy and are working closely with iOS developers to help them implement their feature requests," an Apple spokesperson said.
facebook (Score:5, Insightful)
Facebook is worried about the impact this might have on users' privacy.
That's cute.
Re: (Score:2)
I agree that google and facebook etc. see themselves as a third party that is part of any communication over their platform, but for whatever reason, most people seem OK with it.
Re: (Score:2)
Re: (Score:2)
If Facebook is worried about a change, I would bet that change is good for user privacy.
What exactly are the changes? (Score:5, Insightful)
Re: (Score:3)
I've noticed this on at least three stories lately -- the article never goes into the actual controversy, just mentioning it in a few paragraphs.
It's almost as bad as clickbaits that suggest some awesome scene but never show the actual pictures.
Re: (Score:2)
It did go into the controversy, it just didn't go into the facts. I get this same thing listening to stories about political candidates: their shirt was "controversial" and it has 10 pundits opinions on it, but it doesn't say what the shirt said. Or they cover someone's reaction to what the candidate said, but they don't say what the candidate said or even what the topic was.
Re: (Score:2)
It's almost as bad as clickbaits that suggest some awesome scene but never show the actual pictures.
That's because you need to click on the right arrow graphic and go through 20 pages of pictures and advertisement to get to that awesome scene. A bit annoying since the Google search algorithm no longer favors that kind of website design for obvious reasons.
Re: (Score:2)
Yes! Please tag the story with "uselesssummary"
Re:What exactly are the changes? (Score:5, Informative)
lol the dumb paywall story is the same as the summary here. What exactly are the changes?
Apple is being Apple again.
Basically apps that currently can be set by the user to run in the background, will no longer be able to run in the background no matter what the user wishes.
VoIP apps and encrypted messaging apps tend to do this so they can keep a persistent "control" channel open to their servers, over which is sent "incoming call" or "incoming message" notices.
Then the app can prompt to answer and setup the end-to-end encrypted connection.
Now those apps will become suspended if left in the background, terminating any persistent connections to know they have a call/message.
Apples new API requires you to use Apples notification system to "wake" the app.
But that means Apple now knows when you get a call or message and to which program. The app makers can't keep this restricted to within their app anymore.
The new method means anytime you get an incoming encrypted message, while the message contents are still end-to-end encrypted and protected, the fact a message is being sent, when, and to/from which program are all sent through Apples notification servers.
Which means that info is logged and subject to US law regarding distribution to governments.
Before that, the most Apple knew was when you downloaded the app from the store to install it.
They didn't know when or even if you used it, how often, etc. For all they knew you deleted it shortly after testing it out.
Re:What exactly are the changes? (Score:5, Interesting)
The app makers can't keep this restricted to within their app anymore.
You could kinda bypass it, but it's cumbersome.
Essentially send periodic wake up notifications to your app, and then have the app check via some other means wether or not an actual message was sent. Fake "background" activity through apple servers.
No that is wrong (Score:4, Informative)
100% you can be sure if someone posts Apple technical details as an AC they are wrong.
Basically apps that currently can be set by the user to run in the background, will no longer be able to run in the background no matter what the user wishes.
The place you went wrong is that VOIP apps can still do this, just not other kinds of apps.
Now those apps will become suspended if left in the background
Except for VOIP apps.
The new method means anytime you get an incoming encrypted message, while the message contents are still end-to-end encrypted and protected, the fact a message is being sent, when, and to/from which program are all sent through Apples notification servers.
Unless you send just an ID of the new message and the app uses an encrypted call to get the data. You do not HAVE to send message text over push notifications, and for that matter even if you did you could leave that encrypted.
The issue here is that non VOIP apps want to be able to work in a similar to to how VOIP apps work, but some of them have been abusing the background permission they were given.
Re:No that is wrong (Score:5, Interesting)
Unless you send just an ID of the new message and the app uses an encrypted call to get the data. You do not HAVE to send message text over push notifications, and for that matter even if you did you could leave that encrypted.
The point isn't whether Apple can see the message content. The point is that Apple can see that there is a message being received and that Apple logs that information. Given those logs, you could create clusters of people who get messages at the same and who are presumably in the same group chat. There is probably other information you could datamine from those logs as well. Users of end-to-end encrypted chat apps would like to keep that kind of information private.
Re: (Score:2)
The point isn't whether Apple can see the message content. The point is that Apple can see that there is a message being received and that Apple logs that information.
Apple knows all of that already. iOS knows which apps are running and which network connections they have open and when traffic is sent/received on those connections. They can already infer when you receive a WhatsApp message. The changes to force most apps to wake via their notification system probably make it more obvious, but no new information is being revealed.
Do you know for certain that iOS _doesn't_ track all of this "telemetry" and send it back to HQ?
Re: (Score:2)
The operating system knows those things, but that's not the same as Apple knowing it, practically speaking. Apple doesn't have code that monitors and logs the background activity of WhatsApp and other apps. And although ostensibly they could do so, in practice, they can't. It would produce ridiculous amounts of logging data, which the device would have to then send to Apple. Doing so would waste a crapton of battery power.
Push notifications, on the other hand, already involve a network request to Apple,
Re: (Score:2)
I think you're making it sound harder than it is. The OS can easily detect that a relatively idle app received data out of the blue and suddenly began to make heavy use of the speaker, mic, network, etc. It's not a lot of logging. Just a bit of a state machine.
It's true that the push notification is less work for Apple / User hardware. I think it might be reasonable to do something where the app can be put to sleep until it receives network data. Maybe don't require the data to come from Apple.
I stil
Re: (Score:1)
100% you can be sure if someone posts Apple technical details as an AC they are wrong.
The place you went wrong is that VOIP apps can still do this, just not other kinds of apps.
Oh really?
Dated last month: https://arstechnica.com/gadgets/2019/08/ios-13-privacy-feature-will-force-total-overhaul-for-facebook-apps/ [arstechnica.com]
In iOS 13, Apple will not allow apps to run voice over Internet protocol (VoIP) in the background when the programs are not actively in use. Many apps that offer VoIP services currently run in the background, and they will need to be rewritten to adjust to Appleâ(TM)s upcoming rules. The change is slated to roll out when iOS 13 is released in September. However, app de
That's not right either (Score:2)
First, thanks for providing that link, though why did you not include that to start with?
Second, the Ads article is not really correct either, or at least way too simplistic.
If you really care you can read through the fine details of what is going on in the Apple Developer Forums [apple.com].
Lastly, why on earth would you post this all AC.
No VoIP backgrounding (Score:2)
The second link in the text points to another Slashdot story that is related (and gives more details).
Basically, Apple is no longer making VoIP apps allowed to run in the background, which was the only way to have a process running uninterrupted.
Re: (Score:2)
Indeed, the website that is linked to is called The Information, but it doesn’t contain much information.
free source (Score:5, Informative)
An upcoming change in iOS 13 that limits data collection practices using VoIP APIs will impact apps like Facebook Messenger and WhatsApp, forcing them to be redesigned, reports The Information. Facebook Messenger and WhatsApp allow users to make calls over the internet, and to listen for those calls, the apps run in the background of an iPhone or iPad so calls can connect quickly. While running in the background, the apps are also able to collect data, something that Apple is putting a stop to in iOS 13.
Re: (Score:2)
Re: free source (Score:2)
My suspicion is that the issue is that right now, end to end encrypted chat apps can use VoIP mode to keep running in the background, so they can receive notifications directly, rather than having to use the Apple Push Notification (APN) service.
If the apps can no longer do this, they will be forced to use APN to deliver notifications when the app is not in the foreground. The result is now the messages won't be end to end encrypted by the app provider; they'll have to go through Apple's servers as well.
Pus
Re: (Score:2)
Some of these apps already use APN. But yes, it is slow, which doesn't matter that much for messaging, but is particularly bad for those that do calling as well. If you don't receive a message for a minute or two, that is not so bad. If you call someone and their phone doesn't even start "ringing" until a minute later, well...yeah.
Re: (Score:2)
This change won't affect actual VoIP calls. It'll affect using the VoIP functionality to do OTHER, non-VoIP related tasks in the background.
Apple has always been notoriously strict about letting apps run in the background. You can really only let apps run in the background for things like playing media (Facebook abused this), VoIP and updating location services. They're just closing some of the loopholes that have existed for a while.
Background execution is also a big drain on battery life; if you've notice
Re: (Score:2)
Apple has always been notoriously strict about letting apps run in the background.
Unless, of course, you're an evil company who will pay them loads of money for abusive levels of privilege. [thenextweb.com]
Re: (Score:2)
Yeah, I can see why Facebook would not like a change that stops them from collecting data in the background... because that’s taking money away from them. But that MacRumors article doesn’t say anything about a security concern being caused by the changes - just that Facebook, Telegram, and Signal will need to be modified so they can still receive incoming calls (and that Facebook wouldn’t be able to collect data while running in the background anymore).
I’m wondering if this original
Re: (Score:3)
You missed the part where app makers like FaceBook is using a feature, VoIP, as a proxy to let it run in the background and continue to gather data, despite what you may or may not want.
Remember how Uber used to require your location data to be *ON* all the time? Yeah, same kind of shit.
Re: (Score:2)
Re: (Score:2)
Other than location, what data can it meaningfully collect while in the background? And what's preventing Apple from simply stopping or throttling location updates for VoIP apps while they are in the background?
IPFS copy of the paywalled article (Score:5, Informative)
Re: IPFS copy of the paywalled article (Score:1)
A better summary/article (Score:5, Informative)
https://forums.macrumors.com/t... [macrumors.com]
What Apple is doing is limiting the PushKit API, which was designed to be used for VoIP calls but over time, has also been used for other purposes such as collecting data and, in the case of messaging apps, encryption. In iOS 13, the PushKit API is limited to internet calls, with Apple eliminating its other uses.
Encrypted messaging apps currently use the VoIP APIs Apple is restricting for decrypting messages on the iPhone in the background, and the change disables that functionality.
Given what's actually happening, I don't fault Apple for enforcing the rules. You are not supposed to use PushKit to do non-VoIP things - though encryption is somewhat in a grey area, perhaps PushKit can be enhanced to add encryption for VoIP...
Re: (Score:2)
The restriction to "VoIP" is the problem.
A messaging program, whether voice or text, whether encrypted or not, is a legitimate use of such a capability.
Setting up a framework that specifies a protocol allowing a direct connection that can wake up a process in the background, as well as re-establish the connection securely as network availability come and goes, without going through Apple servers, is the way this should work. It should not depend on any Apple-specific identity or encryption requirements.
It
Re: (Score:2)
Setting up a framework that specifies a protocol allowing a direct connection that can wake up a process in the background, as well as re-establish the connection securely as network availability come and goes, without going through Apple servers, is the way this should work
The article is about Pushkit. The way pushkit works has always been a push from Apple servers. Focus on the issue at hand instead of creating a new argument that wasn't part of the original debate.
Thanks.
https://medium.com/ios-expert-... [medium.com]
Re: (Score:2)
The thing is, without using PushKit (*), AFAIK, you can't launch your app in the background to retrieve the text of new incoming text messages and post a notification locally, which effectively means that the actual text of that notification has to go through push notifications. That seems like a pretty big reduction in security. Am I missing something?
* ... or the legacy VoIP mechanism, making requests to your own servers and marking them as VoIP requests, though that works only if you link against the