W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2012

Re: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky

From: Mike West <mkwst@google.com>
Date: Mon, 15 Oct 2012 11:44:19 +0200
Message-ID: <CAKXHy=dVXQTHKx7KkV0y2E9r3VpgEYn-ckUtCD6HVzVZ9EVicA@mail.gmail.com>
To: Fred Andrews <fredandw@live.com>
Cc: Thomas Roessler <tlr@w3.org>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Boris Zbarsky (bzbarsky@MIT.EDU)" <bzbarsky@mit.edu>
Hey Fred, thanks for following up!

For the most part I agree with Dan's response. I'll simply add one or two
points inline.

On Sun, Oct 14, 2012 at 12:46 AM, Fred Andrews <fredandw@live.com> wrote:

> It is not clear that browser vendors have demonstrated a solution to
> making CSP 'not interfere' with UA extensions, and thus CSP many be
> internally inconsistent.  The sentiment communicated to me suggested the
> interpretation of 'not interfere' does not consider leakage of the state of
> the extension as interfering which would be disturbing.
>

Blocking extension functionality is certainly something that the spec
addresses, stating pretty clearly that UAs shouldn't allow a protected
resource's policy to interfere with things like extensions. The spec isn't
the issue here; if there is an issue, it's with implementation. I don't
think that's something that should block moving to CR. In fact, poking at
implementations is the entire purpose of CR. :)

Regarding implementation, this is something that browser vendors are
actively working on. Off the top of my head, Chrome allows extension
resources (those loaded via 'chrome-extension://*') to bypass a page's
policy, and we're working on allowing resources injected by content scripts
to do the same (see https://bugs.webkit.org/show_bug.cgi?id=97398 for
example). These changes are incidentally laying the plumbing for other
WebKit-based browsers to do the same.

What would you like to see beyond that?

To the extent that rejection of issue 11 and related matters were due to
> the claim that a server could covertly acquire the information from the UA
> anyway, I would like this reason to be on record and I do not believe using
> this as an excuse does the WG any credit.  The PUA Community Group is
> working to close some of the leaks and this may well require CSP behavior
> to be modified and lead to incompatibility.
>

I'm interested in the PUA group's suggestions. It's a tough problem.

For the moment, I'll simply point to the previous discussion for two
points: 1) if a site wants to detect an extension like AdBlock, it has
better methods at its disposal than CSP (Mutation Observers and brute-force
DOM scraping to name a few), 2) The lack of an expected CSP report is as
much a signal as reception of an unexpected CSP report.

I will follow up with a more coherent and complete response as soon as
> possible.
>

Looking forward to continuing the conversation in more detail. :)

-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
Received on Monday, 15 October 2012 09:45:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 15 October 2012 09:45:11 GMT