Did you entirely rewrite the application and then release the update with the update log: “* Stability improvements related to message sending.” ???
Edit: to cancel out the negative sentiment, good job. I personally don’t really interact with the app enough to notice that it’s changed, but if it needed to be done and you did it right, I commend you! Just seems a bit weird that the “what’s new” message is so bland. Is it even for the most recent version? The release on GitHub has a completely different changelog.
I think by client you mean the device and operating system, which is correct to my understanding, but it’s confusing because ‘client’ can also mean the VPN client software which is often supplied by the VPN provider, and that’s what I first think when you say client. So with that in mind it sounds like you’re saying “it’s not about the VPN but the VPN software” which obviously comes from the same provider.
I have not looked into it so you probably understand this more than I, but from the sound of it the VPN software can be built to detect, prevent or counteract the exploit even on affected systems? In which case, even though it’s an environment issue it can still be resolved by the VPN provider.
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
I did not look into that setting that minimises the effect but from the way it’s written it sounds like this isn’t used by default, so by default you’re still vulnerable. Add even if it’s on, there’s still a side vulnerability.
Depending on what its purpose it, it likely needs to be unencrypted (or at least decryptable by the operator without the user’s key) in order to function. A recovery email likely needs to be used precisely when you don’t have your password, so it can’t work if it’s encrypted with your private key.
I suppose this isn’t necessarily obvious to a user but it’s not a flaw or fault of Proton, it’s unavoidable if a recovery email is used. Note that it’s optional to add one (see article update).
By the way they have a feedback system https://protonmail.uservoice.com/forums/932839-proton-drive
If you don’t want all your camera photos backed up, I think you can select a different album (or multiple albums) to be backed up instead. Albums are just subfolders of the DCIM folders.
If you do that, you can back up specific photos by moving/copying them to the album that gets backed up.
I never tried it though so perhaps it’s not as straightforward.
By the way, regarding the issues of this post, I’m in contact with Proton support. They haven’t been able to replicate the issue but they sent me a version of the app that can save debug logs. When I get anything conclusive I’ll post an update.
Thanks. Maybe it does, but as you say that still doesn’t explain it and it should still have ample space. Most of the files are photos or very short videos, and it’s definitely uploading them in order. It wouldn’t parallelize more than, say, 5 at a time. As my OP says it completely skips the biggest videos, so it has a cutoff of (I’m estimating) 5GB or so? So at worst it’s going to deal with two 5GB videos and 3 relatively tiny photos/videos simultaneously. 55GB is plenty for this scenario.
Also, this doesn’t mean much but it doesn’t feel like it’s parallelized. I think it’s just doing them sequentially. Just my hunch though, nothing conclusive.
99% full was when Proton Drive was using all the storage it could before it gave up. Half the reason I want to use Proton Drive is to free up storage space on my phone.
Edit: and factually it works if I just tell it to retry (until the next time it runs out of space) so any excuse you make for it is nonsense. I hope Proton support/devs would take this more seriously than that.
Unrelated to that, I think I’ve found a bug: every once in a while, the process stops, complains about low device storage and I have to push “retry” - after which it keeps going. It seems like the app doesn’t clear its temporary files until it fails due to low storage. I can see the app’s size growing and growing to over 50GB - which at the moment is all the free space I have - and then, when it hits the wall, suddenly shrink back to 144MB. The largest single file in the Camera folder is 17GB. Then I have to open the app manually and tell it to retry. This means I have to babysit it and can’t have it back up everything overnight.
Edit: app version is: Proton Drive 2.3.1. Phone is Samsung Galaxy S22+, OneUI 6.0, Android 15
Another edit: I am now seeing this happen while the app should be idle! Its storage usage just keeps climbing and climbing.
Yes, it is concerning. I don’t remember where I read this, but someone was saying that their account was falsely flagged for suspicious activity and they lost access to everything, including Pass. Very similar to what can happen on Google. I don’t want to say much more details as I might be misremembering and don’t want to spread misinformation.