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

What if we use a UI similar to mixed content, where we let users to
re-enable their extensions.

On Wed, Aug 29, 2012 at 10:33 AM, Hill, Brad <bhill@paypal-inc.com> wrote:

>  Extensions run with the intent and at the behest of the user.****
>
> ** **
>
> In a conflict between user intent and resource policy, user intent wins.**
> **
>
> ** **
>
> *From:* Eric Chen [mailto:eric.chen@sv.cmu.edu]
> *Sent:* Wednesday, August 29, 2012 10:29 AM
> *To:* Odin Hørthe Omdal
> *Cc:* public-webappsec@w3.org
> *Subject:* Re: [CSP] Extensions and user script? (Some feedback)****
>
> ** **
>
> 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****
>



-- 
-Eric