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

On 29/08/2012 19:40, David Lin-Shung Huang wrote:
> Yeah, perhaps ad might use CSP to disable DNT extensions..?

And malware would love CSP to disable NoScript :)

Jokes aside, I'd say Chrome's and Firefox's current approach of
assigning extensions a privileged origin which can't be messed with by
web content (using CSP, in this case) is the sanest way to go to
preserve user choice.

Then if an extension does something (possibly stupid) which involves
embedding 3rd party web content in a CSP-secured web page, I believe
that content should be subject to CSP: if the content is really critical
to the extension, its authors can always take the additional step of
packaging it with the extension itself.

By the way, remote JavaScript execution and/or injection is explicitly
forbidden by Mozilla's add-ons "marketplace"'s policy, and extensions
doing that are rejected by AMO editors
(https://wiki.mozilla.org/AMO:Editors/EditorGuide/AddonReviews#Policies_and_Actions_3
)

-- G

On 29/08/2012 19:40, David Lin-Shung Huang wrote:
> Yeah, perhaps ad might use CSP to disable DNT extensions..?
> 
> On Wed, Aug 29, 2012 at 10:37 AM, Adam Barth <w3c@adambarth.com
> <mailto:w3c@adambarth.com>> wrote:
> 
>     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
>     <mailto: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 <mailto: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 18:22:56 UTC