- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 4 Oct 2011 19:10:16 +0000 (UTC)
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. 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 12:10:16 UTC