From 392023638ad603561769a10ef90bb9fb2cab5ac4 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 3 Mar 2022 19:03:36 +0100 Subject: [PATCH] Publish minutes of 2022-03-03 meeting --- _minutes/2022-03-03-wecg.md | 127 ++++++++++++++++++++++++++++++++++++ _minutes/README.md | 3 +- 2 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 _minutes/2022-03-03-wecg.md diff --git a/_minutes/2022-03-03-wecg.md b/_minutes/2022-03-03-wecg.md new file mode 100644 index 00000000..dd8b84d4 --- /dev/null +++ b/_minutes/2022-03-03-wecg.md @@ -0,0 +1,127 @@ +# WECG Meetings 2022, Public Notes, Mar 3 + + * Chair: Simeon Vincent + * Scribes: Rob Wu + +Time: 8 AM PST = https://everytimezone.com/?t=62200500,3c0 +Call-in details: [WebExtensions CG, 3rd March 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220303T080000) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #165](https://github.com/w3c/webextensions/issues/165), [other issues](https://github.com/w3c/webextensions/issues) + +The meeting will start at 3 minutes after the hour. + + * **Carry-over from previous meetings** + * None + * **Other new issues** + * **Open discussion queue (add yourself at the bottom)** + * [tophf] Produce evidence/statistics on why persistent background scripts are bad for performance + * [Issue 154](https://github.com/w3c/webextensions/issues/154): Proposal: browser.secureStorage API + [PR 167](https://github.com/w3c/webextensions/pull/167): Add browser.secureStorage proposal + * [simeon] [Chrome's Off-screen Documents Proposal](https://docs.google.com/document/d/1b-I-vXq2h7OFFmus78jZXIWcKilKJLKLeGplnY9wt7k/edit) + * [PR 170](https://github.com/w3c/webextensions/issues/170): Offscreen Documents Proposal + * [carlos] WebRequest API + * https://github.com/w3c/webextensions/issues/157 + * https://github.com/w3c/webextensions/issues/164 + * https://github.com/w3c/webextensions/issues/168 + * https://github.com/w3c/webextensions/issues/169 + * **Check-in on ongoing issues** + + +## Attendees (sign yourself in) + + 1. Jack Works (Sujitech) + 2. Simeon Vincent (Google) + 3. Timothy Hatcher (Apple) + 4. Rob Wu (Mozilla) + 5. Bradley Cushing (Dashlane) + 6. Oliver Dunk (1Password) + 7. Krzysztof Modras (Ghostery) + 8. Bastien Granger (Dashlane) + 9. Giorgio Maone (NoScript) + 10. Craig Lurey (Keeper) + 11. Carlos Jeurissen (Jeurissen Apps) + 12. Tomislav Jovanovic (Mozilla) + 13. Frederic Rivain (Dashlane) + 14. Todd Schiller (PixieBrix) + 15. Philipp Claßen (Ghostery) + 16. Dave Herold (Keeper) + 17. Zane Bond (Keeper) + 18. Alexei (Privacy Badger) + 19. Steven McLintock (1Password) + 20. Tyler Carson (Keeper) + 21. Nir Nahum (WalkMe) + 22. Rainer Enders (Keeper Security) + 23. Sergey Aldoukhov (Keeper Security) + 24. Mukul Purohit (Microsoft) + 25. Igor Oleinikov (Grammarly) + + +## Meeting notes + +Discussion item: Evidence for performance claims about persistent background scripts + + * [tophf] Produce evidence/statistics on why persistent background scripts are bad for performance + * [rob] Tophf isn't here, but I have seen sentiment from developers who are seeking evidence for why Google is pushing for DNR over blocking webRequest. + * [simeon] This is not a performance issue, but increasing the privacy guarantees of the platform by moving towards declarative APIs and moving away from APIs that give data to extensions. + * [craig] Concerned about this impact given Chrome's deprecation timeline + * [krzysztof] MV3 is not improving privacy nor performance, rather harming privacy-protecting extensions + * [craig] Examples of detrimental effects on performance (overhead of initializing extensions instead of keeping in memory, e.g. password managers). + * [simeon] The storage.session API addresses that class of concerns. + * [simeon] I can try to get back to Chrome's extension team to get more concrete evidence / documentation on this. + * [alexei] This is a trust issue. Google's actions thus far have not inspired trust. + * [jack] MV3 not feature complete, deadline with MV2, not confident that we can resolve issues in time before Chrome fixes its issues. + * [craig] Major issue is the deadline. Never seen a transition like this in my 20 years. + * [mandoline] What about the vast majority of developers not represented in these meetings? Will their extensions just stop working one day because of Google's poor communication? + * [simeon] I think the sentiment echoed here is representative of the community. Other developers are also concerned about the timeline. + * [hycner] When I first heard about Manifest V3 I assumed it was a small change. + * [hycner] Asking whether it's possible to dump Service worker memory to disk and load that on start + * [simeon] That is technically not feasible. + * [simeon] We have to move to a service worker context because it's closer to reality. This is about setting clearer expectations about what the browser can provide. Limited event pages is another example. + * [craig] Exceptions for Password Managers like Accessibility has been there. Can we have similar exceptions for Service Worker? + * [simeon] This would also depend upon the host system + * [jack] Does Chrome have information about how many extensions don't upgrade to MV3 and where extensions can cease working? + * [simeon] Don't know whether I have that information, and even if I had, whether it can be shared. + * [bradley] Extension termination was exceptional, the new design forces extension developers to treat an exceptional case as a standard case, which is a burden. + * [tomislav] Firefox for Android has the issue where the browser can be killed by the OS, e.g. memory pressure, with no controls over it. Our backup solution is to run extensions in the main process. This is not a viable long-term solution, e.g. extensions with memory issues or security issues. Therefore extensions need to be resilient by design. Limited event pages are somewhere in the middle, a balance. + * [simeon] Tomislav made good points, ultimately we cannot guarantee that a process cannot be terminated. I think that you are referring to the 5-minute cut-off. That is something that I try to work with the engineering team to see how we can alleviate the concerns. E.g. recently native messaging ports extend the lifetime of the Service worker. With this change we can also consider supporting lifetime extensions in other cases. + +[Issue 154](https://github.com/w3c/webextensions/issues/154): Proposal: browser.secureStorage API + + * [oliver] [PR 167](https://github.com/w3c/webextensions/pull/167): Add browser.secureStorage proposal + * [oliver] Got early feedback from Simeon and Rob, more feedback is welcome. Can it be merged? + * [simeon] I already approved. + * [tomislav] I'll take a look and merge if there are no objections + * [mukul] Fine by me. + * [oliver] I don't have write access to the repo, so I don't know if I can approve/merge future changes. + * [simeon] You can already approve PRs, we can help with merging. + * [oliver] Any news from the vendors here? + * [simeon] On the Chrome side: this is interesting and we are open to it, but we don't have time to prioritize and work on it. If a patch has been submitted we can take a look. + * [tomislav] In other proposals, a polyfill can help with getting more weight behind a proposal, even if parts are not supported. + * [oliver] That makes sense. The current proposal may be lacking in functionality, e.g. on data deletion. + +[Issue 170](https://github.com/w3c/webextensions/issues/170): Chrome's Off-screen Documents Proposal + + * https://docs.google.com/document/d/1b-I-vXq2h7OFFmus78jZXIWcKilKJLKLeGplnY9wt7k/edit + * [simeon] Alternative proposal to the Limited Event Page proposal ([issue 134](https://github.com/w3c/webextensions/issues/134)). Allow extensions to spawn an off-screen DOM context with lifetime independent of Service workers. In some sense this is a temporary solution, but on the other hand we expect this to be a capability that's part of the platform for years to come. It's expected to be a temporary context (not event-based), but not tied to the duration of the browser. Typically for use cases where it's active to do some work and suspended when not needed. Other difference is that the context does not have full access to browser extension APIs, so the Service worker would still be the primary point to use extension APIs, and message passing is used to link the two. + * [simeon] When instantiating an offscreen context, extensions should specify a “reason”. This is an important part of the API so that the browser can message to users why an extension uses this capability. The document starts with a small list of reasons, but we expect to grow this list with the community to be more complete. + * [jack] What are the expected timelines of this proposal? + * [simeon] Don't know about the timeline. This proposal is about supporting DOM-based use cases that cannot be supported in Service workers. We'd like to support this functionality sooner than later, but I'll ask the engineering team. + * [bradley] Guarantee that a task can be run from beginning to end where possible (e.g. outside OS pressure)? + * [simeon] … This could be used to run longer-running operations. + * [rob] Could you flesh out the Github description, so we can revisit this topic at the next meeting? + * [tomislav] To clarify Chrome's intentions, this is meant to be an API to support task-based use cases. Secondly, this is a tool for transition, to support use cases until Service workers have kept up with the functionality. + * [mandoline] How does that work? We have to transition to this and move to something else later? Do we have to keep rewriting our extension all the time? + * [craig] It's unreasonable to impose deadlines and force rewrites on companies. + * [rob] Simeon (Google) mentioned multiple years for the offscreen context API, the goal is that eventually most use cases can be served in Service workers. + * [rob] At Mozilla, we believe that limited event pages can be a more fitting transition tool, to achieve the goal of extensions that are resilient by design (against termination). + * [simeon] Communication between the extension engineering team and users is my main job, would love to hear how we can communicate better and set expectations. + * [craig] I'd look at Android, which does a pretty good job of communicating major breaking changes. + * [alexei] It would help to start by not launching an unfinished, broken product while imposing an aggressive deprecation timeline. + * [mandoline] Where is the dialogue between Chrome and extension developers? Conversation is only one way as it is now. + * [nir] I think it would help to have a decision maker from Chrome's engineering team present. That would help increase accountability and improve our ability to trust what is being shared by Google + * [tomislav] What are the next steps? Commenting on the issue / doc? Timeline for when feedback is open? + * [simeon] Doc is closed for comments because that could be unwieldy, it would be best to use the issue for discussion. There are parts that we are flexible on, and parts that are less flexible. I'll put the context in the issue. + +The next meeting will be on [Thursday, March 17th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=62327a00,3c0). diff --git a/_minutes/README.md b/_minutes/README.md index 75765e5a..a8c6f4f6 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -* 2022-03-03 at 8 AM PST = https://everytimezone.com/?t=62200500,3c0 - 2022-03-17 at 8 AM PST = https://everytimezone.com/?t=62327a00,3c0 +- 2022-03-31 at 8 AM PST = https://everytimezone.com/?t=6244ef00,3c0 ## Past meetings +* 2022-03-03 ([minutes](2022-03-03-wecg.md)) * 2022-02-17 ([minutes](2022-02-17-wecg.md)) * 2022-02-03 ([minutes](2022-02-03-wecg.md)) * 2022-01-20 ([minutes](2022-01-20-wecg.md))