Re: [whatwg] Javascript: URLs as element attributes
On Wed, 9 Feb 2011, Boris Zbarsky wrote: On 2/9/11 10:12 PM, Ian Hickson wrote: On Mon, 15 Nov 2010, Boris Zbarsky wrote: On 11/15/10 8:15 PM, Ian Hickson wrote: Gecko's currently-intended behavior is to do what [the spec] describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: (Note that the spec has since changed on this; javascript: either runs in a browsing context that it is navigating, or it doesn't run at all.) What does it do for those cases if it doesn't match the spec? For iframe the behavior in Gecko currently is different in terms of what the URI of the result document of javascript: is set to. Try this: data:text/html,body onload=alert(window[0].location)iframe src=javascript:'' Woah, funky. (Gecko thinks the location is javascript:''.) Note that there is some confusion here in terms of browsing contexts and object, sinceobject does expose a Document object sometimes (but not others) and does participate in session history sometimes, I believe... So I'm not quite sure what behavior the spec calls for forobject. It's defined; see the section on theonject element. I've read that section, in fact. I couldn't make sense of what behavior it actually called for. Has it changed recently (last few months) to become clearer such that rereading would be worthwhile? Not as far as I'm aware. Could you elaborate on how it is confusing? I'm eager to make this understandable! At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. Hm. This currently isn't specced; the spec just assumes the return value is text/html string data and doesn't say what encoding to use. Is there a good way to test this in the context of aniframe, where all the browsers do something with javascript:? body onload=alert(window[0].document.characterSet)iframe src=javascript:'\u0400' http://junkyard.damowmow.com/466 Gecko: UTF-8 if the 'javascript:' URL includes characters 255, ISO-8859-1 if all the input characters are 255. WebKit seems to pick my default encoding regardless. Opera returns . IE8 returns undefined. Since Gecko seems to be alone in this weird behaviour, I haven't specced it. I couldn't find any other effect (e.g. the input seems to always be treated as Unicode, not converted to bytes and redecoded, regardless of what I make it look like, including UTF-16 and UTF-8). On Thu, 10 Feb 2011, Adam Barth wrote: On Tue, Nov 30, 2010 at 11:37 AM, Darin Adler da...@apple.com 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. Apologies for not reading the whole thread before replying, but the design Darin describes [above] has worked well in WebKit thus far. I'd be hesitant to make JavaScript URLs work in more contexts due to the risk of introducing security vulnerabilities into the engine. That's black-box equivalent to what the spec currently requires, I believe (though the spec implements it more like what Boris describes:). On Thu, 10 Feb 2011, Boris Zbarsky wrote: For what it's worth, Gecko treats javascript: URLs as a general protocol, but with tracking of where the URL came from required for the script to actually execute and explicit opt-in on the caller's part required to execute outside a sandbox. This too has worked well in terms of security, for what it's worth, while offering a lot more flexibility in terms of how and where javascript: URIs can work. I don't think we should gate the spec here on Webkit's implementation details if we think a certain behavior is correct but hard to support in Webkit On Mon, 16 May 2011, Philip Jägenstedt wrote: On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Feb 2011, Philip Jägenstedt wrote: For the record, I removed Opera's support (I assume it was an unintended side-effect) for object data=javascript:... along with the rest at the time when I wrote my previous mail in this thread. This intentionally doesn't match what the spec says. (Disclaimer: this is only my opinion on something that isn't really my area of expertise, so others
Re: [whatwg] Javascript: URLs as element attributes
On 6/6/11 4:45 PM, Ian Hickson wrote: data:text/html,body onload=alert(window[0].location)iframe src=javascript:'' Woah, funky. (Gecko thinks the location is javascript:''.) Well... it sort of is. ;) It's defined; see the section on theonject element. I've read that section, in fact. I couldn't make sense of what behavior it actually called for. Has it changed recently (last few months) to become clearer such that rereading would be worthwhile? Not as far as I'm aware. Could you elaborate on how it is confusing? I'm eager to make this understandable! I'll try reading it again and taking notes, I guess. When I can find time to. :( The latency is killing us here. Since Gecko seems to be alone in this weird behaviour, I haven't specced it. I couldn't find any other effect (e.g. the input seems to always be treated as Unicode, not converted to bytes and redecoded, regardless of what I make it look like, including UTF-16 and UTF-8). You can detect other effects by seeing what unescape() does in the resulting document, iirc. As well as URIs including %-encoded bytes and so forth. Also you can detect what charset is used for stylesheets included by the document that don't declare their own charset. There are probably other places that use the document encoding. Worth testing some of this stuff -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Feb 2011, Philip Jägenstedt wrote: For the record, I removed Opera's support (I assume it was an unintended side-effect) for object data=javascript:... along with the rest at the time when I wrote my previous mail in this thread. This intentionally doesn't match what the spec says. (Disclaimer: this is only my opinion on something that isn't really my area of expertise, so others at Opera might decide that the spec is great and push in the opposite direction. It seems unlikely at this point, though.) [...] Of what has been brought up so far, javascript: as an inline resource is not very useful at all, so IMO the only reason to keep it would be for legacy compat. I'll follow up on this again once the change to block inline javascript: URLs in Opera has been in the wild for a while, hopefully reporting that no compat issues have arisen. Since only Firefox now supports this, I've removed support for it from the spec. (It's just commented out for now; we can put it back if someone makes a compelling argument.) Great! I can report that the changes to block inline javascript: URLs went into Opera 11.10 and so far I'm not aware of any site compat issues having being caused by it. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Mon, 14 Feb 2011, Philip Jägenstedt wrote: For the record, I removed Opera's support (I assume it was an unintended side-effect) for object data=javascript:... along with the rest at the time when I wrote my previous mail in this thread. This intentionally doesn't match what the spec says. (Disclaimer: this is only my opinion on something that isn't really my area of expertise, so others at Opera might decide that the spec is great and push in the opposite direction. It seems unlikely at this point, though.) [...] Of what has been brought up so far, javascript: as an inline resource is not very useful at all, so IMO the only reason to keep it would be for legacy compat. I'll follow up on this again once the change to block inline javascript: URLs in Opera has been in the wild for a while, hopefully reporting that no compat issues have arisen. Since only Firefox now supports this, I've removed support for it from the spec. (It's just commented out for now; we can put it back if someone makes a compelling argument.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Javascript: URLs as element attributes
On Thu, 10 Feb 2011 04:12:09 +0100, Ian Hickson i...@hixie.ch wrote: On Mon, 15 Nov 2010, Boris Zbarsky wrote: On 11/15/10 8:15 PM, Ian Hickson wrote: Gecko's currently-intended behavior is to do what [the spec] describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: What does it do for those cases if it doesn't match the spec? For iframe the behavior in Gecko currently is different in terms of what the URI of the result document of javascript: is set to. How does it differ? As far as I can tell, it works the same as the spec says (the document.location is about:blank in the example above). For the others, I believe we execute them in the script environment of the owner document of the object/embed/applet, whereas the spec requires them to execute in a sandbox, as far as I can tell. Ah, interesting. For object, this seems to be a unique feature of Firefox. Opera also executes the script in the context of the owner, but then ignores the results as far as I can tell. Other browsers don't seem to support javascript: in data= at all. For the record, I removed Opera's support (I assume it was an unintended side-effect) for object data=javascript:... along with the rest at the time when I wrote my previous mail in this thread. This intentionally doesn't match what the spec says. (Disclaimer: this is only my opinion on something that isn't really my area of expertise, so others at Opera might decide that the spec is great and push in the opposite direction. It seems unlikely at this point, though.) On Thu, 25 Nov 2010, Philip Jägenstedt wrote: Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. There's a minor body of work on the Web that is based on using javascript: URLs to generate bitmaps, and I don't really see any harm with this. Even if there's no harm, it's unneeded complexity that so far doesn't seem to be needed for web compat, since it currently would only work in Firefox. I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? What the spec currently specs seems to be a reasonable compromise between security, compatibility needs based on what browsers do today, use cases, and consistency across the platform (usability), in that order. What compatibility needs? The only thing I'm aware of is using img src=javascript:... to generate X BitMap images.[1][2] However, the examples would break if the execution was sandboxed as per the spec. Obviously if browsers implement something different, then I'll happily move the spec to match, but it would be sad to just close off these features without good reason. Of what has been brought up so far, javascript: as an inline resource is not very useful at all, so IMO the only reason to keep it would be for legacy compat. I'll follow up on this again once the change to block inline javascript: URLs in Opera has been in the wild for a while, hopefully reporting that no compat issues have arisen. [1] http://www.ridgway.co.za/archive/2005/11/13/dynamicjavascriptimagegenerationwithxbmimages.aspx [2] http://david.blackledge.com/XBMDrawLibrary.html -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On 2/10/2011 12:09 PM, whatwg-requ...@lists.whatwg.org wrote: Date: Thu, 10 Feb 2011 13:43:11 -0500 From: Boris Zbarskybzbar...@mit.edu To: Adam Barthw...@adambarth.com On 2/10/11 1:38 PM, Adam Barth wrote: The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. That's fine; I just think that if you mean Don't specify this because we don't want to implement it and will refuse to do so you should just say that instead of making it sound like there are unspecified security issues with the proposal. Boris, It's more often your group that makes a stand with merit-less refusals. See devicePixelRatio and CSS scrollbar styling for an example of that. So, sure, I can see why you'd assume other groups would do the same. Adam, Would you be willing to dig up the bug report on webkit that documented your attempts to satisfy javascript: urls in embedding? I did a little bit of poking around, but didn't find it. I agree that data-uris are much easier/preferable, but I'd still like to see where the conversation went on the webkit dev list and/or bug list. -Charles
Re: [whatwg] Javascript: URLs as element attributes
On Fri, Feb 11, 2011 at 2:20 PM, Charles Pritchard ch...@jumis.com wrote: On 2/10/2011 12:09 PM, whatwg-requ...@lists.whatwg.org wrote: Date: Thu, 10 Feb 2011 13:43:11 -0500 From: Boris Zbarskybzbar...@mit.edu To: Adam Barthw...@adambarth.com On 2/10/11 1:38 PM, Adam Barth wrote: The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. That's fine; I just think that if you mean Don't specify this because we don't want to implement it and will refuse to do so you should just say that instead of making it sound like there are unspecified security issues with the proposal. Boris, It's more often your group that makes a stand with merit-less refusals. See devicePixelRatio and CSS scrollbar styling for an example of that. So, sure, I can see why you'd assume other groups would do the same. Adam, Would you be willing to dig up the bug report on webkit that documented your attempts to satisfy javascript: urls in embedding? I did a little bit of poking around, but didn't find it. https://bugs.webkit.org/show_bug.cgi?id=9706 https://bugs.webkit.org/show_bug.cgi?id=12408 This is the bug I was thinking about (although not all the discussion was captured in the bug): https://bugs.webkit.org/show_bug.cgi?id=16855 Most directly related is this bug, which unfortunately is marked security-sensitive. I've added Boris to the CC list of this bug, but unfortunately I can't open it up to the public at the moment: https://bugs.webkit.org/show_bug.cgi?id=41483 I agree that data-uris are much easier/preferable, but I'd still like to see where the conversation went on the webkit dev list and/or bug list. Hopefully the links above are helpful. Not all the discussion is captured in the bug database. Some of it happens on mailing lists and in IRC (as well as in person). Adam
Re: [whatwg] Javascript: URLs as element attributes
Apologies for not reading the whole thread before replying, but the design Darin describes below has worked well in WebKit thus far. I'd be hesitant to make JavaScript URLs work in more contexts due to the risk of introducing security vulnerabilities into the engine. Adam On Tue, Nov 30, 2010 at 11:37 AM, Darin Adler da...@apple.com 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. -- Darin
Re: [whatwg] Javascript: URLs as element attributes
On Thu, Feb 10, 2011 at 6:29 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/10/11 4:36 AM, Adam Barth wrote: Apologies for not reading the whole thread before replying, but the design Darin describes below has worked well in WebKit thus far. I'd be hesitant to make JavaScript URLs work in more contexts due to the risk of introducing security vulnerabilities into the engine. For what it's worth, Gecko treats javascript: URLs as a general protocol, but with tracking of where the URL came from required for the script to actually execute and explicit opt-in on the caller's part required to execute outside a sandbox. This too has worked well in terms of security, for what it's worth, while offering a lot more flexibility in terms of how and where javascript: URIs can work. I don't think we should gate the spec here on Webkit's implementation details if we think a certain behavior is correct but hard to support in Webkit The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. Adam
Re: [whatwg] Javascript: URLs as element attributes
On 2/10/11 1:38 PM, Adam Barth wrote: The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. That's fine; I just think that if you mean Don't specify this because we don't want to implement it and will refuse to do so you should just say that instead of making it sound like there are unspecified security issues with the proposal. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Thu, Feb 10, 2011 at 10:43 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/10/11 1:38 PM, Adam Barth wrote: The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. That's fine; I just think that if you mean Don't specify this because we don't want to implement it and will refuse to do so you should just say that instead of making it sound like there are unspecified security issues with the proposal. To be clear, this is just my opinion. Rather than flatly refuse to implement the feature, I'm just sharing my perspective on why WebKit behaves the way it does today and how it's likely to behave in the future. If someone turned up tomorrow with a patch that re-architected how WebKit processes JavaScript URLs to make it possible, e.g., to use JavaScript URLs in the src attribute of an embed tag, I suspect there would be a lot of consternation within the project about whether the benefits of the patch outweighed the security risks. If you look back in the bug tracker, you'll see that I tried doing something along those lines (albeit on a more moderate scale) a while back. The result was roughly as I've described: we decided not to accept the patches because of their security risk. IMHO, data URLs cover these use cases much better than JavaScript URLs. The benefits of implementing JavaScript URLs are mostly to be compatible with web sites that rely upon them. Adam
Re: [whatwg] Javascript: URLs as element attributes
On Mon, 15 Nov 2010, Boris Zbarsky wrote: On 11/15/10 8:15 PM, Ian Hickson wrote: Gecko's currently-intended behavior is to do what [the spec] describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: What does it do for those cases if it doesn't match the spec? For iframe the behavior in Gecko currently is different in terms of what the URI of the result document of javascript: is set to. How does it differ? As far as I can tell, it works the same as the spec says (the document.location is about:blank in the example above). For the others, I believe we execute them in the script environment of the owner document of the object/embed/applet, whereas the spec requires them to execute in a sandbox, as far as I can tell. Ah, interesting. For object, this seems to be a unique feature of Firefox. Opera also executes the script in the context of the owner, but then ignores the results as far as I can tell. Other browsers don't seem to support javascript: in data= at all. For embed, only Firefox does this (tested using window.alert). I didn't test further with embed since there doesn't seem to be a use case for this anyway. I didn't test applet. Note that there is some confusion here in terms of browsing contexts and object, since object does expose a Document object sometimes (but not others) and does participate in session history sometimes, I believe... So I'm not quite sure what behavior the spec calls for for object. It's defined; see the section on the onject element. For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. That's what the spec says currently. That doesn't agree with your comments about script src above... Indeed, I misspoke. The spec actually defaults to not running the script, but in most circumstances of interest does #2, and in a number of other cases does #3 or does #1 explicitly even if it would otherwise do #2 or #3. It's complicated. :-) On Thu, 25 Nov 2010, Philip Jägenstedt wrote: Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. There's a minor body of work on the Web that is based on using javascript: URLs to generate bitmaps, and I don't really see any harm with this. I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? What the spec currently specs seems to be a reasonable compromise between security, compatibility needs based on what browsers do today, use cases, and consistency across the platform (usability), in that order. Obviously if browsers implement something different, then I'll happily move the spec to match, but it would be sad to just close off these features without good reason. On Tue, 30 Nov 2010, Boris Zbarsky wrote: At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. Hm. This currently isn't specced; the spec just assumes the return value is text/html string data and doesn't say what encoding to use. Is there a good way to test this in the context of an iframe, where all the browsers do something with javascript:? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Javascript: URLs as element attributes
On 2/9/11 10:12 PM, Ian Hickson wrote: On Mon, 15 Nov 2010, Boris Zbarsky wrote: On 11/15/10 8:15 PM, Ian Hickson wrote: Gecko's currently-intended behavior is to do what [the spec] describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: What does it do for those cases if it doesn't match the spec? Foriframe the behavior in Gecko currently is different in terms of what the URI of the result document of javascript: is set to. How does it differ? As far as I can tell, it works the same as the spec says (the document.location is about:blank in the example above). The example above doesn't actually return a document from the javascript: URI; it was a shorthand for a generic javascript: URI that does do that. Try this: data:text/html,body onload=alert(window[0].location)iframe src=javascript:'' Note that there is some confusion here in terms of browsing contexts and object, sinceobject does expose a Document object sometimes (but not others) and does participate in session history sometimes, I believe... So I'm not quite sure what behavior the spec calls for forobject. It's defined; see the section on theonject element. I've read that section, in fact. I couldn't make sense of what behavior it actually called for. Has it changed recently (last few months) to become clearer such that rereading would be worthwhile? At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. Hm. This currently isn't specced; the spec just assumes the return value is text/html string data and doesn't say what encoding to use. Is there a good way to test this in the context of aniframe, where all the browsers do something with javascript:? body onload=alert(window[0].document.characterSet)iframe src=javascript:'\u0400' (can't be a data: URI in webkit, for what it's worth; seems to fail same-origin checks). If I load that from file://, italerts UTF-8 in Gecko, ISO-8859-1 in the Webkit-based browsers I have here, empty string in Opera 11 (?). You could also do things like generate a document that links to a stylesheet with no encoding information and see what encoding the sheet is treated as. If the question was whether it's possible to tell by black-box testing what the return string is actually treated as, not just what characterSet the resulting document reports, I'd have to do some more thinking. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Wed, Aug 11, 2010 at 7:58 PM, Cris Neckar c...@chromium.org wrote:
Browsers currently deal with these in a fairly ad-hoc way. I used the
following to test a few examples in various browsers.
embed src=javascript:alert('embed-src');/embed
embed src=http://none;
pluginurl=javascript:alert('embed-pluginurl');/embed
object classid=javascript:alert('object-classid');/object
object archive=javascript:alert('object-archive');/object
object data=javascript:alert('object-data');/object
img src=javascript:alert('img-src');
script src=javascript:alert('script-src');/script
applet code=javascript:alert('applet-code');/applet
applet code=http://none;
archive=javascript:alert('applet-archive');/applet
applet code=http://none;
codebase=javascript:alert('applet-codebase');/applet
link rel=stylesheet type=text/css
href=javascript:alert('link-href'); /
Just curious, why do we want to allow alert/confirm/prompt in URLs for
embed, object, applet etc?
I see some times problem in Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=616838
And I dont see any use case for that.
Cheers
Biju
Re: [whatwg] Javascript: URLs as element attributes
On Thu, 02 Dec 2010 23:56:33 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 12/2/10 2:31 PM, Daniel Veditz wrote: On 12/1/10 7:29 AM, Boris Zbarsky wrote: On 12/1/10 3:49 AM, Philip Jägenstedt wrote: I dunno about solid, but the obvious things you can do with javascript: that you can't do as easily with data: are things that are dynamic. That said, in a sandbox the only things that are available as obvious sources of dynamism are |new Date| and |Math.random|. So achieving solidity might take some work. ;) What dynamism does a javascript: url give you that can't be achieved by running an in-page script to generate data: urls? None, except for the fact that the in-page script would have to find the right places to stick those data: URIs, which might be impossible. For example, if I load a cross-site stylesheet, and it wants to have a dynamically-generated image like so |content: url(javascript:...)| then I couldn't handle that via script from my page, because I can't touch the OM of that cross-site sheet. It would be quite straight-forward to use a cross-site script instead, one that generates the data: URL and then inserts a stylesheet. It also has the benefit of making it clear to the including side that scripting is needed for it to work. (Realistically though, just generating the images once on the server-side as a JPEG/PNG is a more likely solution.) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Wed, 01 Dec 2010 16:24:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 12/1/10 3:16 AM, Philip Jägenstedt wrote: Do you do that just for inlines, or also when navigating to javascript: URLs? If it's both, then that's something we'd need to standardize, unless all browsers already do the same. It's both in Gecko. We really do try to keep the number of special-cases to a minimum. ;) I'm looking forward to some standardization effort on this point. I agree that we probably need to standardize this, because I fully expect web sites to depend on the ISO-8859-1 bit when all the charcodes are 255. Indeed, so the question is just what the compat constraints are. Well, no. There's the question of what's least confusing for authors too; see my other mail about that in this thread. This one? On Tue, 30 Nov 2010 20:32:06 +0100, Boris Zbarsky bzbar...@mit.edu wrote: One other thing since this is a generic protocol, if we define special-case behavior for it in some cases (e.g. img), that opens up some cans of worms. For example, what should url(javascript:) do in CSS? HTML5 seems like the wrong place to define that On this point I can only say that I think that javascript: in CSS should also not execute, and doesn't in Opera (before or after my changes). Right, these aren't inlines, in Opera terminology at least. As far as I can see the spec agrees on this, as frames/iframes have their own browsing contexts. So do objects, sometimes, right? Yes, but as far as I can tell from the algorithm [1], the browsing context isn't created until step 8, after the URL in data= has been resolved and fetched. In other words, at the time the steps for handling javascript: [2] are run, there's no browsing context, and it will be treated as any other inline. This is a good thing IMO, as it would be quite confusing if the context in which the script executed depended on the expected type of the object content. The spec change that I'm suggesting is to remove the case If the Document object of the element, attribute, or style sheet from which the javascript: URL was reached has an associated browsing context, which would mean (among other things) that object data=javscript:... would never execute. But again, let's wait a little bit longer and see if any compat issues arise. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-object-element [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Thu, 02 Dec 2010 11:38:33 +0100, Simon Pieters sim...@opera.com wrote:
On Thu, 02 Dec 2010 09:32:43 +0100, Philip Jägenstedt
phil...@opera.com wrote:
Right, these aren't inlines, in Opera terminology at least. As far as
I
can see the spec agrees on this, as frames/iframes have their own
browsing contexts.
So do objects, sometimes, right?
Yes, but as far as I can tell from the algorithm [1], the browsing
context isn't created until step 8, after the URL in data= has been
resolved and fetched. In other words, at the time the steps for
handling javascript: [2] are run, there's no browsing context, and it
will be treated as any other inline.
What if the steps are run because the data attribute changed?
object data=data:,foo/object
script
document.getElementsByTagName('object')[0].data = 'javascript:alert(1)';
/script
The relevant step would be step 4: Fetch the resulting absolute URL, from
the element's browsing context scope origin if it has one.
So, at this point, there would already be a browsing context, I believe.
If the only reason this is in the spec is so that javascript: URLs will
execute in the object browsing context, then I suggest that this simply
be changed so that data=javascript:... never execute, regardless of
how/when the attribute was set. Unless there are compat constraints here,
this seems simpler and more predictable, and I would guess that this is
what most browsers already do.
Some testing may be in order, though.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On 12/1/10 7:29 AM, Boris Zbarsky wrote: On 12/1/10 3:49 AM, Philip Jägenstedt wrote: I dunno about solid, but the obvious things you can do with javascript: that you can't do as easily with data: are things that are dynamic. That said, in a sandbox the only things that are available as obvious sources of dynamism are |new Date| and |Math.random|. So achieving solidity might take some work. ;) What dynamism does a javascript: url give you that can't be achieved by running an in-page script to generate data: urls? (In a sandboxed context; I don't think we can kill javascript: hrefs in links, however much I'd like to.)
Re: [whatwg] Javascript: URLs as element attributes
On 12/2/10 2:31 PM, Daniel Veditz wrote: On 12/1/10 7:29 AM, Boris Zbarsky wrote: On 12/1/10 3:49 AM, Philip Jägenstedt wrote: I dunno about solid, but the obvious things you can do with javascript: that you can't do as easily with data: are things that are dynamic. That said, in a sandbox the only things that are available as obvious sources of dynamism are |new Date| and |Math.random|. So achieving solidity might take some work. ;) What dynamism does a javascript: url give you that can't be achieved by running an in-page script to generate data: urls? None, except for the fact that the in-page script would have to find the right places to stick those data: URIs, which might be impossible. For example, if I load a cross-site stylesheet, and it wants to have a dynamically-generated image like so |content: url(javascript:...)| then I couldn't handle that via script from my page, because I can't touch the OM of that cross-site sheet. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On 12/2/10 4:26 PM, Daniel Veditz wrote: On 12/1/10 10:25 AM, timeless wrote: Pnglets date to around 1999 according to a quick read of http://elf.org/pnglets/ Pnglets haven't worked in Mozilla for a long time,img src= is sandboxed. It's not just sandboxed; it also doesn't execute. There's a bug on this, where brendan keeps claiming we should execute it unsandboxed and I keep claiming that would be XSS-city and that if we run it, it needs to be sandboxed. ;) -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 20:30:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/30/10 4:35 AM, Philip Jägenstedt wrote: No, as far as I know, Opera hasn't ever sandboxed any inline javascript: URL execution. So img src=javascript: runs the JS in the page's context in Opera? No, img was on the list of inlines where javascript: URL execution was explicitly blocked. However, in the contexts where javascript: URLs did execute, they did so in the containing document's context. (See my first mail in this thread for both lists.) Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something Right; see the can't recall bit above. code=javascript: maybe? or the Java plugin must be installed? This might be needed too, yes. Someone who manages to install a working Java plugin might want to test this. It doesn't seem like it could be a compat issue to me. It seems to me that after sandboxing, javascript: URLs will be quite useless. You can only use them where the content is text That's not the case, actually. At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. Do you do that just for inlines, or also when navigating to javascript: URLs? If it's both, then that's something we'd need to standardize, unless all browsers already do the same. and the script has to be completely self-confined Indeed. Using data: URLs will allow you to generate the data in the outer environment, and it's possible to generate binary data. Right. Now that data: support is universal, there may be a lot less need for javascript: returning data, except for compat reasons. Indeed, so the question is just what the compat constraints are. So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. Except for frames/iframes, right? Right, these aren't inlines, in Opera terminology at least. As far as I can see the spec agrees on this, as frames/iframes have their own browsing contexts. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 22:51:28 +0100, Boris Zbarsky bzbar...@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
Re: [whatwg] Javascript: URLs as element attributes
On 12/1/10 3:16 AM, Philip Jägenstedt wrote: No, img was on the list of inlines where javascript: URL execution was explicitly blocked. Ah, ok. Gotcha. Someone who manages to install a working Java plugin might want to test this. It doesn't seem like it could be a compat issue to me. Agreed. Do you do that just for inlines, or also when navigating to javascript: URLs? If it's both, then that's something we'd need to standardize, unless all browsers already do the same. It's both in Gecko. We really do try to keep the number of special-cases to a minimum. ;) I agree that we probably need to standardize this, because I fully expect web sites to depend on the ISO-8859-1 bit when all the charcodes are 255. Indeed, so the question is just what the compat constraints are. Well, no. There's the question of what's least confusing for authors too; see my other mail about that in this thread. Right, these aren't inlines, in Opera terminology at least. As far as I can see the spec agrees on this, as frames/iframes have their own browsing contexts. So do objects, sometimes, right? -Boris
Re: [whatwg] Javascript: URLs as element attributes
On 12/1/10 3:49 AM, Philip Jägenstedt wrote: 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? I dunno about solid, but the obvious things you can do with javascript: that you can't do as easily with data: are things that are dynamic. That said, in a sandbox the only things that are available as obvious sources of dynamism are |new Date| and |Math.random|. So achieving solidity might take some work. ;) Oh, the other thing that JavaScript can do that data: can't do is trade off url length for CPU time. A data: URI to write out the first 3000 Fibonacci numbers would be a lot longer than the equivalent javascript: URI. Again, one would have to find non-silly use cases here. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Wed, Dec 1, 2010 at 5:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: Oh, the other thing that JavaScript can do that data: can't do is trade off url length for CPU time. A data: URI to write out the first 3000 Fibonacci numbers would be a lot longer than the equivalent javascript: URI. Again, one would have to find non-silly use cases here. mandelbrot sets
Re: [whatwg] Javascript: URLs as element attributes
On Wed, 01 Dec 2010 19:11:25 +0100, timeless timel...@gmail.com wrote: On Wed, Dec 1, 2010 at 5:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: Oh, the other thing that JavaScript can do that data: can't do is trade off url length for CPU time. A data: URI to write out the first 3000 Fibonacci numbers would be a lot longer than the equivalent javascript: URI. Again, one would have to find non-silly use cases here. mandelbrot sets These can also be done with data:text/html,script.../script and maybe canvas. It is slightly longer, but not much. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Javascript: URLs as element attributes
On Wed, Dec 1, 2010 at 8:18 PM, Anne van Kesteren ann...@opera.com wrote: These can also be done with data:text/html,script.../script and maybe canvas. It is slightly longer, but not much. Sure, play the canvas card. I could just as easily respond to everything by saying you don't need layout rules, you could just script + canvas to write your own portable layout engine. Pnglets date to around 1999 according to a quick read of http://elf.org/pnglets/
Re: [whatwg] Javascript: URLs as element attributes
On Mon, 29 Nov 2010 16:36:32 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/10 9:10 AM, Philip Jägenstedt wrote: Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. Does Opera sandbox object data=javascript:? Note that Firefox does not. No, as far as I know, Opera hasn't ever sandboxed any inline javascript: URL execution. That's one reason why it's easier to just not run them at all. Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something or the Java plugin must be installed? I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? (It seems that IE and WebKit are already basically already doing what I'm advocating.) The reason Firefox runs javascript: in object is https://bugzilla.mozilla.org/show_bug.cgi?id=300263. I could probably be convinced to either run it in a sandbox or not run altogether, though I would strongly prefer the sandbox approach Thanks for that pointer. For those who don't want to dig, it was about generating a SVG document for object data=. The demo https://bug300263.bugzilla.mozilla.org/attachment.cgi?id=188843 will break if you start sandboxing the execution as per spec, as it refers to eg_svg from the outer environment. It also doesn't currently work in Opera, it seems like we just execute object data=javascript:, but don't use the return value as the document. Since it also won't work in IE or WebKit, it seems unlikely that there's much content depending on this. It seems to me that after sandboxing, javascript: URLs will be quite useless. You can only use them where the content is text, and the script has to be completely self-confined. Using data: URLs will allow you to generate the data in the outer environment, and it's possible to generate binary data. For reference here's the same demo done with a data: URL instead: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/721 Unlike the javascript: version, this actually works in Opera, Firefox and presumably all browsers that support SVG in object and data: URLs. So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, Nov 30, 2010 at 11:35 AM, Philip Jägenstedt phil...@opera.com wrote: Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something or the Java plugin must be installed? based on: applet codebase=http://java.sun.com/applets/NervousText/1.1; code=NervousText.class width=400 height=75 my guess is: #define something codebase
Re: [whatwg] Javascript: URLs as element attributes
http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt phil...@opera.com wrote: On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. How about code= (or param name=code value=javascript:)? -- Simon Pieters Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Tue, Nov 30, 2010 at 3:21 PM, Simon Pieters sim...@opera.com wrote: How about code= (or param name=code value=javascript:)? i'm assuming not, the spec claims it's not allowed to take an absolute url.
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 30 Nov 2010 14:21:21 +0100, Simon Pieters sim...@opera.com wrote: On Tue, 30 Nov 2010 13:10:28 +0100, Philip Jägenstedt phil...@opera.com wrote: On Tue, 30 Nov 2010 10:48:45 +0100, timeless timel...@gmail.com wrote: http://download.oracle.com/javase/1.4.2/docs/guide/misc/applet.html actually, potentially each of these are probably potential candidates for something: CODEBASE ARCHIVE OBJECT None of those worked for me, even with the plugin (icedtea6-plugin) installed. How about code= (or param name=code value=javascript:)? Nope, I've had no luck. In any case, since Opera (and presumably IE/WebKit, although I haven't checked) doesn't run these, it doesn't seem like a compat issue to worry about. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On 11/30/10 4:35 AM, Philip Jägenstedt wrote: No, as far as I know, Opera hasn't ever sandboxed any inline javascript: URL execution. So img src=javascript: runs the JS in the page's context in Opera? Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? Neither of these execute in Opera, both were explicitly blocked before I started looking into the issue. Note that I can't get applet something=javascript: to execute in Firefox either, perhaps it needs a special value for something Right; see the can't recall bit above. code=javascript: maybe? or the Java plugin must be installed? This might be needed too, yes. It seems to me that after sandboxing, javascript: URLs will be quite useless. You can only use them where the content is text That's not the case, actually. At least in Gecko, the return value string is examined to see whether all the charcode values are 255. If they are, then the string is converted to a byte array by just dropping the high byte of every char. So you can pretty easily generate image data this way. If any of the bytes are 255, then the string is encoded as UTF-8 instead. and the script has to be completely self-confined Indeed. Using data: URLs will allow you to generate the data in the outer environment, and it's possible to generate binary data. Right. Now that data: support is universal, there may be a lot less need for javascript: returning data, except for compat reasons. So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. Except for frames/iframes, right? -Boris
Re: [whatwg] Javascript: URLs as element attributes
On 11/30/10 4:35 AM, Philip Jägenstedt wrote: So far, it seems that the fastest way to reach compat between browsers is to simply not run inline javascript: URLs. One other thing since this is a generic protocol, if we define special-case behavior for it in some cases (e.g. img), that opens up some cans of worms. For example, what should url(javascript:) do in CSS? HTML5 seems like the wrong place to define that -Boris
Re: [whatwg] Javascript: URLs as element attributes
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. -- Darin
Re: [whatwg] Javascript: URLs as element attributes
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
Re: [whatwg] Javascript: URLs as element attributes
On 11/25/10 9:10 AM, Philip Jägenstedt wrote: Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. Does Opera sandbox object data=javascript:? Note that Firefox does not. Also, note that embed src=javascript: and applet something=javascript: (can't recall the attr name right now) also execute the script in Firefox. Do they in Opera? I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? (It seems that IE and WebKit are already basically already doing what I'm advocating.) The reason Firefox runs javascript: in object is https://bugzilla.mozilla.org/show_bug.cgi?id=300263. I could probably be convinced to either run it in a sandbox or not run altogether, though I would strongly prefer the sandbox approach -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Tue, 16 Nov 2010 02:15:45 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Aug 2010, Boris Zbarsky wrote: For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. That's what the spec says currently. I've recently had reason to dabble with inline javascript: URLs in Opera, trying to figure out what the interoperability constraints are. Opera's current behavior is to execute javascript: URLs except for in the context of img, embed, applet and any inline loads from CSS. Before I was aware of this thread, I went through the different kinds of contexts where we do allow javascript: to execute, comparing to other browsers. The results: video poster=javascript:... only executed by Opera script src=javascript:... only executed by Opera bgsound src=javascript:... only executed by Opera object data=javascript:... only executed by Opera and Firefox (I haven't looked at iframe, as we don't treat that as an inline load in the same way as the above.) Based on this, unless there are corner-cases I've missed, it seems unlikely that there's a large body of web content that depends on inline javascript: URLs executing. My current plan is to try completely blocking javascript: URLs in the contexts mentioned above. This seems to be the simplest to implement and the fastest way to reach interoperability. The alternative is to start executing javascript: URLs in more contexts, which, even if sandboxed, doesn't seem particularly useful. I'll keep you posted if there are any compatibility issues that come up with this. Assuming (boldly) there is not, would there be support from other browsers to move in this direction and change the spec to match? (It seems that IE and WebKit are already basically already doing what I'm advocating.) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Javascript: URLs as element attributes
On Wed, 11 Aug 2010, Cris Neckar wrote: The HTML5 Spec is somewhat ambiguous on the handling of javascript: URLs when supplied as attributes to different elements. It does not specifically prohibit handling them in most cases but I was wondering if this has been discussed and whether there is consensus on correct behavior. I don't understand what's ambiguous. As far as I can tell the spec covers all the cases you describe in detail. On Wed, 11 Aug 2010, Boris Zbarsky wrote: Gecko's currently-intended behavior is to do what section 6.1.5 describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: What does it do for those cases if it doesn't match the spec? I presume script src=javascript: is also special; the HTML spec handles that one separately (it does nothing, for historical reasons). Has there been discussion on this in the past? If not we should work towards defining which of these we want to allow and which we should block. Agreed. For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. That's what the spec says currently. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Javascript: URLs as element attributes
On 11/15/10 8:15 PM, Ian Hickson wrote: Gecko's currently-intended behavior is to do what section 6.1.5 describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: What does it do for those cases if it doesn't match the spec? Note that at this point the section in question is 7.1.5: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol For iframe the behavior in Gecko currently is different in terms of what the URI of the result document of javascript: is set to. For the others, I believe we execute them in the script environment of the owner document of the object/embed/applet, whereas the spec requires them to execute in a sandbox, as far as I can tell. Note that there is some confusion here in terms of browsing contexts and object, since object does expose a Document object sometimes (but not others) and does participate in session history sometimes, I believe... So I'm not quite sure what behavior the spec calls for for object. I presumescript src=javascript: is also special; the HTML spec handles that one separately (it does nothing, for historical reasons). In Gecko currently it acts just like most cases of javascript:. More on this below. For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. That's what the spec says currently. That doesn't agree with your comments about script src above... Fwiw, looking at the Gecko code more carefully, it seems that we default to #1 above unless we know where the URI came from, in which case we default to #2, unless a special flag is set at URI dereference time to select behavior #3. That last flag is only set for frame/iframe/object/applet/embed at the moment. Also at the moment in most cases we don't know where the URI came from (e.g. images don't know, nor do script src). Those are considered bugs, not features; the target behavior is #2. Stylesheet loads do know where the URI came from and have behavior #2, as does XHR. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On 8/11/10 2:57 PM, Cris Neckar wrote: 6.1.5 So for example a javascript: URL for a src attribute of an img element would be evaluated in the context of an empty object as soon as the attribute is set; it would then be sniffed to determine the image type and decoded as an image. Right. Browsers currently deal with these in a fairly ad-hoc way. I used the following to test a few examples in various browsers. Your test is assuming an alert property on the scope chain, and that the value of the property is a function. The first assumption would be false in the situation described in 6.1.5, since an empty object would have no such property. Firefox 3.6.3: Allows object.data, applet.code, and embed.src. Blocks all others. Firefox 3.7.863: Allows object.data and embed.src. Blocks all others. Gecko's currently-intended behavior is to do what section 6.1.5 describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: Has there been discussion on this in the past? If not we should work towards defining which of these we want to allow and which we should block. Agreed. For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. -Boris
[whatwg] Javascript: URLs as element attributes
Re-sending from the correct address. -- Forwarded message -- From: Boris Zbarsky bzbar...@mit.edu Date: Wed, Aug 11, 2010 at 12:07 PM Subject: Re: Javascript: URLs as element attributes To: Cris Neckar c...@google.com Cc: wha...@whatwg.org On 8/11/10 2:57 PM, Cris Neckar wrote: 6.1.5 So for example a javascript: URL for a src attribute of an img element would be evaluated in the context of an empty object as soon as the attribute is set; it would then be sniffed to determine the image type and decoded as an image. Right. Browsers currently deal with these in a fairly ad-hoc way. I used the following to test a few examples in various browsers. Your test is assuming an alert property on the scope chain, and that the value of the property is a function. The first assumption would be false in the situation described in 6.1.5, since an empty object would have no such property. Firefox 3.6.3: Allows object.data, applet.code, and embed.src. Blocks all others. Firefox 3.7.863: Allows object.data and embed.src. Blocks all others. Gecko's currently-intended behavior is to do what section 6.1.5 describes in all cases except: iframe src=javascript: object data=javascript: embed src=javascript: applet code=javascript: Has there been discussion on this in the past? If not we should work towards defining which of these we want to allow and which we should block. Agreed. For what it's worth, as I see it there are three possible behaviors for a javascript: URI (whether in an attribute value or elsewhere): 1) Don't run the script. 2) Run the script, but in a sandbox. 3) Run the script against some Window object (which one?) Defining which of these happens in which case would be good. Again, Gecko's behavior is #2 by default (in all sorts of situations; basically anywhere you can dereference a URI), with exceptions made to do #3 in some cases. -Boris
[whatwg] Javascript: URLs as element attributes
Resending from the correct address
-- Forwarded message --
From: Cris Neckar c...@google.com
Date: Wed, Aug 11, 2010 at 11:57 AM
Subject: Javascript: URLs as element attributes
To: wha...@whatwg.org
Cc: bzbar...@mit.edu
The HTML5 Spec is somewhat ambiguous on the handling of javascript:
URLs when supplied as attributes to different elements. It does not
specifically prohibit handling them in most cases but I was wondering
if this has been discussed and whether there is consensus on correct
behavior.
There are several areas of the spec that specifically reference the
use of javascript: URLs as the src attribute for img nodes but
this is not universal.
For example see http://dev.w3.org/html5/spec/Overview.html#introduction-3
6.1.1
Processing of inline javascript: URLs (e.g. the src attribute of img
elements, or an @import rule in a CSS style element block).
And http://dev.w3.org/html5/spec/Overview.html#javascript-protocol
6.1.5
So for example a javascript: URL for a src attribute of an img
element would be evaluated in the context of an empty object as soon
as the attribute is set; it would then be sniffed to determine the
image type and decoded as an image.
Browsers currently deal with these in a fairly ad-hoc way. I used the
following to test a few examples in various browsers.
embed src=javascript:alert('embed-src');/embed
embed src=http://none;
pluginurl=javascript:alert('embed-pluginurl');/embed
object classid=javascript:alert('object-classid');/object
object archive=javascript:alert('object-archive');/object
object data=javascript:alert('object-data');/object
img src=javascript:alert('img-src');
script src=javascript:alert('script-src');/script
applet code=javascript:alert('applet-code');/applet
applet code=http://none;
archive=javascript:alert('applet-archive');/applet
applet code=http://none;
codebase=javascript:alert('applet-codebase');/applet
link rel=stylesheet type=text/css
href=javascript:alert('link-href'); /
IE 8: Blocks all tests
Chrome 5.0.375: object.data, embed.src, Blocks all others.
Firefox 3.6.3: Allows object.data, applet.code, and embed.src. Blocks
all others.
Firefox 3.7.863: Allows object.data and embed.src. Blocks all others.
Opera 10.54: script.src and object.data. Blocks all others.
Has there been discussion on this in the past? If not we should work
towards defining which of these we want to allow and which we should
block.
Thank you,
-cris
