[whatwg] Javascript: URLs as element attributes

Philip Jägenstedt philipj at opera.com
Wed Dec 1 00:49:01 PST 2010

On Tue, 30 Nov 2010 22:51:28 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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.

I'm not sure. As currently specified, javascript: URLs do something quite  
different in the two cases browsing contexts and inline resources. Unless  
there is actually a body of content that relies on inlnie javascript: URLs  
executing *and* won't break if sandboxed as per the spec, it's hard to see  
that we're going to create much confusion.

> 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?

Given that the feature can't be made completely consistent for security  
reasons, I guess it comes down to use cases. Are there solid use cases for  
using the return values of sandboxed scripts as the content of documents,  
that aren't equally well served by the data: protocol?

Philip Jägenstedt
Core Developer
Opera Software

More information about the whatwg mailing list