Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.


This is actually not permitted by the Swiss law, so it's not going to happen.


You can use pgp to send mail to your protonmail acc :D.


Better security theater through marketing.


Yeah, they can just deliver an alternate version of the web client (assuming the target user uses the web interface) -- probably the easiest (or least-detectable) way for ProtonMail to read a user's encrypted email contents.


This is where the security stuff starts going down the rabbit-hole into Wonderland. I’m still trying to figure out how to write a compiler that won’t be subject to the “what if my ur-compiler was infected with a virus that only infects compilers” problem....


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.


There's an idea for hard sci-fi. Silicon backdoored with nanobots in sand.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: