On Thu, 06 Oct 2011 17:05:29 +0200, Adam Barth <w...@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

Reply via email to