|
| 1 | +# WECG Meetings 2025, Public Notes, Nov 6 |
| 2 | + |
| 3 | + * Chair: Kiara Rose |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PST = https://everytimezone.com/?t=690d3680,3c0 |
| 7 | +Call-in details: [WebExtensions CG, 6th November 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20251106T080000/) |
| 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 #895](https://github.com/w3c/webextensions/issues/895), [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 | + * TPAC is coming up! Suggest topics in [WECG at TPAC 2025 #843](https://github.com/w3c/webextensions/issues/843) or tag that issue in comments on other issues. |
| 19 | + * [WEWG charter draft](https://w3c.github.io/charter-drafts/2025/webextensions-wg.html) is being discussed in [\[wg/webextensions\] Web Extensions Working Group strategy#146](https://github.com/w3c/strategy/issues/146) and Simeon is iterating on revisions in [Apply revisions requested in w3c/strategy#146 charter-drafts#711](https://github.com/w3c/charter-drafts/pull/711). |
| 20 | + * **Triage** (15 minutes) |
| 21 | + * [Issue 893](https://github.com/w3c/webextensions/issues/893): Web request tainting (Collusion/Lightbeam) |
| 22 | + * [Issue 888](https://github.com/w3c/webextensions/issues/888): Discuss adding i18n.setAcceptLanguages and i18n.appendAcceptLanguage |
| 23 | + * [Issue 896](https://github.com/w3c/webextensions/issues/896): There is no HTTP Referer header for iframe in an extension page |
| 24 | + * [Issue 897](https://github.com/w3c/webextensions/issues/897): Add support for `tabs.create({ incognito: true })` |
| 25 | + * [Issue 898](https://github.com/w3c/webextensions/issues/898): Add support for `scripting.executeScript({ userGesture: true })` |
| 26 | + * **Timely issues** (10 minutes) |
| 27 | + * [PR 899](https://github.com/w3c/webextensions/pull/899): Proposal: `SecurityInfo` in `WebRequest` |
| 28 | + * **Check-in on existing issues** (20 minutes) |
| 29 | + * (none) |
| 30 | + |
| 31 | + |
| 32 | +## Attendees (sign yourself in) |
| 33 | + |
| 34 | + 1. Rob Wu (Mozilla) |
| 35 | + 2. Timothy Hatcher (Apple) |
| 36 | + 3. Patrick Kettner (Google) |
| 37 | + 4. Vlad Krot (Google) |
| 38 | + 5. Carlos Jeurissen (Jeurissen Apps) |
| 39 | + 6. Kiara Rose (Apple) |
| 40 | + 7. Simeon Vincent (Mozilla) |
| 41 | + 8. Mukul Purohit (Microsoft) |
| 42 | + 9. Benjamin Bruneau (1Password) |
| 43 | + 10. Casey Garland (Capital One) |
| 44 | + |
| 45 | + |
| 46 | +## Meeting notes |
| 47 | + |
| 48 | +Announcements and news |
| 49 | + |
| 50 | + * [kiara] TPAC is next week! (https://github.com/w3c/webextensions/issues/843) |
| 51 | + * [patrick] Chrome 144 will ship browser namespace support by default. Improves interoperability with other browsers. |
| 52 | + |
| 53 | +[Issue 893](https://github.com/w3c/webextensions/issues/893): Web request tainting (Collusion/Lightbeam) |
| 54 | + |
| 55 | + * [rob] I think Krystof filed this issue based on meeting notes after discussion in a previous meeting. The issue refers to Lightbeam, and that repository contains a WebExtension, which suggests that the functionality may already be achievable without new APIs. Not sure what other capability is being requested here. |
| 56 | + |
| 57 | +[Issue 888](https://github.com/w3c/webextensions/issues/888): Discuss adding i18n.setAcceptLanguages and i18n.appendAcceptLanguage |
| 58 | + |
| 59 | + * [carlos] Currently extensions wishing to modify, accept or append languages need to modify the main world and need to change headers to make this work. An easier way for extension to do this… A browser may not understand each language an extension adds. Not as straightforward as it may sound. |
| 60 | + * [rob] Why is this request here? The linked proposal was [added to the source code in 2021](https://source.chromium.org/chromium/_/chromium/website/+/c15c6912a987bf880177cea6eb5c5c05211a5593:site/developers/design-documents/extensions/proposed-changes/apis-under-development/i18n-api/index.md;bpv=1;bpt=0;drc=4d7339a38c5b9ae2809116c05ec9beb492c374fd), exported from a presumably way older source. |
| 61 | + * [carlos] Accept-Languages is currently limited; not all languages can be added in the browser UI. Other use cases. |
| 62 | + * [rob] Accept-Language header can already be modified by DNR and WebRequest. Why are those insufficient? |
| 63 | + * [carlos] They do not modify navigator.languages, nor reflected in the browser UI. |
| 64 | + * [rob] If navigator.language were specified to be derived from the accept-language accept/response header, would that be sufficient? |
| 65 | + * [carlos] Could. Depends on browser implementation details. |
| 66 | + * [rob] How are other browsers thinking about this, especially UI reflection. |
| 67 | + * [kiara] No thoughts at this moment. |
| 68 | + * [carlos] For Safari, I believe this would be complicated because it's tied to the system languages. |
| 69 | + * [rob] I recently looked into how this works in Firefox for Android, and it also happens at a different layer, so it would be difficult to change a header value. I'm not sure if we can commit to the extension-defined language getting mirrored in the browser UI. |
| 70 | + * [timothy] When you say affect browser UI, you mean a language menu picker? Not the browser Chrome? |
| 71 | + * [carlos] I was thinking about the general language setting |
| 72 | + * [timothy] I definitely do have concerns with being able to support this. Everything you've said so far is accurate, not much to add. |
| 73 | + * [rob] Carlos, have you considered the fingerprinting risk of this capability. For example, defining a unique language that sets them apart from all other users. |
| 74 | + * [carlos] Yes, that is a concern. Good point. |
| 75 | + * [rob] Addison already [mentioned](https://github.com/w3c/webextensions/issues/888#issuecomment-3497606134) that they were interested from the Internationalization group perspective. I'll comment on the issue. |
| 76 | + |
| 77 | +[Issue 896](https://github.com/w3c/webextensions/issues/896): There is no HTTP Referer header for iframe in an extension page |
| 78 | + |
| 79 | + * [kiara] Appears that a extensions broke due to a recent YouTube change. Oliver also raised some concerns on the issue. One of the cons of sending the Referrer header is that websites can detect the presence of extensions. |
| 80 | + * [rob] I also had that concern. In Safari the hostname is randomized, which also makes the browser session fingerprintable. For TPAC, we should discuss what an origin should look like in order to allow a server to have a set of expected origins, which I raised before in the context of webauthn ([issue 238](https://github.com/w3c/webextensions/issues/238)). |
| 81 | + * [timothy] That's already in the schedule for Monday. I have some thoughts on ways we could do this. Could be tied to web_accessible_resources where an extension opts into a static host ID. That could be used in every match pattern for web accessible resources. |
| 82 | + * [rob] Something like that could work. And then allowing extensions to configure the default referrer policy. On the web we can't strip the full referer, that's why it defaulted to just origin (strict-origin-when-cross-origin). In extensions we can default to noreferrer. Even without new extension APIs, extensions can use DNR to modify the headers if they really want to. |
| 83 | + * [simeon] is it possible to match \__msg_extension_id_\_ in DNR? |
| 84 | + * [timothy] Not in DNR. |
| 85 | + * [rob] You can create a session rule at runtime using runtime.getURL() to match the extension origin. |
| 86 | + * [rob] In a web page, if the extension page declares a referrer policy, do we want to make it easier for extensions to leak their origin? I don't think we should expose the UUID, but the extension ID. |
| 87 | + * [simeon] Would be good to specify meaning of UUID |
| 88 | + * [rob] In Chrome the host name is always the ID, in Firefox and Safari the hostname is a random UUID. We don't need to specify the UUID, just that the host name can be dynamic. |
| 89 | + * [rob] Another approach is that the host name should always include something extension specific, static instead of dynamic. Idea is to prevent websites from accessing an extension's origin unless the extension opts into exposing the origin to one or more sites, and this would remove the need for randomizing the host name. Let's discuss this in more detail at TPAC. |
| 90 | + * |
| 91 | + * [kiara] Circling back, could we just send the scheme or should we send the identifier as well? |
| 92 | + * [rob] Just the scheme is not a valid URL. Could break web servers. Not sure that's likely in practice. Could send all 0s for a UUID. |
| 93 | + * [timothy] Might be a special case. I believe there's a null UUID we could use. |
| 94 | + * [carlos] Websites might as well break if given an extension URL |
| 95 | + * [rob] Kiara, are you asking about what to expose by default, or what to expose if we want to expose? |
| 96 | + * [kiara] What we expose. |
| 97 | + * [timothy] I think this was in reference to not sending a referrer unless the extension opts in. That would at least give a signal that it's coming from some extension, not a specific extension. |
| 98 | + * [rob] Do we want websites to be able to distinguish between websites and extensions? That's the other side of the coin: we're leaking info that websites can use to reject extensions. I'm open to making this an opt-in. |
| 99 | + * [timothy] For sure. Definitely don't want to incentivize pages to block extension requests more than they already do. |
| 100 | + * [simeon] Also wanted to mention the use case of developers that produce both a website and an extension, where they want to verify that the extension they're communicating with is their extension, not another extension impersonating it by setting a custom header value. |
| 101 | + * [rob] We could consider a Sec-prefixed header that cannot be forged by extensions. |
| 102 | + |
| 103 | +[Issue 897](https://github.com/w3c/webextensions/issues/897): Add support for `tabs.create({ incognito: true })` |
| 104 | + |
| 105 | + * [kiara] Request to open private tabs with incognito:true |
| 106 | + * [rob] I'd say supportive. We already have a bug requesting the ability to open private tabs on Firefox for Android, which is currently not easily supported because of the lack of “windows” concept |
| 107 | + * https://bugzilla.mozilla.org/show_bug.cgi?id=1754184 , duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1372178 |
| 108 | + * [patrick] Haven't had a chance to triage this as a group. I anticipate being supportive, but that's not currently an official position (Chrome). |
| 109 | + * [kiara] Should we talk about private vs. incognito? |
| 110 | + * [simeon] Let's hold off until TPAC, could be very bikeshedable. |
| 111 | + * [patrick] Seems like good fodder for TPAC discussion. |
| 112 | + |
| 113 | +[Issue 898](https://github.com/w3c/webextensions/issues/898): Add support for `scripting.executeScript({ userGesture: true })` |
| 114 | + |
| 115 | + * [carlos] Certain methods in JS require a user gesture. Extensions may not always get user input when injecting, but may need it. |
| 116 | + * [patrick] Sounds like a bug if it's not happening in all situations. |
| 117 | + * [carlos] Occurs in extensions where it does work in the background. |
| 118 | + * [timothy] Is it happening in situations where the action is triggered by a user gesture in the page? |
| 119 | + * [carlos] No, separate async background work. |
| 120 | + * [timothy] If you do an action click event in Safari, that should propagate a user action into the background page in order to give the background access to a user gesture. If the extension then passes back to the content script, the user gesture is preserved. |
| 121 | + * [simeon] Chrome definitely curries the user gesture from a content script to a background script. I'm not sure about going from a background script to a content script, though. |
| 122 | + * [patrick] And the other way around? Where would the background script gets the user gesture from? |
| 123 | + * [rob] If we have time at TPAC, would be good to discuss user gestures, user activation, and our objectives and long-term goals with it? |
| 124 | + * [timothy] I can schedule that on Thursday. |
| 125 | + * [simeon] Would be great to discuss this. IMO this is one of those foundational interactions that are inconsistent across browsers and can result in some weird subtle challenges that you don't find out about until you hit them. |
| 126 | + |
| 127 | +[PR 899](https://github.com/w3c/webextensions/pull/899): Proposal: `SecurityInfo` in WebRequest |
| 128 | + |
| 129 | + * [rob] PR follows from [issue 882](https://github.com/w3c/webextensions/issues/882), and he is on this call. |
| 130 | + * [vlad] Firefox already has SecurityInfo in webRequest; we'd like the information in Chrome, not exactly in the same shape. |
| 131 | + * [rob] In earlier discussion you mentioned you wanted to add it to onCompleted. Is that still the intent? |
| 132 | + * [vlad] No, the proposal aligns with Firefox to expose it in onHeadersRecieved. I overestimated the difficulty when I said it was prohibitively difficult to implement in the past. |
| 133 | + * [rob] Firefox SecurityInfo is quite detailed. The SecurityInfo in the Chrome proposal is a subset. How did you arrive at this minimum? |
| 134 | + * [vlad] Bit of a long story for why this exact subset. The reason is that we have a similar internal web API that only Chrome can access. You can embed any website inside another website ([Controlled Frame](https://developer.chrome.com/docs/iwa/controlled-frame)), and you can put listeners in that that monitors request events using the same API. Uses the same implementation. |
| 135 | + * [rob] Couldn't find references to certificates in Controlled Frames, but didn't see references to certificates. Is that separate, work in progress? |
| 136 | + * [vlad] It's a work in progress, not currently exposed. |
| 137 | + * [rob] If you could update the proposal to include links to the APIs you're modeling against, that would be very helpful. |
| 138 | + * [vlad] I've added it to the proposal. Mostly what I want to know is whether the current shape of the proposal is okay for folks here, especially the part where it's not compatible with Firefox. |
| 139 | + * [rob] I don't have much compatibility concern as developers have to opt into getting this data. I need to take a closer look to see which fields are missing/optional or different. |
| 140 | + * [vlad] Besides additional flags in extraInfoSpec, I don't think anything else is different. |
| 141 | + * [rob] Do you anticipate extensions will always want this information, or only conditionally in some scenarios? If extensions always want it, we can statically expose it, but if it's not always needed and is computationally expensive, may make more sense to put it behind a function. |
| 142 | + * [vlad] Need to think about the use cases. Say we have an extension that observes websites and shows connection strength. In this case, they'd definitely want it. I think 90% of the time it should be unconditional. It might be conditional for some specific cases, like only getting certificates for a specific hostname being monitored. Possible, but can be solved with multiple request listeners. |
| 143 | + * [rob] Have you analyzed existing firefox extensions that get security info to see what kind of usage patterns they have? If not, I can run a query. |
| 144 | + * [vlad] I did a non-through check. Do you have a use case in mind? |
| 145 | + * [rob] No, I'm looking for the use cases. As part of the review I'll do a quick scan of Firefox extensions using the existing webRequest.getSecurityInfo API to see how they're using it. |
| 146 | + * [kiara] Haven't looked at the proposal yet. |
| 147 | + * [timothy] I haven't either. |
| 148 | + |
| 149 | +The next meeting will be on [Thursday, November 20th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=691fab80,3c0). |
0 commit comments