Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I'm not really quite sure the point you're making here, but the VPN vendors don't have responsibility to the API viability within IOS. They just secure themselves. If IOS doesn't work right, or they can't get network routing correct at the core level of IOS, or IOS can't route data consistently using the VPN, that's not an ISVs fault. All an ISV can do is utilize an API, provided by Apple, written by Apple, supported by Apple.

Edit: My quote was that the VPN in and of itself is secure - it does what it attests to do. At least on operating systems other than IOS. Because... APIs. Considering that multiple VPNs have this issue with IOS based VPNs, at least from where I'm sitting, this isn't a VPN problem. It's an Apple problem.
I'm not well versed in the API. But is there an API function that forces all network connections to be dropped? Or is there a sequence of API functions that forces all network connections to be dropped? If there is such an API function, or such a sequence of API functions, does this API not do what it claims to do?

So:
1. If there is such an API and it doesn't work (well), this is on Apple. So, Apple is to blame if this is true.
2. If there is no such API, there is no defect and this is on the VPN vendors as they are making a claim that they can't make. There is a request to provide the API in this case, and in this case Apple has chosen not to implement it. That is bad on Apple. Both the VPN vendors and Apple are to blame in this case, although I would put more of the blame on the VPN vendors for selling something that they know won't work 100%.
3. If there is such an API and it does work well when implemented correctly, the 2 VPN vendors (at least 2) are doing something wrong. The 2 vendors are to blame in this case.

The information I have read so far doesn't make it clear what situation we are in, and who should get to work.
 
From reading the article it only leaks data if you’ve previously established a connection before the VPN started.

So if you have booted your phone and started a VPN and never turned it off, it doesn’t leak right?

Do people turn on and off their VPN routinely? Maybe if you do that you have problems…

It’s seems just never turn your VPN off and it can’t happen.
That was one problem, but it was also leaking for new connections in certain cases. Not using VPN for mail traffic and still using non-VPN DNS for a lot of traffic. It would still leak in this scenario.
 
I'm not well versed in the API. But is there an API function that forces all network connections to be dropped? Or is there a sequence of API functions that forces all network connections to be dropped? If there is such an API function, or such a sequence of API functions, does this API not do what it claims to do?

So:
1. If there is such an API and it doesn't work (well), this is on Apple. So, Apple is to blame if this is true.
2. If there is no such API, there is no defect and this is on the VPN vendors as they are making a claim that they can't make. There is a request to provide the API in this case, and in this case Apple has chosen not to implement it. That is bad on Apple. Both the VPN vendors and Apple are to blame in this case, although I would put more of the blame on the VPN vendors for selling something that they know won't work 100%.
3. If there is such an API and it does work well when implemented correctly, the 2 VPN vendors (at least 2) are doing something wrong. The 2 vendors are to blame in this case.

The information I have read so far doesn't make it clear what situation we are in, and who should get to work.
There is an API, but that doesn’t help. If you read the whole article (yes it’s long), it allows some new connections to bypass VPN. App Store Review doesn’t verify the VPN works as advertised and actually protects privacy, so no protections that APIs are used properly. All these VPN clients are effectively scams as advertised (something the App Store is supposed to filter out), but there likely isn’t a way to offer a working VPN service for privacy on iOS.
 
Last edited:
If you have root access like in a Unix system, sure, you can terminate any connection you like. Giving any application in a mobile device the ability to terminate any connection is not a good thing. For one, this breaks the sandbox restriction.
Application, yes, I agree, but most apps don't have root access. The OS is got to be able to do that, up to and including when a VPN gets established. And that means the app has to be able to ask the OS to do it.
 
Most of my experience with android phones has been with Samsung because they’re the most popular android phone at least in the USA. They are stable in the sense of the phone doesn’t crash but responsiveness when you click something is nowhere near iPhone and some applications just don’t seem to work as well. I think it’s gotten better but not quite there yet.

I wouldn’t consider any android phone running Google’s version of android private. Maybe private from bad guys trying to get your information but not private from your information being sold to advertisers or governments. Of course there are other versions of android but then you start losing some of the convenience. I think that might be the way to go if you’re really worried about privacy.

With Apple the only privacy protection you have is your information isn’t going to be sold to advertisers. That’s not because of any noble belief Tim Cook has but rather Apple isn’t into the advertising business like Google is. This could change and there’s been talk about it.

Why do people think VPNs increase privacy. People have watched way too many YouTube ads or YouTube content creators pitch VPNs as this miracle privacy solution. It does not increase your privacy and it could decrease it. You are preventing your ISP or cellular provider from reading your traffic but now that VPN provider can do it. I trust my cellular provider more than my VPN provider and I don’t trust my cellular provider at all when it comes to not selling my information.
Well, as a corporate guy I can tell you why I use a VPN. It's to mainly protect the corporate goodies, i.e., to not allow direct access to our servers from the internet. Every second of every day there are the script kiddies scanning everything they can scan, and the traffic is tremendous, almost a DoS type thing. I'm not that worried about them getting in, but I really don't even want them to see anything to keep them from the constant attempts.

It also protects the other side somewhat from TCP them having sensitive information just grabbed from whatever LAN they are on.

So it's more of a protection thing than a privacy thing. (and I control the VPN servers, so I don't have to worry about trusting a third party. :)
 
I'm not really quite sure the point you're making here, but the VPN vendors don't have responsibility to the API viability within IOS. They just secure themselves. If IOS doesn't work right, or they can't get network routing correct at the core level of IOS, or IOS can't route data consistently using the VPN, that's not an ISVs fault. All an ISV can do is utilize an API, provided by Apple, written by Apple, supported by Apple.

Edit: My quote was that the VPN in and of itself is secure - it does what it attests to do. At least on operating systems other than IOS. Because... APIs. Considering that multiple VPNs have this issue with IOS based VPNs, at least from where I'm sitting, this isn't a VPN problem. It's an Apple problem.
It also makes one realise that the average consumer really has no way of verifying just how well a VPN works on any device. We are just supposed to trust them (and the random tech YouTubers) that it will protect our privacy on untrusted networks.
 
It also makes one realise that the average consumer really has no way of verifying just how well a VPN works on any device. We are just supposed to trust them (and the random tech YouTubers) that it will protect our privacy on untrusted networks.
That's a very common problem for the masses on anything. And there's no fix possible other than all the companies being truthful and trustworthy -- like that's ever going to happen.
 
  • Like
Reactions: BigMcGuire
Application, yes, I agree, but most apps don't have root access. The OS is got to be able to do that, up to and including when a VPN gets established. And that means the app has to be able to ask the OS to do it.
Isn’t this the same? If an app can ask the OS to drop all connections, all apps can. Bad actors would love this.
 
I understand what you are saying, but I cannot imagine this is not a security risk. It makes me wonder what information is being sent over the connections not taken over by the VPN.
You know that the information leaving the VPN provider network will be equivalent to as if it’s leaving the device’s network provider? Using a VPN provider for Internet access only encrypts the data between device and VPN provider’s network. Once the data leaves the VPN provider network, if it’s not secured (e.g. with TLS 1.2) it’ll be in the clear.

How is using a VPN service for Internet access any more secure? It sure is slower tho., and battery life will be worst.
 
There is an API, but that doesn’t help. If you read the whole article (yes it’s long), it allows some new connections to bypass VPN. App Store Review doesn’t verify the VPN works as advertised and actually protects privacy, so no protections that APIs are used properly. All these VPN clients are effectively scams as advertised (something the App Store is supposed to filter out), but there likely isn’t a way to offer a working VPN service for privacy on iOS.
I read the ars technica article and the blog by Horowitz. Nothing in either article discusses anything about APIs. Horowitz has a mix of results and a mix of complaints. He talks about "the bug" without making it clear what exactly "the bug" is according to him.
What is clear from the test, and this isn't new to me, is that Apple directs some traffic outside of the VPN always. I consider this a problem indeed. My perspective is that Apple does this on purpose and doesn't consider this a bug but rather a design decision. Doesn't make it any better, but Apply may not see this as a bug, and won't if they don't want to.
I do see a difference in his results between ProtoVPN and WireGuard. If I interpret his results correctly, WireGuard works better than ProtoVPN. But his style of writing requires me to do a lot of interpretation.

Horowitz kind of makes me wander about his level of expertise when he doesn't know what a SYN request is. A serious TCP security researcher should know this.
 
Finally, someone mentions battery life. I can't be the only one who usually avoids VPN on my mobile device because of battery life concerns. 99.99% of my VPN usage is on my work laptop or personal laptop if I'm on a wifi that is not what I consider to be "safe" - like airports, coffee shops, work conferences, colleges, etc.

My mobile device? Almost always I have cellular and instead of VPN, I'll hotspot to my phone (my preference). I've only really used VPN on my mobile device when out of the country and on wifi that I didn't "trust" that I wanted to be a little more secure with. But I found VPN through my mobile device: 1. Drained the battery like crazy. 2. Usually resulted in telephone line like speeds. 3. Almost unusable internet (in XYZ country).
 
Isn’t this the same? If an app can ask the OS to drop all connections, all apps can. Bad actors would love this.
Not quite, but it HAS to be able to happen, some VPN connections really are needed for security reasons. TCP/IP is designed to recover broken connections -- it's not the worry you're thinking of.
 
I read the ars technica article and the blog by Horowitz. Nothing in either article discusses anything about APIs. Horowitz has a mix of results and a mix of complaints. He talks about "the bug" without making it clear what exactly "the bug" is according to him.
What is clear from the test, and this isn't new to me, is that Apple directs some traffic outside of the VPN always. I consider this a problem indeed. My perspective is that Apple does this on purpose and doesn't consider this a bug but rather a design decision. Doesn't make it any better, but Apply may not see this as a bug, and won't if they don't want to.
I do see a difference in his results between ProtoVPN and WireGuard. If I interpret his results correctly, WireGuard works better than ProtoVPN. But his style of writing requires me to do a lot of interpretation.

Horowitz kind of makes me wander about his level of expertise when he doesn't know what a SYN request is. A serious TCP security researcher should know this.
See this is what I got too. Instead, we had a handful of people early on in this thread screaming about how it was Apple's fault and anyone who didn't think otherwise had their dignity questioned. I don't get that mentality of ... Apple has to be evil and anyone who doesn't agree is an apologist or they've given up their dignity somehow. Several people were claiming that it was the APIs - FOR SURE.

I use NordVPN rarely, maybe a handful of times a year:

1660919971040.png

(Pic from Desktop Mac application - but Mobile application has identical options). Most people couldn't tell you the difference between these options. And from what little I understand - these aren't system called APIs... A post awhile back seemed to confirm that.

I've programmed bitstream compression and encryption utilities using free Google C# methods (back in the day). I've got certs out my ass... So I consider myself fairly well versed in IT security. That said, I'm not an expert on VPNs.

But you know, if you don't demonize Apple - boohoo on you. It's DEFINITELY Apple intentionally not caring. lol. Good grief.


Agreed completely about your post - I would expect Apple to do Find My by any means necessary, etc.
 
I read the ars technica article and the blog by Horowitz. Nothing in either article discusses anything about APIs. Horowitz has a mix of results and a mix of complaints. He talks about "the bug" without making it clear what exactly "the bug" is according to him.
What is clear from the test, and this isn't new to me, is that Apple directs some traffic outside of the VPN always. I consider this a problem indeed. My perspective is that Apple does this on purpose and doesn't consider this a bug but rather a design decision. Doesn't make it any better, but Apply may not see this as a bug, and won't if they don't want to.
I do see a difference in his results between ProtoVPN and WireGuard. If I interpret his results correctly, WireGuard works better than ProtoVPN. But his style of writing requires me to do a lot of interpretation.

Horowitz kind of makes me wander about his level of expertise when he doesn't know what a SYN request is. A serious TCP security researcher should know this.

Neither Horowitz, Proton, any of the publications echo-chambering this story, or even Apple PR themselves, seem to be able to elucidate this issue coherently.

Here’s a write-up from the folks at Disconnect.me;
https://blog.disconnect.me/ios-vpn-leak-advisory/

It’s Apple fault, and if that write-up is anything to go by, it’s a bigger problem than many realize.
 
Not quite, but it HAS to be able to happen, some VPN connections really are needed for security reasons. TCP/IP is designed to recover broken connections -- it's not the worry you're thinking of.
Don’t think you understand where I’m coming from. An app can use the API to disconnect all connections every 5s for example. DOS attack. TCP or not, you can’t use your device.
 
Finally, someone mentions battery life. I can't be the only one who usually avoids VPN on my mobile device because of battery life concerns. 99.99% of my VPN usage is on my work laptop or personal laptop if I'm on a wifi that is not what I consider to be "safe" - like airports, coffee shops, work conferences, colleges, etc.

My mobile device? Almost always I have cellular and instead of VPN, I'll hotspot to my phone (my preference). I've only really used VPN on my mobile device when out of the country and on wifi that I didn't "trust" that I wanted to be a little more secure with. But I found VPN through my mobile device: 1. Drained the battery like crazy. 2. Usually resulted in telephone line like speeds. 3. Almost unusable internet (in XYZ country).
I have done quite a few tests to validate if VPNs make the battery drain faster. I have used VPN 100% of the time for a day, and have not used VPN at all on other days. Comparing between similar days, having the VPN on did obviously use some battery, but in my situation it was never more then 5% on an entire day. Based on these results I have decided to not take battery consumption into account in the decision to (not) use VPN.

Interesting issue: when you turn on the VPN, the battery app will show a lot of battery use for the VPN app. At the same time, my apps are shown as hardly using any battery. All this while the battery goes empty at the same rate as on other days. It turns out that all battery activity related to networking is attributed to the VPN app, rather than to the apps using the network.
Similarly, I recently switched to Lockdown for my VPN. With Lockdown, the Privacy Report is not as useful when using Lockdown. All network activity is attributed to the Lockdown app, so you don't know what app was actually making the calls. I don't think this is the case with NordVPN, my other VPN app.
 
Only VPN apps would be able to do it, and VPN apps get a special entitlement.
VPN apps are supposed to be trusted then? I don’t think it’s as simple as you make it out to be. I don‘t think giving an app to control network connection is a good idea. I fiddle with Linux netfilter as a hobby. It’s not as simple as one think it is.
 
Don’t think you understand where I’m coming from. An app can use the API to disconnect all connections every 5s for example. DOS attack. TCP or not, you can’t use your device.
Yeah, I knew that's where you were coming from. Like I said, a full disconnect has to be able to happen for security, period, but one would hope that the OS was programmed to recognize a DoS type attack like that and block all but the first in a certain amount of time. It would be trivial to do.
 
I have done quite a few tests to validate if VPNs make the battery drain faster. I have used VPN 100% of the time for a day, and have not used VPN at all on other days. Comparing between similar days, having the VPN on did obviously use some battery, but in my situation it was never more then 5% on an entire day. Based on these results I have decided to not take battery consumption into account in the decision to (not) use VPN.

Interesting issue: when you turn on the VPN, the battery app will show a lot of battery use for the VPN app. At the same time, my apps are shown as hardly using any battery. All this while the battery goes empty at the same rate as on other days. It turns out that all battery activity related to networking is attributed to the VPN app, rather than to the apps using the network.
Similarly, I recently switched to Lockdown for my VPN. With Lockdown, the Privacy Report is not as useful when using Lockdown. All network activity is attributed to the Lockdown app, so you don't know what app was actually making the calls. I don't think this is the case with NordVPN, my other VPN app.
I admit, I haven't used VPNs heavily for years now - so this is great news :D Thank you for the info!
 
I admit, I haven't used VPNs heavily for years now - so this is great news :D Thank you for the info!
Really depends on the crypto algo used. Hardware accelerated algo like AES (e.g. OpenVPN, IPSec) will be kinder to battery life. Algo like Chacha-Poly (e.g. WireGuard) are all software implementation AFAIK, so takes more CPU cycles.
 
  • Like
Reactions: BigMcGuire
Yep I already addressed that in a previous post just prior to the one you quoted. The Tor browser on iOS is ok, but it’s not fully baked Tor, and shouldn’t be assumed as such.

Using a vpn on a mobile is fine for non sensitive stuff. If you just want to stream from a different country or hide your activity from your isp to avoid them selling your data or them seeing you watch a bit of porn or something. The issue shown here won’t affect such, frankly, basic unimportant usage.

People suggesting that until this is fixed Apple is literally killing activists and journalists is hyperbole. Becuase these people sat in deepest darkest Russia or China are not sat messaging their whistleblowing secrets via a mobile OS. They are using a secure laptop system running Tor.

Your last paragraph I definitely agree with.

For using a VPN, between travel, financial and other critical personal info, add in work / contract info, I find it a better option to use one. IMPO.
 
Yeah, I knew that's where you were coming from. Like I said, a full disconnect has to be able to happen for security, period, but one would hope that the OS was programmed to recognize a DoS type attack like that and block all but the first in a certain amount of time. It would be trivial to do.
Most DoS countermeasures are of the form of rate limiting. E.g. less than X per second. This is the other way around, as it affect only one. Hard to detect a pattern. Don’t think it’s that easy to stop bad actors. Once the pandora box is opened …
 
First there is this from the article "However, Proton admits that this is not guaranteed to work, while Horowitz claims Airplane mode is not reliable in itself, and should not be relied on as a solution to the problem." Second when did Nord notify you about this workaround?

Why would Nord inform me of anything? It’s Apples API’s at fault? And this work around fixed the issues I had with Nord, I thing else to understand really? I didn’t know of this workaround till I read this article. The solution is for Apple to fix its API’s, but as they haven’t done for over 2 years I won’t hold my breath.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.