-
Notifications
You must be signed in to change notification settings - Fork 54
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2022-05-26 meeting
- Loading branch information
Showing
2 changed files
with
161 additions
and
1 deletion.
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,159 @@ | ||
| # WECG Meetings 2022, Public Notes, May 26 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=628ec300,3c0 | ||
| Call-in details: [WebExtensions CG, 26th May 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220526T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) 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. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 208: Consider common API for push messages across browsers | ||
| ](https://github.com/w3c/webextensions/issues/208)Resurfacing to get Safari's perspective | ||
| * **Other new issues** | ||
| * [Simeon] Intent to participate in [TPAC 2022](https://www.w3.org/wiki/TPAC/2022) | ||
| * [Issue 214](https://github.com/w3c/webextensions/issues/214): Use cases for long-lived connection in service worker? | ||
| * crbug.com/1271154: Is [this Issue](https://bugs.chromium.org/p/chromium/issues/detail?id=1271154#c47) a thing preventing MV3 updates. Seems like a blocker | ||
| * [Issue 212](https://github.com/w3c/webextensions/issues/212): Support dynamic import() in background service worker | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * Oliver: Updates on browser.secureStorage | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 162: Declarative Net Request: disable individual static rules](https://github.com/w3c/webextensions/issues/162) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Tomislav Jovanovic (Mozilla) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Carlos Jeurissen (Jeurissen Apps) | ||
| 4. Craig Lurey (Keeper) | ||
| 5. Frederic Rivain (Dashlane) | ||
| 6. Oliver Dunk (1Password) | ||
| 7. Bastien Granger (Dashlane) | ||
| 8. Jack Works (Sujitech) | ||
| 9. Tim Heflin (Keeper) | ||
| 10. David Johnson (Apple) | ||
| 11. Benjamin Bruneau (1Password) | ||
| 12. Rainer Enders (Keeper Security) | ||
| 13. Simeon Vincent (Google) | ||
| 14. Felipe Erias (Igalia) | ||
| 15. Ellie Epskamp-Hunt (Apple) | ||
| 16. Steven McLintock (1Password) | ||
| 17. Alexei (Privacy Badger) | ||
| 18. Mukul Purohit (Microsoft) | ||
| 19. Jessie Berlin (Apple) | ||
| 20. Larry Xu (Dropbox) | ||
| 21. Bradley Cushing (Dashlane) | ||
| 22. Tyler Carson (Keeper) | ||
| 23. James Hycner (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 208](https://github.com/w3c/webextensions/issues/208): Consider common API for push messages across browsers | ||
|
|
||
| * [jessie] No update on this from Apple yet; when we have an update we'll leave a comment on the issue. | ||
|
|
||
| Intent to participate in [TPAC 2022](https://www.w3.org/wiki/TPAC/2022) | ||
|
|
||
| * [simeon] No issue yet, but TPAC is where the W3C meets. Planning to write a doc to outline our intent to participate and next steps, and share it at the next meeting. | ||
| * [tomislav] Sounds like a good idea. Another opportunity to meet the WECG is during the [Ad Filtering Dev Summit](https://adfilteringdevsummit.com/) (formerly Ad Blocking Dev Summit) a few weeks later in Amsterdam. | ||
| * [simeon] Tentatively planning to participate in the Ad Filtering Dev Summit too. | ||
|
|
||
| [Issue 214](https://github.com/w3c/webextensions/issues/214): Use cases for long-lived connection in service worker? | ||
|
|
||
| * [simeon] In short, issue is about long-lived communication between content scripts and background scripts via ports. Chrome's position continues to be that the background service worker is event-based, and that the 5-minute limit is useful to enforce ephemerality. | ||
| * [rob] Disconnecting the background script's lifetime from the port's lifetime makes the Port API/primitive unreliable. Developers are understandably concerned about this. | ||
| * [simeon] If I hear you correctly, am I hearing that you're suggesting to rework the API to fit in the event-based execution contexts? | ||
| * [frederic] Why can't there be a world where the background sticks around while the extension is doing work? | ||
| * [simeon] I'm currently drafting a document for further discussion with the team. This is a short-term (next year) constraint that extension developers need to work with. Continuing to work, also in this group to address the extension devs' needs. | ||
| * [simeon] (in reply to question about Chrome's MV2/MV3 deprecation timeline) Considering establishing a secondary meeting on the WECG calendar to focus on Chrome-specific issues. | ||
| * [jessie] Timelines etc. are browser-specific and may be discussed elsewhere, as they are not in the scope of this chart. | ||
|
|
||
| crbug.com/1271154: Is [this Issue](https://bugs.chromium.org/p/chromium/issues/detail?id=1271154#c47) a thing preventing MV3 updates. Seems like a blocker | ||
|
|
||
| * [simeon] A Chrome bug where MV3 Service workers are not properly registered after an update. It's a known issue that we are actively working on. Unfortunately no updates or specific resolution timeline yet. | ||
|
|
||
| [Issue 212](https://github.com/w3c/webextensions/issues/212): Support dynamic import() in background service worker | ||
|
|
||
| * [larry] Was discussed in last meeting in the context of upload size limits of Firefox/AMO. This is a follow-up to ask for the browsers' positions on support for dynamic imports in dynamic service workers. | ||
| * [simeon] (Chrome) Service workers owners are not opposed to extension-specific behaviors different from what's specified for the open web. Right now dynamic imports are disallowed by the Service worker spec, but there is sufficient utility and need in the extensions area, to be supportive of this. | ||
| * [rob] (Firefox) We'd also be supportive of this feature in extensions if possible. | ||
| * [jessie] (Apple) I need to take this back to the team, especially the WebKit team to get an answer to this. | ||
| * [larry] Would this also apply to the open web? | ||
| * [rob] In this group it seems that there is a common positive sentiment towards this API, but we cannot speak on behalf of the open web. If you'd like this to be part of that, open an issue in the Service Workers repo, https://github.com/w3c/ServiceWorker. | ||
|
|
||
| Updates on browser.secureStorage | ||
|
|
||
| * [oliver] Two updates on the proposal. First, [PR 186](https://github.com/w3c/webextensions/pull/186) to update the polyfill. There was an open question on whether the polyfill should encrypt data at rest. Currently planning not to provide this. To address feedback that "polyfill" is the wrong term for what this library is doing, suggesting we call it a "mock". | ||
| * [oliver] Second, [issue 190](https://github.com/w3c/webextensions/issues/190), diverged into two topics, one of which was whether the API should allow developers to specify the method of authentication (pin, touch, etc.). After some internal discussion, we are comfortable deferring to the browser to select a reasonably secure option given a set of constraints on level of security. Suggest using three levels of security. | ||
| * [tomislav] I don’t think we need to “hide” from extensions which type of authentication was used. I believe the reason for the use of generic categories on web/android is to preserve the api surface over changing hardware implementations. So my proposal is for requests from extensions for authentication to use generic categories, but browsers could respond with the actual specific mechanism/technology used (fingerprint vs face id), even if that part can be different/not fully standardized between platforms. | ||
| * [mukul] Tomislav, what's your suggestion here? Agree with the naming or something else (e.g. “strong”)? | ||
| * [tomislav] Don't have a strong opinion on the naming. | ||
| * [rob] Might be useful to get feedback from other extension developers (e.g. other password managers) and browsers, before proceeding here. | ||
| * [craig] Expect enterprises to want to be able to require authentication, but beyond that don't expect them to require specific methods. | ||
| * [oliver] Would it make sense to split the API into biometrics and storage? | ||
| * [tomislav] I wouldn't split it up for now, until we've a better understanding of use cases and applications. | ||
| * [simeon] What are the next steps and what can we do to help? | ||
| * [oliver] Will rename the lib to "mock" for clarity and attempt to land the PR. Feedback from extension developers, and from browser vendors. After that, this will need to be reviewed by the browser vendors. Assistance in that process is welcome. | ||
|
|
||
| [Issue 162](https://github.com/w3c/webextensions/issues/162): Declarative Net Request: disable individual static rules | ||
|
|
||
| * [felipe] As mentioned in the past meeting, I have collected real-world examples of problematic rules. Using dynamic rules to override problematic static rules may have undesirable side effects. Examples are typos, overly broad URL match rules and conflicts with other websites when the rule is overriden. | ||
| * [felipe] Finished the list just before the meeting and shared it at https://github.com/w3c/webextensions/issues/162#issuecomment-1138669359. | ||
| * [jessie] Has there been any proposed mitigations implemented to counter expensive rule compilation. | ||
| * [felipe] Not yet, but can add things like batching, rate-limiting, etc. Use case that I am targeting is cases where updates are too frequent to be solved through extension updates, but not too frequent like every few minutes or so. | ||
| * [jessie] May need something along those lines. Tim commenced something before about a dynamic rule overriding a static rule, or rate limiting it to only being called once every N hours. | ||
|
|
||
| (out of topics after 40 minutes) | ||
|
|
||
| * [simeon] Let's open the floor to open discussion. | ||
|
|
||
| Lack of progress on spec | ||
|
|
||
| * [jessie] Would love to see steps towards specifying what already exists, to make progress on the spec. | ||
| * [tomislav] I agree, and as one of the editors I'm going to see how I can start that. | ||
| * [carlos] I've started before with the initial manifest keys, will follow-up with creating a PR for optional_host_permissions | ||
|
|
||
| Mozilla’s Developer Preview of MV3 | ||
|
|
||
| * [rob] We have published a blog post on our implementation of MV3 https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ | ||
| * [jessie] Great to see that post, congrats! | ||
| * [tomislav] Please report any issues. | ||
|
|
||
| Host permissions opt-in in MV3 | ||
|
|
||
| * [simeon] Related, there was some discussion about host permissions in the WECG channel on Matrix ([link to discussion](https://matrix.to/#/!GNwloPguLwrQNcsyDH:mozilla.org/$Kq9mmedK1Sy9kOlhH6NFI8YX-TT4h9C6OeR5KKEv6zA?via=mozilla.org&via=matrix.org&via=rivoal.net)). Anything worth mentioning here? | ||
| * [tomislav] Host permissions are not automatically granted on install. Currently the UI to opt in on install is not obvious, but we are planning to improve it. Host permissions in manifest.json are not automatically granted to MV3 extensions; users can opt in. | ||
| * [alexei] How do you see it working for (global) content blocking extensions that are supposed to need access to all hosts? | ||
| * [tomislav] Use case still supported via UI (about:addons). Still working on it. | ||
| * [bradley] What's the difference between asking upfront and asking users to do an extra step to grant permissions via the UI? | ||
| * [tomislav] When users want to install something, they will say yes to anything in the install flow. When they want some functionality, they should have some control that's not just “access to everything by default”. | ||
| * [craig] Enterprise will want to control this. | ||
| * [simeon] Firefox is not the only one here; In Chrome we already have the feature, but not enabled yet at install-time. In the future we are planning to change this for both MV2 and MV3, to require users to opt in. | ||
| * [jessie] (Apple) Safari is already shipping this behavior. | ||
| * [bradley] Will users be limited to having to run their extensions on click, or will they be able to enable the current experience. | ||
| * [simeon] In Chrome it will default to on click, but users can customize. | ||
| * [tomislav] In Firefox the (UI) implementation is not final, but users would be in control. | ||
| * [craig] Should be really clear to the user. An example of another issue of user confusion is that action button pinning is not clear. We've seen even technical users have encountered don't necessarily understand this. | ||
| * [alexei] What prevents extensions from lying? | ||
| * [jessie] Store policies; the outlook of extension takedown for example. | ||
| * [alexei] Making extensions going through hoops? | ||
| * [tomislav] Not extensions, but users. | ||
| * [simeon] We are at time now, I'd gladly continue this conversation in the WECG chat room. | ||
| * [craig] Which chat room? | ||
| * [rob] The WECG chat room is at https://chat.mozilla.org/#/room/#wecg:mozilla.org. | ||
| * ([link to post-meeting discussion in WECG chat](https://matrix.to/#/!GNwloPguLwrQNcsyDH:mozilla.org/$yBjpINqK1FfqHYTcttJ-EIbhcmKXjvdInjiesUT42nA?via=mozilla.org&via=matrix.org&via=rivoal.net)) | ||
| * [jack] will our extension stop working suddenly? | ||
| * [simeon] In Chrome, existing installations will continue to have the same host permissions grants. This change only affects new installations as it's changing the install time grants. | ||
| * [jack] we already use dynamic permission requesting, but looks like browser want to limit it to activeTab? | ||
| * [simeon] The intent is to give users direct control over when and where their extensions run. Our view is that by defaulting to only giving extensions access to sites on click, we're giving users direct control. If they want an extension to do things without their direct invocation, they can, but that should be a user choice, not a developer one. | ||
| * [jack] does `chrome.permission.request` continue to work like today? for new installs | ||
| * [simeon] Yes, `permission.request()` is how extensions can ask the user for host permissions or optional permissions at runtime both today and in the new model. | ||
|
|
||
| The next meeting will be on [Thursday, June 9th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=62a13800,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