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

[Robert O'Callahan]

On Sat, Nov 8, 2008 at 7:43 AM, Ivo Emanuel Gonçalves <justivo at gmail.com>wrote:

> I'm afraid the Mozilla people sometimes are a bit too much optimistic
> about how the web works.  It's the unity of human creation: it's
> messy, horrible and most of the time nobody knows what they're doing.


In fact, the optimists are those who believe that cross-site loading has no
risks and any security problems that arise can be patched later without
burdening Web developers. (Or those who believe that man-in-the-middle
attacks are hard and therefore self-signed certificates are adequate.) We're
pessimists because we know these things are not true.

Allowing cross-site loads by default makes things superficially simpler for
developers, but usually once all the security implications are worked out,
it adds enormous complexity for developers who care about security,
especially intranet developers. Jonas pointed out the situation with CSS,
where developers need to know not to put sensitive information in a style
sheet in case it gets loaded cross-origin.

For <video> the situation is possibly even worse, since the set of formats
<video> can load will vary by browser and grow over time. In principle,
anyone putting any file on any intranet would have to consider what could be
leaked to other sites if that file was loaded by <video> in any browser ---
even if they don't use <video> themselves. And this analysis would depend on
the video API which we also expect to grow over time. So there's a real
danger that we'll want to add new formats or APIs but we won't be able to,
or they'll have to fail for cross-site loads, because there's sensitive data
that could become exposed. (Actually, if history is any guide, we'll add
formats or APIs, then discover they let someone's data leak and be forced to
cripple or remove them, breaking some sites that started using them.) It's
probably going to be simpler for developers in the long run to default to
the same-origin restriction now, IMHO. (As I mentioned earlier, we have to
impose it now or never.)

The situation with progress events illustrates this perfectly. We already
have them implemented in Firefox, so if we decide not to impose same-origin
by default, we'll have to lobotomize progress events to not report the bytes
loaded or total bytes for cross-origin loads. If Jonas wasn't such a smart
guy, we might not have noticed and shipped FF3.1 and then had to change
behaviour in a security update (which always hurts everyone). The exact way
we lobotomize it would have to be written into the spec. Someone who writes
a generic player JS library would quite possibly not take into account that
those events might be lobotomized, so the player would work in their
(same-origin) tests but some part might behave strangely when someone used
it with a cross-origin load. Is this really the world you want?

As for the suggestion that servers such as intranet servers should "opt in"
to same-origin restrictions --- I actually think that would be great. But
making that a reality any time soon for the millions of such sites (many
completely unmaintained) is much more optimistic than I dare dream of. In
the meantime, we need to not leak more of their data than we already do.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/theora/attachments/20081108/feba7e82/attachment.htm