> Is there anything preventing Proton from disclosing the email content or metadata?
Mmh.. The fact that it is encrypted client-side ? I mean the code is open-source fgs. [0][1][2]
[0]https://github.com/ProtonMail/android-mail
[1]https://github.com/ProtonMail/ios-mail
[3]https://github.com/ProtonMail/WebClients
In Proton meet isn't what they told you it wasProtonMail
WebClients
TypeScript2016–2026
ProtonMail / WebClients
WebClients
Monorepo hosting the proton web clients
25Distinct people
27Mentions
0Explicit recommenders
5.7KGitHub stars
What to know before exploring
What it is
Monorepo hosting the proton web clients
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2016-03-17 18:55:54 UTC to 2026-04-03 13:40:33 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Web clients
This project is a monorepo hosting the Proton web clients. It includes the web applications, their dependencies & shared modules as well as all tooling surrounding development of the web clients (as well as some additional miscellaneous things).
Proton Mail
Proton Calendar
Proton Drive
Proton Account
Proton VPN
Proton Pass
Proton Wallet
Proton Lumo
Proton Meet
Technically, this monorepo is based on pnpm & pnpm workspaces, with unified versioning for all packages inside.
Getting Started
Prerequisites
You'll need to have the following environment to work with this project:
Node.js satisfying engines.node in the root package.json (a .node-version file is provided for fnm, mise, and similar tools, and a matching .nvmrc for nvm — keep both in sync)
pnpm satisfying engines.pnpm in the root package.json (install with your preferred method, e.g. npm install -g pnpm)
git
CI installs the exact pnpm version from the packageManager field; locally, any version that satisfies engines.pnpm is fine. Wrong package managers are rejected at install time (preinstall), and engine-strict=true in .npmrc makes pnpm install fail when Node or pnpm is below the declared floors.
Installation
# Clone the project
git clone https://github.com/ProtonMail/WebClients.git
git clone git@github.com:ProtonMail/WebClients.git
# Install all dependencies for the entire monorepo & symlink
# local dependents to one another
pnpm install
# Run web clients by running proton-<package-name>
# Example: proton mail web client
pnpm --filter proton-mail run start
For additional details on how to interact with the monorepo, see the pnpm docs for reference.
Shared dependency versions (catalog)
Every workspace declares the dependencies it imports. When many workspaces declare the same dependency and must stay on the same version, the range lives once in the catalog: section of pnpm-workspace.yaml, and each workspace references it with "catalog:" instead of a range:
"devDependencies": {
"@types/node": "catalog:"
}
Use catalog: when:
the dependency is declared by several workspaces (as a rule of thumb, three or more), and
they have to move together, for example the @types packages that tsconfig.base.json lists in compilerOptions.types, or a package where two versions in the tree would break things.
Declare a plain range instead when:
only one or two workspaces use the dependency;
a workspace deliberately needs a different version (for example utilities/lumo-dev-proxy keeps @types/node@^22);
it's another workspace: use workspace:^;
you need to pin a transitive dependency, for example for a security fix: use overrides in pnpm-workspace.yaml, since the catalog only applies to workspaces that reference it.
To add an entry, add the range to catalog: and switch every existing declaration of that dependency to "catalog:" in the same change. To bump it, change the range in pnpm-workspace.yaml only. Either way, run pnpm install and commit the updated pnpm-lock.yaml with it.
How VPN app differs from the rest
VPN is present in both proton.me and protonvpn.com. However, they are served differently. Some parts of VPN are shared, hosted within @proton/components or @proton/shared, however, the entry points to them are different.
For protonvpn.com, the entry point comes from applications/vpn-settings and for account.proton.me/u/{X}/vpn, the entry point is applications/account.
Since both domains are separate, we don't share a local SSO between them. Therefore, we need to serve both applications separately:
# To serve VPN through vpn-settings
pnpm --filter proton-vpn-settings run start --port 8050
# To serve VPN through account
pnpm run start-all --applications "proton-account"
How to version an application manually
While being on the main branch for a clean release.
From the root folder, run pnpm --filter @proton/version run version --applications proton-X --version x.x.x.x
Help us to translate the project
You can learn more about it on our blog post.
License
The code and data files in this distribution are licensed under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. See https://www.gnu.org/licenses/ for a copy of this license.
See LICENSE file
Read the full README on GitHubWhat Hacker News says
27 sourcesIf you want to stay with the convenience of cloud without going back to sync conflicts due to moving a file around, Proton Pass is GPLv3 although I don't personally know what the self hosting story is like if they were to rug pull
https://github.com/ProtonMail/WebClients/tree/proton-pass%40...
https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...
https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE
In Bitwarden is no longer free softwareThis is their monorepo for their clients, including Proton Drive:
https://github.com/ProtonMail/WebClients
In Proton launches its own version of Google DocsProton does a lot of open source washing. Their public communication often mention that they are open source, while in reality only some of their clients are open source and the uploaded source code[1] often lags behind by months (currently 3 months).
[1]: https://github.com/ProtonMail/WebClients
In Proton launches its own version of Google Docs> Is this password-derived key the "account key" which I see in the Proton Mail settings interface?
No, the account key is an OpenPGP key which is encrypted with a key derived from your password. The "key encryption key" is not separately visible. The address keys are in turn encrypted using the account key. (The account keys are also used to encrypt your contacts, for example, which are shared between all your addresses - while the address keys are specific to an email address and are used to encrypt emails etc.)
> Please clarify what key derivation function is being used.
We use bcrypt, in addition to the OpenPGP S2K (i.e. the bcrypt output is fed as the "password" to OpenPGP's key encryption).
We are in the process of rolling out updates to OpenPGP.js and GopenPGP which support Argon2 for the OpenPGP S2K step, after which we'll start u
Read the rest
sing that - but we aren't quite yet.
> Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.
Take a look at https://github.com/ProtonMail/WebClients/blob/main/packages/..., for example. Though to be honest, if you want to verify that we aren't sending the password to the server anywhere, in principle you'd have to check the code of the entire web app (or whichever app you're using). It's all open source, but it's a lot of work, of course. But you can also check the latest audit report: https://proton.me/blog/security-audit. They also verified all of this stuff.
> It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. (...) So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account.
Yeah, I understand. Though the typical advice from a cryptographer's perspective would be, it's better to use separate keys for separate purposes; and the simplest way to do that is to generate separate OpenPGP certificates, so that's what we'd generally recommend. But, if you want to generate separate subkeys and sign them all using a common primary key, that's also reasonable enough. And, we can improve the documentation on that, although it's a bit of a niche use case (not for HN of course, but for the general audience it is).
> Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.
Thanks, glad to hear! :)
> Finally, in keeping with our long track record of transparency, Proton Pass is open source so anyone can review and verify our security architecture
They sure do enjoy writing that sentence without including any hyperlinks. This (https://github.com/ProtonMail/WebClients/tree/main/applicati...) appears to be the browser extension and https://github.com/ProtonMail/WebClients/tree/main/packages/... looks like the backend that's referenced in the extension's readme, but that pass directory's readme is zero bytes so (shrug)
In Proton Pass launched – Protecting your passwords and online identityOne possible mitigation to this would be to let customers deploy ProtonMail's open-source client [0] themselves to wherever (as one example, this is something that TermPair implements [1]).
[0] https://github.com/ProtonMail/WebClients
[1] https://github.com/cs01/termpair/#static-hosting
In Clarifications regarding arrest of climate activist> Truly secure entity just wouldn't have private keys on a server at all.
They don't. They have your encrypted private key, but there's no need to keep that secret. (The decryption key is derived from your password, so the password needs to be strong and secret.)
> Such agency can force PM to modify login process to derive password from submitted form, or to just switch private keys for non-encrypred ones, because the user won't even notice it.
Yes, definitely. It's hard to trust self-updating software (like JavaScript in the browser), particularly if you're concerned about targeted attacks. But creating your own private keys and then entering them in the browser wouldn't help you at all against that sort of attack. You would instead need a different type of client that could be trusted somehow not to leak your private key.
It's not uncom
Read the rest
mon for services like this to offer a downloadable version of the web client so you can pin a version and audit the code as needed. I think maybe https://github.com/ProtonMail/WebClient is that for ProtonMail? If so, you should be able to verify that code and then use that. The fact that an encrypted copy of your private key will live on ProtonMail's servers shouldn't bother you.
> a new protocol that can degrade gracefully
Does Autocrypt meet that definition?
https://autocrypt.org/
Sadly, for the last 3 years, ProtonMail has resisted implementing it (unlike Posteo, for example), using FUD tactics to justify themselves:
https://github.com/ProtonMail/WebClient/issues/120
In The new ProtonMail has passed its independent security auditProtonMail includes Google Recaptcha for login
287 points · Open discussionWell, if something like this doesn't get caught down the production line, they might have bigger issues regarding security.
But I agree with you, I think I should give them a chance to respond to this. Personally, I think this is a serious issue.
I opened up a GitHub issue for their frontend (as they do not have any security disclosure contact possibility as it seems): https://github.com/ProtonMail/WebClient/issues/242
In ProtonMail includes Google Recaptcha for loginComment on ProtonMail's password-based key derivation (by Solar Designer)
2 points · Open discussion> We have email with autocrypt to rally to.
For those unfamiliar:
https://autocrypt.org/
There are plans to add support for it to Tutanota[0], although ironically that blog post was written over a year ago and their FAQ still says that they don't even support interoperable PGP.[1]
When ProtonMail were asked two years ago about supporting Autocrypt, their response was quite negative but also vague[2], and there doesn't seem to have been much progress since.[3]
[0] https://tutanota.com/blog/posts/email-encryption/
[1] https://tutanota.com/faq/#pgp
[2] https://old.reddit.com/r/ProtonMail/comments/8dqk5n/protonma...
[3] https://github.com/ProtonMail/WebClient/issues/120
In EU citizens’ rights are under threat from anti-encryption proposalsThat particular part is detailed on the knowledge base [0], so... Yes? For just this bit.
But I don't think the full API is documented. There are some attempts to reverse engineer an API from the WebClient [1], but they tend to be... Brittle.
[0] https://protonmail.com/support/knowledge-base/download-publi...
[1] https://github.com/ProtonMail/WebClient
In Solarwind, Fireeye, Microsoft and Cisco leaks are offered for saleProtonmail's email encrypted in the browser! Their client is open source:
https://github.com/ProtonMail/WebClient
It is main reason to use ProtonMail over Gmail.
In Firefox’s Test Pilot Program ReturnsShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.