Publish minutes of 2022-03-03 meeting #171
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,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? | ||
|
There was a problem hiding this comment. Should "mandoline" here and elsewhere be updated to Frederic? There was a problem hiding this comment. I wrote "mandoline" because that was the Zoom name. There was a problem hiding this comment. @ghostwords I want to merge this PR, and this is the only pending issue. Are you sure that these comments should be attributed to Frederic? There was a problem hiding this comment. I thought that was the person speaking in "mandoline", but I could be wrong! There was a problem hiding this comment. I'd suggest that land the minutes as is and follow up with Dashlane folks to see if we should update "mandoline" in a separate PR. |
||
| * [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). | ||
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an extension maintainer, this doesn't really strike confidence that everything is going to be resolved by next year. As mentioned by
craig, "It's unreasonable to impose deadlines and force rewrites on companies". A fake deadline to scare everyone into moving may be even less respectful. From my POV it would be better to compel developers with promises of better x, y, z, that could give products a competitive edge in their category.The fact that extensions can no longer be updated, without exception, and the fact that chrome is now aggressively stating in the errors section of the developer console that MV2 extensions will no longer work come next year means that one must hedge bets.
There's a limited event page proposal that is implemented by Mozilla/Apple already that gave me some hope there might be a reasonable path forward one could follow without overdue (edit: overly paying) attention, but Google (who seems to chair this committee) is already proposing something different @ https://docs.google.com/document/d/1b-I-vXq2h7OFFmus78jZXIWcKilKJLKLeGplnY9wt7k/edit
This leaves me with the impression that I'll have to hawk this evolution and prepare for a service workers only scenario, (edit: while hoping the "limited event pages" proposal pans out).
As part of the review process for extensions it's already standard to have to justify use of permissions. Could there not be an extension of the existing (working just fine) api for a while longer provided there is a reasonable justification? If that seems like a lot of work ...
Currently, it takes very little extra work (in the scheme of things) to support multiple platforms with an extension. The future is now uncertain.