Is there any evidence that the mechanism to do that is in place?
I think that would be widely decried especially on HN if that is one day implemented.
I think that would be widely decried especially on HN if that is one day implemented.
In order to block the distributor from going rogue, you need to be able to guarantee that the user device can only install/run code signed by the provider, who must never give those keys to the distributor. My impression is that Android is the only major platform that ever had this, but that Google ruined it a few years ago in the name of lighter bundles by insisting that they hold the keys. (I once had VLC from Google Play Store, but replaced it with a build from F-Droid under the same app ID; Google Play Store shows it has an update for it, but that it can’t install it.)
In order to block the provider or distributor sending specific users a different build, you need something more like Certificate Transparency logs: make it so that devices will only run packages that contains proof that they have been publicly shared. (This is necessary, but not sufficient.)
And if you’re using web tech, the mechanisms required to preclude such abuse do not at this time exist. If you’re shipping an app by some other channel, it can do a resource integrity check and mandate subresource integrity. But no one does things that way—half the reason for using web tech is specifically to bypass slow update channels and distribute new stuff immediately!
The ways to avoid it is by having locked and cryptographically verified software and connections.
Would you like to see a proper evidence of the logging policy? I feel like I can try finding that again if you/HN community would be interested to see that.
Edit: also worth pointing out that keeping logs with time might be a form of meta-data, which depending on your threat-vector (journalism etc.) can be very sensitive info.
[0]: my another comment here: https://news.ycombinator.com/item?id=47624960
And how does that compare to other services we have available and people actually use.
Now, My issue with proton is that, they try to appear transparent but a lot of what they've done especially with proton meet seems to sometimes even be misleading. If they couldn't create EU/Swiss sovereign infrastructure for meet, then why are they using Cloud-act providers while within the same post talking about the implications of Cloud Act. There is some great irony in all of this and this is what is making me suspicious and how Proton seems to be misleading people rather than leading them towards more privacy.
At some point, it raises atleast some questions about trusting proton.
> And how does that compare to other services we have available and people actually use.
That depends on what service are you talking about from, Do you want a whole eco-system or are you happy with individual apps/companies focusing on one thing in a more unix-fashion of things.
Do you prefer non-profits or for-profit companies to handle such infrastructure?
How familiar you are with self-hosting and what is your threat vector?
Are you a corporate or a person yourself and what are your budget of things?
but just to give a pointer without asking these questions, Some good pointers are posteo.de, tutanota, infomaniak (has whole ecosystem) Within the calling system, I personally used to use fairmeeting.net, it used to have screen sharing option for free as well but looks like they might have paywalled it recently. You can find multiple jitsi community instances.
I feel like the only way to answer this question is if people ask with more depth. The threat model differs for everybody, for some people (like journalists), even just this proton meet fiasco is enough for them to reconsider proton ecosystem as a whole and consider it too threatening, especially with recent incidents and their lives being on the line. You might say, well where might they go and I feel like they might go to disroot (non-profit activism oriented) or tutanota or even posteo.de depending on what they might prefer.
The evidence that it's being actively used in the US is in the secret proceedings of a secret court. I kid you not, look up FISA warrant
- Linux (apt, pacman, rpm...),
- Android
And I would add Windows and iOS/MacOS but I'm not at all an expert so I leave others to confirm that their "app stores" don't do such exotic prowesses.
You can artificially insert a malicious script in a package that would scan your system, deduce your identity, and install something based on that, but in this case that means that it is just a malware in the first place. And that would mean that the app to be installed contains a "mutable" component of data that is not defined by the contents of the package but rather written upon post-install actions, so that is also dubious to include that for formally in the "app from that package" definition. In any case, such behavior would get your package banned from any app store or Linux distribution.
The US government routinely deploys malware to users devices, for multiple reasons. Here is a 2017 link about this: https://www.aclu.org/news/privacy-technology/challenging-gov...
Because all the other means I can think of are just basic malwarfare.
As you need to rely on a vendor/distributor to get updates, then of course they are able to push you malware, there is absolutely no going around this first ring of trust.
Conclusion : there is no point in accusing Proton of anything... there are just being software providers (FOSS by the way!!!).
- A/B testing is agnostic of who the user is, it is randomized. If it was not, that would be a bad practice and would legitimately ruin the reputation of the company doing that,
- auto-updates is just the setting allowing the most recently published update to be installed. "Published" means it is for everyone. If that is to be understood in any other meaning, that would also be bad practice,
- and I don't see what you mean by server-side re-routing.
To be honest, maybe I just live with different platforms and apps than you I don't know. I use Android, and Linux on my Laptop, but I would also expect Windows to not discriminate by user when pushing updates.