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

[Ralph Giles]

Forwarding Robert's reply. We've been silently discarding non-member
posts. I've changed it back to moderator-queue accumulation for the
moment, so future replies can get through. Very amusing given we're
discussing access controls.

 -r


---------- Forwarded message ----------
From: Robert O'Callahan <robert at ocallahan.org>
Date: Thu, Nov 6, 2008 at 4:40 PM
Subject: Re: [theora] <video/> and cross site scripting policy.
To: Ralph Giles <giles at xiph.org>
Cc: Gregory Maxwell <gmaxwell at gmail.com>, theora at xiph.org


On Fri, Nov 7, 2008 at 1:14 PM, Ralph Giles <giles at xiph.org> wrote:
>
> On Thu, Nov 6, 2008 at 2:44 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> > Also, if <video> becomes really popular on the Web, as we hope, then I
> > predict that most sites will not want to let other sites "hotlink" to
> > their videos. A smaller number of high-volume sites and hosting
> > providers will. If so, then it's less configuration burden to default
> > to same-origin.
>
> This feels like the crux of your trade-off. The only way I've been
> able to make sense of your position here is if you're already against
> hot-linking.

I'm not against it at all.

If you can't make sense of the points I raised in my last email (or
you think I made them in bad faith), then I guess we can't
communicate.

> > Serving media streams that can be "hotlinked" by anyone in the world
> > doesn't seem like something that everyone is going to want to do. If
> > you want to do it, you need a reasonably large operation capable of
> > handling a lot of traffic. Already today most people who want to serve
> > video just upload it to some site that does all the hard work for
> > them.
>
> And it's a fairer burden for a large operation to implement the access
> control headers everywhere?

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

> Or until my cheap shared
> webhosting runs out of space I want to move the video to amazon's s3.

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 certainly don't envy you implementing your taint tracking. And if it
> doesn't apply to iframes, I guess in practice everyone will just use
> an embed snippet that puts it in an iframe.

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

Rob
--
"He was pierced for our transgressions, he was crushed for our
iniquities; the punishment that brought us peace was upon him, and by
his wounds we are healed. We all, like sheep, have gone astray, each
of us has turned to his own way; and the LORD has laid on him the
iniquity of us all." [Isaiah 53:5-6]