[whatwg] Same-origin checking for media elements

On Nov 10, 2008, at 6:50 PM, Robert O'Callahan wrote:

> Should <video> and <audio> elements be able to load and play  
> resources from other origins?
>
> Perhaps Ian thinks not:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
> There's a to-and-fro discussion here:
> http://lists.xiph.org/pipermail/theora/2008-November/001931.html
> Jonas got involved here:
> http://lists.xiph.org/pipermail/theora/2008-November/001958.html
>
> There are three obvious options:
> 1) Allow unrestricted cross-origin <video>/<audio>
> 2) Allow cross-origin <video>/<audio> but carefully restrict the API  
> to limit the information a page can get about media loaded from a  
> different origin
> 3) Disallow cross-origin <video>/<audio> unless the media server  
> explicitly allows it via the Access Control spec (e.g. by sending  
> the "Access-Control-Allow-Origin: *" header).

I'd prefer 1 or 2 (assuming the restrictions assumed by 2 are  
reasonable).

> The reason to allow cross-origin playback is obvious: it's most  
> convenient for authors. At this point in time few, if any, major  
> file hosting sites support Access Controls in any way.
>
> Reasons to disallow cross-origin playback are a little less obvious.  
> The main issue is the need to avoid leaking information from, say,  
> intranet.example.com when an example.com user visits evil.com. The  
> threat is that an evil.com page tries to guess a URL in  
> intranet.example.com, load it via <video>/<audio>, and get  
> information about the file via the APIs on those elements. For  
> example, currently Firefox reports progress events containing the  
> size of the file; but we don't want to allow people to probe for the  
> file sizes of intranet files. Ideally we would conceal whether the  
> cross-origin resource even exists. We may want to evolve <video>/ 
> <audio> to include features like reporting of cues and caption data  
> to the enclosing page --- data that seem extremely unwise to expose  
> cross-origin.
>
> One thing to keep in mind is the possibility of someone using cross- 
> origin <iframe src="http://example.com/video.ogg">. (This works in  
> Firefox today.) This prevents access to the <video> element API and  
> basically reduces the information leakage and attack surface to that  
> of iframes. We might want to place restrictions on such iframe  
> usage, to give server operators control over their bandwidth. That's  
> a secondary question if options 2 or 3 are preferred.
>
> Another thing to keep in mind is that plugins such as Quicktime  
> allow cross-origin loads without restrictions. We don't want to put  
> <video> at an authoring disadvantage. On the other hand, being just  
> as secure as plugins may not be satisfactory, and we want a richer  
> in-page scripting API than plugins tend to offer.

QuickTime offers a fairly rich API; in fact many things now in the  
<video>/<audio> API were partly inspired by the API of the QuickTime  
plugin, when Apple proposed them. And the newest QuickTime plugin is  
being updated to be even closer to the HTML5 media element API.

> We've had some discussion inside Mozilla (with no consensus  
> reached), and some discussion with the Theora folks, but really it's  
> a cross-browser issue that we need to interoperate on, so I think  
> WHATWG is a more appropriate place to discuss it. And it's something  
> that should be settled soon since Safari shipped a while ago and  
> we'll ship soon.

I agree, the behavior should be interoperable.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081110/ff1a3c15/attachment.htm>

Received on Monday, 10 November 2008 19:49:35 UTC