ProtonVPN did an API bump in this version: Version 2.7.56.1 (2021-06-18) which left everyone with an Android version older than AOS 6 in the dust. So I went to the archives and grabbed the version just before that one. Ran it for the first time, configuration wizard had no issues but as soon as I tried to reach out to the server it refused to stand up a tunnel saying my version was too old. Not only did they leave permacomputing folks behind for sustaining their still-quite-functional devices, but they proactively sabotaged us from the server side.
AFAIK they made no excuses for the API bump. The usual excuse is “for security reasons”… yeah… bullshit. Anyway, here’s the workaround:
The absolute latest openvpn app still supports AOS 5 (somewhat suggesting there is no compelling security reason to force AOS 5 users to throw away their devices). Or if you have AOS 4 you can take the openvpn version from 2 years ago. ProtonVPN distributes openvpn config profiles and the openVPN app can simply import those.
Also worth noting that F-Droid warns of anti-features on the ProtonVPN app but OpenVPN is free of anti-features. That said, I got an authentication error, but I doubt that’s related to this procedure.
update
ProtonVPN is possibly breaking EU law. If someone subscribed to service less than two years before the forced obsolescence, ProtonVPN is obligated to continue service as long as necessary to serve the consumer for 2 years.
I’ve not used this service but a quick search suggested to me that they support IPsec, that should be natively supported by most of the legacy android versions.
But if I had to guess without investigation, they may have been forced to raise their SDK version?
IPsec didn’t occur to me. Apparently they don’t show the ipsec configs when desktop users login (I only recall openvpn and wireguard & i’m not keen to check because just about every login results in a CAPTCHA for me).
The older droids (2.3 for sure) had broken built-in ipsec but they probably got it straightened out eventually.
they may have been forced to raise their SDK version?
What do you mean forced? Forced by who? I would not make excuses for pushers of forced obsolescence. It’s on them to explain and make excuses – which is almost always a quite vague “for security reasons”, like every bank that chases the shiny and forces consumers to buy a new phone every 3 years.
Note Protonmail demonstrates this same forced obsolescence pattern with their Mail app, which requires AOS 6.
What do you mean forced?
By the general ecosystem. If we’re honest, Android is mostly developed by Google, and they’re gradually dropping support for the oldest versions.
In short: the more versions you support, the more complicated (and error prone, and subject to potential vulnerabilities) it is. At some point, it’s reasonable for any developer to drop support for versions more than 10 years old to avoid a bloated and error-prone code base.
AOS 5 (Lollipop) was 7 years old when Proton dropped it, not 10. 10 years is also a reckless place to draw that line. That’s Apple’s line.
Permacomputing folks have much higher standards than that of Apple’s corporate bottom line. I am writing this response using 16 year old machine that works just fine, and which will continue to function and serve my needs for at least another 5 years more.
As developers chase the shiny, bloat increases. Protonmail version 1.13.40 (the last AOS 5) was 23mb. The very next version just 3 months later (3.0.1), the first to demand AOS 6+, was 44mb. Yikes. They are welcoming bloat with reckless disregard. The more you bloat the code, the more error-prone it becomes. Bugs are directly proportional to complexity.
I’m not arguing against permacomputing–I’m all for it, and I regularly use hardware 15+ years old myself. But as a developer, you don’t always get to choose whether to “chase the shiny” because the choice is made for you by other entities in the ecosystem.
FYI, the size of an Android app isn’t necessarily representative of the complexity of the app’s code (at least not in the scale you’re talking). I’m guessing the 23mb to 44mb jump was due to targeting a newer API version. That doesn’t mean ProtonMail’s code is more bloated–it could actually be less, while the OS/API side increased. And in this order of magnitude, that size difference doesn’t necessarily indicate increased complexity anywhere–it could simply be an icon pack that’s included by default or something.
Your principles are sound, but you’re oversimplifying your analysis and have unreasonable expectations as to what a for-profit entity will support, especially in the mobile market. You can’t expect to use older hardware in combination with bleeding-edge online services (like VPN)–you’ll have to host things yourself using older versions, find compatible options, or write it yourself.
Hence the purpose of the thread. The OpenVPN devs serve the permacomputing community better than the devs of the ProtonVPN client. The fact that profit motives are the culprit for the forced obsolescence is guesswork. It’s a very good guess but in the end it’s merely irrelevant trivia. They don’t get a sympathetic pass or some different treatment for needing to profit.
You can’t expect to use older hardware in combination with bleeding-edge online services (like VPN)
Yes I can. Hence the purpose of open standards which make that possible. OpenVPN is proven to work on old hardware with current bleeding edge services. I have it working with riseup and getting it working for ProtonVPN is likely a matter seeing if I fat-fingered my password wrong. I have openvpn connecting to protonvpn from other clients already.
I’m guessing the 23mb to 44mb jump was due to targeting a newer API version. That doesn’t mean ProtonMail’s code is more bloated–it could actually be less, while the OS/API side increased.
It doesn’t matter. Introducing code that statically links in more object code is also accountable bloat that brings bugs. Saying that the code is on someone else’s side of the wall does not discount the bug potential amid other downsides to bloat. It’s also notable that AOS 6 was a minor change. It was Google following a one-major-release-per-year pattern, and just making an insignificant release just for optics so people don’t think they’re slacking on progress. Thus speculation that the same source code compiled in the bloat is unlikely. Not long after that release Protonmail makes another giant leap of bloat to 70mb+ with no change in the SDK API target.
The latest Android version obsoleted many apps and the solution was to raise the SDK level. So if that’s what happened I can see how this happened.
What you seem to be implying is that the OS removed an interface that the app is using. That’s unlikely because ProtonVPN needs generally the same facilities and mechanisms as openVPN, which was not forced to bump their SDK. You can also see that the ProtonMail app (which is inherently very different than VPN service) also bumped their version to abandon AOS 5 users a year later. Yet other email clients (which generally need the same interfaces) were not forced to abandon people.
more precisely, the theory I’m trying to express is that Android 15 & 14 has banned loading apps that target much older versions. A decision made by Google, forcing the developer to comply or see their app not work. So in my opinion your grievance should be targeted towards Google. Personally, I’m pissed that most of my humble bundle android apps collection doesn’t work any more because this.
This does not explain the fact that ProtonVPN’s server proactively refuses to serve users of their client version 2.6.91.0 (which is the last to target AOS 5). Google has nothing to do with that.
But also, if your theory is correct then openVPN fails to install on Android 15 & 14, correct?
