[whatwg] [CORS] WebKit tainting image instead of throwing, error

[Charles Pritchard]

> Message: 4
> Date: Tue, 4 Oct 2011 18:32:02 +0000 (UTC)
> From: Ian Hickson<ian at hixie.ch>
> To: Odin H?rthe Omdal<odinho at opera.com>
> Cc:whatwg at lists.whatwg.org
> Subject: Re: [whatwg] [CORS] WebKit tainting image instead of throwing
> 	error
> Message-ID:
> 	<Pine.LNX.4.64.1110041831060.20981 at ps20323.dreamhostps.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, 4 Oct 2011, Odin H?rthe Omdal wrote:
>> >
>> >  If the CORS-check did not succeed on<img
>> >  src=http://crossorigin.example.net  crossorigin>, this should happen
>> >  according to spec:
>> >  
>>> >  >  Discard all fetched data and prevent any tasks from the fetch algorithm from
>>> >  >  being queued. For the purposes of the calling algorithm, the user agent must
>>> >  >  act as if there was a fatal network error and no resource was obtained. If a
>>> >  >  CORS resource sharing check failed, the user agent may report a cross-origin
>>> >  >  resource access failure to the user (e.g. in a debugging console).
>> >  
>> >  <http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch>
>> >  
>> >  
>> >  In this scenario an author wanting to do some canvas processing with the
>> >  image, will be able to check img.onerror to see whether she can use that
>> >  image. The image won't load on a failed check. Gecko does this.
>> >  
>> >  WebKit, on the other hand, only taints the image and loads it anyway,
>> >  breaking the spec. The error will instead crop up in a way that is more
>> >  verbose and harder to miss when she tries to read the image data out.
>> >  
>> >  
>> >  Is WebKit's method a lesser surprise than the image just not showing up
>> >  (if they don't check for thrown error)? It'd be nice to hear why it's
>> >  implemented like that, if there are any good reasons. WebKit's method
>> >  seemed most obvious to me at first, but after investigating a bit I'm
>> >  not sure anymore...
> The idea is that if the server explicitly rejected the CORS request, then
> the image should not be usable at all.
>
>

Webkit fails to check for "same origin" in extensions, now.

I'd been using <img crossorigin> for everything... It was lazy but 
worked fine until the latest roll-out of Chrome.
Now my local references fail the check. I have to use <img> for local 
images that I know are safe, and <img crossorigin> for images that I 
suspect are not safe.

This is likely just a bug in Chrome, but it was rolled out quickly 
before going through the Chrome Canary process.

Code example: <img src="./localImage.png" crossorigin> may -fail- the 
crossorigin check even though the image will not set a dirty flag on Canvas.

-Charles