Re: [webappsec] POLL: Getting CSP 1.1 to LCWD

I agree that CSP should say nothing about addons, with the following caveat. When the issue was originally raised about CSP implementations affecting addons, CSP was intended to not affect contents' TCB but it was not immediately clear how to express that in a theoretically pure manner. The reference to addons was added as a practical matter, and while theoretically impure, it was close enough to convey the goal of CSP. Until now. Should a theoretically pure yet practical way to spec this goal for CSP appear, it should supplant the statement about addons entirely.

I did not properly convey the full meaning of my usage of 'restricting the user agent', based on your citing of Section 3.3. Section 3.3 discusses an entirely different nature of restriction than the one I meant. Please allow me to rearticulate.

The CSP spec restricts the user agent in such a way to enable content to be self-limiting; that is, enable the content to instruct the user agent to restrict the content itself. With CSP, contents' restrictions are self-inflicted. This is intended to allow content authors to protect users against exploits of any flaws that reside in the content itself. The prime example of a reason to do this is content authors practicing defense in depth. The user agent's TCB does not affect the needs of CSP, and so CSP restrictions stop there. Implementing CSP requires neither DRM, nor hardware root of trust, nor malware protection (antivirus). The act of spec'ing CSP requires neither participants versed in DRM, nor regional regulatory participation, nor malware protection (antivirus) vendor participation.

Item 6 restricts the user agent in such a way to enable content to limit the contents' TCB; that is, enable the content to instruct the user agent to restrict the user agent itself. With item 6, contents' restrictions are inflicted upon the user agent. This is intended to allow content authors to protect content against users. Your given examples of reasons for doing this include legal restrictions (emergency alert), contract enforcement (subscription terms), or poor user choices (naive users installing malware or malicious addons). Because the user agent's TCB violates such a spec (eg user agent addon hiding the fact that the content requested the user agent to restrict the user agent), the restriction applies to the user agent's TCB. In fact, it applies recursively to each layer of the content's TCB, all the way down to hardware. Implementing item 6 requires DRM, hardware root of trust, malware protection (antivirus), or all three. The act of spec'ing item 6 requires participants versed in DRM, regional regulatory participation, and malware protection (antivirus) vendor participation.

Despite both CSP and item 6 restricting user agents, the nature of the restrictions are very different. The concerns of implementing them, spec'ing them, are very different. I argue that the concerns are in fact different enough that CSP and item 6 must not co-exist on the same deliverable (document).

Expanding upon my proposal of discussing item 6 as a hypothetical new document, a title of "User Agent Security Policy" may work. The title alone may help convey the difference between this and CSP: "Content Security Policy" restricts content, "User Agent Security Policy" restricts user agents.

Additionally, this hypothetical document may serve as a home for other similar client integrity requests, such as PayGate's request for standardized antivirus/antimalware attestation. In fact, you may wish to ask PayGate if they will assist you in drafting such a document.

Ultimately, such a document needs to have a home. I encourage you to pitch your proposals as this hypothetical new document to this working group. That said, the WebAppSec Chair has already stated earlier in this thread that the topic is beyond the charter of this working group; you likely will need to find a different area within the W3C to pick this up.

----

On Tue, Oct 1, 2013 at 3:36 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

On Tue, Oct 1, 2013 at 3:02 PM, Carson, Cory <Cory.Carson@boeing.com<mailto:Cory.Carson@boeing.com>> wrote:
I respectfully maintain the position that item 6 is out of scope for CSP. I recognize that your proposals bring legal, user safety, or PoC benefits for some actors in some situations, and I maintain my position that the discussion be framed in the context of a hypothetical new document added to the working group's scope.

If CSP said nothing about add-ons, then it would be better than what is there now. What is *in* CSP now:

"Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets."

Brings the subject of add-on behavior in scope by itself. Suggesting that a hypothetical new document take up these processing semantics in more depth seems a very strange suggestion.

Considering your suggestion (of a new document) a bit more, I could accept that approach if the above language was struck from both CSP 1.0 and 1.1, and this new hypothetical document took up the matter of normatively defining behavior surrounding add-ons/extensions, including the possibility of defining new directives used in this context.

--snip---

Pardon me, but Section 3.3 Processing Model [1] says:

"To enforce a CSP policy, the user agent must parse the policy<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#parse-a-csp-policy> and enforce each of the directives contained in the policy, where the specific requirements for enforcing each directive are defined separately for each directive (See Directives<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#sec-directives>, below)."

If this isn't a restriction on the user agent, then I don't know what is. Any normative statement of what a user agent "must" do is a restriction on the user agent.

[1] https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#processing-model