ProtonMail / WebClients

Monorepo hosting the proton web clients
GNU General Public License v3.0
4.27k stars 545 forks source link

Open source server #257

Closed julianfairfax closed 2 years ago

julianfairfax commented 2 years ago

ProtonMail is committed to open source, but your server is still closed source. One of the main arguments I've seen for this is that open sourcing it would make your anti-spam features useless. I agree with this argument, but I'd like to present another case: Signal is committed to open source, and their server is also open source. They had a problem with spam but to fix it would require closed source code. So what they've decided to do is add one closed source component to their otherwise open source server for anti-spam: https://signal.org/blog/keeping-spam-off-signal/. This means it's not possible to browse the source code or self-host their anti-spam component, but the rest of the server is open. If ProtonMail were to take this approach, you would be taking an important step forward in open source and privacy for your service, and you would still be able to maintain your anti-spam features. Thank you for all you've done with ProtonMail, and I really hope you consider taking this approach!

ghost commented 2 years ago

This is most likely impossible because not only anti-spam technology is proprietary, but also some other components (especially the core technology) are. And a lot of those technology are NDA-ed and only accessible to core developers. So most likely this issue will only be closed/ignored.

By the way there is no way to verify if the backend is running the same code as presented even if they ever open sourced the backend since you simply do not have access to their servers (and you will not, because they are highly secured).

julianfairfax commented 2 years ago

This is most likely impossible because not only anti-spam technology is proprietary, but also some other components (especially the core technology) are. And a lot of those technology are NDA-ed and only accessible to core developers. So most likely this issue will only be closed/ignored.

I don't know how they do that internally so you may be right.

By the way there is no way to verify if the backend is running the same code as presented even if they ever open sourced the backend since you simply do not have access to their servers (and you will not, because they are highly secured).

It's still a step towards more trust, and it allows self-hosting.

ghost commented 2 years ago

It's still a step towards more trust, and it allows self-hosting.

Unfortunately self hosting is most probably likely not going to happen. A previous issue for on open sourcing the backend for self hosting was closed without any explanation/comments (#12).

bartbutler commented 2 years ago

Hi Julian,

I don't think we'll be doing this any time soon, for a couple reasons. While open source is great and we use and contribute back to many, many open-source projects, maintaining one the size and complexity of Proton does involve significant initial and continuing investment for the dev team, which we can't afford now. While we do have internal "dev" configurations of our backend code for developing, our software in production mode is designed to run on our infrastructure at scale and will continue to be written to that aim, so extracting a version which is runnable by others that has full, non-mocked functionality without the thousands of lines of supporting infrastructure we have is not something that we are ready to invest in.

Second, there's no trust advantage here because the what is running on the servers is fundamentally unverifiable by the client. As a result, we've engineering our clients and APIs to have to trust the servers as minimally as possible, but publishing something won't change anything.

Finally, from a business perspective, we are trying to be successful in a market where our largest competitors are "free" (that is, service in exchange for ads/data). Enabling self-hosting or giving a leg up to would-be competitors by open-sourcing our entire stack doesn't seem like the right move to protect our own viability as a company.

Sorry for the disappointing answer, and thanks for you support!

dylangerdaly commented 2 years ago

You mention the client distrusting the server, however the JS that's used to preform client side decryption of messages is provided by... you guested it, the server.

It should be possible to upload only the pubic key portion of a GPG Keypair at the very least.

bartbutler commented 2 years ago

Yes, the web client threat model is different than that of the native clients, we are working on a way to address that if we can.

Not uploading the encrypted private key would negate the one of the main advantages of Proton, namely the automatic (and trustless) key synchronization between multiple clients of the keyring. It would also make the clients not work at all unless those keys were manually synchronized, which would be a UX nightmare.

AddoSolutions commented 5 months ago

I am more interested in where my data lives – from a business perspective, I would be willing to pay for the privilege of hosting my own email data.

I’d also be okay if it had a basic spam “module” but expected spam filtering to be done beforehand.