Can't navigate on pages with a Content-Security-Policy response header.

[duhrer]

On Chrome Web Store pages such as our own listing, the extension isn't injected, so we can't control the page. We need to figure out what the limits are here and exclude additional sites using our filterControllableTabs method.

If we can find documentation on the fact that extensions don't work in the Chrome Web Store, that would be a good start.

We should also see if variants (Brave, Edge, etc.) have their own storefronts with their own issues.

[duhrer]

I can't see that any other extension content is injected there, for now I've added a check to count web store pages as "uncontrollable" to avoid navigating there.

[duhrer]

Brave uses the Chrome Web Store. Opera has its own site, which also appears to not allow extensions.

Edge has its own site, the extension doesn't work for the extension-related parts, but does work on other parts of the same site. I'm looking at the response headers for a clue about how/why a site indicates that extensions aren't allowed.

[duhrer]

Turns out all of these pages have a Content-Security-Policy response header that disallows injecting code. In hindsight, this also explains why we can't control browser internal pages, which also return this request header.

I can see that there ways of bypassing this, as outlined in this stackoverflow post. In short, we can add rules to rewrite the headers and either strip the CSP headers or (hopefully) add rules that allow our code to run.

IMO we should not strip CSP headers, but I would be less concerned about adding our code to the headers for sites that have a restrictive policy, as the benefits are fairly high. Suddenly even browser internals like settings would be navigable.

This should be tested in detail on a side branch and reviewed as its own thing.

[duhrer]

Looking at the declarativeNetRequest documentation, they allow setting and removing headers, but not appending them (which is what I'd have preferred).

My best guess is that we would have to remove the existing headers and ideally replace them with the defaults plus ourselves.

I'd like to try making the permissions optional if possible, once we get anything working, that's something to try.

[duhrer]

On a hunch, I confirmed that the built-in "new tab" also has a Content-Security-Policy header. This explains so much.

[duhrer]

I tried a bunch of things, and was finally at least able to modify some headers some of the time, but was never able to consistently confirm that my ruleset was being applied to relevant traffic when loading the chrome web store.

Even on pages where I could see that the ruleset was being applied, there was no change in behaviour. However, it's hard to say what's happening. I can see that the plugin is manipulating request headers, but don't see any change in the response headers. This is the same behaviour I see when trying every one of the example extensions I found.

It may be that there is an effect, which the developer console isn't showing me. It may also be that there's no effect because I need to get more specific about which hosts I care about. It may also be that there's no effect because they intentionally make it next to impossible to change CSP headers.

I'm going to hold off on this for now until I encounter something that makes me think there's a hope of getting this to work.