Hi Sorry, I didn't read your modular approach proposal before sending the email.
Cheers Devdatta On Oct 20, 2:03 pm, Adam Barth <abarth-mozi...@adambarth.com> wrote: > In the modular approach, this is not true. You simply send this header: > > X-Content-Security-Policy: safe-history > > The requirements to remove inline script, eval, etc aren't present > because you haven't opted into the XSSModule. You can, of course, > combine them using this sort of policy: > > X-Content-Security-Policy: safe-history, block-xss > > but you certainly don't have to. > > Adam > > On Tue, Oct 20, 2009 at 1:59 PM, Devdatta <dev.akh...@gmail.com> wrote: > > The history enumeration threat is a simple threat with a simple > > solution. Opting into Safe History protection shouldn't require me to > > do all the work of opting into CSP. In addition, I don't see any > > infrastructure that is needed by this feature that is in common with > > CSP. > > > Lets say I am a website adminstrator, and I am concerned about this > > particular threat . Opting into CSP involves a lot of work - > > understanding the spec, noting down all the domains that interact > > everywhere on my site, removing inline scripts and evals and > > javascript URLs to corrected code etc. etc. My fear is that this will > > make admins write policies that are too lenient (say with allow-eval) > > , just to get the safe history feature. > > > Cheers > > Devdatta > > > 2009/10/20 Adam Barth <abarth-mozi...@adambarth.com>: > >> On Tue, Oct 20, 2009 at 12:50 PM, Devdatta <dev.akh...@gmail.com> wrote: > >>> Regarding , History enumeration -- I don't see why it should be part > >>> of CSP. A separate header - X-Safe-History can be used. > > >> I think one of the goals of CSP is to avoid having one-off HTTP > >> headers for each threat we'd like to mitigate. Combining different > >> directives into a single policy mechanism has advantages: > > >> 1) It's easier for web site operators to manage one policy. > >> 2) The directives can share common infrastructure, like the reporting > >> facilities. > > >> Adam _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
