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

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

Received on Tuesday, 1 November 2011 15:15:53 UTC