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. 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.
Relying on Apple is about as smart a business strategy as trusting a scorpion to carry you across the river.
I refuse to be pushed into giving them my e-mail address. Mind summarizing what the change actually is?
You know can get a throw away email for free right?
I’m the master of throwaway e-mails (both SpamGourmet and the “Bloody Vikings” Firefox extension) but…
1. I don’t think it’s right for a site to link to an article that does that without quoting/paraphrasing the bit of info that they’re holding hostage.
2. I just don’t care enough. Replying to you here was a simple matter of leaving the tab open while doing that would involve using Bloody Vikings, going over to the disposable account, etc. etc. etc.
I second this. Also, what irony needing to give an email address to read an article and user privacy!
Alas, entering garbage data in the email field still works…
I don’t really get the arguments being made on either side. I get that pushkit API encrypts traffic, and apps can use it to send any information about the user including potentially location information or private data….Ok, but I really don’t understand how apple disabling pushkit would address apple’s concern in any way, shape, or form…the apps still have access to the data, so what is stopping them from transmitting it in channels other than pushkit? Because logically if apple doesn’t try to block all channels that could leak the same data, then I don’t understand the point of blocking this channel on these grounds? Can anyone think of a legitimate reason, or is apple using this to cover up some other motives?
Also, on the other side of the argument, while I see that apple removing an encrypted API is frustrating for devs, what’s stopping them from just using another crypto library (openssl/gnutls) to do it instead of pushkit? It might even be more secure this way. Does anyone know if apple prohibits developers from using 3rd party crypto? If they do, then yes I agree with the developers who are alarmed, but otherwise is there another technical reason they needed pushkit?
Well, that’s no stranger than so-called private messengers requiring a phone number, to be fair.
darknexus,
One of my clients was offshoring some work to an indian team (not newsworthy I know) and they wanted to use whatsapp. I took a look and whatsapp doesn’t provide a linux client, so I asked them to use a normal phone number but they said no b/c it costs too much. So I reluctantly go and install whatsapp on windows only to learn you can’t create an account on windows, they force you to use a smart phone. Now I have a phone number for the business, but it’s not a mobile number and I’m not about to use my personal phone for business, so I tell them that I can’t jump through whatsapp’s hoops and quite frankly whatsapp is not suitable. We end up using skype, haha.
Next time someone asks me to call them with whatsapp I’m saying ‘no’ strait away…
What privacy are you giving up with a throw away email address?
Did you mean to reply to ssokolow? I’m pretty much on the same page as him and consider webpages that demand email addresses to be a public nuisance. Sure you can give them garbage data, but even then they are still a nuisance.
I have some understanding.
+ pushkit does its work in the background. This means that any app that uses it sucks battery even when the app is not in the foreground. IOS has some cleaver tools to limit batter consumption, but pushkit is a work around.
+ pushkit, I think, not 100% on this, also allows applications to work around the requirement of getting permission to use location data when the application is not in use. Because, with pushkit, it *Is* in use even though its not in the foreground. There is a difference between allowing an app to get a moment in time snapshot of where I am, vs an always on beacon that tells companies where I always am.
Bill Shooter of Bul,
Ok, so it seems this is more important on IOS due to the fact that these APIs are used as a workaround for background task limitations on IOS, like the ability to receive TCP data.
https://stackoverflow.com/questions/5840365/how-can-an-ios-app-keep-a-tcp-connection-alive-indefinitely-while-in-the-backgro
https://stackoverflow.com/questions/31815702/ios-how-to-keep-tcp-socket-and-the-nsnetservice-working-when-the-app-is-in-the
This to me seems like the real issue: not privacy, but the inability to process new events in background tasks. I’ve got to side with the developers on this one, they’re only misusing APIs as a workaround for IOS limitations. And if apple doesn’t provide any legitimate alternative, then IMHO they’re the guilty party here.
That sounds completely plausible, however I have a problem with apple insisting they have to eliminate pushkit rather than fix it. If apple wanted to stop background apps from obtaining user location data from IOS, then of course apple’s developers would be able to do that if they were instructed to. So my gut feeling is that this has nothing to do with the reason apple is removing pushkit..
So under the current set of facts, the allegation that apple is doing this to impede competing messaging platforms seems to be the most logical reason behind apple’s decision to pull pushkit (see what I did there ).
https://www.idownloadblog.com/2019/08/06/ios-13-background-activity-whatsapp/
I don’t think this change “undermine the privacy goals”… may be it will undermine the user experience of VoIP calls but has nothing to do with security and privacy
I don’t think it was the scorpion doing the carrying :).
that was my reaction to all this as well.
man, frak these pay/spamwalls.. although i’m not convinced that this article is worth the read anyway..
EDIT: after reading the comments it’s even more obvious. i tried blocking the blur with adblock plus’s element hiding helper but ended up killing the page. oh well. xD