[whatwg] Same-origin checking for media elements
silviapfeiffer1 at gmail.com
Sun Nov 16 18:28:06 PST 2008
Maybe it is possible to combine the two approaches 2) and 3) as
proposed by Robert O'Callahan.
The Access-Control-Allow-Origin: "*" header would then allow access
to more information than is available through the restricted API.
(This was an approach suggested on #theora).
On Mon, Nov 17, 2008 at 12:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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
> I encourage those in favour of not having restrictions to read Jonas'
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg