-
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 #417 from w3c/meeting-2023-07-06
Publish minutes of 2023-07-06 meeting
- Loading branch information
Showing
2 changed files
with
170 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,167 @@ | ||
| # WECG Meetings 2023, Public Notes, Jul 6 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=64a60400,384 | ||
| Call-in details: [WebExtensions CG, 6th PatriJuly 2023](https://www.w3.org/events/meetings/51a7d2ff-e00d-462b-9071-73b93e78b053/20230706T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #409](https://github.com/w3c/webextensions/issues/409), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields | ||
| * **Other new issues** | ||
| * [Issue 411](https://github.com/w3c/webextensions/issues/411): Exposing WebGPU API to extension ServiceWorker | ||
| * [Issue 412](https://github.com/w3c/webextensions/issues/412): Lack of data and features in Chrome.tabs API | ||
| * [Issue 414](https://github.com/w3c/webextensions/issues/414): Specifying css origin as USER in declarative/registered content scripts | ||
| * [Issue 415](https://github.com/w3c/webextensions/issues/415): Allow to cancel method calls | ||
| * [Issue 416](https://github.com/w3c/webextensions/issues/416): Introduce runtime.waitUntil API to keep background service worker / event page active during a specific task | ||
| * [PR 413](https://github.com/w3c/webextensions/pull/413): Update chair and editor information | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * [Issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 361](https://github.com/w3c/webextensions/issues/361): Add an API to integrate with the Credential Management Web API | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Rew Islam (Dashlane) | ||
| 3. Luke Warlow (Unaffiliated) | ||
| 4. Timothy Hatcher (Apple) | ||
| 5. Giorgio Maone (NoScript, Tor) | ||
| 6. Oliver Dunk (Google) | ||
| 7. Tomislav Jovanovic (Mozilla) | ||
| 8. Patrick Kettner (Google) | ||
| 9. Steven McLintock (1Password) | ||
| 10. Simeon Vincent (Unaffiliated) | ||
| 11. Tim Heflin (Keeper) | ||
| 12. Benjamin Bruneau (1Password) | ||
| 13. Jackie Han (No affiliation) | ||
| 14. Rob Hudson (Apple) | ||
| 15. Carlos Jeurissen (Jeurissen Apps) | ||
| 16. Mukul Purohit (Microsoft) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields | ||
|
|
||
| * [timothy] I still need to follow up with the WebKit folks to see if this is something we want to consider. | ||
| * [timothy] In my opinion, if we want to support wildcard TLDs, it would make sense to not limit this feature to DNR, but also other APIs that accept domains. | ||
| * [tomislav] Thinking of using a list of known entities. | ||
| * [patrick] Spoke with Chrome engineering; sharing the same concerns as Rob brought up in the last meeting about perf concerns, and the impact of overly broad matching. E.g. people were not realizing that a wildcard matches many domains. Chrome leaning towards neutral-negative. | ||
| * [simeon] I'd like to focus on the specific use case without broadening it. E.g. content scripts could get an allowance for first-party sets. | ||
| * [patrick] Agree. I think we'd need substantial benefits to get buy in. | ||
| * [rob] Would it be feasible for an extension to declare a group of domains? | ||
| * [timothy] So you could define a trackers list for a given company and expand that in individual rules? | ||
| * [rob] Right. The API would allow the extension to define a list of domains for an identifier/group, and the list of domains in a rule condition would be expanded at rule compilation time. | ||
| * [timothy] I would be onboard with that. Reduces scope and puts it in the developer. | ||
| * [oliver] I'd be interested in hearing from the developer whether this would help them. | ||
| * [tomislav] IMO most compelling use case is matching associated domains. It's easier to ask for <all_urls> than ask for all Google domains. The list is unbound and is confusing to users. | ||
| * [oliver] I can't imagine having a built-in list of domains in the browser. | ||
| * [simeon] Thinking back about Timothy's request and the other discussion - let's stick with the specific scope of the issue (DNR-specific). | ||
| * [patrick] If the main issue is with the regexFilter limit, then we'd be more inclined to bump the regexFilter limit rather than adding a new feature. | ||
| * [simeon] Final thought: if devs could define a domain list that rules consume, perhaps static rules could be amended in a dynamic rule or through a new method. | ||
|
|
||
| [Issue 411](https://github.com/w3c/webextensions/issues/411): Exposing WebGPU API to extension ServiceWorker | ||
|
|
||
| * [timothy] Probably not much to talk about; the consensus appears to be that we should enable the feature once enabled in Service workers on the web platform. | ||
| * [tomislav] Agreed. | ||
|
|
||
| [Issue 412](https://github.com/w3c/webextensions/issues/412): Lack of data and features in Chrome.tabs API | ||
|
|
||
| * [timothy] Asks about mute state and “record”? | ||
| * [rob] I believe that “record” is referring to recording media. | ||
| * [simeon] There is context in the Chromium thread. User muting tab vs extension muting tab are distinct. Also if Chrome is playing music, an indicator appears in the toolbar, and extensions have no way to interact with that. Disconnect between end-user capabilities, extension capabilities and how they interact. | ||
| * https://groups.google.com/a/chromium.org/g/chromium-extensions/c/brg6LX0baHk/m/eUp4TuD-BQAJ | ||
| * [oliver] Apparently there is also a feature to mute a tab vs a domain, and an extension cannot control that. I'd be interested if other browsers have specific capabilities. | ||
| * [timothy] We don't have muting by domain, only muting by tab. | ||
| * [tomislav] We don't have muting by domain either. | ||
| * [oliver] The second bullet point (domain mute feature) sounds like a browser-specific issue. The first one looks reasonable. | ||
| * [simeon] I'll post a comment to request to strike out the second bullet point. | ||
| * [rob] And please also ask whether they can clarify the request. The issue currently looks like a list of issues, without a clear feature request or shape of API. | ||
|
|
||
| [Issue 414](https://github.com/w3c/webextensions/issues/414): Specifying css origin as USER in declarative/registered content scripts | ||
|
|
||
| * [timothy] At least in Safari, they are already USER styles. | ||
| * [simeon] I don't think Chromium supports USER styles. | ||
| * [rob] The capability (css origins user/author) are already available in other APIs. I don't see any issue with offering the feature in the declarative versions as well. | ||
| * [timothy] I should revisit Safari's implementation, to default to the AUTHOR level and allow switching to USER with this new feature. | ||
| * [oliver] Also supportive from Chrome's perspective. | ||
|
|
||
| [Issue 415](https://github.com/w3c/webextensions/issues/415): Allow to cancel method calls | ||
|
|
||
| * [timothy] About the ability to cancel pending long-running API calls, referencing the AbortSignal API. | ||
| * [timothy] I am supportive about this request. In Safari several extension APIs are long-running due to the API calls being blocked on getting user consent. Having the ability to cancel long-running API calls would be beneficial. | ||
| * [tomislav] Does calling abort before execution guarantee that a pending script execution does not execute? Is the complexity worth the potential benefits? | ||
| * [simeon] I would think of this expressing developer intent. E.g. canceling a permission prompt rather than leaving it dangling somewhere. | ||
| * [tomislav] I think that the browser would be in a better position to fix this, e.g. with timeouts. | ||
| * [timothy] Indeed we have a timeout in Safari. | ||
| * [tomislav] I'd support that, e.g. for permission requests. If the extension triggers an action and then walks away, then returns 15 minutes later, then the context is not obvious any more. | ||
| * [simeon] Are you saying that the browser should enforce timeouts. | ||
| * [tomislav] If an extension provides one. | ||
| * [rob] AbortSignal is a web platform feature that exists independent of extension APIs. There could be other situations where an extension wishes to retract a request, such as conditions that motivated the request becoming invalidated. | ||
| * [tomislav] Agreed, except not in a general case. Abort would only make sense in very few APIs. | ||
| * [rob] I meant a general API rather than a new API shape for every method. | ||
| * [simeon] I can imagine methods taking an abort signal in the options when options exist. | ||
| * [rob] Firefox: positive or neutral? | ||
| * [tomislav] Firefox: positive, with the caveat that this only exists in specific APIs. | ||
| * [patrick] Let's ask the developer for an explicit list of APIs where this would be desired. | ||
| * [timothy] Safari: supportive, also in specific APIs, not as a generic concept. | ||
|
|
||
| [Issue 416](https://github.com/w3c/webextensions/issues/416): Introduce runtime.waitUntil API to keep background service worker / event page active during a specific task | ||
|
|
||
| * [rob] See issue. waitUntil proposal. Don't want to hook into several web platform features to extend the lifetime, behavior not obvious to developers either. Want to discuss whether we want the API and what restrictions there should be, if any. | ||
| * [timothy] Safari supportive. Prefer specific method like the one proposed, over updating web platform API implementations. | ||
| * [oliver] Wondering why runtime.waitUntil instead of an event.waitUntil. | ||
| * [rob] Extensions don't have an event object, so we can't expose waitUntil on events like ExtendableEvents in service worker events do. From the implementation point of view, we can set a flag prior to detect event dispatch and unset the flag immediately thereafter, and look up the flag in the waitUntil method to enforce “only in an event” restriction. | ||
| * [rob] Wondering whether we should limit to events or e.g. allow top-level calls. | ||
| * [timothy] | ||
| * [simeon] Detect and restrict to event handlers invoked by the browser. | ||
| * [rob] Extensions can trivially trigger an event. How much value is there? | ||
| * [simeon] E.g. a callback in storage.onChanged. Can we detect the call being part of an event chain? | ||
| * [timothy] Rob's strawman wouldn't have the issues that Simeon is trying to prevent. | ||
| * [oliver] Chrome would probably be more supportive if it is tied to an event rather than a top-level call. | ||
| * [rob] In the issue I also mentioned the possibility of requiring justification, e.g. for reviewers / developers. Is that something we should consider? | ||
| * [simeon] I'm torn. When provided, they're justifications are nice. In the offscreen documents API where there is a reason requirement, often in practice most developers just use a dummy value. Without a place where developers actually see this value being used, there's little motivation for them to provide it. | ||
| * [rob] Could be exposed in logging or as part of a performance timeline. | ||
| * [simeon] I like that. Provides a concrete reason & utility to developers. Even if it's not perfect for this use case, that string could also be used in user-facing UI to explain that an operation is taking an especially long time. | ||
|
|
||
| [PR 413](https://github.com/w3c/webextensions/pull/413): Update chair and editor information | ||
|
|
||
| * [timothy] Correct Simeon's affiliation: Independent instead of Google, add Oliver as Google's official representative, and moved a section for readability. Everyone has approved it, so it can be merged. | ||
| * [simeon] I'll merge it now. | ||
|
|
||
| [Issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state | ||
|
|
||
| * [oliver] There were 3 proposals in this issue in the past: adding onInstalled + new reason (opposed). Adding a new onEnabled event. Our position is to implement onEnabled, and a new event as a home for initialization logic. | ||
| * [tomislav] Why both, if there is a generic catch-all event with a reason parameter? | ||
| * [oliver] Literally just completeness. | ||
| * [tomislav] Ah, convenience and completeness. Sounds good. | ||
| * [rob] Since this is a new event, can we support migrations or data loss in this event? I'm thinking of supporting cases where data migrations can be long-running. | ||
| * [oliver] Haven't personally thought about this. | ||
| * [timothy] Supportive of both events. | ||
|
|
||
| [Issue 361](https://github.com/w3c/webextensions/issues/361): Add an API to integrate with the Credential Management Web API | ||
|
|
||
| * [timothy] Safari is opposed; we prefer credential providers to use the OS APIs, so that the functionality is not limited to browsers. | ||
| * [oliver] At Chrome, integrating at the system level would make sense. | ||
| * [tomislav] On iOS and Android there are unified APIs, but how about desktop? | ||
| * [timothy] macOS and iOS have dedicated credential manager APIs. | ||
| * [oliver] Same in Chrome: use the platform-specific APIs if available. | ||
| * [luke] Which specific credential types the Apple platform APIs supported. Password only or Passkey along with potentially TOTP as well? Would make to use platform-specific APIs to register passkeys if available. | ||
| * [rew] Hi, I'm from Dashlane. On Safari we have a native app, so that would work in system APIs. On other platforms we don't have a native app, and are forced to monkey-patch methods in content scripts. We'd like to manage passkeys through an extension. We're fine with monkey patching on chromium browsers for the time being, it works great in the simple use case, which is the most common. And happy to plug into macOS APIs when they're available for Safari | ||
| * [oliver] If you haven't spoken with WebAuthn folks I can put you in touch with them. | ||
| * [rew] I'm already in touch with them. | ||
| * [simeon] A concern here is that this stance implies that extensions must compete with the native browser UI. Every password manager would have UI interfering with each other. IMO this leaves end users in a very undesirable state. | ||
| * [tomislav] As a cross-platform browser without a separate OS, we'd be interested in exploring this. With the caveat that I haven't chatted with our platform engineering team about this. | ||
| * [simeon] Given Safari and Chrome's stance, I wonder whether the browsers should hook up in the underlying OS platform APIs. | ||
| * [timothy] But the browser would have to be running in the background. Which is why we are opposed to this. | ||
| * [oliver] If another browser such as Firefox wants to champion this, I'd be interested in following along. I was thinking that because Safari and Chrome prefer OS integration, that it wouldn't make sense to discuss implementation details now. | ||
|
|
||
| The next meeting will be on [Thursday, July 20th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64b87900,384). |
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