[whatwg] [CORS] WebKit tainting image instead of throwing error
w3c at adambarth.com
Thu Oct 6 09:11:54 PDT 2011
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
> 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. :)
More information about the whatwg