Then there are the national governments and things like insurance companies. All happily sending message notifications where you need to sign in to their own portals.
Securing email is too complex, so everyone builds their own secured portal thingy, and your mailbox has become a receptacle for notifications. Figuring out a solution would require cooperation, pragmatic lawmaking, and giving up those nice cashcows of moated portals, so it won't happen.
Every vendor's secure email portal I have ever used was ultimately authenticated using my email account. Any one-time passcodes are sent to the same email. Password recovery? Email. If a malicious user is on my PC or otherwise intercepting my mail, they could access 100% of the solutions I've got access to right now.
When BofA sends me a new statement I need to:
* click on the link in my inbox
* wait for the email-provider to scan the email (and Office 365 does sometimes tell me they can't scan the link)
(either) * Enter my username & password
* Select that I want my 2FA via call or text
* Wait for the call or text to arrive
* Enter it (now I'm signed in)
(or) * search my house for my YubiKey
* lean over to insert YubiKey
* click cancel on the Windows popup for the passkey
* click cancel on the Bitwarden popup for the passkey
* click Physical key on the Chrome / Edge popup for passkeys
* put in YubiKey pin
* lean over again to physically touch YubiKey
(end) * Click no on the next credit card offer
* Navigate to Credit Cards
* Click the Credit Card
* Click Documents
* Click current statement
orwhen I'm on my walk (which I do anyway)
* insert key in mailbox
* (no delay) open mailbox
* (no delay) take out letters
* (no delay) close mailbox
* (no delay) remove key
* walk home
* open statement
* validate statement
* trash statement
Even with passkeys there are too many where the flow can / purposefully is interrupted.Here in the US we only wish things were that secure.
Unless by 2FA you mean “code sent via SMS”.
Bluesky follows this pattern for the benefit of the user. The internet tradition has always been: if you want to control it, you have to host it.
In the context of sending a secure message, the sender maintaining control goes in the negatives column. At best it's a compromise in exchange for specific security features.
I actually think there is a more general opportunity here with AI. Every app and website and UI I use is optimized by a gaggle of PMs to achieve business objectives that don't necessarily benefit me. AI is getting to the point where soon it will be able to use these non-aligned UIs for me, and present to me a much simpler UI customized just for me, that does what I actually want and no more.
- Fetch your emails using any of the common local mail sync tools
- Some processing to clean up the plaintext version, may not be necessary even
- Send it to an LLM to extract a link
- Open up a headless browser, trigger something like SingleFile to extract its content.
Though you'll have to keep the cookie refreshed, but if it is initially logged in, this should be fine since you can also program something to keep refreshing every once in a while.
I hovered on the link in Gmail and Chrome told me left bottom it was just that exact url.
But when I opened the url it got blocked by the great firewall.
Why? Any link in Gmail secretly gets replaced by a link to Google that tracks you and then redirects you to the original link.
The most obnoxious thing about this I think is that Chrome shows the original link.
I understand why Google.com wants that data. But in an email client it’s extremely obnoxious.
(IE11 probably isn't super relevant now - but it was almost certainly more relevant when that tracking code was written. You could use feature detection - but its much easier to just use their hacky javascript everywhere instead.)
https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorE...
Not defending Google here, but could it be that the tracking page is opened by onclick() while the browser shows the original href attribute?
I've seen some websites do that for various purposes and opening the link in a new tab (middle mouse click) usually bypasses it.
If you want an opportunity in this space, it isn't actually encrypted emails, but possibly standardizing and streamlining such "message pointers" and address endpoint verification.
I know that there are a lot of HIPAA "secure email" solutions that also do this, but I don't want this to become more common practice then it already is...
Long term archival is a different use case altogether, especially of encrypted materials. It's questionable whether any provider or medium can survive over the long term, so it's better to use an encryption system where you hold the keys and the encrypted data can be migrated to any sort of storage or provider over the years.
Focusing on the Future of Secure Communication
[...] Starting next week, E2E emails on Gmail will no longer function, and all your E2E messages on Gmail will be deleted on February 1 2029.
Then there were a whole plethora of products were build around Lotus Notes Domino that provided a central place for securing outgoing E-mail using either S/MIME or GPG keys. All of this on premises. Then came the Cloud and obliterated these products. And for what?
edit: typos
It was never really solved, PGP email is a usability disaster.
Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire conversation is exposed. Key exchange with new recipients is tedious to do securely.
Not to mention the extra issues caused by HTML in message bodies.
https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you...
In a managed environment, you also get the advantage of certificates stored in a central directory (LDAP etc), and so certificate selection for the client is seamless.
All you have to do is hit "encrypt" in your mail client, enter your smart card PIN and the machine does the rest.
> Not to mention the extra issues caused by HTML in message bodies.
Proton Mail came out with a pretty good statement about this and I fully agree.
> Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk.
Is it that hard to generate a certificate for each email address client side and store that, and the private key encrypted with the user’s password, on the provider’s server?
The majority of email is gmail and Google could make that E2EE by default.
Countless products that have successfully implemented public key distribution (proton mail, instant messaging, …).
Unfortunately, the real world is much more complicated than that.
If Google, Microsoft and Apple offer E2EE similar to Proton, the majority of email will be encrypted, as long as both sides use the same service, or globally if these companies share public keys for public key discovery.
Job security. The software industry was built on the premise that users would buy all new software and hardware every 3 years. In the mid 2000s they collectively realised that software was ‘good enough’ for most users, and that it doesn’t wear out.
SaaS, the subscription model, “the cloud”, they’re all about making the user pay more than once for the same software.
The big problem is verifying identities. The usability of that is an unsolved problem that plagues encrypted messaging of all kinds. So sure, signing PGP keys as a form of introduction is awkward, but at least it is possible. How do you vouch for, say, a Signal user?
Signal uses a much more complex key ratcheting system. It’s TOFU, but the key rotates with each message I send. The first message is vulnerable to a MITM attack, but because of the way signal works, if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure. The earlier keys are also published to make messages deniable. (Aka OTR).
Even then, if you want to verify who you’re talking to, you can click on someone’s name in signal and click “View safety number” and verify the code through a separate channel. Like, in person or over a text message or something.
Because your code is different for every conversation, it protects against correlation attacks. That is to say, a 3rd party watching the traffic can’t tell that all of the messages you send to different recipients came from the same person. Email+PGP doesn’t encrypt the most important information - which is the identity of the sender and receiver.
Signal is way better than pgp-over-email in every regard. The UI is better. There’s no encouragement to publish your keys or your social network. And the security ratchet is better than the static key that pgp uses. I’d pick it every time.
>It’s TOFU, but the key rotates with each message I send.
You seem to be confusing the Signal long term identities with forward secrecy.
>...if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure.
This isn't true. Signal verifies identities the exact same way PGP verifies identities. As with PGP if you haven't checked your "safety numbers" you can't be sure your messages are actually ending up with your correspondent.
>Because your code is different for every conversation, it protects against correlation attacks.
PGP normally uses a different session key for each and every message ... but that isn't really relevant for either the Signal or PGP case if we are talking about correlation. For efficiency and convenience each message is normally tagged with the encryption key fingerprint of the recipient but you can turn that off if that might be a problem in your particular application. At that point there is nothing an observer can use to determine anything about the sender or receiver.
You probably meant to reference Signal's "sealed sender". It doesn't really work in practice:
>https://www.ndss-symposium.org/ndss-paper/improving-signals-...
Some work in this area has been done in the form of browser extensions that are used to verify signed assets delivered to the client:
https://github.com/freedomofpress/webcat
https://github.com/tasn/webext-signed-pages
https://github.com/jahed/webverify
https://github.com/facebookincubator/meta-code-verify
But unfortunately for now, none of these are seeing wide adoption and this remains an unsolved issue. It also does not require anyone to use known-good, audited and verified open-source components, meaning even if the client code is signed, it can still be malicious... there must be a greater reason to trust the code than just "trust me bro".
They ought to do pgp though
Most people, for most things, don't need to verify trust outside of normal government channels.
i.e. any business I correspond with, trust is via the government that they are a business bound by the relevant legal system I live in.
Same story with communicating with basically anyone: if their GPG key was signed by the common government key, then hey, good enough for anyone.
The problem is...we don't have the infrastructure for any of this. And GPG key servers are inadequate for maintaining suitable privacy for people if they were used at this scale.
But we certainly could provide the means by existing technologies: e.g. nothing stops us making drivers licenses and other forms of ID smart cards.
Trusting the government as a peer makes sense for government sites, but for anything else, it just makes censorship way too easy.
Even among businesses, we normally trust the middleman (the credit card issuer, and their protections and chargebacks) over the government. If a business screws over a regular consumer, the government isn't really going to do anything.
Maybe you have a more civilized society and functional government where you live. We don't.
The point isn't "trust the government" the point is trust is contextual and the notion of "key signing parties" always missed it (and if you actually go and read up on the concept, government ID documents were considered to be something to ground whether a signature should be issued by someone so it was already baked into the system anyway).
Companies rolled their own out of a commercial need. The FOSS community didn't trust the government or big companies so never fully solved the problem. Users just don't care.
If you disagree, go set up GPG on a non-tech’s computer, tell them they need to use Thunderbird or some other helper app(s), and see if you can even go home before being asked to remove it all.
That email is your internet id and majority countries digital id too ? Who cares, things usually need to be so broken that even elected officials families report problems :) Then we can have some "plans" announced. EU is especially good at this - announcing (and pushing for more centralization no matter what is happening) and not fixing anything, eg. sane CPU's, when ? Rhetoric question because not in this decade...
By whom? It looks like E2E to me. It’s just that both ends are controlled by the same entity.