[whatwg] Same-origin checking for media elements

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).

Regards,
Silvia.

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
> 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 18:28:06 UTC