Stuart Ballard wrote:
>
> 1) html.css is trusted
> 2) The XBL file that it binds to is trusted
> 3) The association of html.css to the untrusted html file is done by a
> trusted entity - ie mozilla.
There's one really nice feature to the above logic that makes me think
that it really is the right way to go (not that I haven't thought that
about at least 4 different approaches previously, though, so take this
with a grain of salt...).
Consider:
#2 is irrelevant given #1, because if we trust the CSS file, we can
trust it not to bind to untrusted XBL; that would be Bloody Stupid.
#1 is irrelevant given #3, because we can trust the trusted entity here
to not be Bloody Stupid also.
So what this logic boils down to is that we can trust bindings if the
person (principal) that _makes_the_association_ from the document to the
css file is trusted.
Now, in 99% of cases, this association comes from a <link> or a <style
src> or an <?xml-stylesheet?> in the document itself. So in *all* of
these cases, we've reduced the logic down to "The security principal of
the XBL and the CSS file is completely ignored, and the security
principal of the document is used". It reduces to the current model!
The *only* case where it doesn't reduce to the current model is when the
CSS file is attached implicitly by Mozilla, or (perhaps theoretically)
by some other trusted entity. This means, basically, html.css and very
little else :)
The cool thing about this solution is that it keeps the known-secure
model for 99.9% of cases, while also opening it up enough for every
single thing that I can imagine doing using XBL (they would *all*
involve using html.css). And it provides a rationale for doing so.
Thoughts?
Stuart.
