[whatwg] CORS requests for image and video elements

[Ian Hickson]

On Tue, 17 May 2011, Kenneth Russell wrote:
>
> Last week, a proof of concept of a previously theoretical timing attack 
> against WebGL was published which allows theft of cross-domain images' 
> content.
> 
> To address this vulnerability it appears to be necessary to ban the use 
> of cross-domain images and videos in WebGL. Unfortunately, doing so will 
> prevent entire classes of applications from being written, and break a 
> not insignificant percentage of current applications.
> 
> We would like to use CORS to solve this problem; if the server grants 
> access to the image or video, WebGL can use it. Initial discussions with 
> image hosting services have been positive, and it seems that CORS 
> support could be enabled fairly quickly. Many such services already 
> support other access control mechanisms such as Flash's crossdomain.xml.
> Unfortunately, experimentation indicates that it is not possible to 
> simply send CORS' Origin header with every HTTP GET request for images; 
> some servers do not behave properly when this is done.
> 
> We would like to propose adding a new Boolean property, useCORS, to 
> HTMLImageElement and HTMLMediaElement, defaulting to false. If set to 
> true, then HTTP requests sent for these elements will set the Origin 
> header from the page's URL. If the Access-Control-Allow-Origin header in 
> the response grants access, then the content's origin will be treated as 
> the same as the page's.

On Tue, 17 May 2011, Jonas Sicking wrote:
> 
> Does setting "useCORS" make the CORS implementation execute with the 
> "supports credentials" flag set to true or false?
> 
> When set to true, the request to the server will contain the normal 
> cookies which the user has set for that domain. However, the response 
> from the server will have to contain "Access-Control-Allow-Origin: 
> <origin>". In particular "Access-Control-Allow-Origin:*" will not be 
> treated as a valid response.
> 
> If the "supports credentials" flag is set to false, the request will be 
> made without cookies, and the server may respond with either 
> "Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin: 
> <origin>".
> 
> I propose that the latter mode is used as it will make servers easier to 
> configure as they can just add a static header to all their responses.

On Tue, 17 May 2011, Glenn Maynard wrote:
> 
> This could be specified, eg. <img cors> without credentials and <img 
> cors="credentials"> with.  I don't know if there are use cases to 
> justify it.

On Tue, 17 May 2011, Kenneth Russell wrote:
> 
> In general I think we need to enable as close behavior to the normal 
> image fetching code path as possible. For example, a mashup might 
> require you to be logged in to a site in order to display thumbnails of 
> movie trailers. If normal image fetches send cookies, then it has to be 
> possible to send them when doing a CORS request. I like the idea of <img 
> cors> vs. <img cors="credentials">.

I've added a content attribute to <img>, <video>, and <audio> that makes 
the image or media resource be fetched with CORS And have the origin of 
the page if CORS succeeded.

The attribute is "cross-origin" and it has two allowed values, 
"use-credentials" and "anonymous". The latter is the default, so you can 
just say <img cross-origin src="data.png">.

This is only a first draft, I'm not sure it's perfect. In particular, 
right now cross-origin media is not allowed at all without this attribute 
(this is not a new change, but I'm not sure it's what implementations do). 
Also, right now as specced if you give a local URL that redirects to a 
remote URL, I don't have CORS kick in, even if you specified cross-origin. 
(This is mostly an editorial thing, I'm going to wait for Anne to get back 
and then see if he can help me out with some editorial changes to CORS to 
make it easier to make that work generally.)

Implementation and author experience feedback would be very welcome on 
this.


On Tue, 17 May 2011, Kenneth Russell wrote:
> 
> Perhaps an API could also be added to find out whether the server 
> granted CORS access to the resulting media, though this is less 
> important. (Note that the canvas element does not have an explicit API 
> for querying the origin-clean flag.)

I haven't exposed this. You can work around it by trying to use the image 
in a canvas, then rereading the canvas, and seeing if you get a security 
error. If there are compelling use cases for that I'd be happy to add an 
API to handle this feature to the DOM though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'