W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Same-origin checking for media elements

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 17 Nov 2008 01:37:36 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811170121300.1237@hixie.dreamhostps.com>
On Tue, 11 Nov 2008, Robert O'Callahan wrote:
>
> Should <video> and <audio> elements be able to load and play resources 
> from other origins? [...]
>
> 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.

Against my better judgement, and based mostly on the feedback from Maciej, 
I've not changed the spec (and thus continued to allow cross-site 
downloads of data). Implementation experience on this topic is highly 
sought and will influence further updates to the spec.

Implementators should feel justified in implementing cross-site 
restrictions if such restrictions are considered advisable by browser 
vendor security teams. If implementations ship with restrictions, I will 
add them to the spec (though please, document them, so that I have a 
chance of working out what they are!).

When we add APIs for data more sensitive than file size, I will be 
applying cross-site limitations on the APIs. Right now you can get:

 - file existence
 - file size
 - file format
 - server bandwidth
 - media length

...which are sensitive, but not so sensitive that they require opt-in.

Servers concerned with leakage can currently use Referer-triggered 
blocking to avoid leaking the above data.


On Wed, 12 Nov 2008, Jonas Sicking wrote:
> 
> An additional, though rather minor problem, is that implementations will 
> have to delay the loadstart event until it has confirmed that the 
> targeted file is in fact a real video file, and has confirmed that with 
> relatively high level of confidence. Otherwise the size of random HTML 
> files can be measured using the <video> element.

The loadstart event no longer reveals anything regarding the actual 
resources.


I encourage those in favour of not having restrictions to read Jonas' 
e-mail:

   http://lists.xiph.org/pipermail/theora/2008-November/001958.html

I share Jonas' concerns and am very reluctant to not place cross-site 
limitations here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 16 November 2008 17:37:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC