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

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

From: Giorgio Maone <g.maone@informaction.com>
Date: Fri, 01 Aug 2014 06:49:57 +0200
Message-ID: <53DB1C75.3030806@informaction.com>
To: Daniel Veditz <dveditz@mozilla.com>, Philip S Constantinou <pconstantinou@evernote.com>, public-webappsec@w3.org
CC: mkwst@google.com, w3c@adambarth.com
FWIW, as an add-on developer (
https://addons.mozilla.org/en-US/firefox/user/giorgio-maone/ ) I
completely agree with the assessments expressed here by Daniel Veditz's.
-- G

On 01/08/2014 05:32, Daniel Veditz wrote:
> On 7/31/2014 6:24 PM, Philip S Constantinou wrote:
>> 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.
> The wording change is nearly meaningless and you should focus elsewhere.
> In the old text browsers "should not" interfere but were allowed to. The
> current text allows browser to interfere, but they "may" chose not to.
> With either wording the browser is free to interfere or not and be
> perfectly spec compliant.
>
> Both Google and Mozilla representatives have expressed strong support
> for the concept that add-ons represent the user and should not be
> interfered with. In practice that's a hard thing to achieve.
>
>> 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.
> There is no way for the browser engine to distinguish between script
> inserted by an add-on and script inserted by an attack. (It's also
> potentially insecure if a malicious page can manipulate your scripts.)
> Both Chrome and Firefox have features that allow extensions to run code
> in a separate context that can manipulate the page; in Firefox you want
> to check out evalInSandbox(). If you run scripts in this way they will
> not be blocked by CSP because we can distinguish use of that privileged
> feature from web content.
>
> Of course if that script tries to add remote content to the page
> (images, for example) those can still be blocked. I've got ideas on how
> we could fix that in Firefox but need someone to write the code.
>
>> 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.
> I share your belief.
>
>> 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.
> The specification is not the problem.
>
> -Dan Veditz
>
Received on Friday, 1 August 2014 04:50:24 UTC

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