[whatwg] Thoughts on recent WhatWG blog post

[Aryeh Gregor]

On Mon, Feb 7, 2011 at 12:33 PM, Adam van den Hoven <adam at littlefyr.com> wrote:
> In reality all these belong to javascript, but modifying JS to include them
> is not feasible. Also, what if I don't want to do crypto in my code, why
> should I have all that lying around (not that its a hardship but why pollute
> the global namespace)?

Generally we try not to create new objects in the global namespace.
Instead, we try sticking them on other preexisting global objects in
most cases.

> I think that we would all be better served if we were to introduce something
> like CommonJS to the browser, or perhaps a modified version of the require()
> method. This would allow us to move the crytpo and the atob/btoa into
> specific modules which could be loaded using:
>
> <script>
> var my_crypto = window.require( 'html:crypto' ); //or however you wanted to
> identify the 'crypto library defined by html'
> var my_util = window.require( 'html:util' ); // my_util.atob();
> var $ = window.require( '
> https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js' );
> </script>
>
> and so on.

What problem does this solve?  The problem of global namespace
pollution?  Why not just define window.html (or some other single
name) and make all the functions methods of that object?  This is kind
of what we're doing already, although not so systematically.  Your
solution seems overly complicated.

> Further, in CommonJS, the library has to export an object in order to make
> it available. If we could define things in such a way that the browser
> compiled the library independent of the page that loads it, the browser
> could cache the *compiled* code and provide that to the browser page. It
> would also be necessary to either enforce that these cached libraries be
> immutable or that a copy of the compiled code be made available. I couldn't
> implement this so I'm not sure how feasible this is but I suspect that
> requiring immutability would be the easier to implement.

What problem does this solve?  How is it better than inserting a
<script> element, when the returned resource has suitable caching
headers?

> This would have two interesting effects. 'widgets' loaded this way could
> easily be taken from different libraries, this jquery accordion that
> mootools tree view. No having access means that it would have to require it
> itself, and the normal scoping would keep that version internal to itself.

How is this different from importing any well-behaved library?

> Second, this could reduce security risks, if the widget requires a library
> using some authoritative URL (say from Google's CDN), then some blackhatter
> who injects JS onto a page by what ever means could not modify the meaning
> of, say, jQuery.ajax to do something else. They would have to compromise the
> the source code itself which is a significantly more difficult thing to do.

What attacks does this prevent?  If an attacker can already inject JS,
can't they pretty much do whatever they want?