W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] Javascript: URLs as element attributes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 30 Nov 2010 16:51:28 -0500
Message-ID: <4CF571E0.4030609@mit.edu>
On 11/30/10 2:37 PM, Darin Adler wrote:
> In WebKit, we have treated the javascript URL scheme as a special case, with explicit code in the loader, and not handled by general purpose resource protocol machinery. Maciej Stachowiak suggested this approach, back in 2002, and one of the reasons he gave me at the time is that thought WebKit would be more likely to get the security policy right if code paths opted in to JavaScript execution rather than opting out of javascript URL scheme handling.

Note that in Gecko, while javascript: is handled as a regular scheme, 
the handler for it will by default only run in a sandbox and only if the 
security context is known.  The security context is often not known 
(e.g. for <img src> it's not known).  And running not in a sandbox 
requires explicit caller opt-in.

So the net result is pretty similar.

But these are all implementation details.  As far as authors are 
concerned, javascript: is just a protocol like any other, except that 
trying to load it runs script.  Any deviation from this is additional 
complexity for authors; the further the deviation the more complexity. 
The question is how much complexity is warranted.

Certainly the webkit approach of only running javascript: explicitly for 
frame/iframe/toplevel documents is simplest on implementors.  It'd be 
pretty easy to get there in Gecko; we'd just remove some code in 
<object> and change the default execution policy from "sandbox" to 
"don't execute".  So I agree with Philip that for UAs this is the 
quickest path to convergence.  But is the result what we want for the 
web platform?

-Boris
Received on Tuesday, 30 November 2010 13:51:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC