RE: [webappsec] new draft of UI Security available

Anne, thanks.

New update at:

https://dvcs.w3.org/hg/user-interface-safety/raw-file/7128910baa5c/user-interface-safety.html 

> From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On
> Behalf Of Anne van Kesteren
> 
> It's not really clear to me what you mean here. "partial" is an extension by
> definition. A "partial UIEvent" is lacking to define the unsafe property.
> 
>

I added the UIEvent partial and a ref in the Script Interfaces the base CSP 1.1 interfaces.  I hope that clarifies it somewhat?  My question is does it make more sense to define the additional properties as I have done, e.g.:

partial interface SecurityPolicyViolationEvent : Event

or as:

interface UISecurityPolicyViolationEvent: SecurityPolicyViolationEvent

> I noticed "blocked-target-xpath". It's not really clear to me we want to add a
> dependency on XPath. We don't have that anywhere else. And in fact this is a
> new kind of requirement, where you have a node and want to generate a path
> to it, which is something we have nowhere as far as I know.

This is to allow the recipient of a violation report to determine what element triggered the violation - what was the target of the blocked click.
I don't think this adds any significant implementation complexity to the user agent side since, as the example code shows, it can be done rather simply using the standard DOM Level 2 Core bindings already available.  I also believe similar functionality might already be available in many user agents, e.g. as part of developer tools that show the list of parents (though perhaps not directly in XPath format) leading to an element when it is selected.

The only complexity would be, I think, for servers processing such reports to take this XPath and compare it against the source text to identify the target.  Certainly that is optional - report recipients are free to ignore any fields they wish.

> In general this specification lacks a model. There's a bunch of features and
> descriptions of them, but it is not exactly clear where they matter in an
> implementation.

Can you provide a little more constructive assistance here?  The assumption is that these are additional directives in the context of an existing implementation of CSP, so much of the processing model is assumed to apply from that.  Is that the issue, or something else?

Received on Monday, 25 March 2013 22:44:01 UTC