[theora] <video/> and cross site scripting policy.
dale at ucsc.edu
Fri Nov 7 09:32:38 PST 2008
I would also voice concern about the "treating video differently from
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
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
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.
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.
>>> 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
>> 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.
>> 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.
>> 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
> theora mailing list
> theora at xiph.org
More information about the theora