I think it's more a matter of the knowledge on how to use Java as an attack vector (and the inclusion into Java exploits into easy-to-use-kits) causing the anti-Java sentiment, not who owns Java.
And some of that sentiment is misplaced: These exploits are largely a client-side problem (e.g., browsers running Java applets or downloaded Java apps) brought on by the servers dishing the Java up not being properly secured and/or managed.
Java's a great language in terms of what it's brought to the forefront of application development - both in terms of standardizing what a language can offer (I still loathe the days of having to decide if I would roll my own containers or memory manager in 'C' vs. picking and paying for someone's 3rd party libraries) as well as the OO aspects it forces you to consider.
Tough to blame the "media" when good old economics + gov't misdirection play a large part of slanted reporting: When you lose the mainstream funding mechanism for solid investigative reporting (newspapers), and the public relies on the Internet style of reporting (skim what's in the news), well, you creating a nice opportunity to paint whatever you want..
Reading bytes of sound bytes @ whenever you boot up the newsreader.
funny real event: Co-worker could not get his email client to work. Connection is managed using SSL, and the tunnel setup was failing. The reported error was a certificate invalid. That didn't jive with the CA cert - it was issued a year ago and is good for like 20 years.
After looking and looking and looking: He realized his system date was set to 1/1/1980 - his CMOS battery was dead.. Jan 1 1980 is prior to the start of the validity period for the CA cert in use..
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.
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (6) Them bats is smart; they use radar.