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

[Robert O'Callahan]

On Fri, Nov 7, 2008 at 2:21 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> From: Robert O'Callahan <robert at ocallahan.org>
> Date: Thu, Nov 6, 2008 at 5:12 PM
> > On Thu, Nov 6, 2008 at 4:12 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> >> On Wed, Nov 5, 2008 Robert O'Callahan <robert at ocallahan.org> wrote:
> >> [snip]
> >> > The main reason is that it gives servers control over who uses their
> >> > resources. Checking 'Referrer' headers doesn't work well since it
> >> > denies access to anyone behind a firewall that strips Referrer for
> >> > good privacy reasons (or similarly, disables Referrer in the browser
> >> > for the same reasons).
> >>
> >> I think most people who have done serious web work are aware of the
> >> significant shortcomings of referrer (unreliability, inability to
> >> distinguish reference from embedding, etc).  I'm very glad to see the
> >> new control tools.
>
> What makes us think that a new HTTP header will be used more
> consistently than referrer?


Some people, and many firewalls, turn off or strip the Referrer header
because it reveals the full URL of the referring page. So for example, if
http://intranet.example.com/WorldDomination/mind-control.html has a link to
wikipedia.org, example.com's firewall might strip Referrer to avoid leaking
information to wikipedia.org.

The Access Control spec improves matters in two ways:
1) The "Origin" header, unlike "Referrer", contains only the domain, not the
full URL, and I don't think we'll be sending Origin for link navigation. So
it's much less of an information leak and we (browsers, the W3C, etc) will
be encouraging firewalls to not strip it.
2) For simple cases (only same-origin allowed, or only one other domain
allowed), the server can leave the access check to the browser and things
will work even if Origin is stripped.

>> But what would be lost for this purpose by having a fail-working
> >> situation:  Client sends "Origin:"  and the client displays the result
> >> unless the server response indicates otherwise?
> >
> > Good question. The main reasons:
> > 1) It's generally a good idea to make the secure option the default.
> > 2) Access Controls is used in situations (such as cross-site
> > XMLHttpRequest) where the default is (and must remain) restriction to
> > same-origin. Varying the default based on the kind of load would be
> > confusing, and probably dangerous.
>
> So does this mean that in the current situation, where no servers
> support the header, the <video/> element will be useless because it
> will not allow any video to be played?


Not at all. Any site where the video file is hosted on the same domain as
the HTML page containing the <video> will always work just fine. (And I'm
sure there are *some* servers that already have
"Access-Control-Allow-Origin: *" since it's trivial and they're
experimenting with cross-site XHR.)

If search engines cannot access captions and subtitles and any other
> annotations, that will be really useless.


Nothing we're talking about here will have any impact on search engines.

> 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.
>
> To me this sounds backwards. People complained about the bandwidth use
> of images when the Web began. I think that bandwidth is not an issue
> any longer, or at least increasingly less important. I know from my
> own experience with customers that people are currently outsourcing
> their video operations because it is too complex to set up video for
> their sites, and because there is a lot of technology involved (flash
> players, thumbnailing, transcoding, embedding, cross-site domain
> managment). I thought the creation of the <video/> tag was about
> making this easier, not more complicated.


The need for an extra static header to enable cross-site video loading seems
much more minor to me than the things you mentioned ... or the other
inhibitors to <video> adoption, such as the problem of getting a free
interoperable codec into major browsers.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/theora/attachments/20081107/30298e91/attachment.htm