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

[Oops, I totally forgot this email that's been lying around. I probably
wanted to shorten it, but I'll just send it as-is. :D ]

On Wed, 29 Aug 2012 14:13:19 +0200, Mike West <mkwst@google.com> wrote:

> It is a problem (though I certainly don't consider it fatal), and I  
> haven't
> yet seen a truly effective approach to avoiding it completely.
>
> In Chrome, we've addressed it to a limited extent by bypassing CSP
> checks[1] for resources that come from the 'chrome-extension:' and
> 'chrome-extension-resource:' schemes. This means that extensions  
> injecting
> only _their own_ resources will be more or less unaffected by a page's  
> CSP
> directives (with the notable exception of 'sandbox', 'unsafe-inline' and
> 'unsafe-eval'). The experimental 'script-nonce' directive might be a
> mechanism for whitelisting extension's inline scripts as well.

That seems like a good way to solve a bit of the problem. Although I can
think of places where the sandbox could make life hard for some extensions.

> We don't have a good solution for extensions that want to inject  
> resources from third party servers. Images are the biggest issue here.
> For the moment, we're not planning on undertaking the (large) amountof  
> work that would be necessary to support the use case.
>
> As an aside, this problem was actually an issue for WebKit's devtools as
> well, as it uses `eval` to inject code from the console into the page's
> context. There, they've done some tricky work to enable `eval`, run some
> code, and then disable `eval` again.

OK, and that's where things are most interesting. User JS (scripts running
at the page, "greasemonkey" in Firefox) would seem to be broken by this.

Also some extensions, like e.g. an OpenStreetMap extension that shows a
map next to addresses (or similar). What would the behavior for that
extension be on a web site that has CSP? E.g. disabling image loading from
other sites would break it.


The easiest way out might be to just disable CSP for the site if an
extension wants to inject a userscript into it. I think it's a very bad
idea to cripple extensions.

Current browsers send violation reports based on these "violations".
That's noise. Our internal webdev team didn't like it because of the false
positives they got due to extensions. I would guess in a real-world
setting it'd quickly feel like fighting spam today. You have to go through
lots of noise in order to find something actually useful.

Another dimension is the privacy issue. Your browser is effectively
leaking information about what extensions you've got installed. Or maybe
even your private hash if the extension does a GET with that security
token in the URL. I would guess that can be easily exploited other ways
too and such an extension would be considered badly written, but the main
issue of reporting still stands.


These issues can arguably be said to be just a matter of implementation,
but the spec has to be implementable, and it would make sense for us to
actually think about what problems it's going to cause.

I guess quite a lot of extensions will get broken by this. Thankfully few
websites use CSP right now, but having extensions break is a rather
drastic step to take.


It might hurt CSP if the _real_ implementation cost is too high for anyone
to prioritize it. In two ways I can see:

If I'm doing a good-guy website, I won't really be able to use CSP because
it might interfere with my users' extensions. I don't want that.

And me, as a user, would probably just turn the whole of CSP off if it
breaks my extensions/userscripts. :-)


So, more thoughts? Is external images really used so little that noone  
will really feel any impact on it? Are we not worried about giving CSP a  
bad name/reputation? Will writing extensions be made harder by this?

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Received on Tuesday, 25 September 2012 14:43:57 UTC