Skip to content

Latest commit

 

History

History
155 lines (135 loc) · 12.8 KB

2022-03-17-wecg.md

File metadata and controls

155 lines (135 loc) · 12.8 KB
Raw

WECG Meetings 2022, Public Notes, Mar 17

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=62200500,3c0 Call-in details: WebExtensions CG, 17th March 2022 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
  • Other new issues
    • [oliver] browser.secureStorage
      • Thanks to Dashlane and Keeper for adding their support, clear this is something the entire password management industry wants
      • PR 183: Remove Proposal 1 from browser.secureStorage
      • PR 186: Add polyfill for browser.secureStorage
  • Open discussion queue (add yourself at the bottom)
    • None
  • Check-in on ongoing issues
    • None

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Oliver Dunk (1Password)
  3. Rainer Enders (Keeper Security)
  4. Timothy Hatcher (Apple)
  5. Zane Bond (Keeper Security)
  6. Carlos Jeurissen (Jeurissen Apps)
  7. Frederic Rivain (Dashlane)
  8. Richard Worth (Capital One)
  9. David Hénot (Dashlane)
  10. Craig Lurey (Keeper)
  11. Steven McLintock (1Password)
  12. Philipp Claßen (Ghostery)
  13. Tyler Carson (Keeper)
  14. Tim Heflin (Keeper Security)
  15. Jane Yao (1Password)
  16. Igor Oleinikov (Grammarly)
  17. Krzysztof Modras (Ghostery)
  18. Bradley Cushing (Dashlane)
  19. Bastien Granger (Dashlane)
  20. Alexei (Privacy Badger)
  21. Jack Works (Sujitech)
  22. Simeon Vincent (Google)
  23. Tomislav Jovanovic (Mozilla)
  24. Giorgio Maone (NoScript)
  25. Antonela Debiasi (ConsenSys)
  26. James Hycner (Keeper)

Meeting notes

Issue 145 comment about Improving our meetings

  • [tomislav] Improving our meetings #145 (comment)
  • [tomislav] In the last meeting, Simeon was chairing, but could not keep up with chairing, moderating and replying to the participant's questions as a Google spokesperson at the same time. I suggest to schedule Google-specific topics to meetings where Timothy (Apple) is chairing.
  • [craig] Could we invite a product manager from Google? E.g. David Li, senior engineering manager. We would like a decision maker to understand our concerns on the MV2 cutoff date
  • [simeon] I am looking to see if another Google representative can join.
  • [timothy] Google is not the only browser shipping MV3. Safari 15.4 will ship MV3 soon.
  • [craig] Is Safari going to drop MV2 in January?
  • [timothy] We are not.
  • [craig] Main concern is the MV2 shutdown timeline, we need time to adapt to changes.
  • [oliver] Clarifying the linked comment, to emphasize that the request was to ask for more places to talk about MV3, not to shut down discussion here.
  • [timothy] Discussions about APIs, etc. fit here. We cannot talk much about timelines here.

Issue 170: Offscreen Documents Proposal

  • Chrome's Off-screen Documents Proposal
  • [carlos] Question: when an iframe is embedded in this off-screen context, will extension APIs that usually apply to normal web content also apply to that iframe in the off-screen context (e.g. DNR to remove X-Frame-Options)?
  • [simeon] The intention is that this will be supported.
  • [timothy] What's the goal here?
  • [carlos] That DNR rules still apply in this off-screen document.
  • [rob] Third party dNR rules as well?
  • [carlos] Yes, want it to behave "normally"
  • [timothy] Makes me wonder if dNR proposal should have an option to bypass other extensions' dNR rules. I lean towards having an option for complete isolation.
  • [krzysztof] How can extension APIs refer to these frames? tabId is -1.
  • [simeon] I believe that we have talked about a “document ID” concept before.
  • [rob] Yes, here is the previous issue where we discussed this. #8
  • [tomislav] Simeon, could you or someone on your team bring your current thinking to issue 8?
  • [craig] Will this context support modal dialogs (alert, confirm, prompt, etc.)
  • [tomislav] These are already not supported (in Firefox).
  • [simeon] We (Chrome) currently support alerts and such in MV2. Somewhat of a UI problem, though, as we hang it off the current page.
  • [craig] There are use cases where we want the extension to get a confirm from a user.
  • [rob] That could be implemented with an extension popup.
  • [tim] Can these contexts spawn web workers?
  • [simeon] Nested workers are currently not supported in service workers in Chrome, but we consider this to be a bug in the context of extensions. Offscreen document would allow for background instantiation of a web worker
  • [tim] I read in a previous meeting note that this API is temporary - is it?
  • [simeon] This API probably has uses that cannot be implemented in a Service workers. Initial motivation is to support features that cannot be implemented yet in Service workers such as audio. Primary plan is to support more use cases in an extension service worker, so developers can move logic from the off-screen context to the Service worker. API requires extensions to specify a reason for creating an off-screen context. Our intention is if extension service workers were to fully support audio capabilities, that we would deprecate the “audio” reason and give enough notice for extensions to migrate. I am hesitant to claim the removal of the off-screen API in e.g. 5, 10 years. From a developer POV, you should be able to do the things you are doing today, but prepare for the possibility of porting the functionality over, e.g. with modular development.
  • [tim] Only brought up the service worker & web worker example because we want to do some multithreading. My request would be to have some multithreading within the SW at some point.
  • [simeon] Confirms that this should be supported.
  • [timothy] To summarize what you've said, Simeon, the whole API would not be temporary, but the purposes would come and go as use cases were needed and service workers eventually gain support for one of the purposes.
  • [Frederic] Expresses concern over introducing a feature with an uncertain lifetime.
  • [timothy] Agree, anything that we put out should be supported long-term.
  • [krzysztof] Would like to talk about the purpose. Sounds like this will require users to consent to a given purpose. Want to discuss Safari's approach to broad host permissions. May unnecessarily scare off users.
  • [timothy] Want to address this in Safari. Know wording can be very scary at times. We try to balance this, but want to be sure that everyone understands the implications of these capabilities. That's why the justification string is included in offscreen documents proposal. Would like to see a justification string in general going forward.
  • [simeon] Wants to throw in a consideration from the browser side. Understands the desire to have user facing strings provided by the developers, but this can be abused. Of course we try to catch as much abuse as possible in review, but it's not foolproof.

browser.secureStorage

  • [oliver] Thanks to Dashlane and Keeper for adding their support, clear this is something the entire password management industry wants
    • [tomislav] Would be nice to not just hear support from other extension developers, but actual feedback on the content / API design.
  • PR 183: Remove Proposal 1 from browser.secureStorage
    • [oliver] This was a lower-level proposal, but from the feedback received so far this idea is not supported by browser vendors, so I suggest to remove it.
    • [timothy] I approved it
  • PR 186: Add polyfill for browser.secureStorage
    • [oliver] This polyfill was requested before in one of the earlier meetings.
    • [timothy] I added a review comment.

Non-blocking webRequests

  • Issue 148: Proposal: allow webRequest with background.persistent: false / SW
  • Issue 157: non-blocking webRequest use case
  • [carlos] Sounds like non-blocking web request will continue working in all browsers
  • [simeon] Yes for Chrome
  • [timothy] We support it on macOS, with persistent background pages. On iOS non-persistent background pages are mandatory, and we didn't support webRequest because Chrome didn't support (non-blocking) webRequest in event pages either.
  • [carlos] You intend to implement webRequest on iOS?
  • [timothy] We will reevaluate our position in the future.
  • [simeon] webRequest does not work well in the Service worker model. Expectation is that enterprises may make different trade-offs with performance and such. We are not comfortable with making similar decisions for the general audience.
  • [carlos] Would you keep the service worker running?
  • [simeon] We cannot keep them alive indefinitely, and we cannot repeatedly incur the overhead of reviving the service worker.
  • [carlos] What about use case of extension pages that may want to use the webRequest API to modify requests made in that extension page.
  • [simeon] I see that this may make sense in the context of extension tabs. This has not crossed my mind, I don't know if the engineers have considered that use case. My gut feeling is that that may simply be a scenario that's weird and out of scope, but I'm happy to follow up on this.
  • [krzysztof] We track trackers and do so with blocking webRequest. Believe that it is an inherent value of a user agent to control how the user agent behaves, and removing the ability for extensions to control this is an attack on the user's liberty.
  • [timothy] Agree on the aspect of the network layer approach being too low level and flat. A lot of the privacy issues with webRequest is the amount of information given to extensions, which is hard to explain to users in a way that they understand.
  • [timothy] webRequest is a noisy hose. Wondering if there's a non-blocking web request alternative that provides a digest of events instead of a constant stream of events. This is just musing.
  • [tomislav] Compare digest idea to MutationObservers, which provides a collection of DOM modifications
  • [giorgio] Is the end-game complete removal of editorial screening of extension? Could we have a special permission (e.g. webRequest that we have now) that undergo manual review (potentially with requirements such as readable code etc). Without any manual screening, any advanced feature is doomed. Earlier someone commented about the overhead of spawning the SW, but with webRequest the worker would be kept alive indefinitely.
  • [simeon] It is a concern of the network stack: triggering a service worker delays the processing of a request.
  • [giorgio] I don't think that starting a SW is comparable to the time needed to process a request.
  • [timothy] Starting up a SW can potentially take seconds.
  • [simeon] And especially for worse case scenarios, if there are multiple (dozens?) of active extensions.
  • [tomislav] Since SWs are off-main thread, they could be started in parallel, so even the worst case wouldn't need to run them sequentially. But overall, we disagree with Chrome's performance trade-offs as presented, in Mozilla's opinion they don't justify removal of extension capabilities. Most of the time, extensions that need and use blocking webRequest would stay alive in the background, and user impact should be minimal. If it starts to degrade user experience, we could highlight which extensions are taking long to respond, and users could choose to uninstall them.

The next meeting will be on Thursday, March 31st, 8 AM PST (4 PM UTC).