Need MV3 host_permissions to set Access-Control-Allow-Origin header?

[ghucz...@gmail.com]

Hi there

Looking for advice/sanity check on a manifest v3 upgrade.

I have an extension which grabs and saves all images from the current web page.

I hoped I could reduce my broad mv2 host permissions (http://*/* and https://*/*) by using mv3 declarativeNetRequest.

The extension currently loads+saves images from the background script, which is unaffected by CORS. I need the broad host permissions, as I don't know which web page the user will save images from, and where those images are located.

With mv3, I could use a declarativeNetRequest dynamic rule to intercept image requests from the user's current web page, and set Access-Control-Allow-Origin=* on the response. I could then make image requests from a content script on that web page with image.crossOrigin="Anonymous" - passing all CORS checks - and so save all page images from the content script itself (not the background script).

This solution seemed great until I read this in the declarativeNetRequest docs: "[declarativeNetRequest] allows extensions to block and upgrade requests without any host permissions. Host permissions are still required if the extension wants to redirect a request or modify headers on it".

So does my declarativeNetRequest approach _still_ need broad host permissions to set the 'Access-Control-Allow-Origin' header? I still won't know all the image origins I might fetch from. In which case there is no value in doing this, every though I feel the new approach is a better (and more constrained) expression of what the extension actually does.

Many thanks

Greg

[Simeon Vincent]

So does my declarativeNetRequest approach _still_ need broad host permissions to set the 'Access-Control-Allow-Origin' header? - Greg

Yes. You quoted the exact line of text from the docs that I would have. Simple modifications, like upgrading from HTTP to HTTPS or simply blocking a request don't require host permissions, but potentially dangerous operations (like modifying request headers) do. 

If you really wanted to tamp down on the permissions that your extension requests, you might want to consider whether you could accomplish your goals using the activeTab permission. Using this permission, you can react to user invocation by injecting a content script into the page that finds the images you wish to download. 

Simeon - @dotproto

Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b4397438-0a51-41b6-a3e8-40301adbc430n%40chromium.org.

[ghucz...@gmail.com]

Hi Simeon, and thanks for the response.

I actually already do what you suggest, and work within the confines of the activeTab permission: the “save images” content script is only injected into the currently active web page when the user clicks the extension button. 

So is “activeTab” + broad host permissions considered less risky?

Greg

[Simeon Vincent]

There's no point in requesting activeTab if you are also requesting broad host permissions. activeTab only grants temporary host permissions when the extension is invoked. 

Simeon - @dotproto

Chrome Extensions DevRel

[Gregory Huczynski]

Aaaah, an interesting quote from the activeTab docs: "The extension temporarily gets host permissions for the tab's main frame origin.”

So are you saying that I might be possible to do away with broad host permissions, if I can work within the confines of the host permissions the active-tab web page, which my extension would inherit?

Greg

[Simeon Vincent]

Yep, sounds like you've got it :)

Simeon - @dotproto

Chrome Extensions DevRel

[Gregory Huczynski]

Hi Simeon - quick question before I seriously explore the activeTab idea.

Re activeTab "The extension temporarily gets host permissions for the tab's main frame origin”.

Does this mean that the extension gets permission 1) _only_ to the origin of the main frame, or 2) _all_ origins that are accessed in assembling the main frame webpage?

So for a main frame web page url of https://www.example.com/hello, which loads images from https://somecnd.com/hello.png.

Option 1 means the extension has access only to example.com origin

Option 2 means the extension has access to both example.com and somecdn.com origins

I’m hoping option 2. If the answer is option 1 (only frame origin), this makes activeTab constrained and far less useful. That would mean the extension would have _less_ host permissions than the active-tab web page itself.

Thanks

Greg

[Simeon Vincent]

Does this mean that the extension gets permission 1) _only_ to the origin of the main frame, or 2) _all_ origins that are accessed in assembling the main frame webpage?

Option 1: only the origin of the main frame. Sub-frames are not exposed. 

If the answer is option 1 (only frame origin), this makes activeTab constrained and far less useful. That would mean the extension would have _less_ host permissions than the active-tab web page itself.

This is incorrect because the extension can inject scripts into the page, which means that at that point it can do anything that the page itself can do. You just can't use extensions APIs to interact with those other origins. I agree, though, that the restriction to only operating on the main frame's origin can be  frustrating.

The basic problem is that when the user invokes an extension on a given page, that's a clear signal that they want to do something on that page, so we can grant access to the page itself. But if a user invokes the extension on a page with, say, social media sharing widgets, it's not clear that the user also wants to grant the extension access to all of those social media sites as well. Inferring intent in these situations is tricky, so we err on the side of protecting users.

Simeon - @dotproto

Chrome Extensions DevRel

[Gregory Huczynski]

Hi Simeon - thanks for the clarification. I’ll do some digging, but - based on exploration I’ve done so far - I don’t think my “save all page images” will work with just activeTab in its current state.

I take your point re “the extension can do what the page does with injected content scripts”, but for the image-saving case, the extension needs more capability than what the page itself can do. Specifically for images, a page can load images from third party origins and display them, _but_ it cannot access the image content as it’s considered “tainted”. So an extension content script runs into exactly the same problem - you can fetch the image, but you can’t do anything with the image data, so you can’t save it (unless you add the Access-Control-Allow-Origin=* header on the image response).

I was hoping I could fall into the “pit of success” here - a phrase I’ve heard re manifest v3 - but it seems I’m bumping into a wall. I’ve a use case that doesn’t fit into activeTab alone and will require broad host permissions that I don’t really want.

I wonder if there’s a feature request that can be made from this use case, like being more nuanced on extension access to origins accessed in rendering web pages - are all origins alike?

I take the point that current activeTab capability is erring on the side of protecting users, but it kind-of isn’t if it leads me (and other developers?) to request far broader host permissions than necessary.

Cheers

Greg