miscoded

The DOMStorage feature of the WHATWG WebApps spec is criticised for the security implications. 0x000000 has excellent points (particularly in comments) and I'll think out loud about how UAs like Firefox and Opera will need to address them. I'm not terribly good at spec writing and not implementing this stuff myself so only personal opinion and thoughts to be found here..

Quoting 0x000000:

Starting in Firefox 2 but mainly in Firefox 3, the browser is fully capable of restoring this sessiondata after a crash. This is interesting because we could on purposely crash a window and inject sessiondata to make it an persistent denial of service

Yes, that's a real threat. Opera already addresses a similar issue in the dialog you get on resuming after a crash, where you can choose to start without open windows. An even better implementation might be to detect what window or session caused a crash, and attempt to restore all others - I assume it would require quite some engineering like a separate monitoring process or something. In any case, users will need a "start without restoring sessions" option to avoid persistent session storage enabling persistent crashers.

this storage engine allows me to store what ever I want, whenever I want, and it allows huge data -if I have access to that page- which is useful when there is some XSS hole on that page

Um, if there is an XSS hole on the page you've got the data anyway, is this really more dangerous than just submitting it to a server you control?

It can be used to store worms and activate them across webpages instead of calling remote scripts

Still requires some XSS vulnerability on the page you want to run the worm on. If white-list restriction is implemented it requires both attacker and target to be white-listed.

it can used to store heapspray shellcode to actively stay under the radar of anti virus programs

The bad code needs to travel over the wire at least once to get to the local storage, so that's not entirely true but still an interesting point. I guess it's a matter of timing. If you can get a piece of malware into the local storage of a sufficient number of UAs before security software is updated to detect this threat, you could then activate the attach with some fairly innocent-looking JS that might be much harder to filter out. Should UA vendors collaborate with Antivirus companies on enabling local storage scanning? I'm not sure here, guess malware detection evasion side effects of local storage need more thinking..

it can store a great deal of information later to used on sub domains to read them out again and use them, like defeating single sign on schemes

I'm not sure what he means by "defeating single sign on schemes" here.

it can also be used to profile users and de-annonymize them by storing data vectors in their browser

Yes, it can if you find an XSS hole on a site I give personal information to (or if a web developer by mistake stores given information in a too public part of the local storage).

Now, security concerns are addressed by the specification. Perhaps it's too easy to overlook, but note how the spec explicitly states that

user agents may prevent domains from storing data in and reading data from the top-level domain entries in the globalStorage object

and I guess UAs will in practice require per-domain white-listing of domains that are allowed to use global storage, or make it available only in "application-like" contexts such as widgets. I can't imagine any UAs implementing this part of the spec without additional security restrictions, that would indeed be crazy. On the other hand, per-domain whitelisting will address most of his potential exploits as long as the white-listed sites themselves are safe.

Nevertheless, the spec gives greater powers to web developers. It will enable them to do interesting things more easily, but as we know with greater powers comes greater responsibility - including responsibility for coding responsibly and preventing XSS. The greater capabilities we give JavaScript, the greater the damage a single XSS exploit can cause.

(Opera doesn't support DOMStorage yet but we probably will at some point, apparently Firefox 3 will support it according to 0x000000's post.)

In ECMAScript, functions can be defined by a "FunctionDeclaration" or a "FunctionExpression". Basically, the difference is that a FunctionDeclaration includes a function name so that it can be called from other functions - it is defined as:

function Identifier ( FormalParameterList_opt ){ FunctionBody }

while a FunctionExpression is the anonymous function - note in the definition that the "Identifier" part is marked as optional:

function Identifier_opt ( FormalParameterList_opt ){ FunctionBody }

However, including an identifier is still allowed. The identifier can be used inside the function to refer to itself, but not outside it.

This may confuse authors if we forget that whether something is a FunctionDeclaration or a FunctionExpression depends on the context. The right hand side of an assignment or the arguments of a function call will be a FunctionExpression, in other words behave like an anonymous function. For example

var a=function b(){return 'Hi'}; alert(b());

fails: there is no function named b there. alert(a()) would work. Likewise,

setTimeout( function a(){}, 50 ); a();

fails because the argument is evaluated as a FunctionExpression and after the setTimeout() call no function named "a" exists. (IE seems to violate/extend the standard here!)

It can be confusing that a FunctionExpression is allowed to look exactly like a FunctionDeclaration but behaves differently, and I don't really see a strong use case since arguments.callee exists.