Ask HN: How do you trust that your personal machine is not compromised?

What does the policy really protect against?

If it's being locked out after 15 minutes of inactivity because of roommates or kids it doesn't protect you against anything in the grand scheme of things. For example if I leave my office for lunch and you step in 10 minutes later then you have a solid 40-50 minutes to do whatever damage you plan to do while I'm gone.

The only time it makes a difference is if it locks really fast, such as 30 seconds but then using the computer naturally would be ridiculous because you couldn't stop touching the keyboard or mouse without being locked out.

Also, what if your room mate planted cameras in your office that let them see exactly what keys you're pressing on what screens without ever compromising the machine itself? Now everything is compromised and they have full reign to do whatever they intend to do.

> The argument that you live alone etc is irrelevant as I have no idea (and don’t want to know) whether that’s true

This is the real problem. Everyone gets treated like an equal criminal when in reality none of the measures taken really do anything to provide the security they were designed to do. It reminds me a lot of "for the children" but applied to corporations for "compliance reasons".

I'd be more ok with the precautions if they worked.

Until pretty recently (~3-4 years) Linux the kernel was actually pretty far behind in most respects versus competitors, including Windows and mac/iOS. I say this as someone who used to write a bunch of exploits as a hobby (mainly for Windows based systems and windows apps). But there's been a big increase in the amount of mitigations going into the kernel these days though. Most of the state of the art stuff was pioneered elsewhere from upstream but Linux does adopt more and more stuff these days.

The userspace story is more of a mixed bag. Like, in reality, mobile platforms are far ahead here because they tend to enforce rigorous sandboxing far beyond the typical access control model in Unix or Windows. This is really important when you're running code under the same user. For example just because you run a browser and SSH as $USER doesn't mean your browser should access your SSH keys! But the unix model isn't very flexible for use cases like this unless you segregate every application into its own user namespace, which can come with other awkward consequences. In something like iOS for example, when an application needs a file and asks the user to pick one, the operating system will actually open a privileged file picker with elevated permissions, which can see all files, then only delegate those files the user selects to the app. Otherwise they simply can't see them. So there is a permission model here, and a delegation of permissions, that requires a significant amount of userspace plumbing. Things like FlatPak are improving the situation here (e.g XDG Portal APIs for file pickers, etc.) Userspace on general desktop platforms is moving very, very slowly here.

If you want my honest opinion as someone who did security work and wrote exploits a lot: pretty much all of the modern systems are fundamentally flawed at the design level. They are composed of millions of lines of unsafe code that is incredibly difficult to audit and fix. Linux, the kernel, might actually be the worst offender in this case because while systems like iOS continue to move things out of the kernel (e.g. the iOS WiFi stack is now in userspace as of iOS 16 and the modem is behind an IOMMU) Linux doesn't really seem to be moving in this direction, and it increases in scope and features rapidly, so you need to be careful what you expose. It might actually be that the Linux kernel is possibly the weakest part of Android security these days for those reasons (just my speculation.) I mean you can basically just throw shit at the system call interface and find crashes, this is not a joke. Windows seems to be middle of the pack in this regard, but they do invest a lot in exploit mitigation and security, in no small part due to the notoriety of Windows insecurity in the XP days. Userspace is improving on all systems, in my experience, but it's a shitload of work to introduce new secure APIs and migrate things to use them, etc.

Mobile platforms, both Android and iOS, are in general significantly further ahead here in terms of "What kind of blast radius can some application have if it is compromised", largely because the userspace was co-designed along with the security model. ChromeOS also qualifies IMO. So just pick your poison, and it's probably a step up over the average today. But they still are comprised using the same fundamental building blocks built on lots of unsafe code and dated APIs and assumptions. So there's an upper limit here on what you can do, I think. But we can still do a lot better even today.

If you want something more open in the mobile sector, then probably the only one I would actually trust is probably GrapheneOS since its author (Daniel Micay) actually knows what he's doing when it comes to security mitigation and secure design. The FOSS world has a big problem IMO where people just think "security" means enabling some compiler flags and here's a dump of the source code, when that's barely the starting point -- and outside of some of the most scrutinized projects in the entire world, I would say FOSS security is often very very bad, and in my experience there's no indication FOSS actually generally improves security outside of those exceptional cases, but people hate hearing it. I suspect Daniel would agree with my assessment most of the fundamentals today are fatally flawed (including Linux) but, it is what it is.

Second, unless you're in a situation where you've pissed off/threatened some rather large actors, you should be fine assuming you follow best practices for backup, software, update and password management and you avoid using things like cheap IoT devices to connect to your cloud services.

Third, when disaster strikes, keep calm, rely on backups, change affected passwords and notify others who might get affected.

OpenBSD by contrast has dual auditing and a stellar security reputation, but development is much slower and compatibility is very low.

seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet.

MacOS, iOS, and Windows are proprietary so they are dramatically worse off than Linux in security out of the gate. No one should use these that desires to maximize freedom, security and privacy.