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’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.
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.
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.