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

[Ralph Giles]

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.

> 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?

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.

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. Or until my cheap shared
webhosting runs out of space I want to move the video to amazon's s3.
I've always thought the principle of easy linking was one of the
foundations of the web, an important ingredient in its popularity and
continued agility. Having opt-out access controls on static resources
is really setting the barrier too high. Sites already go down all the
time for exceeding their traffic or cpu quota. I only ever hear about
it because the site itself is popular. I don't see how giving the
media elements different behaviour is really solving that problem.

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. mv_embed already does this
for java playback anyway. So you'd get your security and we could work
around it. Perhaps that's no big deal since people will be using a
fallback script for the next decade anyway, but it's another way
<video> is no improvement on the status quo. :(

 -r