PSA: Dynamic URL support in Chrome 130

985 visninger
Gå til det første ulæste opslag

Oliver Dunk

ulæst,
9. okt. 2024, 08.52.429. okt.
til Chromium Extensions
TLDR: Starting in Chrome 130, we will enable support for the `use_dynamic_url` property on entries under the `web_accessible_resources` key in the manifest.

Hi all,

If you’re not already familiar, `use_dynamic_url` is a feature we proposed early in the development of Manifest V3. This is an opt-in way to protect users from fingerprinting across the web.

This was mentioned in our documentation in the early stages of the Manifest V3 transition but support was not ready in Chrome, and the setting was gracefully ignored. We are now enabling support for that setting starting in Chrome 130.

How it works

Any content in an extension package can be made accessible to websites by using the `web_accessible_resources` key. Resources are then accessible to the website at a known and predictable URL:

```
chrome-extension://<EXTENSION ID>/<PATH>
```

To avoid a website which never needs to load this resource from doing so, we added a `matches` key in Manifest V3 to restrict access to the resource to only certain websites.

However, this doesn’t help in all cases. If you have a resource that you may need to add to any website, you need to provide <all_urls> as the matches pattern. In turn, this means that even if you haven’t injected into a website, it can attempt to load a resource at the path to see if your extension is installed. This can be used to fingerprint users.

When `use_dynamic_url` is enabled, <EXTENSION ID> in the path is replaced with a random GUID. This means a site cannot check if your extension is installed in the same way.

When you do need to access the resource, you can use `chrome.runtime.getURL` to get the correct URL to use.

Read more in our documentation.

As always, please do let us know if you have any questions or feedback.

Thanks,
Oliver on behalf of Chrome Extensions DevRel

Uğur

ulæst,
18. okt. 2024, 07.57.1118. okt.
til Chromium Extensions, Oliver Dunk
Hi Oliver, the vite bundler I'm using to bundle my react app and create a distribution code, it turns out they all use "use_dynamic_url" inside web_accessible_contents: 

an example: 

```   {
      "resources": [
        "assets/src/entries/contentScript/primary/main-541944c9.js",
        "assets/button-4d233a5f.js",
        "assets/icon-f198090f.png",
        "assets/AppStore-1ca19a3b.js",
        "assets/main-078a6da1.css",
        "assets/button-eb751d6c.css"
      ],
      "matches": [
        "https://mail.google.com/*"
      ],
      "use_dynamic_url": true
    }
```

And it now breaks all of my applications that I have developed so far.  Content scripts that appends scripts into the page are not working anymore.

An example error: 

``` main.js:1 Refused to load the script 'chrome-extension://849a1981-c137-4283-ba15-9a71a465d9c7/assets/src/entries/contentScript/primary/main-28be0580.js' because it violates the following Content Security Policy directive: "script-src 'self' 'wasm-unsafe-eval' 'inline-speculation-rules' http://localhost:* http://127.0.0.1:*". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. ```

when I manually modify dist/manifest.json to have use_dynamic_url: false, everything works like a charm. But all my extensions I published now is broken. 

Is there any thing I can do about this? Why I get such error?

another error example that bundles svelte code: 

Screenshot 2024-10-18 at 14.56.37.png

Oliver Dunk

ulæst,
18. okt. 2024, 08.15.1118. okt.
til Uğur, Chromium Extensions
Hi Uğur,

Could you share the bundling tool that you're using?

I know that `vite-plugin-web-extension` is one that was impacted, and the default value was changed in the most recent release: https://github.com/samrum/vite-plugin-web-extension/releases/tag/v5.1.1

We also plan to support this in a future version of Chrome which we're tracking here: https://issues.chromium.org/363027634. I'm hoping that we can get to that sooner rather than later as this seems to have had a wider impact than we anticipated.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Uğur

ulæst,
18. okt. 2024, 09.55.4018. okt.
til Chromium Extensions, Oliver Dunk, Chromium Extensions, Uğur
Yes I'm using that bundler. This is so unfortunate that already published extensions are disregarded and this feature has shipped with a bug. 

Thanks

Jay W

ulæst,
21. okt. 2024, 04.28.3221. okt.
til Chromium Extensions, Uğur, Oliver Dunk, Chromium Extensions
A bunch of eco system tooling will need to catch up to this update. This breaks a bunch of existing tools which somehow has this set to true already. For example this discussion: https://github.com/crxjs/chrome-extension-tools/issues/918

This also wasted like 2-3 hours of my time today...

Oliver Dunk

ulæst,
25. okt. 2024, 05.40.0325. okt.
til Jay W, Chromium Extensions, Uğur
Hi all,

Thanks again for all of the feedback on this one. It's clear that the impact was greater than we had hoped.

We've just merged a fix for https://issues.chromium.org/363027634 which is in today's Chrome Canary and will ship in the next version of Chrome.

Please do give it a try and let us know how you get on.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Svar alle
Svar til forfatter
Videresend
0 nye opslag