Re: Trigger a DOM event/error when a CSP violation happens.

On Wed, Nov 28, 2012 at 8:10 AM, Dan Veditz <dveditz@mozilla.com> wrote:

> I like the concept but have concerns over re-using 'self'. This is a
> completely different 'self', the page vs. the origin server elsewhere.
> Maybe something like 'page','events' or 'enable-events'? Those aren't even
> close to a "URI" though and it's too late to change the report-uri
> directive name -- maybe 'self' wasn't so bad.
>

I think 'self' fits, though I agree that it's a different meaning than in
other source lists. I think there's a strong enough relationship between
the directive and the keyword, however, to make the meaning clear to
developers. However...


> I prefer opt-in, but a similar syntax for opt-out could be
>    report-uri 'no-events' <sites>;
>

Going opt-out would be a good reason to introduce a new keyword. I think I
prefer opt-out conceptually, as I think it's likely the general case.
Extensions that set a policy on a resource will (I suspect) be few and far
between. I don't think it's a good idea to require developers to remember
to ask for events. I'd rather place that burden on the few folks who
explicitly won't want them.

I think we should also leave room for implementors to simply do something
different when implementing an extension-set policy. There's no reason
extensions must have the same defaults as pages.


> When you describe this as an "event" do you mean a DOM Event conforming to
> the DOM Level 3 Events spec? Does that mean document.securityPolicy is a
> DOM Node somehow? Maybe we should target the document itself instead.


Suggestions are welcome. My vague plan was for the 'securityPolicy' object
to implement the EventTarget interface, but I'll happily defer to people
who actually know something about designing JS APIs. :)

-mike