You've missed my point: UEFI offers another layer of defense. (And not withstanding, the O/S being adapted to make use of the secure loading, local attestation, etc. etc.) Make sense?

With respect to loading something new - unsigned - depends on how the O/S implements attestation, right? And it does *not* have to exclude one for the other. This is the big deal about UEFI - the difficulty of managing the (trusted) signing keys so that coders can readily deploy a new and/or updated set of code (let alone, test drive it in production!).

And you're absolutely correct on running PHP or Perl or..whatever - unless they do something like Java's sandbox security mechanism (which according to most sources is the #1 attack vector for online attacks). Then you just get another can of worms to defend.

Huh? If you have to re-install *any* O/S, and the user has not backed up their files, UEFI does NOT make it worse.

It is absolutely the same.

It's the "thoroughly written" part that's hard. Secureboot adds another layer of defense to the O/S and applications it loads. Here's what makes it more difficult:

If the BIOS only allows the loading of "trusted" O/S - because it's been signed by a known key, and in turn, the O/S only allows the loading of trusted apps - because they are signed by known keys - then the compromise needs to become trusted in order to run. In other words, unless the compromise is using a trusted key to sign the malware, the O/S will reject loading the stuff.

Thus, just tweaking some bits is no longer adequate - you would now need to re-sign whatever you've changed. And this problem - having to sign code with trusted keys - is at the heart of the petition cited by this poster. It's NOT about secure boot loading (which is actually a good thing); it's about the lack of freely available keys to sign open source code with.

*LOTS* of people should get recognized for work related to crypto. Then again - if you're any good at it, chances are there are groups who would rather you didn't get recognition.

The recommendation has merit regardless of the political motivation. The heart of the issue is how does one TRUST and verify the INTEGRITY of the download when its transported using XML. What's frustrating is someone's inability to agree to rely on existing standards - there's simply no reason to spend more $$$ reinventing / resolving what's already solved. Doesn't the government currently exchange XML-based information today? Isn't that information secured in such a manner that the provider (say, the contractor of the F-22) can be proven and the validity of the message confirmed? Another side-show and the land of the free where matters such as paying people to entertain us is more important than paying people to educate us.