You may be interested to know that AFS has implemented a variant of this feature. The conceit is that filenames can contain a magic string @sys, which gets substituted with the "sysname" of a particular system. This means if someone publishing software over AFS wants to have multi-platform support, they merely have to setup a directory divided by sysname and have compiled versions of the software for each system type they wish to support.

The first trap you will fall into thinking about this is that it should be the end-all security policy, and will solve our problems. It won't. That's not the intent, and also impossible given our diverse browser ecosystem.

The ability to tell the browser, via out-of-band, non XSS-able information, that certain scripts should not be executed, however, is a very powerful defense in depth measure, and makes it one step harder for attackers to make an attack work.

Security is a war of attrition. Bring it on.

That's because there is none; we agree. :-P

Don't use it, company I work for doesn't use it, don't care.

Why would Microsoft ever want to hire a cadre of Linux kernel developers? It's more likely that Microsoft would find some-odd patent in its catalog and sue them. :-)

As a typical geek, I don't care much about AIX's concurrent updates. If I were a corporate dude, I probably wouldn't care too much about AIX's concurrent updates (I'd have to have a lot of other good reasons for switching to AIX). As a geek who runs Jaunty, I care a lot about Ksplice. It's awesome. I can run it on all of my boxen. If I were a geek who runs another distro, I don't care much about Ksplice, except maybe for the fact that we're starting to get rebootless updates into mainstream. But if I were a corporate dude, I care a lot about Ksplice: if I pay these dudes, I can get these updates for *any* system. I don't need no special kernel. I don't need no complex process. I just fork over money and these guys make the magic happen. That's powerful.

Pointless or improvement?

Ksplice is still pretty neat, and worth playing around with (it's very very quick: after installing it's a little like boom boom boom, patches are applied). It also means that you can keep a fully patched kernel without having to compile one yourself every time a new patch comes out; a little different from being rebootless, but eminently useful for us mere mortals.

That's a collection of shell scripts around the free software Ksplice tool that merely automates the task of downloading the Fedora kernel. (The Ksplice software has been released for over a year, and is also packaged in Ubuntu and in Debian, although the ksplice.com apt repo has newer versions.) Ksplice's Uptrack service is a way to automatically apply Ksplice updates that have been vetted for safety by the Ksplice developers, which is a much more convenient thing unless you like reading every kernel patch daily and testing the resulting Ksplice patch yourself.

Note: Not all security updates support HotPatching, and some security updates that support HotPatching might require that you restart the server after you install the security updates.

Yeah. Rebootless updates. Uh-huh.

I'm sure if you talk to them, they can set you up with a pricing model for update streams for these distributions. :-)

That is an interesting question, no? After all, this company has made all of its software open-source, and if someone else is able generate update, they can "cut in" on Ksplice's market share. (This is forking the service, you're speaking of, not really the software.)

But this is not really a problem unique to Ksplice; it applies to any service based open-source model. And as such, what Ksplice has going for it is expertise: they were the ones who developed the Ksplice tools, they have an intimate understanding of the interplay between the kernel and hot updates, they are the ones who know how to "tweak" patches in order to make them work with the Ksplice system (as I understand, there are some nontrivial transforms necessary for certain updates).

So, they're doing the common "commercial open source" thing where the software (the application, the kernel patcher) is open source, but it's also tied to a service (the actual kernel patches) which is not so (free for Jaunty, but if you want a different kernel you'll have to pay Ksplice for support). So the Terms of Service applies to the service, which is really quite sensible.

If you read the CVE advisory carefully, the vulnerability is a faulty access policy for allowing extension installation by web-based JavaScript.

Yes, the technique is old, in that it's been around since iframes and CSS have been around, but we haven't really seen it in malware websites; most attackers use less sophisticated but still effective methods.