Skip to content

Latest commit

 

History

History
110 lines (88 loc) · 9.97 KB

2023-09-14-wecg.md

File metadata and controls

110 lines (88 loc) · 9.97 KB
Raw

WECG Meetings 2023, Public Notes, Sep 14

  • Chair: Simeon Vincent
  • Scribes: Oliver Dunk

Time: 8 AM PDT = https://everytimezone.com/?t=65024d00,384 Call-in details: WebExtensions CG, 14th September 2023 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

Attendees (sign yourself in)

  1. Tomislav Jovanovic (Mozilla)
  2. Rob Wu (Mozilla)
  3. Simeon Vincent (Unaffiliated)
  4. Kiara Rose (Apple)
  5. Timothy Hatcher (Apple)
  6. Rob Hudson (Apple)
  7. David Johnson (Apple)
  8. Jason Waterman (Mozilla)
  9. Patrick Kettner (Google Chrome)
  10. Sam Macbeth (DuckDuckGo)
  11. Oliver Dunk (Google Chrome)
  12. Devlin Cronin (Google Chrome)
  13. Steven McLintock (1Password)
  14. Richard Worth (Capital One)
  15. Carlos Jeurissen (Jeurissen Apps)
  16. Dmitrii Seregin (AdGuard)
  17. Maxim Topciu (AdGuard)
  18. Tim Heflin (keeper)
  19. Luke Selker (Dashlane)
  20. Mukul Purohit (Microsoft)

Meeting notes

(Introduction)

  • Simeon: Welcome, this meeting will be a bit different, we'll first be summarizing some of the discussions we've had at TPAC this year, then the second half of the meeting we'll go through open issues as normal.

Sep 11, 2023

  • Public meeting: 2023-09-11 WECG TPAC meeting minutes
  • [simeon] Meeting structure and follow-up - general discussion on how to work to achieve goals. Generally participants were happy with the general structure of meetings. Wanted to make more progress on spec. Spec should be focused on manifest V3+ and reflect the reality of what we implement, not an ideal version. There was a desire to get contributions from the community - we thought we could unblock these by deciding on basic structure. Plan to hold breakout session later in the week to begin discussing.
  • [simeon] Automated compatibility testing - strong interest, want to use Web Platform Tests as building block. Some security concerns with making it possible to dynamically load extensions at runtime. May need to make some changes to accommodate this. Patrick volunteered for initial implementation of MVP test harness.
  • [simeon] Open Web API integration - Some participants including Simeon interested in allowing extensions to extend web APIs e.g allowing extensions to set userVisibleOnly to false in push notifications. Allows us to avoid collisions and for web developers to reuse knowledge. Specs avoid specifying user agent so we should describe what the user agent might do and then leave it open who will be allowed to use these.
  • [simeon] Custom protocols - open discussion was used for discussion on registering custom protocol handlers and being able to serve content on these protocols. Two main ways to go forward: foreign fetch, or using APIs similar to Firefox's filterResponseData.
  • [simeon] Would someone like to explain what we discussed around DNR?
  • [oliver] discussion on what we might want to support in the future, the rule types that are not supported, and the “safe rules” proposal from Chromium.
  • [devlin] we went through the existing plans for user scripts under mv3, and the currently proposed primitives which are in the works, should enable user script managers to run user scripts in mostly similar way to mv2, with the additional security protections from a separate isolated world.
  • [devlin] webauthn rpid for webextensions, we explored what it would mean to allow extensions to use “their own” public origin
  • [oliver] talked with Nina from Google WebAuthn team and others from the password manager community before this meeting and gained some additional clarification. The rpid is already a field in the API, which can already customized (by the web to use a consistent/single origin from subdomains), so we might be able to just directly hook into that. Also got some more clarification on the threat model. Can share some notes on this conversation after the meeting.
  • [tom] and at least for now, we might just directly check host permissions there, as we've discussed with webAuthn folks.
  • [rob] we discussed, and i want to write up the proposal for primitive for communication between content script and isolated user script world.
  • [simeon] Custom elements – can someone speak to this? [devlin] At the movement it's not clear that having a custom element registration API provides much benefit beyond what developers can already do with current main world script injection.

Sep 12, 2023

  • Public meeting: 2023-09-12 WECG TPAC meeting minutes
  • [simeon] (summarized meeting notes)
  • [tomislav] On namespace, we discussed with folks working on WebIDL namespacing, Noted that chrome. is already exposed in main world for web pages to communicate with extensions. They suggested we find a place in a web standard or somewhere else where we would define that the browser global would exist with some methods.
  • [rob] As additional context, Chrome does currently not expose browser. in the main world. There was some concern about doing this because it is not a standard part of the web platform. Coincidentally Rick Byers from Google was also at TPAC and helped with answering questions to unblock this uncertain concern.

Sept 13, 2023

  • [simeon] No public discussion, but did have informal discussions and a breakout.
  • [devlin] We also had a big discussion on specifications. Discussed what is in scope and out of scope in order to allow us to accept contributions. Want to specify the very core of manifest file, keys, general concepts (e.g you have APIs…). Hold off on specifying actual APIs.
  • [oliver] We also discussed changes to charter - do we want to discuss those?
  • [simeon] Yes. We identified two main things - we say WebDriver integration is out of scope, but there is clear to desire to talk about this.
  • [devlin] The other thing is packaging format - this was likely intended to mean flat file structure, but reads as though we meant CRX, XPI files etc.
  • [simeon] Can we also summarize discussion on browser specific naming?
  • [devlin] There are some cases like omnibox where we may have wanted to standardize on a name and API. But there will also always be cases where we want to use browser specific naming if it is truly relevant in only one file.
  • [simeon] The tentative plan is to review the Chrome API proposal process and adapt that for our purposes.
  • [devlin] Likely just use for inspiration, not directly take that.
  • [simeon] Also had a bug bash session.
  • [oliver] All of this is documented in the GitHub issues. We left comments on everything we discussed.
  • [rob] To clarify, we reviewed and triaged a number of issues, left comments on them etc.

Sept 14, 2023

  • [simeon] Tomislav shared some extra information on how Message Format 2 is used. We will keep an eye on how that specification evolves.
  • [simeon] Also discussed bfcache. As you navigate away from a page, the previous page is pushed in to cache, when pressing the back button it is retrieved. Discussed specific behaviors of how that integrates with messaging APIs and open ports. This is currently inconsistent and we were seeking alignment.
  • [devlin] The tentative plan is for Chrome to align with Firefox's behavior where any ports will be disconnected when a page enters the bfcache. No special behavior will happen when the page comes out of the cache. The content script can listen to the pageshow event and reconnect. We discussed other tools we could provide to reduce potential breakage, e.g queueing which everyone was opposed to, or an onSuspend event. Decided to make no changes.
  • [devlin] Current Chrome behavior is to evict the page when a message is sent to a port open on a page in bfcache. Firefox behavior has been around for ~8 years and they have not seen issues. Future changes could be adding events to port or background events on webNavigation API or others.
  • [tomislav] Tried to verify behavior in Firefox after discussion. Wasn't able to because the page was being evicted too often and yet to troubleshoot.
  • [simeon] Next up was service worker fetch events, i.e being able to listen to the “fetch” event in service workers. On the web, this is used to intercept requests and provide offline support. Can also be used for more novel use cases like a JSON API served from your host. Common alignment was that typical requests that come from normal web flows e.g a script tag go through fetch event listeners. Other file loading like scripting.executeScript or content scripts do not load in the same path and therefore do not go through the service worker.
  • [devlin] In Chrome we want to keep supporting this, especially since we don't want to deviate from web service worker. We will look at ways of resolving edge cases. Firefox and Safari expressed that they will wait and see.

The next meeting will be on Thursday, September 28th, 8 AM PDT (3 PM UTC).