W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2014

Re: [CSP] Request to amend bookmarklet/extensions sentence in CSP1.1

From: Glenn Adams <glenn@skynav.com>
Date: Sun, 3 Aug 2014 11:10:32 -0600
Message-ID: <CACQ=j+di7MXE1JTEN=uOLBEmUwwpQ41t6e4JrQ7XTmUib0S3Yg@mail.gmail.com>
To: Philip Constantinou <constantinou@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Adam Barth <w3c@adambarth.com>, Daniel Veditz <dveditz@mozilla.com>
On Thu, Jul 31, 2014 at 7:30 PM, Philip Constantinou <constantinou@gmail.com
> wrote:

> Dear W3C CSP working group -
> Evernote voices our strong opposition to the wording changes regarding
> extensions and bookmarklets in CSP1.1 and our strong support of
> http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0061.html.
> Evernote provides a free web service to over 100 million users world wide.
> We also provide browser extensions for Google Chrome, Safari, Internet
> Explorer and Opera in addition to bookmarklets which are used on other user
> agents. Additionally, we have ongoing development efforts on several mobile
> browsers.
> For example, the Evernote Web Clipper for Chrome is a top rated free
> extension installed by over 3.4 million users.
> We've built these extensions for the express purpose of allowing users to
> capture and mark up content they find on the web. To create a great user
> experience, our extensions insert JavaScript into the viewers page upon
> user request. This mechanism risks being broken by the vague
> extension/bookmarklet wording change proposed in CSP 1.1.
> We strongly believe that users should be allowed to control their own
> experience on the web through a choice of browser and the use of browsers
> extensions. Changing the CSP specification in a way that limits browser
> extensions operates counter to the needs of users and limits companies like
> ours from making the web better for everyone.
Since it was I, representing member Cox as well as the Television industry
that requested the original change, I must state that there is no
disagreement about the desire to allow users to control their own
experience of the web. We also agree in that desire. Further, we have no
issue against browsers providing support for 3rd party add-ons and
extensions that may modify a user's experience of web content.

However, in order to do this in a way that protects the user, we feel there
have been some shortcomings in the ways that UAs have treated add-ons and
extensions. We note that there are legitimate reasons to deny use of some
or all add-ons and extensions, including, e.g.:

   - uses on public or shared devices;
   - uses in the context of potentially malicious or compromised
   - uses in the context of heterogeneous user desires, such as user
   wishing to allow add-ons and extensions in some browsing contexts but not
   - uses where an add-on/extension may inadvertently interfere with the
   user experience of the web in a manner undesirable to the user or in
   violation of a user's agreements of use of some service;

We also recognize the problem associated with excessive policy violation
reporting traffic that may result from simple application of CSP to add-ons
and extensions.

In order to make add-ons and extension safe for use by users and provide
the flexibility needed for users to control that use, we believe UAs need
to move beyond a simple policy of ALLOW ALL or DENY ALL when it comes to
the application of CSP to add-ons and extensions.

This means that UAs need to evolve a more sophisticated treatment of
add-ons and extensions, and, in doing so, need the freedom to choose
whether to allow an add-on or extension to run despite CSP or to be subject
to CSP, as well as freedom to determine when to send policy violation
reports. This is precisely the reality reflected by the new language, which
effectively makes the specification neutral to the eventual policy adopted
by UAs.

Over time, as UAs evolve their treatment of add-ons and extensions in the
face of CSP, then it is possible to go further than the current informative
language, but at this time, multiple UA vendors have agreed with the
proposed language and believe it gives them the freedom to evolve their
support as desired.

> Thank you for your consideration -
The WG has already considered this issue carefully, and no new input has
been presented that would argue for re-opening the WG decision. To quote
Dan Veditz "the specification is not the problem". It would be better for
you to work with UA vendors directly to ensure your needs are met while
simultaneously addressing the issues mentioned above.

Glenn Adams (for Cox Communictions)

> Philip Constantinou
> VP of Products
> Evernote
> remember everything
> ps. Sending this from my personal email address because the w3.org
> emailing list says evernote.com is blacklisted.
Received on Sunday, 3 August 2014 17:11:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC