- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 8 Feb 2011 18:39:32 -0500
On Mon, Feb 7, 2011 at 6:15 PM, Adam van den Hoven <adam at littlefyr.com> wrote: > But that is exactly what has happened, or perhaps some existing pollution is > simply being codified. atob() and btoa() were first implemented years ago, I guess by Netscape, and are supported in all major browsers except IE. So they were already in the global namespace (except if you only care about IE). > You could collect them into a single global object, and that was something I > though about, as well. But I think that this is a more generally applicable > solution.?There are many libraries that do nothing but load javascript from > within javascript. They all do it by writing a script tag to the DOM. I > believe this is a code smell. Having a consistent way to do this sort of > thing would improve the lives of a lot of code developers and create some > consistency between what is happening on the server side as well. It would certainly make sense to have some way to include JavaScript other than adding <script> to the DOM, but I don't think it needs the namespace/module-style functionality that's part of your proposal. Your proposal seems to be trying to do several different things at once, not all of which look necessary. To make a good proposal, you need to first clearly identify all the problems you see with the status quo, in the form of use-cases -- "I want to do X but can't", where X is something of self-evident utility. Only once you've clearly identified the problems is it useful to talk about solutions. Mixing the problem statement together with your solution makes it harder for everyone else to consider alternative solutions to your problems. > It seems to me that allowing a mechanism by which compiled?javascript to be > cached between page requests should be a benefit. What does "compiled" mean here? Browsers these days do compile JavaScript to machine code, but if they could cache the compiled form with your proposal, they could cache it without your proposal too. How does your proposal benefit caching compared to the status quo? Or do you mean "compiled" as in JavaScript minification? In that case, I don't see how it's relevant to browser-level features, since browsers don't know about minification. > Inserting a script element is great, so long as you're writing code that > only gets run in a browser. What non-browser agent are you thinking about here? > The number of well behaved libraries is very limited and generally they > don't work well together. Jonas says this is being worked on elsewhere at the language level, so no need to consider it here further. > Its quite simple. If you have a page that contains user contributed content, > you spend lots of time trying to prevent people from injecting bad code. For > example, if you were to bypass the filters (which unfortunately does happen > from time to time) you could redefine jQuery.ajax to send a copy to where > ever. You could also steal the user's cookies and send them off to your evil site without using jQuery at all. How does access to jQuery exacerbate the attack? Once you can run JS, you don't need libraries to carry out typical attacks. Put another way, why would an attacker even bother trying to use the libraries you've loaded instead of just running whatever code they like directly?
Received on Tuesday, 8 February 2011 15:39:32 UTC