Re: SecurityPolicyViolation DOM events.

On Wed, Mar 20, 2013 at 2:12 PM, Mike West <mkwst@google.com> wrote:
> On Wed, Mar 20, 2013 at 2:14 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> 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. :)

I think we might want different task sources depending on where the
restriction occurs. E.g. sometimes it might not need to be queued if
fetching already queued a task to handle a certain thing for instance.
It depends a bit on what the implementation strategy is and how much
of that is observable (a lot I think if you look at the edge cases).


> 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).

The problem is that pages often end up depending on these orders even
though it's not meaningful at all which is why we should be careful.


> 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?

I think just as in implementations we'll end up with different hooks
for these (unless I'm missing something about how this will be
implemented). (We might even want different events if they're
fundamentally different.)


-- 
http://annevankesteren.nl/

Received on Saturday, 23 March 2013 19:29:47 UTC