Message: 4
Date: Tue, 4 Oct 2011 18:32:02 +0000 (UTC)
From: Ian Hickson<[email protected]>
To: Odin H?rthe Omdal<[email protected]>
Cc:[email protected]
Subject: Re: [whatwg] [CORS] WebKit tainting image instead of throwing
error
Message-ID:
<[email protected]>
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
