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

[Jonas Sicking]

On Thu, Oct 6, 2011 at 9:11 AM, Adam Barth <w3c at adambarth.com> wrote:
> On Thu, Oct 6, 2011 at 8:45 AM, Odin Hørthe Omdal <odinho at opera.com> wrote:
>> On Thu, 06 Oct 2011 17:05:29 +0200, Adam Barth <w3c at adambarth.com> wrote:
>>
>>> The reason it's implemented like that is because I didn't add any new
>>> security checks.  I just expanded the canvas taint-checking code to
>>> understand that a CORS-approved image could pass.
>>
>> Ok, so not really intended then. Good :-)
>>
>>> w.r.t. to blocking the whole image, there isn't any security benefit
>>> for doing so (if we did so, attackers would just omit the crossorigin
>>> attribute).  If you want to prevent folks from embedding the image,
>>> you need something that works regardless of how the image was
>>> requested (like From-Origin).
>>
>> Well. I could, as server operator, block everything that didn't have an
>> Origin-attribute. It wouldn't work then for browsing normal pages on your
>> own, but maybe for a special api of some such.
>>
>>
>> Anyway, that was really never my concern; the whole reason for actually
>> having a crossorigin-attribute on the image would be because you want to get
>> that extra check so you can be able to use it like you want.
>>
>> With WebKit now, if I built such an application, I wouldn't have any nice
>> and obvious method of knowing whether I really could use the picture or not.
>> Throwing an error on the image on the other hand makes it fail early, before
>> I do all the canvas-processing.
>>
>>
>> Since the crossOrigin attribute exist, it'd make sense to have it behave as
>> a real way for you to say «I'm going to use this and I need an explicit
>> allowance».
>>
>> Right now, the attribute doesn't really do anything from the author's point
>> of view. It /may/ make an untainted image, or it might not. It's obviously
>> different from always making tainted images (like not using the attribute
>> would), but I think the whole reason why someone would go to the extra
>> trouble of adding «crossOrigin» is if they really want an untainted image.
>>
>> If they don't care about tainting, and just really want the picture, they
>> can refrain from setting the crossOrigin attribute.
>>
>>
>> If they actually want a fallback, they can easily just reload the picture
>> without crossorigin, and they will probably get the cached image directly
>> from the browser (because it already has it, only won't show it).
>>
>> Obviously, if there hadn't been a crossOrigin-attribute, this would be the
>> nice way to handle all image fetching.
>
> It sounds like you're arguing that it's better for developers if we
> fail fast and hard, which is the opposite of how most of the web
> platform is design (vis HTML versus XML).
>
> The arguments revolving around wishful thinking about how the world
> should have been don't carry much weight for me.  :)

I absolutely agree that we should make the web platform easy to
develop for. But removing error conditions doesn't always make it
easier to develop.

If someone explicitly adds a crossorigin attribute, they are most
likely doing that in order to use the image in a way that require it.
I.e. they are likely planning on using the image in WebGL, or use the
image in canvas and then read from the canvas.

By making the load "succeed" even if the proper CORS response wasn't
present you now force the site to do error handling in two locations.
They still have to listen to error events from the <img> load itself
in case there were network errors. But they now also have to wrap a
try/catch around every site where they then use that image in WebGL in
case the load didn't have the proper CORS response.

It seems better for the developer to know that if a <img crossorigin>
successfully loads, they can always be sure that the image can be used
without tainting or throwing happening.

/ Jonas