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

[Gregory Maxwell]

I'm glad that I didn't totally misunderstand. Hopefully you won't mind
a few simple questions.

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.

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?

Presumably parties wishing to deny embedding are well aware of their
own wishes and are able to take proactive measures to achieve those
ends.

Is the concern the aforementioned stripping proxies stripping origin?
In that case the video content will failing mysteriously while the
bulk of the site continues to work.  With a few more lines of code the
proxy may forge the request-response handshake back towards the
client, and this security measure will be somewhat defeated.

Obviously fail-by-default should be the case for dangerous things
which are not allowed cross site today to avoid creating a security
vulnerability.  But I think the security argument is completely dead
for <video/> so long as this behavior is not also extended to <img/>

[snip]
> and that's been a gigantic source of security troubles. We'd block
> cross-site loads of those resources if we could without breaking the
> Web.
[snip]

If this functionality were implemented as fail-working server-opt-in
it could be provided for all media.

Is there any reason to expect that <video/> would present a different
security profile from images? (barring implimentation bugs, of course)

> The burden of configuring the "Access-Control-Allow-Origin: *" header
> on the servers that are willing to serve video (or fonts etc) to the
> world seems like a reasonable tradeoff.

I hope you have carefully considered the negative implications here:

I routinely see problems where users are hosting files where the
webserver mis-identifies mime types and causes client misbehavior.
Even though most webserver software allows mime overrides via simple
tools like htaccess solving this simple problem is far beyond the
technical sophistication of many content creators, and if the server
is controlled by someone else it may be nearly impossible to get a
simple configuration change.  I would expect access-control to be
significant more difficult in the short term, and no easier in the
long term.

I hope that at a minimum it will be possible to interrogate the
<video/> object via JS and determine that access was rejected by the
target server so that a human-compatible error message can be produced
rather than silent failure.

So, it seems to me that this decision will put <video/> at a
significant disadvantage compared to web media for some use cases.
Where the primary concern (server embedding control) could be
accomplished without fail-broken, and where the possible security
benefits are mooted by the parallel functionality of <img/> which can
not be made fail-broken for compatibility reasons.

Am I off the mark?


Thank you for your time.