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

[Gregory Maxwell]

---------- Forwarded message ----------
From: Robert O'Callahan <robert at ocallahan.org>
Date: Thu, Nov 6, 2008 at 5:12 PM
Subject: Re: [theora] <video/> and cross site scripting policy.
To: Gregory Maxwell <gmaxwell at gmail.com>
Cc: Chris Double <chris.double at double.co.nz>, theora at xiph.org


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.
>
> 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.

Also, if <video> becomes really popular on the Web, as we hope, then I
predict that most sites will not want to let other sites "hotlink" to
their videos. A smaller number of high-volume sites and hosting
providers will. If so, then it's less configuration burden to default
to same-origin.

> [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.

Yes. In fact, I think we do want to support a server header which says
"This resource should not be loaded cross-origin, unless there is
additional Access Controls metadata which says otherwise". But that
*sucks*. It's only acceptable as the best of a bad set of options for
dealing with legacy assumptions.

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

For <img> we have a bunch of problems with cross-origin information
leakage. We try very hard to avoid leaking any more information than
the image's existence and size. For example, if a page draws a
non-same-origin image into a <canvas>, we "taint" the canvas so that
the canvas toDataURL method no longer works. (Of course we have to
propagate taint if a tainted canvas is rendered into another
canvas...) We now face subtler methods of pixel extraction, such as
using SVG filters to move data from color channels to alpha channels
and then using SVG pointer-events and the DOM elementFromPoint method
to extract information from alpha channels via hit-testing. (See
http://markmail.org/message/w3fz4qxycfa2tbic )

<video> has all that of course, but also more because the <video>
element's interface is much wider than the <img> element, and it's
likely to get wider with time. For example, it would be great if
scripts could access read closed-caption data in the stream, but
obviously we don't want to leak that data cross-origin. Should a
scriptable API to test the video format be accessible cross-origin?
Etc.

> I routinely see problems where users are hosting files where the
> webserver mis-identifies mime types and causes client misbehavior.

That is a problem we're quite familiar with :-)

>
> 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.

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.

Note that serving your video in an IFRAME that other people can
include cross-origin remains an option.

> 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.

We should look into that.

> Am I off the mark?

No. This is a vexed area where all options are unsatisfactory.

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]