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

Thanks!

On Tue, Sep 25, 2012 at 4:41 PM, Odin Hørthe Omdal <odinho@opera.com> wrote:

> On Wed, 29 Aug 2012 14:13:19 +0200, Mike West <mkwst@google.com> wrote:
> 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.
>

Indeed. Sandboxing is tough to get around. We've punted on it for the
moment.


> 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.
>
>
This has changed slightly in the last week or so. It might be possible to
allow resources injected from an extension's context without massive
effort. That work is underway at
https://bugs.webkit.org/show_bug.cgi?id=97398 if you'd like to follow along.

It's something I'd like to see fixed, and I'm hopeful that we'll be able to
make it work.


> 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.
>

Yes, without some work on the browser's part, this use-case breaks. We're
trying a few things to enable it; I think it's important.

Rather than disabling CSP for a protected resource, a less insecure idea
might be to create an API that would allow extensions to add sources to the
page's policy (of course, in a way that wouldn't show up in violation
reports). I believe some sort of delegation mechanism similar to that has
been proposed as an addition to the DOM feature-detection API that's
currently experimentally specified in CSP 1.1.

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.
>

Reporting is an issue I'd very much like to resolve. I'm less concerned
about detectability, simply because any extension that modifies the DOM is
detectable (MutationObservers, brute force scanning, etc).


> 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 hope (believe!) that the efforts underway in WebKit/Chromium will prove
that this section of the spec is implementable.

-mike