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

[Adam Barth]

On Tue, Nov 1, 2011 at 3:04 PM, Charles Pritchard <chuck at jumis.com> wrote:
>> 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.

Sorry about that.  This is filed as
<https://bugs.webkit.org/show_bug.cgi?id=71053>.  I've got some time
scheduled to look at this later in the week.

Adam