- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 6 Oct 2011 08:19:36 -0700
On Thu, Oct 6, 2011 at 8:16 AM, Anne van Kesteren <annevk 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. >> >> 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). > > You mean WebKit does not support the crossorigin attribute at all? That is > how I envisioned CORS to work for <img>. WebKit does support the crossorigin attribute. When we issue the request, if the img has the crossorigin attribute, we add CORS requests headers. If an image is ever drawn onto a canvas, then we check whether it taints the canvas. If it's an image from another origin, it taints the canvas unless CORS says otherwise. Odin is asking why an img with the crossorigin attribute doesn't fail to load entirely if the server doesn't supply appropriate CORS headers. Adam
Received on Thursday, 6 October 2011 08:19:36 UTC