W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2013

Re: SecurityPolicyViolation DOM events.

From: Mike West <mkwst@google.com>
Date: Wed, 20 Mar 2013 15:12:26 +0100
Message-ID: <CAKXHy=fG9CfJVgTQ+GfrCLLM_YqpuvqxtfUducVhMJ2sVjLjrA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "dveditz@mozilla.com" <dveditz@mozilla.com>, Adam Barth <w3c@adambarth.com>, "Hill, Brad" <bhill@paypal-inc.com>
On Wed, Mar 20, 2013 at 2:14 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Mar 19, 2013 at 10:29 AM, Mike West <mkwst@google.com> wrote:
> > I've updated the spec in
> > https://dvcs.w3.org/hg/content-security-policy/rev/06d7091e7531 and
> > https://dvcs.w3.org/hg/content-security-policy/rev/5ad7f5b58dc0.
> Hopefully
> > that makes things a little less vague and strange. Thanks again, Anne,
> for
> > the pointers!
>
> So it's completely unclear when this event is dispatched.


I'll add some of this detail, thank you again.


> What task source is used,


The DOM manipulation task source seems like a reasonable fit. I don't think
it's worthwhile to mandate the creation of a new task source, given that I
don't anticipate much practical effect (see the next point): I've made this
change in https://dvcs.w3.org/hg/content-security-policy/rev/52bc48987fa0.
If it's a terrible idea, I'm happy to revert. :)


> how does it relate to other events that fire when the violation occurs,
> etc.
>

My intention is for these events to serve as fire-and-forget notifications
that something on the page ran afoul of the active policy. I assumed that
queuing a task to fire the event would make it clear that they're
explicitly asynchronous, and that the ordering of the event in relation to
other events was indeterminate (or, at least, not meaningful).

I have the feeling the right long term solution is tight integration
> with http://fetch.spec.whatwg.org/ to solve problems such as this. I
> don't have an immediate suggestion on how to fix this, but I think we
> should at least point out in the specification that this is not
> considered.
>

Hooking into the fetch specification seems like a reasonable option for a
lot of cases, but doesn't match other well; for instance, inline script or
style (or blob:/filesystem:) aren't fetched. How would you suggest that we
proceed?

-mike

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Received on Wednesday, 20 March 2013 14:13:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC