Proton Mail discloses user data leading to arrest in Spain (2024)

It seems there is some mental conflict going in readers between the reality of what ProtonMail does for its customers and their expectations of what kinds of protections a legitimate business can provide.

Both ProtonMail and Apple will challenge subpoenas when they believe they are not valid, however neither company has the final say in the matter and can be compelled to provide access to data that they reasonably have access to. It is up to the user to plan what information they provide to service provides in order to not leave a trail of crumbs, and also evaluate what kind of man-in-the-middle weaknesses a service might have for the possibility of wiretapping. It should go without saying that linking a phone number or back-up email address can be a pretty large crumb.

The learning here is to recognise that these services can be compelled to provide whatever small information that they have reasonable access to, and that this information may be useful in unmasking an identity.

I suppose the second learning is to elect governments which respect democratic freedoms, even if that puts them on the back foot.

I don't think this is solely the issue that users don't understand that the companies are obliged to provide the data requested by the authorities.

The whole controversy surrounding Proton started when they marketed themselves as "secure and private email", promising they would NEVER give away their users' data, until they did. I had a similar discussion with my friends today about this topic and the issue I have with it is that Proton tries to market itself as an email which will never snitch your data to the authorities. And we've seen countless times (they have provided data to almost 6k requests last year) that this isn't the case.

The problem as I see it is that Proton is not even trying to challenge the requests anymore. It's not like Tuta, who you can read on the news that they keep challenging almost every order they get from the authorities, even if they lose the battle in court: https://techcrunch.com/2020/12/08/german-secure-email-provid...

As I read on a website comparing "private email services", the question here is not whether a service provider will or will not abide by the court requests. It's whether it will do anything to challenge it or just giveaway the data without questions asked.

I disagree, while the marketing is carefully worded, it doesn't say that and both Proton's privacy policy and their transparency report detail what kinds of information they gather and how often they hand over that data.

https://proton.me/legal/privacy

https://proton.me/legal/transparency

I standby the assertion that people will believe what they want to, despite there being easily accessible information that contradicts those ideas.

Tangent: Been looking to switch email providers for a while, and hadn’t heard of Tuta. Looked good enough I just went ahead and signed up… only to find out apparently they provide no real data portability whatsoever.

The only option for getting your email _out_ of their systems is to select small batches of them one-by-one in their app and export them.

There have been many requests for something similar to Proton’s bridge functionality that haven’t gone anywhere. A more useful export function has been near the top of their public roadmap[0] for half a decade now it looks like.[1]

Guess I’ll go find out what their refund process is like.

Don’t mind me. Just yelling into the void.

[0] https://tuta.com/roadmap/[1] https://github.com/tutao/tutanota/issues/1292

The one good way forward I can see for any such privacy-conscious service provider is to let the user see exactly what data is stored about them (and purge it where feasible).

You store my access times and IP addresses? I should see that.

I think this would align well with GDPR, too.

> It is up to the user

And therein lies the problem. We on HN may have a few ideas about how to do this, but the typical user of a secure email/VPN/tor unfortunately doesn’t and realistically can’t understand the corner cases and tricks.

Realistically, even HN users would make enough mistakes.

This is why I’m dubious of these types of products marketing to average consumers

I wouldn’t call it reasonable.

If you’re trying to evade LE because it’s illegal to be gay in your country, and you get caught because you’d listed an Apple address in your ProtonMail account - can’t we design better products to make this less likely?

Who gets to decide which specific sorts of evasion of law enforcement are acceptable?

Should we consult your personal moral preferences for that, as applied to each of the 200+ countries on the planet? Why do your preferences overrule those jurisdictions' decisions?

I think you’ve completely missed the point.

Folks who design products that are trying to protect privacy should do their absolute best to sand down the sharp edges and make them secure-by-default wherever possible.

>I suppose the second learning is to elect governments which respect democratic freedoms, even if that puts them on the back foot.

Democratic freedoms, in the United States at least, protect people from UNREASONABLE search and seizure.

Compelling a third party to reveal information about a customer via a court order is not now, has never been, and will never be until the end of time and space, unreasonable.

The order itself might be unreasonable and should be challenged if so, but the procedure and ability to do so is not and will never be.

> Compelling a third party to reveal information about a customer via a court order is not now, has never been, and will never be until the end of time and space, unreasonable.

Its unreasonable if the standards for issuing the court order (as applied, even if not in theory) are unreasonable.

And that is often now, and has often been, and will often be (likely until the end of human history), unreasonable.

Yeah. This stuff is all about putting an end to the global mass surveilance dragnets. Police and government should still be able to operate of course, with checks and balances.

They should not be able to push a button and learn everything about a person. If they want to learn about an individual's private life, they should have to get a warrant then put people to work on the guy's case. They should have to literally follow their targets, photograph them, put hardware keyloggers into their keyboards. That sort of hardship imposes natural limits on the scale of their operations: there are only so many police officers you can assign. With computerized dragnet surveillance, the scale of their operations is essentially limitless.

These encrypted communications services aren't generally in the business of going to jail in their customer's place. They gotta comply with the government laws. When a court orders them to do something, they either obey or they are held in contempt of court if not worse. It can't be helped. It's still helping reduce global surveillance by forcing them to target their attacks.

>Democratic freedoms, in the United States at least, protect people from UNREASONABLE search and seizure.

You're conflating what's written in the law and the sad reality of how a lot of that is simply ignored by law enforcement, while they are standing on your neck, searching your car.

>I suppose the second learning is to elect governments which respect democratic freedoms,

This will _never_ happen. It's the human condition....

I would argue that the second learning is to make it impossible to comply with these subpoenas where possible by making it so the company itself is unable to decrypt it.

Admittedly this is not really an easy solution with something as open as emails, it's possible within corporations but I don't know of a solution between "random" people.

But outside of email and things that have to be unencrypted for interoperability, everything should be encrypted and inaccessible to the company so this situation is impossible.

I think the ship has sailed on the idea of electing people who will actually care about privacy of their citizens.

Proton Mail is in the title because it's where they went first, but the actual identification (real name, phone number etc.) seems to come from Apple on request for info related to the address.

In this case the email address was the lead, but I wonder what other info would be enough to get the phone provider to spill the beans. For instance would an IP address used at a specific time be uniquely identifying if it was VPNed by Apple at that moment ?

Or a Google Ad cookie that could get correlated to other devices showing similar behavior (the same way Google tracks households or related accounts) ?

>but it can be easily resolved to one

Do you have any source to back that up? Last I heard a random person or company won't have a way to find out the real identity given just an IP in general.

Per multiple opinions I got from people whose job was to advise me on the matter, a 2016 ECJ ruling[0] suggests that it doesn't matter if a provider can find a person from their IP address or any other detail, but that there exists a scenario where it is possible.

I am not sure how the CCPA treats IP address, but unless you're at Google or Facebook, it doesn't matter. Few can afford to build separately for the EU and the rest of the world, and hence err on adapting the strictest interpretation.

--

[0] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...

> I suspect governments and ISPs all keep historical logs of who was assigned what address.

They do. It's often required by law.

It can be used to identify a location, but not an individual.

I assume it could be easily challenged in court (network was compromised, “i give out my WiFi to anyone who visits my home”) without other supporting evidence.

Not in Germany, where you are responsible for the Wifi access, see hundreds of copyrights fines each year...

Anyway, it puts the persons living in that location on the radar of the police, and other evidence can be collected (For example by getting a warrant and taking all electronics out of the "location").

It would be great to have the discussion open for people with actual knowledge and experience of the issues.

To keep the discussion interesting, please do not assume or guess, thanks!

They were legally compelled to add IP logging for that specific user. After this incidence, they went on to obtain a court ruling in Switzerland, where they operate, so that this specific attack cannot happen again. In their blog post about it [1], they instruct concerned users to access their account over Tor.

Of course when Proton say they don't log, we just have to take their word for it. People who don't want that element of trust can use Tor. Personally I believe their story in this case.

[1] https://proton.me/blog/climate-activist-arrest

We've worked on improving it in the meantime, so we recommend that you try again. If you come across any issues, please contact our support team at: https://proton.me/support/troubleshooting?product=account

They say quite clearly why in their privacy policy: https://proton.me/legal/privacy (section 2.5: IP Logging).

> 2.5 IP logging: By default, we do not keep permanent IP logs in relation with your Account. However, IP logs may be kept temporarily to combat abuse and fraud, and your IP address may be retained permanently if you are engaged in activities that breach our terms and conditions (e.g. spamming, DDoS attacks against our infrastructure, brute force attacks). The legal basis of this processing is our legitimate interest to protect our service against nefarious activities. If you enable authentication logging for your Account or voluntarily participate in Proton's advanced security program, the record of your login IP addresses is kept for as long as the feature is enabled. This feature is off by default, and all the records are deleted upon deactivation of the feature. The legal basis of this processing is consent, and you are free to opt in or opt out of that processing at any time in the security panel of your Account. The authentication logs feature records login attempts to your Account and does not track product-specific activity, such as VPN activity.

> Proton Mail is in the title because it's where they went first, but the actual identification (real name, phone number etc.) seems to come from Apple on request for info related to the address.

Irrelevant to the point. Proton Mail provided authorities with user data.

Are you sure?

> The core of the controversy stems from Proton Mail providing the Spanish police with the recovery email address associated with the Proton Mail account of an individual using the pseudonym ‘Xuxo Rondinaire.’

No one is talking about the optionality of the information.

We're saying that Proton Mail provided the authorities with user data, which it did.

I dislike that a website with privacy in the name collides privacy and anonymity. Privacy does not protect you from the state. Privacy is good enough to protect you from the public.

If you are doing battle with or an enemy of the state, much less an agent of the state acting in bad faith simple privacy will do nothing for you. Worse your misunderstanding of it is actually a vector, like in this case. The measures for anonymity you require will not incorporate fancy UIs, nice features, or even reasonable reliability at times because they will be sacrificed in the name of leaving no trace.

Privacy is also meant to protect you from the state, or more specifically state abuse. It's an essential aspect of privacy.

Like privacy is also meant to e.g. not disclose topics you have communicated about so that it can't be abused against you. For example there is a long history of states persecuting people for idk. being gay, believing in a certain religion or being a journalist which was involved in a unpleasant disclosure.

Still privacy and anonymity are two tightly related but different things. Mainly privacy of communication doesn't always imply anonymity, through sometimes does (and has too!).

Anyway it is foolish and somewhat strange to believe that a legally operating email service will protect you against judge backed lawful orders (no matter if it should be lawful or not).

Handing out metadata isn't even the worst which can happen, e.g. a judge might order them to make copies of unencrypted mails you receive or make copies of unencrypted mails you write or even undermine your encryption the next time you login.

They can try to dispute it and that alone does reduce abuse potential (if they operate in a place which still can be called a state of law) in the end especially for mail there is just no true privacy and even less anonymity.

Which doesn't mean their service is useless.

Just if you worry about political prosecution by EU countries, or do crime it's not protecting you.

Some interesting facts about Proton Mail. It generates OpenPGP keys on their own servers, and if you want to use your own keys their instructions show users how to upload upload their entire OpenPGP secret keychain to Proton Mail. Not just encryption/signing subkeys, the master key also needs to be included.

I've emailed them to ask that they fix this. I also created a post on their user voice thing about it.

https://protonmail.uservoice.com/forums/284483-proton-mail/s...

TLDR; Proton Mail tells users to do this:

 gpg --armor --export-secret-keys "${USER_ID}" | import-into-proton-mail

They should support this instead:

 gpg --armor --export-secret-subkeys "${PROTON_ENCR_SUBKEY_ID}!" | import-into-proton-mail gpg --armor --export-secret-subkeys "${PROTON_SIGN_SUBKEY_ID}!" | import-into-proton-mail

First one leaks the user's master key to them.

Hi! Crypto team lead here.

1. We don't generate OpenPGP keys on the server, we generate them in the client, and then encrypt them with a key derived from your password (which we never send to the server), and store the encrypted key on the server. Then, when you login again, we fetch and decrypt the private key, and use it in the client. The server never has access to your private keys.

2. We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates). The required private key material needs to be in a single OpenPGP key though (with a dummy primary key), but that's what `gpg --export-secret-subkeys` does by default. Though, as mentioned above, we don't have access to the primary key on our servers either way.

2a. Note that "GNU Dummy" keys are a gpg-specific extension to OpenPGP [1]. The upcoming new version of the OpenPGP standard [2] allows a more standardized way of doing this by combining public key packets and private key packets in a single transferable private key, but it's not widely implemented yet.

3. I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either). That's the reason we don't explicitly recommend this: it doesn't meaningfully improve security. But we don't stop you from doing it (now that we support it, even though it's a nonstandard feature), either.

[1]: https://github.com/gpg/gnupg/blob/master/doc/DETAILS#gnu-ext...

[2]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-cry...

> We don't generate OpenPGP keys on the server, we generate them in the client, and then encrypt them with a key derived from your password (which we never send to the server), and store the encrypted key on the server.

I see, I stand corrected then. Thanks for clarifying. The Proton Mail interface contains buttons labeled "generate" so I got the impression it was being generated in the server. Is this password-derived key the "account key" which I see in the Proton Mail settings interface?

Please clarify what key derivation function is being used. The OpenPGP S2K which gpg uses is outdated and probably not secure enough. I know that Proton Mail is involved in the OpenPGP standards body in an effort to modernize it and that the new RFC contains support for the memory hard argon2 algorithm. Is that what's being used? If so then I would believe that it's even more secure than the encryption that gpg applies to the exported key output.

Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.

> We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates).

Wow that is GREAT and the exact information I wanted! I only believed otherwise because of the documented instructions, which contain the command I posted above. I double checked with Proton Mail support as well but everything led to believe that this was not supported when in fact it was.

Please add this fact to your documentation and instruct your support staff about this!!

> I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either).

I agree. Those are the keys which sign and encrypt the data after all.

It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. I'm putting quite a bit of effort into getting it right. I printed out the master key to paper in paperkey and QR code format. I even contributed code to ZBar to add binary decoding support so that the key backup is easy to restore. I'll also be making an effort to join the decentralized web of trust.

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. This way the emails I send can be signed by the same identity that I'll publish on the OpenPGP key servers. Looks like it's going to be possible after all.

Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.

> 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 using 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! :)

Thanks for clarifying.

> although it's a bit of a niche use case (not for HN of course, but for the general audience it is)

No doubt about that. Safe to assume that 99% of your users will not know or care about this. That's why I want to thank you for supporting this advanced key management feature for those of us who want it. To me that's evidence that Proton Mail takes OpenPGP seriously.

fix it? are you kidding!

that they demanded the private key tells you _everything_ you need to know about protonmail.

Well, they are literally in the business of making OpenPGP easy to use. I understand your worry but I can also understand where they're coming from. The fact is PGP is stupidly hard. I once ran into a gpg bug that deleted my master key. I got so frustrated I just gave up and forgot about it for years. Without services like Proton Mail, this stuff is just never going to be mainstream.

The only way to retain full control over all the keys is to do it the hard way: manually encrypt the emails and send that payload via SMTP. If we refuse to give them the keys, we can't enjoy the convenience of Proton Mail doing that automatically for us. Proton Mail offers a middle ground and it's a very attractive one if you accept the inherent risks associated with giving them the keys.

I'm not willing to give them the master key though. I want the ability to generate a bunch of subkeys just for them. Then I can just revoke those keys if they're ever compromised, and the emails will be encrypted and signed by my actual OpenPGP identity that I'm investing time into, not a separate master key generated for my Proton Mail account.

The support guys confirmed to me in writing via email that Proton Mail only ever uses the signing and encryption subkeys. They don't need the master key.

> We use the signing subkey for signing and the encryption subkey for encryption, and you will have to import the whole OpenPGP at once.

So I asked them directly to add support for importing just the subkeys.

I made a post on their user voice thing about this too. It's garnered a bit of support already.

https://protonmail.uservoice.com/forums/284483-proton-mail/s...

Let's see what happens.

They could but then you open the mobile app or another computer and the key just isn't there. They could generate one subkey for each device but then you risk user emails being impossible to decrypt if they ever lose that device. Hell I'm a programmer and I somehow managed to get my own master key deleted because I ran smack into some gpg bug which I then reported and sent a patch for. If I can't do this without deleting my keys and being forced to revoke them from keyservers immediately after publishing, what hope do end users have?

The most secure solution is to generate keys on an OpenPGP smartcard like an NFC enabled YubiKey and use that key everywhere. Even that's incompatible with maximum reliability: YubiKeys can and will eventually fail and when they do your keys are gone. So you can't generate the encryption subkey on the smartcard, you need to generate it on a secure device, back it up to paper just like the master key, and then copy it to the smartcard. Otherwise you risk being unable to decrypt data later.

It's an incredibly hard problem and it's full of tradeoffs. I can at least respect their attempt to solve the problem.

Maybe. I haven't tried it. Someone actually suggested this to me on the #gnupg IRC but I just kinda forgot about it.

The --export-secret-subkeys command does just that: it replaces the master key with some GNU specific stub packet thing. It's conceivable that they could detect this and reject the uploaded key. In order to avoid that, one might edit the secret key packet manually instead. Just zero fill or randomize all the secret key bits or something. I assume it wouldn't match up with the public key though. Aren't the public and private keys mathematically related? Maybe you can detect that the key is bogus if you try to do cryptographic operations with it. Maybe the operation somehow fails or produces nonsense results. I don't really know enough cryptography to say.

It is also security theater. 99.9% of the time the other side you are communicating with stores their mails with server-side encryption. If your fancy encrypted e-mails have a "plaintext" mirror, your encryption is useless.

You want to optimize your 99.9% case for convenience (say, use Fastmail), and optimize your 00.1% case for security (manually managed PGP with a secondary anonymous e-mail). It makes no sense to trade away swathes of convenience and security just so you can be lazy with your 00.1% case.

I view Proton Mail as the convenient 99,9% case. It's a very polished service and it seems to offer a somewhat higher security baseline than the other email providers which probably don't even try to do anything encryption related.

The maximum security manual OpenPGP 0.1% case is still absolutely necessary though. No doubt about that. Anyone claiming that Proton Mail solved this doesn't actually understand how OpenPGP works. Not that I would fault them for failing to understand this ludicrously complicated stuff.

https://news.ycombinator.com/item?id=40283698

That's probably wise. I wish there was a way to add metadata to the subkeys. I want to have one set of subkeys for Proton Mail and another set for absolute privacy. I want to mark them as "leaked" keys somehow. Not quite revoked but close.

I read the OpenPGP standard and it seems to have some kind of "notation" packets. Seems to be somewhat related to metadata but I can't figure out how it works or even what its purpose is and it looks like nothing ever uses that anyway.

We do fetch keys from WKD, as announced almost 5 years ago: https://proton.me/blog/security-updates-2019 :)

Actually, you have a bug that has been unfixed for 5 years now. I know because I submitted it. Still no action.

Here's my last message to Proton Mail support, request ID 822331. I was directly told no resources would be spent on fixing it:

> Well, it has been multiple years now so can you guys maybe prioritize this? How long do you want me to continue waiting on this issue? I can't count on PM users to send my mailserver E2EE mail when the mobile app doesn't support it.

I don't know much about Proton Mail but presumably they want that so they can actually provide you with a more complete service, other than just being a mail gateway?

I would assume that any technically sophisticated users who just want an SMTP/IMAP server would never let their keys leave their control, but there might be other users for whom a "middle layer" service which has their keys is good enough. (I guess this is especially evident in cryptoassets where people seem to cheerfully let third parties manage their tokens, so it's not really surprising to me that there are a bunch of people willing to do it with their PGP keys for email purposes.)

I guess there's an argument about whether or not they're being responsible in providing such an option at all, which is fair enough.

It's how they make OpenPGP easy to use. Everyone who's ever tried it knows how hopelessly complicated it is. Their bridge's entire purpose is to present a standard email server to email clients so that all the OpenPGP stuff can be done automatically and transparently behind the scenes.

Does that create trust issues? Absolutely. Still, OpenPGP sucks and I just can't fault them for trying to fix it. They're even participating in the standards bodies alongside other OpenPGP projects trying to modernize the whole thing. Somehow it resulted in gpg forking the standard and making everything even worse. It was hard to use before, now it's hard and fragmented.

https://lwn.net/Articles/953797/

https://news.ycombinator.com/item?id=38554393

I suppose they could have gpg or OpenPGP smartcard integration in the bridge, then it could use those keys to sign and encrypt. That's more secure but creates quite a bit of hassle. Suddenly the web and mobile apps become incapable of sending OpenPGP email unless you have the smartcard connected. I've got two NFC enabled YubiKeys and I can't even begin to imagine how to connect this stuff to a smartphone. Looks like there isn't enough support for it.

https://news.ycombinator.com/item?id=40177539

> Mainly privacy of communication doesn't always imply anonymity, through sometimes does (and has too!).

Anonymity is simply people not knowing who you are, not necessarily what you say. It's not privacy of communication, but privacy of identity.

I can post on the internet as Anonymous Coward, and those posts are public even though my identity is private.

I can encrypt an email and send it, and it will be picked up by all the relays. They can look up the source and identify me, but hopefully not read the email contents.

yes but also sometimes just knowing a persons identity can infringe on their privacy

I would say anonymity is an aspect of privacy, one you sometimes but not always need.

e.g. I would say leaking who was present at a anonymous self help group isn't just breaking anonymity but also infringing on privacy

I didn't say that identity wasn't privacy.

I said that the post I responded to was conflating two different types of privacy.

Who said things is different to what was said.

Bob and Alice spoke about something, is not the same as Anon to Anon "The government is listening".

One is the message and one is metadata. They are protected in different ways and leaked in different ways. Mixing the two means that you will probably not get the protection that you desire.

You state this distinction as if it's established, but it's not a definition I've personally heard explicitly stated before. If I read the introduction of the Wikipedia article on "privacy", I find the following:

>The right not to be subjected to unsanctioned invasions of privacy by the government, corporations, or individuals is part of many countries' privacy laws, and in some cases, constitutions.

So according to Wikipedia, at least in some cases, privacy is protection against the state. Where does your definition come from?

Obligatory George Carlin quote:

"Your rights? Right this way."

> unsanctioned invasions of privacy

GPs definition might as well come from wikipedia.

That, and the terms themselves tend to invoke clues about the meaning. Privacy implies there is an identity, but it is kept hidden. Anonymity implies there is no identity established so there is nothing to hide.

We don't see much of the latter since most web services require an email to sign up, at minimum, which still leaves discoverable bread crumbs. The web services that require you to give up nothing to use them are far less popular, so I guess I can see why people might conflate the two.

I'm not sure where you're drawing your implications from, but that is not implied, to me. I frequently see the concept of privacy applied to situations where an entity isn't required to ID themselves for the sake of privacy.

The common description when contrasting anonymity vs privacy is that anonymity allows one to do things publicly without being ID'd while privacy allows one to do things without the public having knowledge. There is no implication or requirement that the private party has been ID'd by another other entity.

Privacy protects some things from the state, which is why the western world has the concepts of warrants and such.

But the concept certainly doesn't mean that a business is going to help you cover your tracks in regards to data you've already shared. (in this case, the recovery email address)

If you give out your personal information, commit a crime, and ask that person to help you hide, you're not asking for anonymity, you're asking for an accomplice.

I think that is the GP's point. Privacy means the data is reasonably hidden, though it still exists somewhere in a readable state. Anonymity means the information of who did what really doesn't exist anywhere.

In the case of governments, private data is only hidden until the government decides that it needs to look for it (or ask for it). Anonymity means the data isn't there, regardless of whether the government decides it needs to, and has legal justification to, demand access to the data.

Anyone providing anonymity is only an accomplice if they know your intent. Simply not collecting data doesn't make you an accomplice, not collecting data with the intent of hiding someone else's illegal behavior does.

I could have been more clear there. I was specifically thinking about data that can identify you, not just data in general.

If I'm the only one in possession with data I don't really consider it data collection at all, at least in the context of privacy and anonymity. Other than that I agree with your clarifications here though.

It is, I am agreeing.

The bottom line is that if you told someone who you are, you're not anonymous.

You seem to be confusing privacy with practicality. In practice, nothing is ever secure, nothing is ever private and nothing is ever safe.

What matters here is what Proton promises and advertises to users/potential users vs. what it can actually deliver. I don’t know if Proton is more open about this, but hopefully this isn’t just buried in some long Terms of Service that almost nobody reads.

> Proton is incorporated and headquartered in Switzerland, meaning your data is protected by some of the world's strictest privacy laws.

This is the main statement from Proton about their privacy protection. They say they obey Swiss privacy laws. So if one has a problem with Protonmail complying with Swiss law, maybe one should complain to Switzerland.

> In practice, nothing is ever secure,

Well that's clearly not true.

Ever heard of thermorectal cryptanalysis?

As long as your secure world is not fully isolated but has any interactions with the physical world at all (e.g a human being somewhere receiving and reading your message with his eyes), then it's only a matter of resources allocated to trace you. You can pile up layers of "hops" through uncooperative jurisdictions -- this certainly helps to raise the bar but doesn't give you a mathematical proof of security.

That's technically and theoretically true but also largely practically irrelevant.

Consider a building or a server. You can absolutely make them secure. Sure, eventually, everything can be broken/bypassed/hacked/cracked whatever, but if there is no chance of that happening for the duration that the security has to persist, then it is secure.

> Consider a building or a server. You can absolutely make them secure.

I'm not sure it's a good example. A server that you build from off-the-shelf components will likely come with the IME, providing direct tcp-to-ram access. Motherboard manufacturers probably add their own backdoors on top. We know about Gigabyte because they were caught red-handed, but how many we don't know about? How many rootkits in the SSD firmware? In hundreds of other firmware blobs installed on your Linux server right now?

I'm not even talking about Open Source backdoors which are hard as they have to be done in the open. Hardware/firmware backdoors are not in the open, they have been around for decades, they have been found and confirmed numerous times and god only know how many were NOT found.

Building a secure server nowadays is an extremely complex task, only solvable at the government level perhaps and only an a few select countries, if solvable at all. You need full control over the whole supply chain that includes tens or hundreds of thousands of corruptible employees.

I think it's a fantastic example because it's flexible enough for us to extend to make our points.

You make a good point, as when I made my comments I was considering an 'average' usecase, typically wanting to guard against malicious attacks from unknown actors on the internet.

You're talking here though about absolute security against basically a state level actor. No one else is going to be dealing with exploiting backdoors in firmware for specific targets.

But I still maintain my points is correct, it just requires substantially more money. If guarding against state actors is the requirement, that can be met by having custom or at least verified (at every stage of manufacturer) hardware. Expensive, but far from impossible. As for software issues, that's why we have stuff like SELinux and SEL4.

So yeah, I maintain you can absolutely secure a server. You just have to be clear about what the threats you are wanting to protect against are, and for most people that isn't state actors.

> Privacy does not protect you from the state. Privacy is good enough to protect you from the public.

Public doesn't care mostly. Governments on the other hand...

Buying used phones and laptops with cash at a bazaar whilst wearing a wig, one at a time.

You got a few days of Tor on each device; then they need to burn.

I really don't know what more you can do beyond making your own chat client. Internet is not a place for revolution.

With all "security" cameras and face recognition software and big data mining, which links many sources together, real world in developed world is not a place for revolution too.

Welcome do dystopia and hope that governments in developed world will not become too nasty (CCP-level nasty) too soon due to inertia.

> Privacy does not protect you from the state. Privacy is good enough to protect you from the public.

While I get what you are saying, that is a little too black and white for the entire field. Privacy can be used to shield whistle blowers from the state.

Yes it's a strangely skewed article focusing on proton, when:

> Once he got it, he asked Apple for information about this second email address, and got its name, home address, and phone number. Afterwards, the Civil Guard also asked the telephone company responsible for the telephone number who was the owner of the line, which matches the name provided by Apple. Also, they say they have found that this person is registered at the same address provided by Apple.

I can think of one country in the whole world (Iceland) where a company can tell the country it operates from, NO.

However in this case (an operating police officer who gave information to a group who wants to split away from the country) i make a bold assumption that even Iceland would order the company to give the data out (since it has nothing to do with protecting journalists/whistleblowers, but espionage)

>I can think of one country in the whole world (Iceland) where a company can tell the country it operates from, NO.

Are you claiming that businesses in Iceland are not required to comply with court orders? On what basis do you believe that to be true?

Doh. I read it as "a company can tell the country it operates from, Norway."

I thought "Huh? Why would an Icelandic company operate from Norway?" Well, I thought, I suppose there must be quite a few. But why's he mentioning it here?

Thanks for inadvertently clarifying.

>Doh. I read it as "a company can tell the country it operates from, Norway."

Really Norway? Are you guys stupid?

NO is the country abbreviation for Norway.

In answer to your question: firstly I am not "guys", I'm one person; and secondly, yes, I feel pretty stupid.

> Use a good VPN service to hide your IP address whenever possible. (Failure to do this is what compromised a Proton Mail user in France who was arrested after after police obtained IP logs.)

If your VPN is tied to a payment method then all you've done is give police one extra hop to follow to get at you, which wouldn't have saved this activist. Their list of VPNs only includes Mullvad in position 9 of 10, but as far as I'm aware it's the only one that offers payment methods that preserve your anonymity.

If you're doing low-bandwidth stuff like sending e-mails, TOR (which is of course free) should be your first choice.

But you have to absolutely "air-gap" that from the rest of your identity, such as not making a proton e-mail address over TOR and then using your usual email address as the recovery one.

Only if the vpn provider had logs.

Most claim they don't, PIA even was subpoenad at least once and responded they don't have logs.

Let's say I buy Mullvad access with a credit card, then access my otherwise-unrelated Proton Mail account via Mullvad.

How are police going to find me behind that hop?

In this case an activist in the oppressive regime of...Spain?!

Opsec is hard and most activists in western countries don't take it seriously. It's not like we live in PRC or DPRK right?

Ironically, it is likely far harder for PRC or DPRK to get data from Proton than it is for Spanish police.

> It's not like we live in PRC or DPRK right?

Right. Western governments are much, much better at mass covert surveillance.

> it is likely far harder for PRC or DPRK to get data from Proton than it is for Spanish police

You balk at the idea of a western government being oppressive while pointing out that our “secure” email services can be easily compromised by government action.

Well Spain probably never got over the Franco legacy.

https://www.wired.com/story/europe-break-encryption-leaked-d...

“Ideally, in our view, it would be desirable to legislatively prevent EU-based service providers from implementing end-to-end encryption,” Spanish representatives said in the document.

> but if I were an activist in an oppressive regime

Then mail them your money

I think most people are considering less serious threat models

> you mean non-governmental

I would say most people are concerned with dragnets, not targeted attacks. There's quite a lot you can hide from the government in terms of dragnets, in the same way you'd hide from big tech.

"Hide" isn't the right word. "Defend from" I think is probably better. Defending our constitutional rights from government and defending our privacy from big tech.

I'm actually perfectly okay with governments in targeted attacks (where a warrant is reasonably given). I'm just not okay with police being lazy.

You are totally wrong. You are assuming that every single VPN is logging everything you do online, every IP address, and every website, and then saving this information for every user. Completely false. Show me a single reputable VPN that does. Show me the real life cases where this has happened. Any good VPN, including Mullvad, is a no-logs VPN, which means activity through the VPN is not recorded and cannot be connected with users. There have been numerous VPNs that have not only been audited to verify this, they have been proven correct in court or real-life tests. Mullvad is a perfect example of this:

https://restoreprivacy.com/mullvad-vpn-says-customer-data-is...

Paying for a VPN account does not mean the VPN is going to start logging user activity. Keeping payment records does not equal logging user activity through VPN servers. And most of the big name VPNs allow for crypto payments.

The heart of the issue is this:

> Under Swiss law, Proton Mail was compelled to collect and provide information on the individual’s IP address to Swiss authorities, who then shared it with French police.

They can claim all the privacy guarantees they want, but unless the privacy is guaranteed by cryptography, it's an empty gesture. Nobody is willing to do prison time to protect your privacy.

> The heart of the issue is this:

No, that was last year's issue.

This time it's:

> The core of the controversy stems from Proton Mail providing the Spanish police with the recovery email address associated with the Proton Mail account of an individual using the pseudonym ‘Xuxo Rondinaire.’ This individual is suspected of being a member of the Mossos d’Esquadra (Catalonia’s police force) and of using their internal knowledge to assist the Democratic Tsunami movement.

and

> Upon receiving the recovery email from Proton Mail, Spanish authorities further requested Apple to provide additional details linked to that email, leading to the identification of the individual.

This does not stop the host from being compelled to wiretap future communications.

Just don't try to make encrypted email happen. It can't, and we don't need it to be. We have better solutions for encrypted communications, for those that need it.

Consider a certified tamper-resistant operating system which cryptographically certifies the versions of software it operates, and prohibits uncertified processes from running. The certificate of authenticity verifying the software is made available to the clients which connect to the remote application. This cert specifies all of the program transforms which were required in order to produce the compiled software, and they specify the capabilities required for the transform.

It is certainly a very hard and complex problem but I wouldn’t necessarily go as far as “impossible”. Maybe you know something I don’t know, though.

> Consider a certified tamper-resistant operating system which cryptographically certifies the versions of software it operates, and prohibits uncertified processes from running.

If I own the hardware, I can decide how the software is executed, including containerizing your certification processes to make them feel warm and fuzzy and happy but in reality they are running inside a simulation.

If push comes to shove I could theoretically manufacture my own RAM sticks that copy everything and your OS wouldn't even know, but there's a 99% chance I could successfully pull it off at the kernel virtualization level.

gullible vpn fans believe anything

or at least their favorite youtuber with the paid ads and zero domain knowledge of network topology

serious question I have is whether “internet reseller” is a compelling service. because that's all that VPNs are, and I dont mind paying to use them for that purpose.

If you are super duper serious about securing yourself, recovery email is non-viable. Every piece of data is a potential vector towards exposure.

Which comes directly into the problem of security vs convenience.

Proton Mail can't give email content, only things like email address, ip adressese etc.

Email content is encrypted and Proton Mail has no access

When thinking about these types of cases, always keep Parallel Construction in mind: https://en.m.wikipedia.org/wiki/Parallel_construction

There’s a reasonable chance that they already had this info (possibly even cleartext email via an ISP lawful intercept), and the proton/apple jig whilst bad, wasn’t as bad as the real source

Proton Mail gives info only when the Swiss law mandates it and Swiss law enforcement requires it. Swiss privacy laws are quite good.

That's the strictest privacy policy any company can hope.

Proton Mail can't give email content, only things like email address, ip adressese etc.

Proton Mail can give email content, however, it is encrypted and they do not have the encryption keys.

Anything that is stored by anyone can be handed over. That information may be useful, may be useless or may be useless now and useful tomorrow when they have the key.

> they do not have the encryption keys.

True, but they can trivially obtain them given they control everything in the browser.

The question then becomes, does the law allow compelling to that degree? Apple fought back in the San Bruno case, but they’re very well lawyered up

> True, but they can trivially obtain them given they control everything in the browser.

Open source clients that you can self-host are available. I mean of course you still have to trust the code if you can't audit it. But hijacking your keys won't be as easy as visiting their webmail.

I would hope so, but is that confirmed?

Is there a clear definition between handing over data they have and being compelled to make modifications in order to intercept?

This is not true - most of the time all you need to do is fill out the captcha. In some cases (when our systems detect something suspicious about your network), we would request an additional email address. Even in those cases, the email addresses are not tied to your account - we only save a cryptographic hash of your email. Due to the hash functions being one-way, we cannot derive your data back from the hash: https://proton.me/support/human-verification

While we did use phone verification in the past, this is not the case any longer. Phone numbers were stored in the same way as the email addresses, so, again, we have no way to derive them back from the hash.

> While we did use phone verification in the past, this is not the case any longer. Phone numbers were stored in the same way as the email addresses, so, again, we have no way to derive them back from the hash.

I've no reason to doubt this but brute-force cracking a hash known to be from a phone number would likely be pretty trivial.

Fwiw, I use protonmail and trust it more than most other services. But my threat model doesn't involve technically capable adversaries directly targeting me, certainly not ones that could compel protonmail to divulge phone number hashes.

> Due to the hash functions being one-way, we cannot derive your data back from the hash

This isn't true in practice. It's not hard to build a big list of ~every email address (give or take), and have a GPU churn through them all until you get a match.

If you've ever received a spam email, your email address is on such a list.

argon2id with dynamic salt should effectively prevent this, but it will also not allow to tell if two users have the same e-mail or not -- which I suspect is the main reason for hashing in the first place.

If equality-check is required to prevent e-mail reuse by spammers then argon2id with static salt rotated every few months will be reasonably strong too.

Of course I have no idea if any of this is implemented or it's just sha256(email). Just replying to the question of general feasibility.

They are a huge target for spam.The reason why they do this is to prevent spam.

Unfortunately, it can and has been abused.

Not surprised at all. Even if it did not start with this intention, one has to suspect that with enough time it will become compromised.

About the only way to even vaguely keep your email private is to use a self hosted server with GPG keys. And any lapse on security updates for that thing and you could be compromised almost immediately.

Beyond that I cannot think of anything more one could do.

I have always treated email as something to travels in the clear. My current provider (Fastmail) is compromised by authority. The Australian Privacy Act 1988 by being based in Australia and it gets caught up by PRISM as the servers are run out of New York.

You can create anonymous accounts with Tuta through Tor and they don't ask for a phone number or contact email address. They even made a tutorial video on YouTube a few weeks ago for how to do it: https://youtu.be/oXv3llPIfvo

If you continued using the account only through Tor, there wouldn't be any traceable info.

Yes, I just tested it and was able to register by giving a (disposable) email.

It did then prompt me to add an email and/or phone number as recovery methods, but that step was skippable.

I have never found protonmail's signup step asking for phone number verification or a recovery email to be unskippable.

Protonmail can still be the best choice for a pseudonymous mail service so long as it's combined with diligent, consistent IP address obfuscation. Protonmail will continue to allow logins and new account creations over Tor. All the major free email providers have long since disallowed new signups over Tor, and most have some form of degraded user experience when logging in over Tor, if they allow it at all. Small, niche email providers appear and disappear so often that relying on them still to exist even a few months into the future is a big gamble. Hosting one's own email requires payment of some type to the hosting provider, so it is not anonymous. Other privacy-oriented free email providers, such as riseup, will do exactly what protonmail did, because if they refuse, their only option is to go the way of lavabit.

> It skips this if you’re using a non-proxy IP

Get one from your neighborhood coffee shop Wi-Fi, and pay cash for your coffee.

Terrible advice, being that "neighborhood" means you live close by. Go to a coffee shop in another city, state or country and do so! (Although flights leave paper trails too)

Also make sure to avoid CCTV...

This is not the first time they have provided recovery emails to the feds.

https://www.forbes.com/sites/thomasbrewster/2023/08/08/proto...

Archive: https://web.archive.org/web/20230814144638/https://www.forbe...

 This case is particularly noteworthy because it involves a series of requests across different jurisdictions and companies, highlighting the complex interplay between technology firms, user privacy, and law enforcement. The requests were made under the guise of anti-terrorism laws, despite the primary activities of the Democratic Tsunami involving protests and roadblocks, which raises questions about the proportionality and justification of such measures.

Proton Mail is pretty good email. I use it since I decided to de-google as much as possible. That said, I don't consider it truly 'private.' Weird key handling in order to make pgp 'easy,' just email being what it is, and courts and governments being what they are.

I'll continue to use it despite some hyperbole on the site, but as long as my mail isn't being fed to an advertising engine it's a step up.

Switzerland does have strict laws on the topic. Data requests are only honoured for cases which are a crime both under the foreign country's law and under Swiss law.

If you live in a country where hom*osexuality is illegal, and your local government is chasing you because of this, a Swiss company won't comply with data requests, and a Swiss judge has no reason to honour any data request.

If your local government is chasing you because of something that is recognised as a crime in Switzerland, then they will disclose data to foreign authorities.

> Proton provided us with an explanation that inbox contents remain secure.

Yup, until they receive a court order asking them to mitm an inbox, if they haven't already...

This entire system of "receive email in clear text but store it encrypted at rest" is smokes and shadows, really.

I think this is the same distinction as a phone operator providing the metadata (when, between who, for how long did phone calls happen) but not wiretapping the call itself.

The former has distinctly less legal requirements than the latter, and authorities might be OK with keeping it that way, as metadata is already good enough in most cases.

It depends on the local laws. Not all places can demand that a service provider do an active attack on a user. Of course many countries have passed such laws and others are planning to

It wouldn't technically be a MITM attack, they would just capture the incoming email. Tuta was famously forced to do that once by the German authorities.

There's lots of work on that problem!

https://dwheeler.com/trusting-trust/

There are also a number of people making minimal OSes, interpreters, and compilers that you can, for example, assemble by hand and type in "from scratch".

There was a nice list of those that I can't find right now, but you could look at

https://bootstrappable.org/projects/mes.html

as one example in this direction.

The rabbit hole goes further with UEFI, components embedded in PCBs, microcode, HDL synthesizers, etc.

To make a perfectly secure system, the first step is to obtain high purity sand.

Yes, you can definitely get very severe attacks from backdoored hardware. Some of them appear almost impossible to defend against with software alone.

On the bright side, it's hard to imagine that many of these attacks will be self-propagating, which is the particularly insidious thing about the Trusting Trust attack. Yes, hardware is used to design hardware, but typically in a more indirect and heterogeneous way than the "compiler compiling itself" scenario. To be concrete, I'd say Microsoft or Canonical has much more to fear from a Trusting Trust sort of attack than Intel does, but the software developers also have better options to contain or detect such an attack.

What email was suspicious? From what I can read. Proton provided the Spanish authorities with a recovery email address, which the latter then used to find an associated Apple account.

While I agree this makes Proton unreliable for many things, there's no indication they were reading any emails.

Still waiting for DIME[0].

0. https://en.wikipedia.org/wiki/Dark_Mail_Alliance#DIME

I never thought of ProtonMail as a secure-from-state-surveillance provider. Only as a secure-from-civil-surveillance-aparatus provider. A replacement for Gmail, no more than that.

If I wanted to conduct illegal activities I would not use my main account on it, at minimum.

Protonmail is a step up from Gmail/Outlook, but no more than that. You need more layers on top of it.

I use Proton to protect myself from Google, Microsoft, advertisem*nts, tracking, terrible, slow, “too much padding everywhere” UI, my emails/data being sold to 3rd parties, etc. I’m not worried about Proton cooperating with law enforcement agencies to catch criminals.

However.

What if say, russia/nk/china wants to catch somebody some journalist for speaking truth about their regimes? Or, like say, Jason Bourne exposing some IronHand in “democratic” country like USA? How can we protect good actors without enabling adversaries to do “bad stuff”? Is it even possible? I still don’t know the answer…

There are some serious anti-proton-vibes in this thread, so just my 2 cents as a paying customer: I'm rather happy with their service. I pay them money, they make sure that Joe in Marketing won't be able to harvest data from my emails. I'm also fairly optimistic that they take security serious enough that the blast radius of some dataleak is hopefully very limited.

I have zero delusions however that they can protect me from state agents, let alone state agents with malicious intent. And I don't think it's realistic to expect that for the amount of money they cost. But that's fine with me - it's Joe from Marketing I'm scared about, and so far they seem to do a good job keeping Joe at bay :)

Seconded, happy Proton customer for years since de-Googling my life.

Par for the course at HN to have a "vaguely dislike-ish" relationship with Protonmail. Fastmail is the poster child of HN on the other hand.

I would guess the gist of it is that if you promise _any_ amount of security (or whatever feature), HN will nitpick you to death on not going 100% (despite the general improvement to your security). If you don't promise security at all, it doesn't matter that you're less secure than Proton. Something like that.

I've just been poking around at the Dropbox APIs recently when I got so frustrated by the fact that the Fastmail "attach from Dropbox" feature has been loading directly into my personal files space rather than showing the shared team folders since we switched over to using those last year - and I now have to download and re-upload files from those folders.

It's more than a glorified FTP. FTP does some heinous things with a separate control channel and stuff (let me tell you about adding encryption support to the Perl FTP server some other day), but this is next level!

https://developers.dropbox.com/dbx-team-files-guide

It's not even as simple as just sending a fixed string in the "Dropbox-API-Path-Root" header for every API request (and they're all path based, so you have to make sure you always send that header or the paths won't parse right) - you have to get an ID for the real root, with a separate request, with a scope that we weren't requesting on refresh tokens.

So I hacked together something that worked on my testbed on the train ride home, but making it good is going to include adding a caching layer to the token refresh code, and suddenly it's not just a casual project. I'm still going to do it though, because dammit I have a file to attach to an email on Friday and I'm happy to spend hours on this to save myself 30 seconds.

Maybe this is disabled for free customers but at least for me there are settings to enable/disables what I kind of informations I'd like to receive from them.

Gmail in that regard I've always perceived as worse - every few months or so they update their policy, linking to some gargantuan document that I can't be bothered to read, each time wondering how much of my soul I've sold this time around...

https://proton.me/blog/protonmail-threat-model

> This individual is suspected of being a member of the Mossos d’Esquadra (Catalonia’s police force) and of using their internal knowledge to assist the Democratic Tsunami movement.

...and...

> The requests were made under the guise of anti-terrorism laws, despite the primary activities of the Democratic Tsunami involving protests and roadblocks, which raises questions about the proportionality and justification of such measures.

As I understand it, Catalonia has long desired for independence[1]. Is the Democratic Tsunami movement something different, entirely? If not, can someone fill-in the blanks of how vying for independence (in this case) gets umbrella'ed under terrorism?

[1] - https://en.wikipedia.org/wiki/Catalan_independence_movement

Edit: Accidental caps-lock on a word. My bad.

The Democratic Tsunami was/is(?) more of a pure action based protest group lead by an anonymous leader structure. The leaders were/are probably certain leader figures within the independence seeking community; but that is just a speculation on my part.

Its biggest action was probably at the Barcelona Airport in October 2019, a protest a couple of years after the Catalan independence election in October 2017. The election itself was deemed unconstitutional by the Spanish government. The registered voters/turnout of this election was 43.03%; where 92.01% voted for separation from Spain and 7.99% voted to stay within Spain –– see: https://en.wikipedia.org/wiki/2017_Catalan_independence_refe... –– but this was not a normal election by any means (read the link for more).

Typically the ANC –– see: https://en.wikipedia.org/wiki/Assemblea_Nacional_Catalana –– has been the leading organization in the independence movement. They have been organizing big independence rallies etc. and the actions has been peaceful (from what I've read and seen). The Democratic Tsunami based protests were different in this regard, where more direct confrontation was more the norm. From what I have read Democratic Tsunami is not particularly active at the moment, but of course this might change.

They did extreme protests like road blockages, and some other stuff which the government considered sabotage and so pursued them with anti-terrorist legislation.

Also some members were arrested apparently planning even more extreme things.

The IRA and ETA were vying for independence too...

That said, I think it's crazy how much time the government wastes on this when the cities are full of petty criminals acting with impunity. Someone was stabbed to death outside my apartment just in a robbery and yet nothing changes.

> Catalan independence organization, Democratic Tsunami

OK, I think I grokked this. You might think that a Greco-Nipponese name for this organization poorly conveys Catalan nationalist pride. But in fact it quite effectively says "anything but Spanish". That's almost certainly the gag.

Instead of blaming corporations for following the law, blame the laws and the government for what they force others to do.

It is not up to corporations to decide which laws should be enforced, and this again shows how futile this specific kind of corporate resistence is.

Just change the law.

Quite interesting how the Spanish authorities got the recovery email: (from a link in the article)

> In the police cooperation form requesting the information, the Spanish officers indicate to the Swiss authorities that the investigation is for the crime of terrorism.

This situation is interesting, but the article mentions using a VPN for example, and also the recovery email.

What if my recovery email is to another proton mail account?What if my VPN used is Proton VPN?