Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open source server #257

Closed
julianfairfax opened this issue Nov 4, 2021 · 7 comments
Closed

Open source server #257

julianfairfax opened this issue Nov 4, 2021 · 7 comments

Comments

@julianfairfax
Copy link

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
Copy link

ghost commented Nov 7, 2021

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
Copy link
Author

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
Copy link

ghost commented Nov 7, 2021

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants