|
| 1 | +# WECG Meetings 2025, Public Notes, Feb 13 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PST = https://everytimezone.com/?t=67ad3600,384 |
| 7 | +Call-in details: [WebExtensions CG, 13th February 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250213T080000/) |
| 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 #754](https://github.com/w3c/webextensions/issues/754), [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 | + * Announcement: WECG meetup in Berlin, March 2025 ([Issue 759](https://github.com/w3c/webextensions/issues/759), [wiki page](https://github.com/w3c/webextensions/wiki/2025-Berlin-F2F-Coordination)) |
| 19 | + * **Triage** (15 minutes) |
| 20 | + * [Issue 755](https://github.com/w3c/webextensions/issues/755): Proposal: about: matching |
| 21 | + * [Issue 756](https://github.com/w3c/webextensions/issues/756): Proposal: Exclude Matching |
| 22 | + * [Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) |
| 23 | + * [Issue 763](https://github.com/w3c/webextensions/issues/763): Proposal: Add excludeTopFrameMatches and excludeTopFrameGlobs |
| 24 | + * **Timely issues** (10 minutes) |
| 25 | + * [PR 760](https://github.com/w3c/webextensions/pull/760): Specification for loading extensions in WebDriver Classic |
| 26 | + * [issue 764](https://github.com/w3c/webextensions/issues/764): WebDriver: install command optional parameters |
| 27 | + * **Check-in on existing issues** (20 minutes) |
| 28 | + * [Issue 746](https://github.com/w3c/webextensions/issues/746): Proposal: Persistent Authentication |
| 29 | + |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. Rob Wu (Mozilla) |
| 34 | + 2. Oliver Dunk (Google) |
| 35 | + 3. Giorgio Maone (NoScript, Tor) |
| 36 | + 4. Steven McLintock (1Password) |
| 37 | + 5. Krzysztof Modras (Ghostery) |
| 38 | + 6. Lena Cohen (Privacy Badger, EFF) |
| 39 | + 7. Tomislav Jovanovic (Mozilla) |
| 40 | + 8. Maxim Topciu (AdGuard) |
| 41 | + 9. David Johnson (Apple) |
| 42 | + 10. Kiara Rose (Apple) |
| 43 | + 11. Mukul Purohit (Microsoft) |
| 44 | + 12. Timothy Hatcher (Apple) |
| 45 | + 13. Casey Garland (Capital One) |
| 46 | + |
| 47 | + |
| 48 | +## Meeting notes |
| 49 | + |
| 50 | +Announcement: WECG meetup in Berlin, March 2025 ([Issue 759](https://github.com/w3c/webextensions/issues/759), [wiki page](https://github.com/w3c/webextensions/wiki/2025-Berlin-F2F-Coordination)) |
| 51 | + |
| 52 | + * [tomislav] The in-person WECG meetup will take place from Tuesday 25 March until Friday 28 March, in the Mozilla office in Berlin. We expect about 10 - 20 attendees. If interested, sign yourself up in the issue. |
| 53 | + |
| 54 | +[Issue 755](https://github.com/w3c/webextensions/issues/755): Proposal: about: matching |
| 55 | + |
| 56 | + * [timothy] about:-matching would be OK by me. |
| 57 | + * [rob] about: in content scripts is already covered by `match_origin_as_fallback`; API-dependent solutions may work better. E.g. for context menus. |
| 58 | + * [krzysztof] Do extensions have access to about:newtab at the moment? |
| 59 | + * [rob] No. |
| 60 | + * [krzysztof] Seems to have potential for privilege violation. |
| 61 | + * [timothy] If anything, I would at most be supportive of about:blank and about:srcdoc. |
| 62 | + * [oliver] Similarly. We don't even have about:newtab. |
| 63 | + * [oliver] The contextMenus API use case specifically could be solved by a combination of `documentUrlPatterns` (to include the HTTP and HTTPS protocols, while excluding file:) and the addition of a `match_origin_as_fallback` like key that would also allow matching blank frames. |
| 64 | + * [timothy] |
| 65 | + * [rob] Not sure if we would want to support “about:blank” in match patterns, the capability to match about blank otherwise in context menus sounds reasonable. |
| 66 | + * [oliver] I wonder whether support for something like `match_origin_as_fallback` would be sufficient. |
| 67 | + |
| 68 | +[Issue 756](https://github.com/w3c/webextensions/issues/756): Proposal: Exclude Matching |
| 69 | + |
| 70 | + * [oliver] This is a generic feature request. |
| 71 | + * [rob] Firefox supports menus.onShown, menus.onHidden and menus.refresh() which allows extensions to hide/show/update menus at runtime. |
| 72 | + * [timothy] We don't support that in Safari. |
| 73 | + * [rob] Would you consider it, or does it not fit in your model? |
| 74 | + * [timothy] We may consider it, but it is not a high priority. |
| 75 | + * [timothy] The issue suggests negating a match by prepending `!`. |
| 76 | + * [tomislav] Clarify use cases with reporter. |
| 77 | + |
| 78 | +[Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) |
| 79 | + |
| 80 | + * [alexei] Determining whether something is third-party, in DNR, all comparisons are against the immediate parent. This is not what developers want. We want to add a filter to DNR rules to include or exclude by the top level document. E.g. `facebook.com` loads Zinga which loads more facebook domains. It is currently not possible to block facebook except on `facebook.com` domains. |
| 81 | + * [krzysztof] We share the use case, mainly to allow user control. Users see the top-level URL, and not the frame URL. |
| 82 | + * [giorgio] +1 |
| 83 | + * [rob] allowAllRequests was designed for this. It is not ideal, but have you looked into it? |
| 84 | + * [oliver] allowAllRequests would ignore all rules, but in this case the goal is to only ignore requests that are first party with the top level frame. Chrome is supportive of this request. |
| 85 | + * [krzysztof] This is more important for general extensions beyond ad blockers. |
| 86 | + * [giorgio] In NoScript, contextual policies need this capability, to implement something based on the top domain. |
| 87 | + * [rob] Supportive from Firefox's side. |
| 88 | + * [rob] What if the top URL is about:blank, e.g. a popup opened by `example.com`? |
| 89 | + * [giorgio] In my use case, it would be the real domain. |
| 90 | + * [alexei] I don't know from the top off my head; I'd look at MV2, what happens in webRequest? |
| 91 | + * [krzysztof] Please ask again in the issue, then I can come back to this later. |
| 92 | + * [timothy] We'd be supportive on the Safari side. |
| 93 | + |
| 94 | +[Issue 763](https://github.com/w3c/webextensions/issues/763): Proposal: Add excludeTopFrameMatches and excludeTopFrameGlobs |
| 95 | + |
| 96 | + * [tomislav] The use case is mainly about a mismatch between how we treat match patterns and user expectations. When a user disables an extension on Reddit, they expect to disable scripts in Reddit and all of its subframes, not just on Reddit. Alternatives exist (location.ancestorOrigins). |
| 97 | + * [alexei] This is another issue from the class of issues where DNR/MV3 APIs compare against the immediate parent frame, not the top-level document frame. Extensions generally want to compare against the top-level document, or at least should have the choice. |
| 98 | + * [rob] Are there signs of extensions desiring this capability? E.g. if extensions use location.ancestorOrigins. |
| 99 | + * [oliver] Is there a need to match by full URLs or should we match by origin? |
| 100 | + * [krzysztof] |
| 101 | + * [tomislav] Most flexible matching mechanism is by top URL and individual frames. Is this the requested feature, or part of a more generic desired feature set? |
| 102 | + * [rob] Matching by origins is feasible to implement, full URLs are not guaranteed to be available across origins, in a cross-domain frame. |
| 103 | + * [giorgio] Matching by domain would be a great start. |
| 104 | + * [krzysztof] Matching by globs is sometimes needed, e.g. to support matching by `google.*` instead of listing all domains separately. |
| 105 | + * [rob] I'm not opposed to this capability, but would like to see existing demand for this feature before considering its implementation. |
| 106 | + * [alexei] Wouldn't it be much nicer for developers to declaratively specify the top-level domains they want to include/exclude, than having to make custom checks in content scripts just because the scripting API doesn't support matching against top-level domains? |
| 107 | + * [giorgio] Contextual policies in NoScript uses origins. |
| 108 | + * [rob] Chrome already supports location.ancestorOrigins, Firefox is working on it. |
| 109 | + * [alexei] When a user “disables” an extension on a site through the browser, it does not only disable it in the top frame, but also iframes in different sites. |
| 110 | + * [timothy] I see this being useful for content scripts. This is the inverse, all subframes, not the main frame. |
| 111 | + * [rob] `window === top`, `location.ancestorOrigins` and others can be used in content scripts to do the matching and exit early if needed. If extensions can already achieve a goal with existing APIs, there is no strong case for introducing a new API to something similar, unless there are strong benefits to doing so. |
| 112 | + * [krzysztof] In MV3 scripts are declarative/static and cannot be configured. |
| 113 | + * [timothy] And that is where globalParams would be useful. |
| 114 | + * [giorgio] Yes, please! |
| 115 | + |
| 116 | +[PR 760](https://github.com/w3c/webextensions/pull/760): Specification for loading extensions in WebDriver Classic |
| 117 | + |
| 118 | + * [kiara] PR to describe the webdriver classic protocol to enable loading extensions in Safari. Based on webdriver-bidi protocol. |
| 119 | + * [tomislav] I had some feedback, which applies equally to the webdriver-bidi protocol. In the interest of avoiding duplication of discussion, I'll delete my comments and approve. |
| 120 | + * [oliver] I added approval, you can consider this to be approval from Chrome's side. |
| 121 | + |
| 122 | +[issue 764](https://github.com/w3c/webextensions/issues/764): WebDriver: install command optional parameters |
| 123 | + |
| 124 | + * [krzysztof] How should browser-specific features be passed to installation? There are universal cases such as private browsing access; others are more fragmented. |
| 125 | + * [kiara] We discussed this on our side in testing; currently default to granting all permissions by default, but would be nice to have the ability to toggle that behavior. |
| 126 | + * [oliver] This is a good discussion, thanks for opening. |
| 127 | + * [krzysztof] Should the ability to grant permissions be part of install or a subsequent command? |
| 128 | + * [kiara] In testing, by default would be to grant them; for specific tests it would make sense to allow the opposite. |
| 129 | + * [tomislav] Would be nice to have the ability to grant some permissions at install time. |
| 130 | + * [kiara] I agree, on install would be preferred. |
| 131 | + * [krzysztof] Things like the geolocation permission are examples of what exists. |
| 132 | + * [rob] If you identify common patterns in the webdriver-bidi spec that can be re-used here, that would be really nice. |
| 133 | + * [tomislav] To avoid scattering the discussion, let's discuss what we want in our group, in the issue, and then reach out to the webdriver bidi. |
| 134 | + |
| 135 | +[Issue 746](https://github.com/w3c/webextensions/issues/746): Proposal: Persistent Authentication |
| 136 | + |
| 137 | + * [rob] This was discussed before; since we are out of time, let's process this issue async. |
| 138 | + |
| 139 | +The next meeting will be on [Thursday, February 27th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=67bfab00,384). |
0 commit comments