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

[Michael Dale]

I would also voice concern about the "treating video differently from 
image" approach being proposed.  I work on one such javascript library 
mv_embed that remaps video tags to multiple playback mechanisms. And its 
worlds easier to deal with all the plugins that do allow cross domain 
video than the ones that don't (java cortado). The cross-domain java 
issue is already the source of the most configuration troubles and 
impediments to rich interfaces.

Take this blog for example: http://metavid-mike.blogspot.com/ It pulls 
text transcripts from a remote server allowing the local site to stylize 
and or format the transcripts if so desired. As the video plays back the 
transcript auto-scroll in the page. The transcripts are pulled from one 
server and the video url is dynamically pulled form any number of media 
servers. 

We have yet to implement all the crazy trickery needed to query the 
iframed java video object for timestamps, play state etc. (I belive you 
can do it by packing data in a constantly updated anchor link and 
reading the iframe src attribute)... Having the video object "just work" 
(like every other in browser video playback system (quicktime, windows 
media, mplayer, vlc , flash etc) makes these sort of usages worlds easier. 

Ofcourse this could still be done by broadly applying the Access-Control 
mechanism as you describe but this raises the barrier to entry. Plus if 
people have any of the above mentioned plugins you can still elicit all 
the cross site media info you aim to restrict. What are the chances of 
someone not having any of the above mentioned plugins installed? Is this 
effort boradly supported is Adobe on board to respect 
Access-Control-Deny-Origin headers?

I think Gregory's point about people accidentally broadly applying the 
Access-Control header must be fully considered. Since its possible this 
security mechanism that differentiates static video content from static 
image content will cause more problems than it will solve as people who 
can't configure things apply excessively broad security mechanisms 
because they often do "what works"

The proposed security mechanism would be nice if we where designing the 
web from day 1. But cross site static content querying is for better or 
worse part of the net ecosystem and attempting to reverse that course 
may just cause more trouble than it will save.

and finally as Gregory mentions most big sites already have all their 
static content on a separate domain..so essentially we propose breaking 
the way that this is presently dealt with to add another way that may 
result in media on the same domain as logins and putting the security at 
risk by people improperly configuring cross domain header restrictions.

--michael

Gregory Maxwell wrote:
> On Thu, Nov 6, 2008 at 11:07 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>   
>> Putting all your world-accessible video files in one directory subtree and
>> changing the .htaccess there is still quite simple IMHO. At least if we do
>> it *now* before all this stuff is deployed and set up.
>>     
>
> Back to the assumption that the server supports htaccess.
>
> Even still,  It is still more complicated. From my perspective every
> step is another chunk of users who won't get it working, and another
> chunk who will shoot themselves in the head security wise.    With
> that in mind I think we can understand each other's positions.
>
> [snip]
>   
>>> But there are still many sites that won't but would still want to
>>> allow hot linking. Especially smaller sites, for example the xiph.org
>>> wiki would become vulnerable to XSS attack by using an allow all
>>> policy, yet we would want to permit hotlinking images stored on or
>>> servers.  Worse, people who donate capacity to us would make
>>> themselves vulnerable or have to undergo even more complicated
>>> configuration.
>>>       
>> That is an issue worth thinking about. It doesn't seem to me very hard to
>> collect the resources you want to be world-accessible and configure them so
>> --- I presume video and similar resources are already collected together in
>> their own directory space, with scripts and other sensitive data elsewhere
>> --- but, I haven't thought about that very much and I don't have experience
>> at running a Web site.
>>     
>
> It depends.  Structured CMS systems like mediawiki will have that
> behavior,  virtually everything else wont.   In practice people are
> going to handle this incorrectly.
>
>   
>>> [snip]
>>>       
>> That depends on how it's done. You'll start leaking the size of the video,
>> its existence, maybe its type. The spec gets more complex because it has to
>> describe behaviour in same-origin and cross-origin situations. So does our
>> code. There's more attack surface.
>>     
>
> True.
>
>   
>> One thing to keep in mind is that if we ship with a same-origin restriction
>> now, and then discover later that was a really dumb mistake, we can then
>> relax it and little has been lost. But if we ship with no restrictions and
>> then find out *that* was a dumb mistake, there's nothing we can do without
>> massively breaking things; we'll have to live with that mistake forever
>> (like <img>).
>>     
>
> This is a very good point which I had not fully considered.
>
> I'd like to point out that <img> can be significantly improved:
> Specify a header Access-Control-Deny-Origin: with the following rules:
>  If there is an allow header mentioning your origin, allow. If there
> is a deny mentioning your origin deny.  If there is a wildcard allow,
> allow, wildcard deny deny.  No header?  Allow for legacy things, deny
> for new things/unsafe things.
>
> Under that scenario images would eventually gain the protection as
> servers are updated to emit a deny.   But in that situation I'd
> suggest that video should work like img in accordance with the
> principle of least surprise.
>
>   
>> Why do you need to distinguish same-origin failure from any other failure?
>> Wouldn't you try fallback no matter what the failure is? And wouldn't you
>> normally know whether the file you're linking to is same-origin or not?
>> These are not rhetorical questions, I really want to know :-).
>>     
>
> I know if it's same origin or not but I do not know if the not-same
> request will be permitted or denied by the target server.  The
> fall-backs are clearly inferior to native support (including long load
> times, wasted bandwidth, and some risk of triggering a client crash),
> we would prefer not to use them unless we must (so, no flipping to
> Java just because it's not the same-origin).   Additionally,  it would
> create tremendous confusion if I popped up a message that said "This
> video will not play because fooserver.com does not allow playback from
> barserver.com. See here for more info on fixing this problem"  when in
> reality the file is corrupt or just doesn't exist.  (if the file
> doesn't exist AND the file was not permitted, this message is less
> harmful)
> _______________________________________________
> theora mailing list
> theora at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora
>