Re: [whatwg] Adding crossorigin= to more elements
On 11/30/12 3:13 AM, Boris Zbarsky wrote: Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. What's in CSSOM now is tainting. It seems like the wrong model to use the effective script origin for stylesheets, since you can't set document.domain for a stylesheet. Consider this test case: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2324 Firefox throws here, but Chrome allows cssRules to be read. Same result if the document.domain script is moved above the link. Now, the spec could either use tainting or it could compare the origin of the style sheet with the origin of the script that tries to access it. This would only be different in a case like this: http://foo.example.org/parent.html link rel=stylesheet href=http://bar.example.org/style.css script document.domain = 'example.org'; /script iframe src=http://bar.example.org/child.html/iframe http://bar.example.org/child.html script document.domain = 'example.org'; alert(parent.document.styleSheets[0].cssRules) /script Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think canvas doesn't support the equivalent thing, either, per spec (although a canvas is a bit different in that it can have lots of images drawn on it from different origins). -- Simon Pieters Opera Software
Re: [whatwg] Adding crossorigin= to more elements
On Fri, Nov 30, 2012 at 11:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: Right. My point was that cross-origin for the case of stylesheet at least in Gecko depends on the origin of the script that tries to modify them, not on the origin of the document that linked to them... Is there a good reason for this? This seems fairly distinct from how img, script, and video work. -- http://annevankesteren.nl/
Re: [whatwg] Adding crossorigin= to more elements
On 6/17/13 6:05 AM, Simon Pieters wrote: What's in CSSOM now is tainting. Sort of. I think of tainting as you can write to it but read from it, but what's in CSSOM is you can't touch it. I guess the point is that whether you can touch or not is detected statically at load time? There needs to be some sort of dynamic check here in practice, since extensions need to be able to touch these things even if the page can't, but clearly that's out of scope of this specification. It seems like the wrong model to use the effective script origin for stylesheets That's possible, yes. The default security checks in Gecko always use effective script origin; a way to check the origin didn't even exist until pretty recently. So any security check dating back far enough always uses the effective script origin... Now, the spec could either use tainting or it could compare the origin of the style sheet with the origin of the script that tries to access it. This would only be different in a case like this Yes, agreed. Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think canvas doesn't support the equivalent thing, either, per spec (although a canvas is a bit different in that it can have lots of images drawn on it from different origins). Right, canvas has a tainting model where once you taint it no one can read from it (modulo extensions) even though they can keep writing to it, because trying to define an origin for such a thing would involve having an actual origin lattice in the platform or something along those lines. ;) In any case, I don't have a huge problem with what's in CSSOM right now if it better matches what other UAs do. Finding resources to change the Gecko behavior is another matter. :( -Boris
Re: [whatwg] Adding crossorigin= to more elements
On 6/17/13 7:38 AM, Anne van Kesteren wrote: On Fri, Nov 30, 2012 at 11:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: Right. My point was that cross-origin for the case of stylesheet at least in Gecko depends on the origin of the script that tries to modify them, not on the origin of the document that linked to them... Is there a good reason for this? This seems fairly distinct from how img, script, and video work. Just in terms of considering effective script origins instead of origins? img and video compare the origin of the canvas to the origin of the image/video, if you mean the security check I think you mean. It explicitly doesn't use effective script origin because you can't set that on img. script, if you mean the onerror checks, in Gecko checks whether the effective script origin of the window whose onerror is about to fire matches the origin of the script. And we make the origin of the script an alias of the effective script origin of the document it's loaded into in cases when the script was either loaded no-cors or passed cors security checks. What do other UAs do? Again, the default security check in Gecko is always against effective script origin, so any check that predates a recent spec is always that way. Whether there's a good reason for it needs to be checked on a case-by-case basis. -Boris
Re: [whatwg] Adding crossorigin= to more elements
On 6/17/13 1:44 PM, Boris Zbarsky wrote: On 6/17/13 6:05 AM, Simon Pieters wrote: What's in CSSOM now is tainting. Sort of. I think of tainting as you can write to it but read from it, but what's in CSSOM is you can't touch it. True. In CSSOM, since writing can have observable effects depending on what the style sheet was originally, it's difficult to allow writing to it without exposing information about what was there originally. For instance, insertRule can throw depending on the current state of the style sheet, and deleteRule throws if the index is out of range. I guess it's possible to do nothing instead of throwing, but it seemed simpler to just not allow writing. In practice, you can just write to a new style sheet instead. I guess the point is that whether you can touch or not is detected statically at load time? Yes. There needs to be some sort of dynamic check here in practice, since extensions need to be able to touch these things even if the page can't, but clearly that's out of scope of this specification. It seems like the wrong model to use the effective script origin for stylesheets That's possible, yes. The default security checks in Gecko always use effective script origin; a way to check the origin didn't even exist until pretty recently. So any security check dating back far enough always uses the effective script origin... OK. Now, the spec could either use tainting or it could compare the origin of the style sheet with the origin of the script that tries to access it. This would only be different in a case like this Yes, agreed. Since this currently throws in Firefox, it's likely that there isn't a big Web compat problem to not support this. I think canvas doesn't support the equivalent thing, either, per spec (although a canvas is a bit different in that it can have lots of images drawn on it from different origins). Right, canvas has a tainting model where once you taint it no one can read from it (modulo extensions) even though they can keep writing to it, because trying to define an origin for such a thing would involve having an actual origin lattice in the platform or something along those lines. ;) In any case, I don't have a huge problem with what's in CSSOM right now if it better matches what other UAs do. Finding resources to change the Gecko behavior is another matter. :( OK, thanks. -- Simon Pieters Opera Software
Re: [whatwg] Adding crossorigin= to more elements
On Thu, Nov 29, 2012 at 6:44 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Nov 2012, Boris Zbarsky wrote: Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? No idea. Adam? I'm not sure I have all the context for this question, but generally CORS and CSP don't really interact with each other. If something is blocked by CSP, the user agent never gets to the point where it wonders about CORS. Adam
Re: [whatwg] Adding crossorigin= to more elements
On Wed, 28 Nov 2012, Boris Zbarsky wrote: On 11/28/12 7:42 PM, Ian Hickson wrote: Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. Pretty sure that's not web-compatible... Yeah, I don't expect it is. This stuff is going to change as part of the bug below though so I'm not too worried for now. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 Done. Thanks. An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. A CORS-enabled load from a server that knows nothing about CORS will throw away the sheet, while a no-CORS load will happily apply the sheet to the page (but not give access to its data). So inheriting the mode can cause drastic changes in behavior compared to not inheriting it... Well, yeah, but the sheet knows which mode it's in, so I don't think that part of it is a big deal. If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. That's not quite correct. It changes the _object_ origin to that of the caller. It doesn't change the _subject_ origin. True (assuming we define those terms somewhere). The real issue here is that CSS is different than other things we've applied CORS to before, in that it is, to some level, alive. Before we've applied it to bitmaps (that can't do anything), scripts (that aren't in any way limited in the first place), and media (that can't do anything). This is the first time, I think, that we've used CORS with something that can do something with its privileges. Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. On Wed, 28 Nov 2012, Boris Zbarsky wrote: Oh, I see. You've added this taint thing, which you're using for the CSS bit. That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. I don't believe Gecko has any such concept. Well presumably you don't block all cross-origin loads of CSS when there's no crossorigin= attribute. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On 11/29/12 5:09 PM, Ian Hickson wrote: Well, yeah, but the sheet knows which mode it's in, so I don't think that part of it is a big deal. Maybe. Problems can arise with a sheet that itself sends CORS headers but links to sheets that don't and that's tested in a UA that doesn't do link crossorigin. But OK. I'll see about inheriting the CORS mode. The real issue here is that CSS is different than other things we've applied CORS to before, in that it is, to some level, alive. Yep. See https://bugzilla.mozilla.org/show_bug.cgi?id=732209#c1 for a (probably non-exhaustive) list of possible meanings for CORS here. I implemented option 5 in Gecko. Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? On Wed, 28 Nov 2012, Boris Zbarsky wrote: Oh, I see. You've added this taint thing, which you're using for the CSS bit. That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. Oh, ok. Sorry. Reading diffs of HTML is a pain. :( Well presumably you don't block all cross-origin loads of CSS when there's no crossorigin= attribute. :-) Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. -Boris
Re: [whatwg] Adding crossorigin= to more elements
On Thu, 29 Nov 2012, Boris Zbarsky wrote: Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? No idea. Adam? That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. Oh, ok. Sorry. Reading diffs of HTML is a pain. :( Yeah, couldn't agree more. If you have any idea how I can improve this, by the way, let me know. I tried running HTML diff tools for a while, but couldn't find one that actually could handle a 5MB file, and in any case they didn't really make things any more readable than plain text diffs in practice. Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. The behaviour called tainting in this context in the spec just means treat as a cross-origin resource as opposed to treat as a network failure. The term comes from the first time I introduced crossorigin=, which was for img, where the default behaviour of cross-origin images as opposed to same-origin images is that they taint the canvas. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On 11/29/12 9:44 PM, Ian Hickson wrote: The behaviour called tainting in this context in the spec just means treat as a cross-origin resource Right. My point was that cross-origin for the case of stylesheet at least in Gecko depends on the origin of the script that tries to modify them, not on the origin of the document that linked to them... Wish I had any bright idea on HTML diffs. :( -Boris
[whatwg] Adding crossorigin= to more elements
On Thu, 1 Mar 2012, Robert Kieffer wrote: For reasons documented in https://bugzilla.mozilla.org/show_bug.cgi?id=696301, I�d like to propose that support for the �crossorigin� attribute be added to SCRIPT tags. tl;dr - When applied to window.onerror information, the same-origin policy makes it near-impossible to host script resources on a CDN, while simultaneously using window.onerror to gather information about JS errors. Done. On Tue, 28 Aug 2012, Boris Zbarsky wrote: I just added support for link rel=stylesheet crossorigin in Gecko.[1] Such links are subject to CORS checks if the load is cross-site, and the sheet load will fail if the CORS check fails. If the CORS check succeeds, script in the page will be able to script the cross-site stylesheet. This allows stylesheets served from a CDN to be scripted by the page if desired, so I would like to propose that we add this feature to the spec. Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ...and I'll try to fix it when I update that part of the spec (the CSSOM/HTML coordination). An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. On Tue, 28 Aug 2012, Boris Zbarsky wrote: If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. Maybe this is OK, but it's non-obvious; usually for security purposes the importing sheet is what affects things like can-load checks, Referer headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. Anyway, that part of it belongs in CSS/CSSOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On 11/28/12 7:42 PM, Ian Hickson wrote: Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. Pretty sure that's not web-compatible... If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 Done. An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. A CORS-enabled load from a server that knows nothing about CORS will throw away the sheet, while a no-CORS load will happily apply the sheet to the page (but not give access to its data). So inheriting the mode can cause drastic changes in behavior compared to not inheriting it... If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. That's not quite correct. It changes the _object_ origin to that of the caller. It doesn't change the _subject_ origin. Otherwise loading something via CORS would allow it to act on behalf of the loading page, whereas usually pages assume that using CORS just gives them expanded access to something. Or put another way, if I have a file:// page that loads a sheet from http:// with CORS, that shouldn't imply that the sheet can then link to file:// URIs the page can link to. This is very important; oversimplifying the security model to the point where it becomes insecure is bad. ;) Maybe this is OK, but it's non-obvious; usually for security purposes the importing sheet is what affects things like can-load checks, Referer headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. No, see above. The page can make the sheet do whatever, agreed. But this is about the _sheet_ taking on the permissions of the _page_ in some sense, which may not be desirable. Anyway, that part of it belongs in CSS/CSSOM. That's fine by me. Assuming we ever end up with a CSSOM spec not holding my breath. ;) -Boris
Re: [whatwg] Adding crossorigin= to more elements
On 11/28/12 11:03 PM, Boris Zbarsky wrote: Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. Oh, I see. You've added this taint thing, which you're using for the CSS bit. I don't believe Gecko has any such concept. We simply fail the load if the CORS check fails. Furthermore, Gecko's behavior is what the CORS spec requires: failure to respond properly to a cross-origin CORS request must be treated like a network error per CORS. -Boris
