Re: CSP formal objection.

On Wed, Jan 29, 2014 at 5:03 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Glenn Adams wrote:
> >You appear to believe in a static, monolithic model of user intent. A
> >simple model, such as always ignore or always enforce CSP policy with
> >respect to an extension/addon installed by some (not necessarily the same)
> >user, is inadequate to address practical concerns. UA vendors appear to
> >recognize this, and need the flexibility to find an appropriate balance
> >based on a combination of dynamic interests.
>
> The requirement is in the CSP 1.0 CR and the CSP 1.1 WD because they are
> specifications for user agents, and user agents should not let web sites
> interfere with user agent operations that users have configured, other-
> wise they would not be user agents and would implement CSP incorrectly.
>
> The requirement does not mention anything about "static" or "monolithic"
> or whatever else you might read into it. There is no basis, that I can
> see, for making CSP implementations that enforce CSP policies in manners
> that grossly interfere with user agent operations unconditionally com-
> pliant with the user agent requirements of the CSP specifications. That,
> however, is the effect of removing it without proper replacement.
>
> It is quite possible that the first generations of implementations have
> some limitations with respect to the requirement, and some might need to
> adapt, for instance, their extension mechanisms to take CSP policies in-
> to account; the current phrasing of the requirement takes that into
> account adequately, while also making the intent clear enough.
>
> It would be rather harmful if the specification could be interpreted as
> if CSP policies could be used to attack the user like by allowing sites
> to disable assistive technologies the user might rely on.


I find it rather unproductive to talk about "CSP policies ... used to
attack the user". It is better to have a longer term discussion about how
to adequately model a user's intentions and how browsers can accommodate
those intentions while simultaneously permitting CSP policies to be
respected.


> The require-
> ment fortunately makes it clear that if sites could do this, and there
> is no alternate way to implement the same functionality available, then
> the fault is with the CSP implementation. I do not see how there is any
> need for more "flexibility" in scenarios like that.
>

Flexibility could translate to a variety of user preferences or
interactions that can be used to fine tune how CSP policy applies. There
are a wide variety of technical options open to browser vendors without
resorting to an "always enforce" or "always ignore" application of CSP
policy to extensions/addons. In any case, the consensus appears to be that
browser vendors should drive this process. In the longer term, if a
majority of browsers choose the same implementation, then perhaps it can be
documented by the specification.