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

Yeah, perhaps ad might use CSP to disable DNT extensions..?

On Wed, Aug 29, 2012 at 10:37 AM, Adam Barth <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> 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
> >>
> >
>
>