Re: [whatwg] window.onerror and cross-origin scripts
On Thu, 22 Sep 2011 16:02:30 +0200, Simon Pieters sim...@opera.com wrote: I was talking about window.onerror. script onerror per spec fires for empty src=, unresolvable URL and network errors (DNS or 404). If we want to make onload always fire for cross-origin, it would make sense for script onerror to not fire for network errors. (Opera doesn't fire error on script, assuming my testing isn't bogus this time.) I don't know if it's worth it to try to plug this hole this way, however. We won't be able to plug it everywhere, e.g. img will expose if an image is loaded. So masking onload/onerror for script just makes the feature less useful without solving the problem. Maybe we should instead focus on implementing the From-Origin header and try to get sites to use that. It was pointed out to me that the following site expects an error event for a cross-origin script (which returns 404): http://www.alvoradafm.com.br/Player/player.html which tries to load http://lp.longtailvideo.com/5/%20gapro/%20gapro.js -- Simon Pieters Opera Software
Re: [whatwg] window.onerror and cross-origin scripts
On Wed, 21 Sep 2011 19:36:23 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/21/11 5:25 AM, Simon Pieters wrote: Oops. Bogus testing on my part. We do support script onload. Will have to investigate whether we should change our behavior for the cross-origin case. One other thing. Are we talking about error events fired on the script element? Or error events fired on the window due to exceptions thrown by a script? Or both? Your initial post seemed to be about the latter, but expressed concerns that are applicable to both to some extent I was talking about window.onerror. script onerror per spec fires for empty src=, unresolvable URL and network errors (DNS or 404). If we want to make onload always fire for cross-origin, it would make sense for script onerror to not fire for network errors. (Opera doesn't fire error on script, assuming my testing isn't bogus this time.) I don't know if it's worth it to try to plug this hole this way, however. We won't be able to plug it everywhere, e.g. img will expose if an image is loaded. So masking onload/onerror for script just makes the feature less useful without solving the problem. Maybe we should instead focus on implementing the From-Origin header and try to get sites to use that. -- Simon Pieters Opera Software
Re: [whatwg] window.onerror and cross-origin scripts
On Wed, 21 Sep 2011 05:02:47 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/20/11 5:40 PM, Simon Pieters wrote: However, it is still possible to tell if the user is logged in or not if a site serves a script for a particular URL when the user is logged in and redirects to the home page or so when the user is not logged in. Can't you tell this from the load event for the script tag, without involving the error event in any way? I'd love it if we could close this hole up, but the ship has long sailed. :( There are other ways to tell if the user is logged in, however it seems we should try to keep them to a minimum. I'm not sure that onerror and onload are really different ways to tell here. Unless the proposal is that in this case onload fire instead of onerror for the script that ends up as an HTML document? We don't support script onload yet. When we implement that, it's likely that we would try to find ways to not leak information in some way (possibly always firing onload for cross-origin scripts if that doesn't break Web sites). -- Simon Pieters Opera Software
Re: [whatwg] window.onerror and cross-origin scripts
On Wed, 21 Sep 2011 08:16:41 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 21 Sep 2011 05:02:47 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/20/11 5:40 PM, Simon Pieters wrote: However, it is still possible to tell if the user is logged in or not if a site serves a script for a particular URL when the user is logged in and redirects to the home page or so when the user is not logged in. Can't you tell this from the load event for the script tag, without involving the error event in any way? I'd love it if we could close this hole up, but the ship has long sailed. :( There are other ways to tell if the user is logged in, however it seems we should try to keep them to a minimum. I'm not sure that onerror and onload are really different ways to tell here. Unless the proposal is that in this case onload fire instead of onerror for the script that ends up as an HTML document? We don't support script onload yet. When we implement that, it's likely that we would try to find ways to not leak information in some way (possibly always firing onload for cross-origin scripts if that doesn't break Web sites). Oops. Bogus testing on my part. We do support script onload. Will have to investigate whether we should change our behavior for the cross-origin case. -- Simon Pieters Opera Software
[whatwg] window.onerror and cross-origin scripts
We're implementing window.onerror in Opera. In order to not expose the URL of redirects in cross-origin resources with window.onerror, errors from cross-origin scripts are masked in Gecko and WebKit, i.e. instead of invoking window.onerror with a useful error message, a URL and the line number, it's invoked with Script error., , 0. http://www.w3.org/Bugs/Public/show_bug.cgi?id=14177 https://bugzilla.mozilla.org/show_bug.cgi?id=568564 This makes window.onerror rather useless for cross-origin scripts. However, it is still possible to tell if the user is logged in or not if a site serves a script for a particular URL when the user is logged in and redirects to the home page or so when the user is not logged in. We have found a bank site where this is possible. There are other ways to tell if the user is logged in, however it seems we should try to keep them to a minimum. Therefore we suggest that window.onerror should not be invoked at all for errors in cross-origin scripts. Thoughts? -- Simon Pieters Opera Software
Re: [whatwg] window.onerror and cross-origin scripts
* Simon Pieters wrote: This makes window.onerror rather useless for cross-origin scripts. However, it is still possible to tell if the user is logged in or not if a site serves a script for a particular URL when the user is logged in and redirects to the home page or so when the user is not logged in. We have found a bank site where this is possible. There are other ways to tell if the user is logged in, however it seems we should try to keep them to a minimum. Therefore we suggest that window.onerror should not be invoked at all for errors in cross-origin scripts. I note there are at least two other ways to minimize the disclosure pro- blem here, which is due to a bug on the bank's site, and it seems quite likely there should be many more ways to check whether the script loaded (like checking for global variables it sets, markup it might add, mess with event listeners it might register, and so on): limit this to the cookie domain and basing the decision on the media type of responses. Either would disclose more, but taking away the ability to issue alerts when there are too many scripting errors (new browser update pushed to users that you did not catch in advance is incompatible with script, as an example) short of having people add script_xy_loaded_okay data to the scripting environment, which might be a new source of leaks when it is used incorrectly, is a bit of a problem, even if the rule that you do not get errors from cross-origin loads is certainly the most simple. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] window.onerror and cross-origin scripts
On 9/20/11 5:40 PM, Simon Pieters wrote: However, it is still possible to tell if the user is logged in or not if a site serves a script for a particular URL when the user is logged in and redirects to the home page or so when the user is not logged in. Can't you tell this from the load event for the script tag, without involving the error event in any way? I'd love it if we could close this hole up, but the ship has long sailed. :( There are other ways to tell if the user is logged in, however it seems we should try to keep them to a minimum. I'm not sure that onerror and onload are really different ways to tell here. Unless the proposal is that in this case onload fire instead of onerror for the script that ends up as an HTML document? -Boris
