On Sat, Nov 8, 2008 at 7:43 AM, Ivo Emanuel Gonçalves <span dir="ltr"><<a href="mailto:justivo@gmail.com">justivo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm afraid the Mozilla people sometimes are a bit too much optimistic<br>
about how the web works. It's the unity of human creation: it's<br>
messy, horrible and most of the time nobody knows what they're doing.</blockquote><div><br>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.<br>
<br>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.<br>
<br>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.)<br>
<br>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?<br>
<br>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.<br>
<br></div></div>Rob<br>-- <br>"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]<br>