According to Ortis, briefed him about a “storefront” that was being created to attract criminal targets to an online encryption service. A storefront, said Ortis, is a fake business or entity, either online or bricks-and-mortar, set up by police or intelligence agencies.
The plan was to have criminals use the storefront — an online end-to-end encryption service called Tutanota — to allow authorities to collect intelligence about them.
“So if targets begin to use that service, the agency that’s collecting that information would be able to feed it back, that information, into the Five Eyes system, and then back into the RCMP,” Ortis said.
you’re right about the IP thing. that’s a good clarification rather than just “spy”. i suppose it’s less dire than Tutanota not encrypting incoming mails if you use tor and vpn by default.
yeah basically it more or less proves that swiss privacy is a bit stronger in this case vs Germany.
on the proton encryption, i did know about this but does that apply to proton-to-proton, proton-to-NonProton, or both? if you have details on this let me know.
either way the fact that they dont makes me feel that proton is a similar honeypot to signal and telegram, where they make a compromise with the five eyes, to give them metadata even if actual contents are safe. metadata can be much more powerful than contents often times
in general email is just the worst protocol when it comes to privacy. sadly.
on the proton encryption, i did know about this but does that apply to proton-to-proton, proton-to-NonProton, or both? if you have details on this let me know.
As I know it applies to both. Formerly they were asking (among other things) about the titles of your latest emails for account recovery.
(after I have put all the links here I realized that these don’t give a details on whether this also applies to inter-proton messages…)
either way the fact that they dont makes me feel that proton is a similar honeypot to signal and telegram, where they make a compromise with the five eyes, to give them metadata even if actual contents are safe. metadata can be much more powerful than contents often times
Yeah, might as well be. But if it is, I’m afraid we won’t get to know for a few decades, if ever. And I think it’s still better than the alternatives… the alternative email providers, that is.
If it comforts you, in their reddit comment I linked they mention (in 2019…) that there’s a proposal they support for openpgp to be able to have an encrypted subject line.
I found out also that Tutanota is essentially the same, except that they do E2EE subject lines between tutanota users, but I am guessing that is because they don’t use PGP unlike Proton. In which case, Proton is in the right in this case because they are increasing E2EE interoperability beyond just their own users. So, my comment about honeypotting was really uncalled for I think, and I apologize for that.
The OpenPGP proposal is interesting, but I couldn’t find anything on it. All I found was this below, which explains that email headers can’t be/aren’t encrypted, and subject is one of those, so that’s why. I have no clue what Proton was talking about, or where they got that info
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !privacyguides@lemmy.one
In the digital age, protecting your personal information might seem like an impossible task. We’re here to help.
This is a community for sharing news about privacy, posting information about cool privacy tools and services, and getting advice about your privacy journey.
You can subscribe to this community from any Kbin or Lemmy instance:
Check out our website at privacyguides.org before asking your questions here. We’ve tried answering the common questions and recommendations there!
Want to get involved? The website is open-source on GitHub, and your help would be appreciated!
This community is the “official” Privacy Guides community on Lemmy, which can be verified here. Other “Privacy Guides” communities on other Lemmy servers are not moderated by this team or associated with the website.
Moderation Rules:
We prefer posting about open-source software whenever possible.
No soliciting engagement: Don’t ask for upvotes, follows, etc.
Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
Be civil, no violence, hate speech. Assume people here are posting in good faith.
Don’t repost topics which have already been covered here.
News posts must be related to privacy and security, and your post title must match the article headline exactly. Do not editorialize titles, you can post your opinions in the post body or a comment.
Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
No help vampires: This is not a tech support subreddit, don’t abuse our community’s willingness to help. Questions related to privacy, security or privacy/security related software and their configurations are acceptable.
No misinformation: Extraordinary claims must be matched with evidence.
Do not post about VPNs or cryptocurrencies which are not listed on privacyguides.org. See Rule 2 for info on adding new recommendations to the website.
General guides or software lists are not permitted. Original sources and research about specific topics are allowed as long as they are high quality and factual. We are not providing a platform for poorly-vetted, out-of-date or conflicting recommendations.
you’re right about the IP thing. that’s a good clarification rather than just “spy”. i suppose it’s less dire than Tutanota not encrypting incoming mails if you use tor and vpn by default.
yeah basically it more or less proves that swiss privacy is a bit stronger in this case vs Germany.
on the proton encryption, i did know about this but does that apply to proton-to-proton, proton-to-NonProton, or both? if you have details on this let me know.
either way the fact that they dont makes me feel that proton is a similar honeypot to signal and telegram, where they make a compromise with the five eyes, to give them metadata even if actual contents are safe. metadata can be much more powerful than contents often times
in general email is just the worst protocol when it comes to privacy. sadly.
As I know it applies to both. Formerly they were asking (among other things) about the titles of your latest emails for account recovery. (after I have put all the links here I realized that these don’t give a details on whether this also applies to inter-proton messages…)
A few sources:
https://proton.me/support/proton-mail-encryption-explained
https://www.reddit.com/r/ProtonMail/comments/b1ect2/a_question_about_encryption_metadata_subject/eiphhs7/?context=3
https://security.stackexchange.com/questions/196265/why-is-some-meta-data-not-encrypted-in-proton-mail
Yeah, might as well be. But if it is, I’m afraid we won’t get to know for a few decades, if ever. And I think it’s still better than the alternatives… the alternative email providers, that is.
If it comforts you, in their reddit comment I linked they mention (in 2019…) that there’s a proposal they support for openpgp to be able to have an encrypted subject line.
Really appreciate your thoughts and time, thanks.
I found out also that Tutanota is essentially the same, except that they do E2EE subject lines between tutanota users, but I am guessing that is because they don’t use PGP unlike Proton. In which case, Proton is in the right in this case because they are increasing E2EE interoperability beyond just their own users. So, my comment about honeypotting was really uncalled for I think, and I apologize for that.
The OpenPGP proposal is interesting, but I couldn’t find anything on it. All I found was this below, which explains that email headers can’t be/aren’t encrypted, and subject is one of those, so that’s why. I have no clue what Proton was talking about, or where they got that info
https://www.reddit.com/r/ProtonMail/comments/cku293/cant_find_the_openpgp_subject_line_encryption/