Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@freakazoid Right, and that is a legitimate issue, but - and this is the crucial point - that is first and foremost an *operating system* problem.

There's so much more that operating systems could be doing to be much more resilient against this type of issue, like capability security, but aren't. Instead, the problem got shifted to firmware, even though that's a much worse place to address it in in many ways.

(Also: something that fucks with the boot chain can still be removed. There's nothing that makes that *fundamentally* harder than any other kind of software repair, and with sufficient-yet-imperfect security on the OS level, it would be a rare enough occurrence that it can be trivially handled through all the usual repair venues.)

@freakazoid Does it, though? What is the actual threat model here? Because this whole boot security panic started with BIOS malware - which needs to get installed somehow, which is usually going to be done by something run *within the OS*. If the OS does not permit that, nothing *can* get between the two.

The only threat models that firmware-level protections actually protect against are those that involve someone with physical access - and even then if the whole thing is configured in a watertight way and there's zero vulnerabilities in the system, and absolutely nothing except for a specific boot image is allowed to boot.

That leaves us with roughly three categories of beneficiaries:
- Particularly tech-savvy high-profile activists,
- Corporations trying to keep out employees, and
- Manufacturers trying to implement DRM.

There are other categories of people who would benefit from protection against physical attacks (folks with abusive partners, for example), but they are vanishingly unlikely to be able to set up boot security in such a way that it actually *would* protect them. And the vast majority of people are not high-profile activists.

So who is this firmware-level protection actually *for*?

@freakazoid While complexity is a real issue, I think the problem is of a different nature here: bootloader security should not have been the firmware's job to begin with, this is something that is IMO handled much better on an OS level, which can finely control which things can or cannot mess with the boot setup.

@freakazoid The bigger problem is that manufacturers cannot actually be trusted to do this right and so implementations constantly get broken, regardless of what the cryptographic model is on paper

@SimonTesla I... question whether that is even compliant with the applicable legislation, to be honest.

@venite Duidelijk onmisbaar commentaar!

@nessie The "mutual" refers to "among peers", more or less - rather than depending on some central institution of power, we help each other.

There's some degree of reciprocity implied in that, in the "each other" part, but it's not a hard expectation, and it's not just about financial support either - it's much more about the underlying ethics of solidarity, helping when you're able and receiving help when you are in need.

Some people will need much more help than they can give, because they grew up in a much less privileged environment, and that's completely okay - they don't "owe" anyone anything. The help is freely given, it's just about recognizing the moral responsibility to give that help if you *are* able.

Summarized: if you are in need of help, money or otherwise, feel free to ask for it! You do not owe anyone anything for it. All that's asked is that *if and when* you find yourself in a situation where you're stable and doing well, you have a look at how you can help others still in need. If things never are stable enough for that, that's okay too.

As long as those who are doing well do their part in supporting those who aren't yet, we'll all get there.

@ryantownsend @viq Over the years, I've had a peek behind the curtains of a lot of infrastructure/service/security providers, in various capacities and to various extents, and I honestly can't say that I share that reasoning.

I'm certainly not saying that there are no competent people working at such companies, but there's often a very big cliff between "the security/reliability posture that is advertised or implied" and the "the posture that the provider actually has", frequently because of overworked infra/security teams or micromanagers meddling and not letting them do what's needed.

There are probably specific providers which have competent teams (though even that only gets you so far, at a certain scale it becomes unmanageable). But I think that outsourcing it to a competent-*appearing* provider and assuming that takes care of your security/reliability, is a very dangerous thing to be doing. You're mostly just paying for a security blanket at that point - which of course will be cheaper than the real thing.

Basically: if your company is dependent on IT infrastructure, you *must* have someone in your company who understands that infrastructure, its weaknesses, and who has both the ability and access to recover from its failures. Whether you outsource things to a third-party provider or not. And by that point, running a standard Linux server is not a very tall order either.

@freakazoid I'm not sure that that strategy's going to pay off, given that their stock price has *remained* low and even the opportunistic vulture traders seem uninterested in the company now

@viq @ryantownsend I would count them as one such platform, yeah. Though again with the same vendor lock-in caveat :)

(And they do piecemeal billing, like AWS, which is a very good way to get a surprise bill at the end of the month IME)

@viq @ryantownsend I'm more thinking of platforms like Heroku (ironically) and the smattering of other "we will host your app for you [with various degrees of add-on services]" providers. They kind of by definition provide a standardized environment, at least within the confines of their own service.

But I find them uninteresting due to the vendor lock-in, so I don't track very closely which ones are currently alive :)

@viq @ryantownsend My suspicion would be that that's because tooling and documentation for k8s are better than for NixOS, as that is usually the reason; which can be a valid reason for an immediate choice, of course, but is also somewhat of a chicken-and-egg problem :)

Short of massive capital injections, things are generally only going to improve if people use them, and so it often pays off in the long term to look more closely at the 'minimum complexity' introduced by different options, and select one with a low complexity even if it means a bit more work to figure out how it works. (In general, not just regarding NixOS)

@viq (Of course there are also many PaaS options, as @ryantownsend alluded to, but as those generally come with some form of vendor lock-in, I did not include them here)