- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 4 Oct 2011 13:24:12 -0700
On Tue, Oct 4, 2011 at 12:11 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > "default origin behavior" is only relevant when the mode is "No CORS". See > http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch > > So for images it only applies when the "crossorigin" attribute is not set. > > So no, WebKit's implementation is not correct if you were trying to > implement the spec. > > In particular, if "crossorigin" is set, you end up at > http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch > step 3 item 1 in the 'If mode is "Anonymous" or "Use Credentials"' section, > which is exactly what was cited in the mail that started this thread. Right, I see now. Sorry. On Tue, Oct 4, 2011 at 12:10 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 4 Oct 2011, Anne van Kesteren wrote: > > On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson <ian at hixie.ch> wrote: > > > The idea is that if the server explicitly rejected the CORS request, > > > then the image should not be usable at all. > > > > FWIW, from a CORS-perspective both scenarios are fine. CORS only cares > > about whether data gets shared in the end. One advantage I can see about > > <img crossorigin> still displaying the image is that the request does > > not use cookies. Not displaying the image probably makes debugging > > easier however. > > On Tue, 4 Oct 2011, Boris Zbarsky wrote: > > > > Displaying images involves sharing data, basically. That's why we're > > having to jump through all these hoops.... > > On Tue, 4 Oct 2011, Anne van Kesteren wrote: > > > > Sure, but not more than per usual. Note that if you do not specify the > > crossorigin attribute the image can still get untainted. And if it does > > not you would still display the image (as always). > > The thing is that you can grab the image data (at least the alpha channel > using 2D canvas) from these images, even with tainting enabled, so if the > server says no, we really should honour it. > I don't think that this is a good argument for the currently specified behavior. The server only has the option of declining cross-origin access if the application specified the crossorigin attribute. A hostile application would simply not specify that attribute, would receive the tainted image, and would use the timing attack I assume you're referring to to infer the alpha channel. The far more common case today is that the server doesn't understand the CORS request, not that it explicitly forbids cross-origin access to the resource. It seems to me that tainting the image if the CORS check fails is more graceful behavior, but I also see the advantages in early error reporting. Odin, if you file a bug on bugs.webkit.org, would you CC my email address? -Ken On Tue, 4 Oct 2011, Boris Zbarsky wrote: > > > > And in particular an <img crossorigin> that's in the DOM and fails the > > CORS checks should not render the image on the page. Anything else is > > just broken. > > Agreed. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Tuesday, 4 October 2011 13:24:12 UTC