On a related note, just to have one more example (and for my learning) , I went ahead and wrote a draft for ClickJackingModule. https://wiki.mozilla.org/Security/CSP/ClickJackingModule
In general I like how short and simple each individual module is. Cheers Devdatta 2009/10/20 Lucas Adamski <[email protected]>: > 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
