Re: SecurityPolicyViolation DOM events.

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!

Currently we're defining the properties of reports twice; I'll eventually
extract that out to some common definition. For the moment, however, I've
relaxed some of the requirements for the JavaScript events. I'm not sure it
makes sense to strip out fragment data when it's trivially accessible via
JavaScript, for example. Discussion of exactly what the requirements should
be would be appreciated; on the one hand, I'd like to give JavaScript as
much information as simply as possible. On the other, it seems a bit
strange to strictly lock down what CSP itself can POST while giving
JavaScript free reign to do whatever it likes with the data. I think that's
a defensible position, insofar as we have to trust the developer to do the
right thing with their own data, but I expect others will have different
opinions. :)

Thanks!

-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


On Tue, Mar 19, 2013 at 12:33 PM, Mike West <mkwst@google.com> wrote:

> Thanks, Anne. That's extremely helpful.
>
> I'll take a pass at both of those this afternoon.
>
> -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
>
>
> On Tue, Mar 19, 2013 at 12:12 PM, Anne van Kesteren <annevk@annevk.nl>wrote:
>
>> On Tue, Mar 19, 2013 at 6:22 AM, Mike West <mkwst@google.com> wrote:
>> > In https://dvcs.w3.org/hg/content-security-policy/rev/0c7cb63e2e48,
>> I've
>> > stubbed out an initial pass at a SecurityPolicyViolationEvent
>> interface. I'd
>> > appreciate some feedback on both the content and the language used to
>> > describe it. I tried to steal context from other specs, but none really
>> did
>> > exactly what I wanted. Ah well.
>>
>> Event.cancelable is already false by default so you don't have to say
>> that. You also need to initialize all the other members. See
>> http://xhr.spec.whatwg.org/#concept-event-fire-progress for an
>> example.
>>
>> You also need to define an event constructor, see
>> http://xhr.spec.whatwg.org/#interface-progressevent for an example.
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>
>