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
It’s all layers of protection and/or trust and compromises.
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.
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.
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).
There's nothing inherently slow about it, anymore than there is anything inherently slow about x86 or ARM.
High performance microarchitecture implementations are definitely possible. Some of them are available for licensing.
At least one of them (Tenstorrent Ascalon) has been tapped out into a chip and will show up in development boards later this year.
It might not be slow forever, but it’s slow now. I’d love to see an open ISA that is fast. But I don’t understand why the industry decided to start over with RISC-V when the compilers and toolchains and chips already existed in power land.
Shrug. The first RVA23-compliant chips are coming soon.
spacemiT K3 imminent (likely shipping boards this month) and Tenstorrent Ascalon (via Atlantis SoC devboard) this summer. These won't be the fastest CPUs available, but they'll meet the "fast enough" criteria for many uses and users.
Multiple parties including Tenstorrent expect performance parity with the ARM and x86 offerings available at the same time by 2028. Note performance is mainly gated by access to latest fab nodes, which comes with costs that necessitate serious volume. They expect to be there by then.
>But I don’t understand why the industry decided to start over with RISC-V when the compilers and toolchains and chips already existed in power land.
The rationale was documented in the "Instruction Sets Should Be Free: The Case For RISC-V" paper[0].
Note OpenPOWER is mentioned but is not in the comparison. The reason for that is simple: RISC-V predates OpenPOWER. It was an obvious reaction to RISC-V, and they were too late, as RISC-V already had the industry's attention. Furthermore, Open is a lie; payment to IBM is required in practice.
0. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
I think that’s a sweeping generalisation.
yes which is why i hoped they would implement a verification system like with a browser addon that compares the website client code used for encryption and alerts the user if it does not match the one served everyone else.
ctemplar mail used to have this many years ago
https://web.archive.org/web/20200201012958/https://ctemplar....
The ones that control whatever source you are pulling the updates from. Very very few people are building everything from source and reading the source in full everytime.
Notice I am not saying this is likely. I am saying that it is theoretically possible anytime you accept code from the outside (doesn’t matter if it is pull or push)
Which ones are these "most distros"?
When you download a program on Linux through the distro package manager, you download it once and run this, every time. You know very well when it gets updated. You can compare the hash of your program/package with the one distributed by the distro, and the distro is not the developer of the program (so there is another layer there). You can audit that code (if open source), and at the very least you can compare with others to see if they receive the same code. And again, the program is served by the distro, not by the developer. The backdoor situation would require asking the developer to implement a backdoor, and then asking the distro to server you a different executable, and then hoping that you never, ever check the hash of that program that you own offline. It's a lot harder.
In a way, for ProtonMail (in your browser) to be "end-to-end encrypted", you have to trust Proton. But that kind of defeats the purpose of end-to-end encryption.
Same applies to e.g. WhatsApp Web, which is an interesting example because there exists a browser extension allowing you to "validate" that you run the code Meta expects you to run. Though you still have to trust Meta: the extension only helps making sure that nobody other than Meta is abusing you. The WhatsApp mobile app doesn't have that problem, as it is distributed as an archive by a third party (Play Store).
Yes, and every VPN in the world (that isn't self-hosted) relies on trust that they won't share your info, not even your fingerprint - which defeats the purpose of VPNs. It's very hard to have perfect security. OK, impossible.
My point here is that when you run a webapp from a browser, you have to trust the server. When you run a program that you download on your system, it's easier to check that it doesn't change and to make sure that others get the same one.
If it's "Google knows too much and I want an alternative" Proton is great, cheap, and convienent. If it' "my own government might kill me" then it might be time to think about self hosting.
I think that Proton does a good job with the suite (docs, sheets, calendar, password manager), and I believe they have a good VPN (for what we may expect from a VPN).
Interestingly, Proton started with ProtonMail, and I find it's the least convincing of their products:
1. As an individual, writing from your ProtonMail account to (probably) someone on GMail doesn't change anything.
2. As a company, writing from Proton to Proton is a good idea, but there is no need for end-to-end encryption: just choose a mail provider you trust, I guess?
3. The ProtonMail end-to-end encryption in the web browser defeats the purpose of E2EE: you have to trust Proton anyway, because they serve the code every time your employees load the page.
I think that would be widely decried especially on HN if that is one day implemented.
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.
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!
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.