I'm confident we can figure out how best to communicate CSP use cases
to developers independent of implementation. What we should have are
documentation modules that walk a web dev through specific goal-driven
examples, for example.
The problem with modules I see is they will complicate the model in
the long run, as the APIs they govern will not be mutually exlusive.
What if 3 different modules dictate image loading behaviors? What if
the given user agent in a scenario does not implement the module where
the most restrictive of the 3 policies is specified?
Lucas
On Oct 20, 2009, at 15:07 Devdatta <[email protected]> wrote:
I actually think the modular approach is better for the web developer
as the policy is easier to write and understand.
But I do share your concern, Atleast right now, it is pretty easy to
say -- user agents that support XSSModule are protected against XSS
and user agents that support history module are protected against
history enumeration attacks. Going forward, we want to keep the
separation just as clear and simple.
* This would require very clear and simply stated threat models for
each module. Each module's threats should be (ideally) disjoint.
* A module should be small and complete. We should make it clear why
every part of the module is important for the given threat model. This
would hopefully ensure that browser vendors either implement the whole
module or none of it. (I.E implementing half of a module will give no
security)
I think this breakup of the spec into modules is useful to the
webdevelopers (making it easier to understand) and easier for the
browser vendors to implement.
Regards
Devdatta
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
