-
Notifications
You must be signed in to change notification settings - Fork 60
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 #548 from w3c/meeting-2024-02-15
Publish minutes of 2024-02-15 meeting
- Loading branch information
Showing
2 changed files
with
161 additions
and
2 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,158 @@ | ||
| # WECG Meetings 2024, Public Notes, Feb 15 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=65cd5400,3c0 | ||
| Call-in details: [WebExtensions CG, 15th February 2024](https://www.w3.org/events/meetings/33c0ebca-0fc1-478b-b826-955a409f2e65/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #535](https://github.com/w3c/webextensions/issues/535), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. | ||
|
|
||
| * **Announcements** (2 minutes) | ||
| * **Triage - 15 minutes** _(Hard cut-off at 20 minutes past)_ | ||
| * [Issue 522](https://github.com/w3c/webextensions/issues/522): Proposal: Give extensions easy access to MediaSession | ||
| * [Issue 523](https://github.com/w3c/webextensions/issues/523): API limitation: content scripts URL matches and History API, Navigation API, BFCache | ||
| * [Issue 527](https://github.com/w3c/webextensions/issues/527): chrome.scripting.executeScript doesn't resolve/reject for frozen state tabs | ||
| * **Timely issues - 10 minutes** _(Hard cut-off at 40 minutes past)_ | ||
| * [Issue 540](https://github.com/w3c/webextensions/pull/540): Add userScripts.execute() API proposal | ||
| * [Issue 433](https://github.com/w3c/webextensions/issues/433): Inconsistency: Alarms API time slipping | ||
| * Chrome 123 uses wall clock time | ||
| * Should we keep the issue open for fixing Firefox sleep behavior and keeping a consistent schedule for repeating alarms? | ||
| * [Issue 401](https://github.com/w3c/webextensions/issues/401): Expose SHA256 value of DownloadItem | ||
| * [Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include a origin trial token | ||
| * **Check-in on existing issues** **- 20 minutes** | ||
| * [Issue 519](https://github.com/w3c/webextensions/issues/519): Proposal: Event.addListener should accept an interface. | ||
| * [Follow up](https://github.com/w3c/webextensions/issues/402#issuecomment-1591619962) on [Issue 402](https://github.com/w3c/webextensions/issues/402): Provide a means to discriminate initiators and destinations belonging to a local (private) network | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Patrick Kettner (Google) | ||
| 3. Simeon Vincent (unaffiliated) | ||
| 4. Philippe Le Hegaret (W3C) | ||
| 5. Giorgio o Maone (Tor, NoScript) | ||
| 6. Richard Worth (Capital One) | ||
| 7. Carlos Jeurissen (Jeurissen Apps) | ||
| 8. Tim Heflin (Keeper) | ||
| 9. David Johnson (Apple) | ||
| 10. Dmitriy Seregin (AdGuard) | ||
| 11. Anton Bershanskyi | ||
| 12. Emilia Paz (Google) | ||
| 13. Maxim Topciu (AdGuard) | ||
| 14. Todd Schiller (PixieBrix) | ||
| 15. Mukul Purohit (Microsoft) | ||
| 16. Dávid Tóta (AdGuard) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Before start of meeting: | ||
|
|
||
| * [plh] I'm from the W3C. We're curious about why this is a CG and not a WG? | ||
| * [simeon] Answering that will take more time than we have on the agenda. I'll invite you to a separate meeting to discuss that. | ||
| * [simeon] Reminder: this is the first meeting with the new agenda format sketched in [issue 531](https://github.com/w3c/webextensions/issues/531). Thanks Oliver for preparing the template and agenda for today! | ||
|
|
||
| [Issue 522](https://github.com/w3c/webextensions/issues/522): Proposal: Give extensions easy access to MediaSession | ||
|
|
||
| * [simeon] Request is to expose controls to MediaSession so that extensions don't need all_urls permission to interact with playback of a tab. | ||
| * [oliver] Interesting capability. For prioritization, having use cases would be good. | ||
| * [rob] Came from a bugzilla issue and we asked them to open a ticket. Niche feature, but sounds useful. Exposing MediaSession could fit within the existing API. Ideal next step is for someone to prepare a proposal and prepare a patch. | ||
|
|
||
| [Issue 523](https://github.com/w3c/webextensions/issues/523): API limitation: content scripts URL matches and History API, Navigation API, BFCache | ||
|
|
||
| * [anton] Is there interest in supporting content scripts in response to changes to the history API? | ||
| * [simeon] In cases of web_accessible_resources, subpaths aren't allowed in match patterns. I'm wondering how that is handled from the perspective of prompting. | ||
| * [rob] web_accessible_resources patterns are only limited in Chrome. Would prefer to address this issue by having the extension inject on all pages of the origin and observe History/Navigation API calls itself. Major problem is that we can't un-run a content script. | ||
| * [oliver] I left a comment with similar things. Offering this at the platform level has a number of issues. | ||
| * [simeon] The resolution here is to document this aspect on MDN. | ||
|
|
||
| [Issue 527](https://github.com/w3c/webextensions/issues/527): chrome.scripting.executeScript doesn't resolve/reject for frozen state tabs | ||
|
|
||
| * [simeon] When scripting.executeScript is run on a frozen tab, execution does not happen immediately. | ||
| * [rob] What is “frozen”? | ||
| * [oliver] When a tab is put in a tab group, the tab is frozen, I don't know the specific meaning with it. | ||
| * [simeon] bfcache also has a similar issue. | ||
| * [oliver] The request here is, if the execution cannot succeed immediately, should the call wait or reject immediately? | ||
| * [simeon] Perhaps we should add a flag to the tab to signal whether the tab is able to handle script injection. | ||
| * [rob] Prone to race conditions. Prefer to expose another property on the options bag. This concern also applies to other cases like permission requests (e.g. in Safari where extension API calls are suspended until host permissions have been granted). Looking at the broader area of request with a delayed response, we should consider how to signal that a call is suspended and/or aborted. Complete API proposal would be welcome. | ||
|
|
||
| [Issue 540](https://github.com/w3c/webextensions/pull/540): Add userScripts.execute() API proposal | ||
|
|
||
| * [emilia] Code injection using user scripts API, programmatically. | ||
| * [rob] I will take a closer look after the meeting; note that this has already been discussed before at [issue 477](https://github.com/w3c/webextensions/issues/477). | ||
|
|
||
| [Issue 433](https://github.com/w3c/webextensions/issues/433): Inconsistency: Alarms API time slipping | ||
|
|
||
| * [anton] Chrome 123 uses wall clock time. | ||
| * [anton] Should we keep the issue open for fixing Firefox sleep behavior and keeping a consistent schedule for repeating alarms? | ||
| * [anton] We can close the issue or keep it around for Firefox. | ||
| * [oliver] Another issue is firing the alarm on a consistent schedule, when repeating. | ||
| * [anton] That is a separate issue. | ||
| * [oliver] From what we discussed before, the alarm should keep going when the device resumes. | ||
| * [anton] Suggest a separate issue to track that. | ||
| * [simeon] Can wpt cover this scenario in tests? | ||
| * [patrick] I don't know from the top of my head. I guess that it might not, depending on the hooks around suspension. | ||
|
|
||
| [Issue 401](https://github.com/w3c/webextensions/issues/401): Expose SHA256 value of DownloadItem | ||
|
|
||
| * [anton] Q: should the hash be an ArrayBuffer or a hex string? Hex string is most common use, ArrayBuffer is more consistent with the crypto.digest API. | ||
| * [rob] I think it should be hex as that's the most common use. It's an implementation detail if the browser chooses to use the same internals. | ||
| * [anton] Should the specifier be case sensitive or not? Prior art potentially supports both approaches. | ||
| * [rob] Case-sensitive. | ||
| * [patrick] Feedback months ago on Chrome's end is to accept the patch, with no strong opinions one way or the other on case sensitivity. | ||
| * [simeon] Are there any cases where case sensitivity is meaningful to distinguish between algorithms. | ||
| * [rob] No. The prevailing pattern is to avoid special input handling, therefore case sensitive. | ||
|
|
||
| [Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include an origin trial token | ||
|
|
||
| * [anton] In Chromium I implemented this, and want to get an API spec … multiple CL. Token applies to all contexts where an extension runs? Background scripts, content scripts, offscreen documents. | ||
| * [patrick] I see an issue with not doing it everywhere. | ||
| * [patrick] When an Origin Trial is requested in Chrome, a hash is provided. Not sure what would happen when a content script is injected in a main world environment. | ||
| * [rob] Main world is always associated with the document. Content scripts have a separate extension context but share the DOM with the web page. Should the token only be evaluated against the extension's origins or is the isolated world a viable injection target? | ||
| * [oliver] Wonder if it might be tricky to say it only affects the content script, not the main world. | ||
| * [simeon] Discussed before in SecureContexts. | ||
| * [rob] Recap: Some APIs are restricted to SecureContexts. Other APIs are tied to secure schemes. With origin trials, you're potentially asking for very powerful APIs. Powerful enough that browsers may not want to expose them to normal web contexts (and processes hosting web content). | ||
| * [rob] Is there any demand for Origin Trials in content scripts? | ||
| * [patrick] Haven't heard demand for it specifically. | ||
| * [simeon] Inclined to restrict exposing Origin Trials in content scripts until there is a clear demand. | ||
| * [patrick] This originally came up in the context of WebSQL deprecation. | ||
| * [oliver] WebSQL in the context of a content script would be associated with the website, not the extension. | ||
| * [oliver] If an extension has a use case for WebSQL in a website, then the website would presumably already have requested it. | ||
| * [patrick] Looks like the consensus is to not offer Origin Trials to content scripts. | ||
| * [rob] What about offscreen documents, sandboxed documents (opaque origins)? | ||
| * [patrick] Offscreen documents would be the same origin as extension pages. I don't know about sandboxed documents. | ||
|
|
||
| [Issue 519](https://github.com/w3c/webextensions/issues/519): Proposal: Event.addListener should accept an interface. | ||
|
|
||
| * [rob] The topic of conditional event listeners has come up before. Could we add first class support for changing the filters on an event? | ||
| * [simeon] An issue is that listeners are not really identifiable. E.g. setTimeout returns a handle that can be passed to clearTimeout. | ||
| * [rob] First class support would require the introduction of an ID that developers could use. | ||
|
|
||
| [Follow up](https://github.com/w3c/webextensions/issues/402#issuecomment-1591619962) on [Issue 402](https://github.com/w3c/webextensions/issues/402): Provide a means to discriminate initiators and destinations belonging to a local (private) network | ||
|
|
||
| * [oliver] Original request was to provide a means to change requests based on whether it goes to the network. Concern in DNR is that it would evaluate too late, since DNR was designed to evaluate before the start of a request. In Chrome the preference is to build a UI for the private network feature. In DNR we're currently working on modifying requests based on response headers, I wonder whether that would make it more viable to support this. | ||
| * [giorgio] There's no webRequest stage where this information is available at the right time. You need to do it when the IP is available, so after connect. We currently use the blocking but async webRequest API in Firefox. Relevant attacks are based on DNS rebinding. Being able to act on the IP is very useful for this case. Ideal stage is after resolution and before data transmission. | ||
| * [rob] 2 questions. Can you think of a declarative API for this? Is DNR the right place for this? | ||
| * [giorgio] Depends on how generic we'd like this feature to be. | ||
| * [rob] Reason for asking is connections can be reused. If you're interested at the connection level, potentially a different API layer may be more appropriate. | ||
| * [giorgio] Both are useful. Sometimes TCP/IP level is useful, sometimes you just want to block an HTTP request. | ||
| * [rob] To move forward with this feature request, it would be best to have a concrete API proposal. | ||
| * [oliver] This feature not being in browsers is a motivation for this request. If we shipped it, would you still want this capability? | ||
| * [giorgio] Until it's implemented and (critically) enforced, we need this. | ||
| * [simeon] Are there existing matching strategies for IP addresses? | ||
| * [rob] CIDR - https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation | ||
|
|
||
| Wrap-up | ||
|
|
||
| * [simeon] Reminder: upcoming in-person meeting in San Diego, [issue 525](https://github.com/w3c/webextensions/issues/525) (March 18-20). | ||
| * [simeon] If you have any thoughts on the new agenda format, please leave feedback in the WECG chat on Matrix or on [issue 531](https://github.com/w3c/webextensions/issues/531). | ||
| * [rob] If you want a topic to be discussed at the meeting, explicitly nominate it on the agenda. I will post an issue on the WECG issue tracker after the end of each meeting, along with the pull request with the meeting notes for the current meeting. | ||
|
|
||
| The next meeting will be on [Thursday, February 29th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=65dfc900,3c0) |
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