Lol, ok, fair.

I guess I see a lot of wiggle room in the marketing speak of their page and I haven’t actually “looked in to” Proton Mail’s claims in a loooong time. So I guess what I really wanted to say is that it’s interesting to me that people take that marketing at face value if they’re actually trying to maintain secrecy. I’ve always just taken it as a given that third party services aren’t particularly good at that, especially as they grow in complexity like Proton has. Signal has been easier for me to believe because of the singular focus and the reputation of the founder in the crypto community; although I guess he’s long gone.

It’s interesting what people expect of Proton Mail. I’ve used it for a long time but for only one reason really: their revenue stream is my subscription and not ads. I’ve never even given a second thought to all their encryption claims. Even with Proton Mail if I ever wanted to send a “secret” email I’d wrap the content in my own personal keys.

With respect to IP addresses of email logins, I’m surprised they ever claimed they don’t have logs. You’ve always been able to review the IP of a login through the web UI as far as I remember. Was the idea that that was also supposed to be encrypted?

Personally I’m OK with them complying with court orders, but I understand that “the definition of criminal is state defined” and that poses serious issues. It kinda seems like if you want to do something that could be considered criminal at some point in your life by your country you should consider something other than a 3rd party email provider for those messages. Signal would be a step up in that regard if you still wanted to use a third party.

We seem to have a very different view of the discussion of “open source” and “open source models” above. I don’t entirely see how you arrived there, but that’s OK. I don’t think I took it on a tangent at all. No biggie I guess it’s just a forum.

Does that actually match with the discussion in your opinion? The discussion about building open source projects? Does the information I provided not help in understanding my response?

Are you being serious or just trying to be pedantic…?

I don’t follow CVEs: when was the last time a remotely exploitable kernel bug was a concern? Ignoring the fact that this is a home server and they likely care about uptime a lot more than exploitation on their LAN.

Generally I expect kernel bugs to be LPEs so updating user space would probably be sufficient for most home servers

I agree, but given the context of the discussion and the commonly accepted definition of Linux from Scratch, what else do you think they could have meant other than building a complete Linux based operating system from source?

The average person wouldn’t be building an open source LLM either. I don’t think I follow. I was just saying that your comparison wasn’t going to hit correctly at all due to how easy it actually is to build Linux and a full Linux distribution.

… Then why did you use it as an example?

It’s mad easy to build your own Linux from scratch in comparison to building an LLM. You can have your own distro running in like an hour. With buildroot you can have it in even less than that.

The difficulty of black box over white box is the reason obscurity has benefits…

only using my own code

You’re going to write your kernel and bootloader as well? Drivers for the hardware? And a compiler for those? And an assembler to build that bootstrap compiler? Build the CPU? The second any of these are “out of your control” you lose “absolute security”. The reason people say there is no “absolute security” is that it is not a useful concept to even consider. Since you have to approach it theoretically, you can easily end up stuck at the fact that every computation changes the state of the world and thus every computation can in some way be measured. It’s a useless endeavor even if it were theoretically possible because it leads you to absurd solutions against absurdly powerful attackers. You want security in a well defined threat model not some “absolute”.

Air gapping isn’t sufficient to prevent communication either. For example there are functional TCP stacks working over audio. Silence on the Wire is quite old at this point, but also explores esoteric exfiltration methods.

People like to think in black and white, but you’re definitely right. Having your SSH server on port 36271 will likely stop a ton of drive by attacks because they simply won’t check it. Having it only listen on IP6 would stop almost all of them because you can’t trawl the IP6 space efficiently. These are “obscurity”, but they have real benefits. The idea that “obscurity” doesn’t help is just a meme that people love to quote because it’s a great single sentence with some nice rhyming “security by obscurity”. I assume the reason it became a meme is because tons of products fully relied on obscurity; I still see it all the time. As you said, it’s all layers.

Yes I’m not going to take some “survival of the fittest” nonsense approach to security: consumers need securely built devices and software. This is the first line of defense always: we need to make things secure and then have secure defaults according to whatever we decide “secure” means in the context of our widget or software. Then we need to provide “advanced” (or even just “ignorant but risk tolerant”) users with the ability to change the device or software to match their definition of “secure”.

The easiest example is secure boot. Your laptop likely has a key provided by your OEM and likely Microsoft’s key preinstalled. This is a valid “secure boot” path for the average user, provided your OEM and Microsoft don’t get compromised, which is APT territory. However you are provided with the ability to use a different key if you know how to do that. You have thus opted in to protecting your own private key but now you have more control over your device. This design is notably absent in phones, which is absolutely bananas and actually less secure in some threat models

You could extend examples like this if you wanted. One could easily imagine a device that does soft brick itself after the EOL date to simply protect people that are ignorant of the potential risks, but also provides an advanced user with the ability to revive it in a “less secure” state. The less advanced user will then have to either learn something new or buy a new device.

Security is constantly used as a guise for removing consumer rights and as someone who has been in the security industry for about 9 years I’m so sick of it.

First and foremost, everyone please understand: the user should be allowed to opt into your concept of insecurity: you do not know their threat model and you do not know their risk tolerance.

Using exploits in low level drivers in the wild is approaching APT level, and even if there were a simple one to use it’d likely be useless without some sort or local access to the device (bar some horror show bug in a Bluetooth or WiFi firmware). The risk is incredibly low for the average person. I’d put it pretty close to 0.

Wire transfers aren’t instant and for large sums (your inheritance) the banks will likely require more than just a request from your app. If the bank cares about that then they can also use the attestation APIs which would be more than sufficient, as much as I hate them.

This boogey man of the APT going after my technologically illiterate <family member> with nation state level exploits needs to die. Long ago we entered a new era of security where it just isn’t worth it to waste exploits. Especially when you can just text people and ask for their money and that works plenty well.

Security is not a valid reason to soft brick consumer devices at some arbitrary end of life date.

This is not true at all. https://en.wikipedia.org/wiki/Post-quantum_cryptography good place to start if you’re genuinely interested. Most password managers that are worth while will be using symmetric cryptography which just requires longer key lengths to survive in the quantum age. AES256 should be fine for the foreseeable future.