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

[Gregory Maxwell]

Thanks again for having the patience to discuss this with us, my
response is inline:

On Thu, Nov 6, 2008 at 7:40 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> Absolutely. The larger the operation, the less relative effort it is to make
> a trivial one-time configuration change.
>
>> I have to agree with Greg: this will be a serious blow to <video>
>> adoption. The whole point of the new elements was to simplify
>> embedding video as a first class element in html. Your access
>> restriction plan makes serving video just as complicated as the way
>> flash video works now, where it essentially has to be dynamic.
>
> Embedding video is completely simple as long as it's same-origin or the
> media server sends a single static header.
>
>> It will work fine as long as I put up a page and the video on the same
>> server. Until I try to embed it in my blog.
>
> You can link to video on your server from a third-party blogging site just
> fine, as long as you have "Access-Control-Allow-Origin: *" configured on
> your server. (If you use Apache, it should be as simple as adding
> Header set Access-Control-Allow-Origin "*"
> to your .htaccess.)

We spent nearly two hours trying on IRC to help someone get the mime
types correct a few weeks ago, and all that took is a htaccess line
(logs available if you don't believe me :) ).  While you might suspect
the skill level of the person who took that long, this was someone who
had already managed to author a rather sophisticated website and was
just trying to get the media working right.

And this is assuming Apache. Many other webservers do not provide a
'user' accessible way to change this. So the user is stuck waiting on
the sysadmin to get around to it.   You can assume the sysadmin may
not be too eager, see my next point:

> I'm confident that S3 and other services will add support for Access
> Controls. Remember that as well as video, this spec is being used for
> XMLHttpRequest (including IE8's XDR) and fonts, and more stuff over time.

I think this is this point raises serious flaw in the "just one line
to allow wildcard access" argument.  With video you will be mixing
things with vastly different security profiles under the same access
control mechanism.  Video and image are nearly identical (you pointed
out that video is somewhat worse, I can agree, but it's still very
similar) while XMLHttpRequest is fairly similar.

Consider: Gregsbank.com  adds an "Access-Control-Allow-Origin" => "*"
to their config, since thats whats a google search told them they had
to allow other sites to embed <video/>.

Now evilhacker.com sets up client side scripting which uses
XMLHttpRequest to send users to Gregsbank.com, using their cached
session/credentials and has them wire money to Russia.

This can be avoided by being careful to add the access control header
to video only, but you've now escaped the simple one line change.
You're talking multiple lines, at least one per audio/video file type,
and on some webservers (lighttpd, for example) doing more than a
single static header is much more complicated.

So with access control we've got a great security mechanism, but by
including video we're going to create an enormous incentive to lower
security below what we have today.

> It seems a lot easier to add that .htaccess line than to create even that
> one-line IFRAMEable page on the server.

Forget an IFRAMable page:  someone trying to be a rude hotlinker could
simply IFRAME directly to the media itself.  I would be very surprised
if any browser supporting <video/> did not also directly support
playing media URLs, FireFox certainly does. (and would file a bug if I
ever found one...)