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

I think extension mechanisms are quite implementation-specific - I don't object to discussing them on list, but I'm not sure that they need standardizing.   And new security UI associated with CSP is a third-rail I think we mostly all want to avoid.

I think flipping your idea might be appropriate: browser implementers could provide APIs for an extension to inspect and temporarily disable the CSP for a resource it wants to modify.

From: Eric Chen [mailto:eric.chen@sv.cmu.edu]
Sent: Wednesday, August 29, 2012 10:41 AM
To: Hill, Brad
Cc: Odin Hørthe Omdal; public-webappsec@w3.org
Subject: 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<mailto: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<mailto:eric.chen@sv.cmu.edu>]
Sent: Wednesday, August 29, 2012 10:29 AM
To: Odin Hørthe Omdal
Cc: public-webappsec@w3.org<mailto: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<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



--
-Eric