Video, Audio and Cross Domain Usage
[ Update 19/Nov/2008: This is currently under discussion in the WHATWG and the W3C bug has been marked "won't fix". For now, cross domain usage is fine. ]
This is a heads up for a change to the HTML5 media elements that may break existing usage. If you use <video> or <audio> then you may need to make changes to the way you serve your media resources.
It looks likely the that <video> and <audio> elements will be restricted so that requests for a media resource from a domain other than the page containing the element will be disallowed. There is a W3C bug (<video> and <audio> should prevent cross-origin media loads) about this.
Once the browsers implement this then default usage of cross domain media resources will fail. This includes requests for resources on subdomains, or different ports. So if you have a page on example.com, this will work in the Firefox implementation now, but will break when the change is made:
If you are hosting your media resource on a third party hosting system you'll need to ensure that they support these headers if you want to display video and audio on a different domain. Programs such as Icecast, used to stream video and audio, will also need to be compatible with the Access Control specification if you want to use the streams with <video> or <audio> from a server on a different host or port.
This unfortunately breaks some common patterns for building sites that allow uploadable media, or separate media files into subdomains, until they (or their software/hosting provider) supports access control. Now would seem to be a good time to request access control support if you're in this situation.
A discussion on this has started on the Theora mailing list. Jonas Sicking has a good summary of the reasons for the cross domain restriction.
Categories: firefox, video
This is a heads up for a change to the HTML5 media elements that may break existing usage. If you use <video> or <audio> then you may need to make changes to the way you serve your media resources.
It looks likely the that <video> and <audio> elements will be restricted so that requests for a media resource from a domain other than the page containing the element will be disallowed. There is a W3C bug (<video> and <audio> should prevent cross-origin media loads) about this.
Once the browsers implement this then default usage of cross domain media resources will fail. This includes requests for resources on subdomains, or different ports. So if you have a page on example.com, this will work in the Firefox implementation now, but will break when the change is made:
<video src='http://media.example.com/foo.ogg'></video>Cross domain usage can be enabled by sending headers along with the file being requested. The header explicitly says 'this resource can be used cross domain'. The protocol for doing this is described in this Access Control document.
If you are hosting your media resource on a third party hosting system you'll need to ensure that they support these headers if you want to display video and audio on a different domain. Programs such as Icecast, used to stream video and audio, will also need to be compatible with the Access Control specification if you want to use the streams with <video> or <audio> from a server on a different host or port.
This unfortunately breaks some common patterns for building sites that allow uploadable media, or separate media files into subdomains, until they (or their software/hosting provider) supports access control. Now would seem to be a good time to request access control support if you're in this situation.
A discussion on this has started on the Theora mailing list. Jonas Sicking has a good summary of the reasons for the cross domain restriction.
Categories: firefox, video
Labels: mozilla
posted by Chris Double at 3:54 PM
12 Comments:
So now we have cross-site AJAX and JS in general, but not video/audio?
That seems stupid.
This decision means that OGG will never compete with Flash/OnVP6/H.264 in the way that Flash/OnVP6/H.264 content from YouTube can be embedded in a 3rd party web page.
Congratulations open web zealots, you just gave another free kick to the closed web and kicked your open web developer supporters in the nuts - AGAIN!
Why on earth did they decide to put that in?
Video and audio should be complements to img and work in the same way.
This is mostly a nuisance for everyone involved. If they wanted to have some basic protections for people offering the content, they should do opt-out for cross domain responses.
bye
Andraz Tori
Hmmmm... where exactly is the problem? If you want your media to be cross-site embeddable you just grant fitting rights using access control. This is an one time trivial configuration effort.
Given how big security issues on the web are today because things were not designed "safe by default" I welcome a more careful approach this time.
Plus of course this isn't Ogg specific.
(Where exactly did open web zealots kick open web developers in the nuts? You prefer security problems later on with browsers implementing "99% working" workarounds?)
Really, this is the first time I hear people saying "boooo, the web guys are spending way to much consideration on security" ;-)
But... why? The bug report doesn't provide any sort of justification.
Security? What vulnerabilities could this possibly prevent? Video and audio should be no more dangerous than images and much safer than Javascript, both of which can be used across domains.
Is it to prevent unauthorized use? Access-Control could solve that in an opt-in manner rather than the restrictive-by-default opt-out manner suggested here.
1) cross-site AJAX is based on a hack with frames. You can't do it asynchronisly either.
2) you can likely circumvent his security in a simelar manner
3) this security protects the user. Imagine a site allowed you to sent a private video to another person. A 3rd party site could intercept or at the very least show this video anyway you like
4) if you want to grab a video... there will be a firefox extension. again: it's about protecting users, not limiting.
5) this has got nothing to do with opensource by itself; and in the end browser makers will decide for themselves wether or not they will put this in. If they put this in, it will provide a user the protection that site A can't access private video's on site B. So, mike's hacky-website won't access a video gmail streams to you because your girlfriend sent it to you.
6) obviously, you are all a bunch of wanking script-kiddies to make me explain this too you
Say you work for foocorp and foocorp posts videos on its intranet at http://internal.foocorp.com/videos/ using Ogg/Theora with closed captioning (helps search, plus accessibility).
While on the foocorp network you checkout your competion's webpage at barcorp.com.
Without the same-origin policy barcorp can do several interesting things.
If they have some idea where your videos are stored (by hiring ex-foocorp employees, for example) they can use JS driven probing to scan for video files on http://internal.foocorp.com/videos/ which they couldn't normally access. They just have JS insert hidden video/ tags until they find one that has a length. This risk is the same for img/.
After discovering that newproducts-q2-2009.ogg exists they could then use JS to extract the closed captioning material. This is a risk that still images don't present.
These things could still be protected with opt-in security. And video/ failing in 'mysterious' (to the laymen) will probably cause people to just defeat the security with a wild card permit. For example, if foocorp normally puts videos on videos.foocorp.com but then embeds them from intranet.foocorp.com, it's very likely that they'll wildcard it just to make it work … but you can't claim that these security measures are pointless.
Hopefully the API will be rich enough that we'll be able to tell exactly when access was denied due to an access control failure and a little bit of video-helper JS (which most people will have in order to help non-video/-capable browsers) will be able to provide a helpful error message.
FWIW, I've asked two friends with commercial hosting services ask for the access control header to be enabled for them. Two days now, no results. This is going to suck. :(
It seems most of the criticism is caused by the access control being embedded in a http-header, which is harder to understand for content providers (non-techies uploading a video to their webspace) than a "meta file" like crossdomain.xml used by flash. The need for at new special http-header will probably also make it harder or impossible to use reverse proxies or s3 (was just looking through the s3 documentation and it seems only a fixed set of standard headers and headers with a special prefix is allowed).
Are there any chance that a fallback "meta file" could be implemented?
You are right that Amazon S3 does not allow additional headers and therefore cannot be used for holding videos that can be played by the video element.
This is actually something I had working with tinyvid.tv as a fallback when disk space went low. This won't work under the cross domain restriction until/if Amazon implement the access control specification.
s3 was just an example. Windows based web-hosts are another.
The main point was that, the problem could be made far easier to handle if the access control attributes could be communicated e.g. though a file (either with a known name as flashs "crossdomain.xml" or a ".ram" or ".asx" file that Real and Microsoft uses) or perhaps encoded in the filename.
Access Control is definitely required. But as ppl say, It should be opt-in kind of feature. those who wants to prevent cross domain usage will implement it and those who don't will not. By default it should not be there. In this new world of sharing things is priority, It should definitely off by default unless specified. Its necessity for sure as , say i have limited bandwidth and i don't want video being streamed everywhere.
Keeping all things secure.. kills usability. Flash videos will be more usable, so they killed video and audio before it landed in web-sphere. Bravo.. keep up that good work, in HTML 5 kill img too ;-) bring it some DRM system, so no one will be able to use cross-site images without license send by http header.
Post a Comment
<< Home