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

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.

--
Odin H?rthe Omdal,
Opera Software

Received on Thursday, 6 October 2011 08:45:19 UTC