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

Re: [CSP] Extensions and user script? (Some feedback)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 29 Aug 2012 10:37:30 -0700
Message-ID: <CAJE5ia9AP+J+JXiAjy8=ucUMtw5mLcCa7JoaENUhoi3Lg8s2aw@mail.gmail.com>
To: Eric Chen <eric.chen@sv.cmu.edu>
Cc: Odin HÝrthe Omdal <odinho@opera.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
http://www.schemehostport.com/2011/10/priority-of-constituencies.html

On Wed, Aug 29, 2012 at 10:29 AM, Eric Chen <eric.chen@sv.cmu.edu> wrote:
> I'm not sure if this idea has been discussed before, but why not have a CSP
> policy that disables extensions? Disabling extensions entirely is probably
> better than half-breaking extensions.
>
>
> --
> -EC
>
>
> On Wed, Aug 29, 2012 at 4:34 AM, Odin HÝrthe Omdal <odinho@opera.com> wrote:
>>
>> Hello all :-)
>>
>> I've gotten some internal web site author feedback trying to implement CSP
>> on a web email service that I'd like to share and discuss.
>>
>> There's of course a few minor things that will get better with time. Like
>> browsers using prefixes and different implementations of different
>> versions of the spec. As well as some potential bugs found, such as using
>> an same-domain iframe with an email in it, and then rewriting links
>> therein to do target=_blank, and it was suddenly blocked. They had to open
>> up frame-src: * in order for the links to open. From my cursory reading of
>> the spec, it does seem like this is in fact intended behaviour, but I'm
>> not sure.
>>
>> The biggest problem however is the interference of pages' CSP policies
>> when an extension goes mucking around the page doing whatever it likes to
>> do.
>>
>> This is not the same as having a CSP-profile on the extension, as Chrome
>> is doing, but the other way around:
>>
>>> Extensions can
>>> inject arbitrary javascript, css into the page and modify the DOM in any
>>> way. Depending on the CSP policy, those will potentially be blocked. The
>>> most annoying thing is that those might break your extension or the page
>>> in subtle ways because some things the extension does work (DOM
>>> manipulations), but other things fail (scripts/css injection).
>>> Additionally changes that do fail will generate heaps of false positive
>>> feedback reports, making the reporting feature a pain to sift through
>>> and work out "now is this a problem with my CSP poilicy, or is it some
>>> extension the users installed that's trying to modify the page in some
>>> way".
>>>
>>> I don't see any realistic solution to this. You'd have to track a whole
>>> bunch of manipulations and changes to the DOM as either "done by the
>>> page" or "done by an extension" to work out if they should be allowed or
>>> not.
>>>
>>> So at first I thought "what a great idea", but after two days of messing
>>> around and actually trying to use it, I decided that it might be
>>> bordering on unuseable in the real world
>>
>>
>>
>>
>> I have not looked into it myself, but this is a very valid concern if we
>> were to implement it in Opera. What have you that have implemented this
>> already done about it? How does it work? Is really extensions crippled in
>> such a way, do they have to think about it?
>>
>> --
>> Odin HÝrthe Omdal (Velmont/odinho) ∑ Core, Opera Software,
>> http://opera.com
>>
>
Received on Wednesday, 29 August 2012 17:38:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 August 2012 17:38:31 GMT