Proton Meet Isn't What They Told You It Was
https://www.sambent.com/proton-meet-isnt-what-they-told-you/
Proton built Proton Meet to escape the CLOUD Act. They built it on CLOUD Act infrastructure. Their website promises "not even government agencies" can access your calls. The company routing them hands your call records to the government when asked. Proton hid them from their privacy policy.
Most of the privacy claims (of all type of apps) are essentially garbage anyway because realistically, if a website or an app can be compelled to push an update to a specific user, then they can intercept anything they want.
It doesn't even have to be a specific binary, it can be "just turn on this A/B testing / debug flag for that user" or a piece of javascript
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.
Yes? A/B testing flags, auto-updates, server-side re-routing, etc are just some mechanisms from the top of my head that can do that.
The ways to avoid it is by having locked and cryptographically verified software and connections.
Not sure if that counts as proper evidence, but I have seen some logs[0] albeit with encryption but from my understanding, they control the encryption keys or atleast certainly have the ability to change (if they get hacked themselves for example)
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
That's evidence for the mechanism, as asked
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
You need mechanisms to avoid the possibility. The mechanisms to do such things exist by default, by both the software provider (e.g. Proton) and the software distributor (e.g. Apple for App Store, Google for Play Store, Cloudflare or AWS for web stuff), and various countries have laws that allow them to secretly compel implementing specific backdoors.
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!
>Most of the privacy claims (of all type of apps) are essentially garbage...
True. Everything has backdoored CPUs as its foundation. Consider, for starters: (Intel's 'Management' Engine); AMD's (PSP); Apple/Arm (black-box hardware).
You can layer as much theater as you like on top of the hardware-surveillance-layer in modern computers; it still won't grant you privacy.
China is building out RISC-V, just like they are leading actually-open AI.
https://www.scmp.com/tech/big-tech/article/3347684/alibaba-d...
Weirdly, the authoritarian state is the one saving us from our own digital authoritarians.
> they are leading actually-open AI.
How are they leading? If I parse this correctly, "actually" open would mean fully open data training and weights? Then, by this definition, I'm only aware of Olmo (AllenAI - Seattle), Apertus (Swiss) and to some degree (unclear what data was actually published) Nemotron (Nvda, US). What are some examples of chinese similar models? (I'm not aware of any).
They are very expensive. Cheapest Power9 system Raptor Systems has is $6,794.99 and it has only 4 cores and 8GB DDR4 RAM and 128GB SSD. Reminds me of Sun Sparc pricing.
> Most of the privacy claims (of all type of apps) are essentially garbage anyway
I think that’s a sweeping generalisation.
I once did some tinkering with Proton Docs and I was able to find that the comments within Proton Docs when I used it via curl definitely felt like it had something like logs (I feel like I should try doing this again to have more definitive answer)
Either way, the response was encrypted but they hold the encryption key atleast within proton-docs.
I also want to say that Proton allows the ability to change password through OTP, (Something which I sorta appreciate[0]) but that means that their infrastructure can then have the ability to change password and you can toggle that functionality by sending a request to proton to allow OTP and on which number, so proton themselves can do that too. Unless, I am getting it wrong, by default, Proton still has your encryption keys and even if you change them (which 99% including me might not do), even then I definitely feel like there can be some concern.
To be honest, There is nothing like zero trust, that's what I learnt, You are still trusting Proton Aka The swiss laws behind it so that you know that they won't get legally forced to give more data than usual (like US companies for example) but they will still comply with the swiss laws (recent proton incident)
Then, secondly, you have to trust Proton themselves, but with something like this incident where Proton Meet might be omitting somethings, it doesn't paste a clear picture of transparency or trust.
I don't really know why Proton might create something like Meet especially with its infrastructure relying on the CLOUD Act, and then, try to sell it within the idea of privacy. They both are contradictory.
Proton is, creating lots of products, On one hand I can appreciate that, but on the other, as part of community, I feel frustrated/sad because they don't have some core features like proper proton drive rsync support or even some API[1]'s surrounding it. I tried to do the experiment in first place because I wanted to create a commenting engine for static websites which could use proton-drive as its backend. They really could gain a lot from transparency with proper API support and letting the community do things with it, but that's not really the case :/
I am still using Proton but they definitely aren't a bastion recently. I might still recommend Proton, but I sort of hope that companies self host some open source applications themselves, whether self-hosting with hardware or in a proper EU cloud like Hetzner/OVH.
But Incidents like these are making me a little more hesitant to recommend Proton nowadays.
[0]: as someone who had lost one of my previous accounts after my Keepassxc database got deleted because of me accidentally wiping my archlinux with tinkering with it, Now I use Bitwarden with OTP on proton.
[1]: I was able to make something like an API myself by relying on something like puppeteer, even with puppeteer though, it was really hard to make something like that. I couldn't create a public endpoint of it because having puppeteer instances for a commenting engine would be very resource intensive.
bundie
