- From: Mike West <mkwst@google.com>
- Date: Mon, 15 Oct 2012 11:44:19 +0200
- 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>
- Message-ID: <CAKXHy=dVXQTHKx7KkV0y2E9r3VpgEYn-ckUtCD6HVzVZ9EVicA@mail.gmail.com>
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 UTC