-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #479 from w3c/meeting-2023-10-26
Publish minutes of 2023-10-26 meeting
- Loading branch information
Showing
2 changed files
with
169 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,164 @@ | ||
| # WECG Meetings 2023, Public Notes, Oct 26 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=6539ac00,384 | ||
| Call-in details: [WebExtensions CG, 26th October 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20231026T080000/) | ||
| Zoom issues? Ping @robwu (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **New business** | ||
| * [simeon] Simeon's affiliation status | ||
| * **Carry-over from previous meetings** | ||
| * [Issue 445](https://github.com/w3c/webextensions/issues/445): Inconsistency: notifications.NotificationOptions (data update from Chrome) | ||
| * [Issue 463](https://github.com/w3c/webextensions/issues/463): Inconsistency in browser.action: windowId key and enable()/disable() arguments | ||
| * [Issue 464](https://github.com/w3c/webextensions/issues/464): [Proposal: Event priority in Background Service Worker or Event page](https://github.com/w3c/webextensions/issues/464) | ||
| * **Other new issues** | ||
| * [Issue 466](https://github.com/w3c/webextensions/issues/466): Proposal: allow storing metadata in a static ruleset | ||
| * [Issue 467](https://github.com/w3c/webextensions/issues/467): Proposal: change the static ruleset JSON structure | ||
| * [Issue 468](https://github.com/w3c/webextensions/issues/468): [DNR] Redirect rule does not allow applying other redirect rules to the resulting request | ||
| * [Issue 469](https://github.com/w3c/webextensions/issues/469): request: allow to retrieve a tabId and documentId from the content script | ||
| * [Issue 470](https://github.com/w3c/webextensions/issues/470): Proposal: expose the new tab URL | ||
| * (7 more issues - moved to next meeting due to running out of time) | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (unaffiliated) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Mukul Purohit (Microsoft) | ||
| 4. Jarek Samic (1Password) | ||
| 5. Carlos Jeurissen (Jeurissen Apps) | ||
| 6. Steven McLintock (1Password) | ||
| 7. Oliver Dunk (Google) | ||
| 8. Richard Worth (Capital One) | ||
| 9. Todd Schiller (PixieBrix) | ||
| 10. David Johnson (Apple) | ||
| 11. Timothy Hatcher (Apple) | ||
| 12. Kiara Rose (Apple) | ||
| 13. Jackie Han (No affiliation) | ||
| 14. Dmitriy Seregin (AdGuard) | ||
| 15. Maxim Topciu (AdGuard) | ||
| 16. Tim Heflin (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| (Simeon's disclosure) | ||
|
|
||
| * [simeon] I've worked for Google Chrome for several years, and then I did not. Since then I have been unaffiliated. I'm currently contracting for Mozilla, but I'm not working for Mozilla in the WECG and remain independent/unaffiliated here. | ||
|
|
||
| [Issue 445](https://github.com/w3c/webextensions/issues/445): Inconsistency: notifications.NotificationOptions (data update from Chrome) | ||
|
|
||
| * [patrick] I pulled up the data, but I'm not sure what I should provide in this issue. | ||
| * [rob] Property usage relative to all extensions with the “notifications” permission. | ||
|
|
||
| [Issue 463](https://github.com/w3c/webextensions/issues/463): Inconsistency in browser.action: windowId key and enable()/disable() arguments | ||
|
|
||
| * [timothy] Feature in Firefox that we'd like to support in Safari, is windowId in the action API. tab > window > manifest. Want to add windowId to all action API methods. enable() method takes tabId integer instead of options object, so suggesting to introduce setEnabled method that takes an object. | ||
| * [rob] I would prefer the alternate option that overloads `enable()` with an options object. | ||
| * [timothy] Works for us too. | ||
| * [carlos] Backwards compatibility? This could throw and break compatibility with existing use. | ||
| * [rob] That's why I'm suggesting to overload - the old signature continues to work, and if someone wants to use the new signature, they can use try-catch and fall back if desired. | ||
| * [carlos] How about resetting, e.g. clearing the title? | ||
| * [rob] Setting to null with windowId should clear it. Should verify this is common behavior. | ||
| * [timothy] Would we consider dropping the current tabId parameter in a future manifest version? | ||
| * [simeon] Yes, I'm supportive of that. | ||
| * [oliver] Personally, the overloading idea sounds nice. I'll follow up with the Chrome team. | ||
|
|
||
| [Issue 464](https://github.com/w3c/webextensions/issues/464): [Proposal: Event priority in Background Service Worker or Event page](https://github.com/w3c/webextensions/issues/464) | ||
|
|
||
| * [simeon] (see issue). One of the questions that I'm curious about is whether this is necessary to expose the install/update state async instead of synchronously. | ||
| * [oliver] I don't think so? | ||
| * [jackie] This is a special case where it would be useful to offer a synchronous way to retrieve install/update status, because an extension can't know whether “onInstalled” is going to fire, or just didn't fire at all. | ||
| * [rob] Multiple things in this issue. The specific case of onInstalled is separate. The general request is to define a specific order that events are dispatched. | ||
| * [simeon] Agreed | ||
| * [rob] Events are queued while the background context is not active. During startup of service worker/event page, we fire startup events, but there's no guaranteed order. This is likely to cause issues for developers as the order will be different than persistent background pages. | ||
| * [timothy] That is something we all do. In Safari we fire onInstalled/onStartup first before other events. | ||
| * [rob] If a method is invoked during event page/service worker startup, are any triggered events dispatched after the event queue is drained? | ||
| * [timothy] We fire all queued events first, and anything that happens after. | ||
|
|
||
| [Issue 466](https://github.com/w3c/webextensions/issues/466): Proposal: allow storing metadata in a static ruleset | ||
|
|
||
| * [maxim] Chrome announced fast-tracking of reviews if only static rules have been changed. Request here is to support additional metadata in a ruleset file. | ||
| * [timothy] We ignore keys we don't know about, so that should be fine. I'm wondering whether we should reserve the metadata key. | ||
| * [oliver] I think it makes sense. But there is one thing: the metadata field is free data; the DNR ruleset has a known format that can be fast-tracked. | ||
| * [rob] I was having exactly the same concern; I do note that it is already possible to store arbitrary metadata by encoding it to a string and storing it in a rule with a never-matching condition. | ||
| * [simeon] Thoughts on comment vs metadata? | ||
| * [timothy] “comment” makes be think about JSON5, which supports comments, but comments disappear after parsing. | ||
| * [simeon] There is also JSONC, which is JSON with comments. | ||
| * [maxim] Andrey was targeting not just comments, but structured data. | ||
| * [oliver] I think you wanted to store converted filter list rules in DNR rules. | ||
| * [dimitriy] That, and other data such as counters for converted rulesets (e.g. counters for number of regular expression rules) | ||
| * [rob] Do these comments need to be included in the ruleset file? Could they be stored separately? | ||
| * [dimitriy] Currently storing in a separate file, but as we understand we would not be able to update separate data for fasttrack review. | ||
| * [rob] Sounds like the only reason for this request is that the Chrome Web Store review process favors updates with only DNR ruleset changes. CWS could also adjust their process to permit specific comment files. | ||
| * [oliver] Having it in the DNR ruleset could also enable a method to retrieve the metadata through the DNR API | ||
| * [rob] But that wouldn't be of use to DNR itself. A 5 MB DNR ruleset file could become 6 MB with metadata, and that all needs to be loaded and parsed when the browser compiles the DNR rules. | ||
| * [oliver] Another option without requiring API changes is to have the external files stored on a server and fetch the metadata at runtime, key based on the extension's version. | ||
| * [maxim] Concerned about the orchestration and maintenance burden. | ||
| * [timothy] The memory constraints are a good point. We are certainly limited on iOS. | ||
|
|
||
| [Issue 467](https://github.com/w3c/webextensions/issues/467): Proposal: change the static ruleset JSON structure | ||
|
|
||
| * [rob] Supportive of this proposal. The current format of having a top level array is not extensible. | ||
| * [kiara] Safari is also supportive. | ||
| * [timothy] I believe we previously discussed having a version number as a top level property, but we can't do that with an array. | ||
|
|
||
| [Issue 468](https://github.com/w3c/webextensions/issues/468): [DNR] Redirect rule does not allow applying other redirect rules to the resulting request | ||
|
|
||
| * [rob] The issue reported is that rules changing query parameters but remain on the same URL do not trigger additional rules. | ||
| * [timothy] We have the same issue. | ||
| * [oliver] I know we support query transforms, why doesn't that work here? | ||
| * [rob] The query transform is part of the redirect. You can modify multiple parts of the request as part of the redirect. … Could introduce a new rule like removeParamsRedirect to address this specific case that would allow fall-through. Curious if this is sufficiently useful? | ||
| * [timothy] I think this is useful. | ||
| * [rob] Firefox could support this, but the design of DNR emphasizes finding and applying a single match. Should consider this as we discuss capabilities. | ||
| * [maxim] As Andrey noted in the original issue, some rules can apply to the same request. | ||
| * [rob] Two issues here. First, is the workaround I suggested sufficient for adGuard? Two, are browsers okay with chaining multiple redirect rules (combining multiple queryTransform options, potentially with an opt-in)? I'd be okay with that from Firefox's perspective. | ||
| * [timothy] I have to go back and talk to our expert. | ||
| * [oliver] I'll follow up with our team. | ||
|
|
||
| [Issue 469](https://github.com/w3c/webextensions/issues/469): request: allow to retrieve a tabId and documentId from the content script | ||
|
|
||
| * [todd] Context here is that you have to ping the background script in order to get this data currently. | ||
| * [oliver] Two questions here. Does the renderer process already have this data? If so, then that's less of a concern. Content scripts run in that process and a compromise would expose more data. If it's already in that process, then there's no additional risk. | ||
| * [rob] There's no API that exposes this data right now, so by design it's not exposed. Exposing it now would impose higher requirements on the implementation. | ||
| * [todd] For clarity, your concern is attacks that leverage this data from an extension, correct? In that case, if extensions expose this data via a round trip to the extension, I'm not sure what the concern is. | ||
| * [oliver] There is a boundary between scripts running in a page and content scripts, but it's weaker because there's no process isolation. So a page exploiting a browser vulnerability could pretend to be a content script and call these APIs. | ||
| * [todd] Host page already doesn't have access to the content script. | ||
| * [oliver] There's some separation, but no additional protection because it's in the same process. | ||
| * [rob] Todd, do you want this data to be available synchronously or asynchronously? | ||
| * [todd] Doesn't really matter, for us it's really the lag with reaching the background. | ||
| * [rob] If that is the case, then a method sounds reasonable to me - it's identical to the content script sending a message to the background and the background mirroring message.sender back. Supportive from Firefox. | ||
| * [timothy] We'd be supportive in Safari. | ||
|
|
||
| [Issue 470](https://github.com/w3c/webextensions/issues/470): Proposal: expose the new tab URL | ||
|
|
||
| * [rob] I'm opposed to the suggestion for the described use case. The new tab URL is not static, and there is not only one. Can be overridden by extensions, and can be different between private and non-private browsing. For the use case a way to query whether the tab should be archivable would be more useful. | ||
| * [carlos] Can't you create a new tab with a blank URL? | ||
| * [rob] Yes, but the same issue exists – the URL is not fixed. | ||
| * [carlos] Cases like (...). Uses in my own extension, it's useful to know if the new tab page is open in order to decide whether or not to override it. | ||
| * [simeon] | ||
| * [carlos] Use case is to not replace the normal new tab page. If the user intends to open a given URL (e..g from an extension popup), some users prefer to replace the new tab page under the popup rather than opening an entirely new tab. | ||
| * [rob] The runtime.openOptionsPage() example, right? Where if the page is already open that is focused. | ||
| * [carlos] Not exactly. Some users prefer if the current new tab page is open, that page is navigated rather than opening another new tab. | ||
| * [rob] I see, you'd like to mimic or ignore the browser's behavior that replaces “blank” new tabs opposed to opening the new content in a new tab (and leaving the blank tab around). | ||
| * [jackie] Instead of exposing the new tab URL, we could provide a static method like `isNewTab()` where this method receives the tab ID or tab object. | ||
| * [timothy] I prefer the proposal where we have a new key on the tab object that tells the developer what it is. Something to easily say this is a new tab page, bookmarks, etc. | ||
| * [simeon] Are you thinking of a single key on the tab object that would have a string value that could represent the state? | ||
| * [timothy] Yes. | ||
| * [rob] Would this be a single value or an array? An overridden new tab page could be both a new tab page and an extension page. | ||
| * [timothy] In Safari even if an extension has overridden it, we know that it was a new tab. | ||
| * [rob] Chrome input? | ||
| * [oliver] Nothing at the moment. The discussion sounds reasonable. | ||
|
|
||
| The next meeting will be on [Thursday, November 9th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=654c2100,3c0) (note: Daylight Saving Time ended). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters