[theora] <video/> and cross site scripting policy.

[Gregory Maxwell]

On Mon, Nov 10, 2008 at 1:56 AM, Ralph Giles <giles at xiph.org> wrote:
> I can't speak for Robert, but I believe the concern with static video
> is with leaking the video itself, which has privacy and, in a
> firewalled environment, information security implications.
>
> For example, many webcams have a standard access url. So a malicious
> page could include javascript which probes ip addresses on the user's
> lan, downloads and samples the video in the background and uploads it
> back to the origin. Since those cams might be behind a nat/firewall
> and aren't publicly addressable, this is a breach of organization-
> level security through what is effectively a subverted machine.

There isn't a leak of the 'video' proper unless there are bugs.  The
canvas tag should be the only way to grab frames and it impliments
some gnarly tainting to prevent that.

The image grabbing issue would be the same for <img/>, so there is no
real point in treating <video/> differently for that purpose.

But video isn't quite the same as <img/>,  for example Video may
contain captioning and it would be VERY useful if JS could get to the
captioning.  A caption leak is probably worse than a few frames leaked
for video which is captioned. Even without captions Video also has
more information that can leak (length, for example) than just the
width and height of images.

Likewise, as mentioned, abusing clients for scanning purposes is an
important concern. (Although I do wonder if you can't detect the
existence of a video file using some legacy tag that isn't subject to
the cross-origin check).

On Mon, Nov 10, 2008 at 3:27 AM, Conrad Parker <conrad at metadecks.org> wrote:
> got it.
>
> So perhaps a good default (unconfigured) server configuration is to
> not send out any special Allow header, and then document how to change
> that appropriately.

I think we need to know if the client can detect cross-origin check
failure. If it can, then I'd recommend deny by default since the
failure would not be mysterious so long as the client was running JS
for video-compatibility.  If ultimately we will not be able to detect
in any popular browsers, then I'd have to recommend allowing by
default with appropriate warnings in the docs.

Adding complexity for the sake of security is acceptable but
mysterious failures are not so much.