- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 21 Jan 2011 23:22:33 -0800
- To: Lucas Adamski <ladamski@mozilla.com>
- Cc: public-web-security@w3.org
On Fri, Jan 21, 2011 at 3:29 PM, Lucas Adamski <ladamski@mozilla.com> wrote: > On Jan 21, 2011, at 1:47 PM, Devdatta Akhawe wrote: >> * It should be possible to handle violations programmatically. As I >> argued before, I think this is a cleaner/simpler/better/flexible >> design than the current CSP design. As Adam noted before, the >> SecurityViolation (and whatever its called in CSP) is for programmer >> convenience and thus accessing it programmatically (which is imho more >> convenient for the developer) is a good idea. > > Actually the reporting is primarily aimed at webserver and security admins, not developers. Developers aren't usually the ones monitoring production websites. The current reporting mechanism integrates better with existing server logging technologies, and can be deployed universally across an entire website w/o require explicit developer support in every page (an advantage of using headers to deliver policies in general). One major benefit of CSP is that server admins can deploy policies with confidence that they will be applied consistently to all HTML, which can help detect when new code is deployed that violates the existing policy (and associated security assumptions). I'm generalizing, but in-content solutions tend to rely on dogmatically consistent implementation on the part of developers... which is a problem. >From the folks I've spoken with, this seems to depend on social or organizational structures. For example, when the "ops" folks are separate from the "dev" folks in some sense. In the some cases, (e.g., shared hosting), the "ops" folks are so separated from the "dev" folks that they actually have no lines of communication. In other cases, (e.g., Facebook), the two are extremely well integrated. Adam
Received on Saturday, 22 January 2011 07:23:38 UTC