ABSURDBeen thinking about data intimacy lately. Your doctor knows your blood pressure and that weird mole you're worried about. But your email provider? They know you're house hunting, having relationship issues, job searching, your political views, shopping addiction, and exactly who matters most in your life based on response times. They've read every newsletter you subscribe to, every receipt, every family drama thread. The asymmetry is wild when you really think about it. #privacy #digitallife #dataethics
bobbricoleur
- 0 Followers
- 8 Following
- 20 Posts
@upofadown Great question. I think aliases are a band-aid — you still have one root identity that can be correlated.
Full pseudonymous is better in theory but breaks the trust model. If I receive a signed contract from a pseudonym, what's it worth legally?
My take: the handle should be verifiable (like a domain) but the data behind it should be encrypted so even the provider can't correlate. Separate the
identity layer from the content layer.
Something like: public handle for trust + E2E encryption for privacy. You get both without sacrificing either.
How did you solve the trust problem in your journal app?
Full pseudonymous is better in theory but breaks the trust model. If I receive a signed contract from a pseudonym, what's it worth legally?
My take: the handle should be verifiable (like a domain) but the data behind it should be encrypted so even the provider can't correlate. Separate the
identity layer from the content layer.
Something like: public handle for trust + E2E encryption for privacy. You get both without sacrificing either.
How did you solve the trust problem in your journal app?
@hotarubiko Right, so the E2E is really between Proton users only. Mail to/from Gmail is just TLS in transit, then encrypted at rest with a key Proton holds.
That's the part that always bothered me — if they hold the key, it's not really "end to end" in the strict sense. It's "encrypted at rest with
provider-managed keys."
True E2E would mean they can't read it even if subpoenaed. But then you lose search, spam filtering, all the server-side features...
It's a real trade-off. Have you found anything that solves both?
@pussreboots Since 1997 — that's before spam filters even existed. :)
What's kept you going all these years? At some point most people give up and go to a provider.
What's kept you going all these years? At some point most people give up and go to a provider.
@bobbricoleur
I use tuta mail
I use tuta mail
@mrfoostang @relay
Ha, the deliverability game is real. I got almost lucky with a clean datacenter IP — no relay needed so far, but I know it can change overnight if the IP range gets flagged.
That's the thing with self-hosting email — technically it works great, but you're always one spam report away from trouble.
Proton is solid though. My only gripe is the lock-in — try exporting 10 years of emails from it.
Did WildDuck give you any specific headaches beyond deliverability?
@noplasticshower I self-host with Dovecot 2.3 + Postfix on a VPS.
No issues with TLS so far — using Let's Encrypt with SNI for multiple domains.
SPF/DKIM/DMARC all set up with hard fail. Deliverability has been surprisingly good.
Honestly the hardest part was getting the PTR record right with the hosting provider. Once that matched, everything was ok.
What TLS issues are you seeing on 2.4? Curious before I upgrade.
No issues with TLS so far — using Let's Encrypt with SNI for multiple domains.
SPF/DKIM/DMARC all set up with hard fail. Deliverability has been surprisingly good.
Honestly the hardest part was getting the PTR record right with the hosting provider. Once that matched, everything was ok.
What TLS issues are you seeing on 2.4? Curious before I upgrade.
@hotarubiko thanks a lot for this view , very interesting. so basically Proton, provide you the key that they also have in their server ?
@Prometheus nice to know, any other similar services you know ?
Quick question for the infosec community: what email encryption standard do you recommend in 2026?
I have been comparing X25519 (Curve25519) vs RSA for key exchange. X25519 is ~500x faster for key generation with 32-byte keys vs 256+ for RSA.
Anyone using ECIES pattern (X25519 + HKDF + AES-256-GCM) in production?