|
| 1 | +# WECG Meetings 2025, Public Notes, Sep 11 |
| 2 | + |
| 3 | + * Chair: Kiara Rose |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=68c36280,384 |
| 7 | +Call-in details: [WebExtensions CG, 11th September 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20250911T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | + |
| 11 | +## Agenda: [discussion in #867](https://github.com/w3c/webextensions/issues/867), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 16 | + |
| 17 | + * **Announcements** (2 minutes) |
| 18 | + * N/A |
| 19 | + * **Triage** (15 minutes) |
| 20 | + * [Issue 394](https://github.com/w3c/webextensions/issues/394): DNR: Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields |
| 21 | + * [Issue 868](https://github.com/w3c/webextensions/issues/868): DNR redirects make fetch(..., { redirect: "error" }) reject → easy blocker detection |
| 22 | + * [Issue 869](https://github.com/w3c/webextensions/issues/869): Expose browser UI theme (read-only + change event) |
| 23 | + * **Timely issues** (10 minutes) |
| 24 | + * N/A |
| 25 | + * **Check-in on existing issues** (20 minutes) |
| 26 | + * [PR 798](https://github.com/w3c/webextensions/pull/798): Proposal: Allow to change permissions behavior on extension updates |
| 27 | + * agreed on"backward compatibility" concern |
| 28 | + * browser vendors to review and agree on the proposal |
| 29 | + * discuss alternative (permissions_on_install) https://github.com/w3c/webextensions/pull/798#issuecomment-3281329407 |
| 30 | + |
| 31 | + |
| 32 | +## Attendees (sign yourself in) |
| 33 | + |
| 34 | + 1. Oliver Dunk (Google) |
| 35 | + 2. Rob Wu (Mozilla) |
| 36 | + 3. Kiara Rose (Apple) |
| 37 | + 4. Dave Vandyke (DuckDuckGo) |
| 38 | + 5. Giorgio Maone (Tor, NoScript) |
| 39 | + 6. Krzysztof Modras (Ghostery) |
| 40 | + 7. Simeon Vincent (Mozilla) |
| 41 | + 8. Mukul Purohit (Microsoft) |
| 42 | + 9. Oleksii Levzhynskyi (Grammarly) |
| 43 | + 10. Jordan Spivack (Capital One) |
| 44 | + 11. Casey Garland (Capital One) |
| 45 | + 12. David Johnson (Apple) |
| 46 | + 13. Carlos Jeurissen (Jeurissen Apps) |
| 47 | + 14. Harsh Singh (GSoC) |
| 48 | + 15. Maxim Topciu (AdGuard) |
| 49 | + |
| 50 | + |
| 51 | +## Meeting notes |
| 52 | + |
| 53 | +[Issue 394](https://github.com/w3c/webextensions/issues/394): DNR: Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields |
| 54 | + |
| 55 | + * [kiara] On the Safari side we added support for subdomains. The asks is for example.\* wildcards is something we cannot support. |
| 56 | + * [dave] Not sure if having a general TLD wildcard is useful. |
| 57 | + * [krzysztof] This request came from ad blockers, to match google.\* for example. Recently Ghostery had another use case: to allowlist on the original domain. They don't want to think about whether they have covered everything correctly. |
| 58 | + * [rob] Would a publicSuffix API help here? Allows extensions to expand wildcards themselves. |
| 59 | + * [krzysztof] I expect that would help. Of course, don't want to match [google.wordpress.com](http://google.wordpress.com/) for a Google wildcard. Similarly, Rob has an extension (Don't Track Me Google) that is basically a content script injected into a large number of Google domains. |
| 60 | + * [rob] For that specific example, I listed all known Google domains at the time, but adding a new domain would create a new permission request, so I don't do that. |
| 61 | + * [oliver] Anchoring of urlPattern would help with anchoring of (sub)domains, wouldn't it? |
| 62 | + * [dave] Now that you mentioned it, yes, that does work. And regexFilter offers even more flexibility. |
| 63 | + * [dave] On the Google use case, some domains may not be google dot something, e.g. YouTube. |
| 64 | + * [timothy] Concerned about affecting unrelated websites that they have not tested with. |
| 65 | + * [simeon] When I was at Google, there was something with first part domains that grouped domains. |
| 66 | + * [rob] That's called first party sets, that concept is no longer being pursued. |
| 67 | + * https://github.com/WICG/first-party-sets |
| 68 | + * [oliver] First party sets still lives on, as “Related Website Sets”, with some additional requirements. |
| 69 | + * [simeon] https://privacysandbox.google.com/cookies/related-website-sets and https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Related_website_sets |
| 70 | + * [oliver] On the Google side our opinion is still similar, not keen on the capability of wildcards. Just because you have many on the same TLD, does not mean that you own domains for all TLDs. We are neutral, so willing to accept solutions but not a priority to implement. |
| 71 | + * [rob] Would regexFilter work? It does not work for initiators right now. |
| 72 | + * [dave] If we had regular expression matching conditions that applied to initiator domain instead of request domain, I figure that would meet your use-case with the approach like Rob suggested and be more generally applicable? |
| 73 | + * [rob] Extension could decide which part of the rule the PSL applies to. |
| 74 | + * [krzysztof] Would work for basic config, but might not work for rule matching. Adds additional complexity to DNR rule processing. |
| 75 | + * [maxim] Probably could fix, but if you start considering sites unsafe when using regular expressions, might create other problems. But not totally ruling this out. |
| 76 | + * [kiara] I will discuss this on the Safari side to gather our position. |
| 77 | + |
| 78 | +[Issue 868](https://github.com/w3c/webextensions/issues/868): DNR redirects make fetch(..., { redirect: "error" }) reject → easy blocker detection |
| 79 | + |
| 80 | + * [krzysztof] Opened by a teammate. When using redirect rules, websites can easily detect the presence of a content blocker. This is not desirable, obviously. Quick solution: whenever the DNR rule applies, return a 200. There's some extra info relevant to Safari: the redirect points to the extension's URL, leaking the extension ID. |
| 81 | + * [timothy] That's probably something we want to fix. |
| 82 | + * [rob] That URL leakage is not just a Safari concern. I have wanted to address this issue for years, and we've had other issues filed in WECG. The general solution that I came up with is the ability to replace response bodies while keeping the rest the same. That may still have issues with subresource integrity. First want to see if there is interest from other browsers in modifying the response. |
| 83 | + * https://github.com/w3c/webextensions/issues/604 |
| 84 | + * https://bugzilla.mozilla.org/show_bug.cgi?id=1712096 |
| 85 | + * [timothy] Interested in that area too. |
| 86 | + * [oliver] I'd like to follow up. Fingerprinting in general is something we want to avoid. Don't know enough about the caveats for this specific case. |
| 87 | + * [krzysztof] Don't want to redirect so much as rewrite the response. |
| 88 | + * [david] Would we want to change to redirect or introduce a new rule to swap response content? |
| 89 | + * [timothy] Depends on the nature of the redirect. Maybe that's the key, if it's an extension resource replace the response body. |
| 90 | + * [rob] On the Safari side, are you thinking of a specific approach? |
| 91 | + * [kiara] Still need to discuss; the fact that we leak the extension URL is something we need to fix. |
| 92 | + * [timothy] We have some masking of URL, e.g. masking URL in the DOM. |
| 93 | + * [rob] Are you interested in opening an issue describing your current state, and see what we can do there? I'm very interested in addressing the fingerprinting issue. I have had thoughts before, and recognize the value of cross browser alignment for interoperability. |
| 94 | + * [timothy] I can do that. |
| 95 | + * [krzysztof] Are there use cases for redirects to extension resources where the URL should change? |
| 96 | + * [maxim] Ad blocker extensions usually redirect to internal resources or change parameters. |
| 97 | + * [krzysztof] Should we disallow redirects to external resources? Concern of untrusted script execution when redirecting to other websites. |
| 98 | + |
| 99 | +[Issue 869](https://github.com/w3c/webextensions/issues/869): Expose browser UI theme (read-only + change event) |
| 100 | + |
| 101 | + * [oliver] I saw a related Chromium issue opened, I'm not sure what the context is and I haven't heard any discussions internally: https://issues.chromium.org/443765363 |
| 102 | + * [oliver] Firefox has an existing API but it only returns themes applied by an addon, not the browser theme: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/theme/getCurrent |
| 103 | + * [rob] theme.getCurrent() returning null for the browser theme is a known issue ([bug 1435216](https://bugzilla.mozilla.org/show_bug.cgi?id=1435216)). This is because it is hard to condense the browser theme into the same return type. |
| 104 | + * [rob] Why do you think this proposal would be a general solution for all use case? So far it has been rather difficult to find a solution to works for various use cases. |
| 105 | + * [krzysztof] I haven't read all the links Carlos provided due to time constraints. When time allows, I can follow up with a revised proposal. |
| 106 | + * [timothy] … I see some concern that this may overlap too much with general web functionality. I'm missing the use cases that would be served by this API. |
| 107 | + * [krzysztof] Many extensions provide sidebars, would be nice to match the theme of the browser. I would be fine with a CSS solution. |
| 108 | + * [carlos] Accent color and system color aren't supported in all browsers. |
| 109 | + * [david] I'm in favor of a DOM or CSS based solution, especially with Liquid Glass. Just querying a theme might not be sufficient. |
| 110 | + * [krzysztof] The browser icon could also benefit from the ability to adapt to colors. |
| 111 | + * [simeon] Alternatively SVG? |
| 112 | + * [timothy] Chrome does not support that. |
| 113 | + * [timothy] In Safari we try to avoid that possibility where a specific color would conflict with the page. It is something the browser should solve, and not every extension on their own. |
| 114 | + * [krzysztof] Maybe we should move the browser action concerns into a separate issue for clarity. |
| 115 | + * [timothy] In favor of a declarative solution instead of an event/iterative based approach, due to delays and flashes. That's why we precompute light/dark mode upfront, as we change frequently, which we do with Liquid Glass. |
| 116 | + * [oleksii] Colors for badges |
| 117 | + * [timothy] Currently Safari does not support custom colors for badges, it is always red. |
| 118 | + * [oliver] What do you think of closing this issue and explaining why this specific API would not work? |
| 119 | + * [simeon] Sounds good to me. |
| 120 | + * [oliver] I will write a comment. |
| 121 | + |
| 122 | +[PR 798](https://github.com/w3c/webextensions/pull/798): Proposal: Allow to change permissions behavior on extension updates |
| 123 | + |
| 124 | + * (from agenda) |
| 125 | + * agreed on "backward compatibility" concern |
| 126 | + * browser vendors to review and agree on the proposal |
| 127 | + * discuss alternative (permissions_on_install) https://github.com/w3c/webextensions/pull/798#issuecomment-3281329407 |
| 128 | + * [oleksii] Summary at https://github.com/w3c/webextensions/pull/798#issuecomment-3281105339 |
| 129 | + * [oleksii] PR proposes permission_behavior, which only works for browsers that do support it. Another option is to add a new property (e.g. `permissions_on_install`), a concern is that nobody would use the permissions and use the new permissions key. |
| 130 | + * [timothy] Problem with backcompat is that we cannot go in the past and change software that users have. Have to bake for 1-2 years before everyone is up to date. |
| 131 | + * [carlos] I believe that `permissions_on_install` would help here; historically we have `permissions` and `optional_permissions`; `permissions_on_install` would swap the logic around. Instead of specifying the “optional” permissions. You would specify the “to-prompt” permissions. When present, it would suppress the prompting behaviour of `permissions` and the hoisting of `content_scripts` permissions. |
| 132 | + * [oleksii] So eventually `permissions_on_install` would replace `permissions` key? |
| 133 | + * [carlos] No, eventually (in a next manifest version), `permissions` and `optional_permissions` can be fused as one `permissions` which are all treated as “optional”. (Kind of what was initially the plan with host permissions in mv3). |
| 134 | + * [rob] Could you describe a concrete usage of the proposed API? The original use case is about updating: Currently if you have [example.com](http://example.com/) as a host permission. If you want to add [example.net](http://example.net/), Chrome would disable the extension. |
| 135 | + * [carlos] You'd add the new permission to `permissions_on_install`, but this would only be prompted for new users. |
| 136 | + * [oleksii] To clarify, a developer would only add [example.net](http://example.net/) to `permissions_on_install`, correct? |
| 137 | + * [carlos] Correct. |
| 138 | + * [oleksii] Feels like this property would likely replace permissions. |
| 139 | + * [rob] I see a use case for developer that don't want to ask for the world. When they want to add a new host permission, they add the new ones to permissions_on_install only, and continue to ask for limited permissions in the `permissions` key. They would gently nudge the user over time to add the new permissions with extension-specific UI (using `permissions.request()`. After a year or so, most users are expected to have approved, and they migrate the required permissions to the `permissions` field to make the requirement explicit (causing the extension to be disabled in Chrome for users who have not approved). Is that the kind of use case you had in mind? |
| 140 | + * [carlos] Correct. This is to help with a transition period. |
| 141 | + * [dave] This also encourages extensions to ask for fewer permissions; currently they ask for many upfront to avoid Chrome's issue. |
| 142 | + * [oliver] I thought we were talking about `permissions_on_install` being a new array. For content scripts, how would content script injection work? I don't think the behavior of one key should affect another. |
| 143 | + * [oleksii] I can update my proposal to incorporate this feedback and work with Carlos to address his concerns. |
| 144 | + |
| 145 | +The next meeting will be on [Thursday, September 25th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68d5d780,384). |
0 commit comments