Skip to content

Latest commit

 

History

History
126 lines (104 loc) · 12.6 KB

2022-08-18-wecg.md

File metadata and controls

126 lines (104 loc) · 12.6 KB
Raw

WECG Meetings 2022, Public Notes, Aug 18

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=62fd8100,3c0 Call-in details: WebExtensions CG, 18th August 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
    • None
  • Other new issues
    • PR 247: add: extension store issues are out-of-scope
    • Issue 255 Blocking webRequest usecase - Quick prototyping / deployment of defenses against new security threats (e.g. Leakuidator+)
    • Issue 256 Native messaging connection from service worker
  • Open discussion queue (add yourself at the bottom)
    • Giorgio Maone: would like to have clarifications about the (non?) resolution of other past issues about blocking webRequest use cases, such as #169 “add, modify and remove CSP directives”
    • Richard Worth: Re-visit Issue #113 Proposal: Make extension APIs browser neutral - specifically would like to discuss the main API namespace "browser" as an alias of "chrome"
  • Check-in on ongoing issues

Attendees (sign yourself in)

  1. Simeon Vincent (Google)
  2. Tomislav Jovanovic (Mozilla)
  3. Giorgio Maone (NoScript, Tor)
  4. Rob Wu (Mozilla)
  5. Carlos Jeurissen (Jeurissen Apps)
  6. Juha-Matti Santala (Mozilla)
  7. Tim Heflin (Keeper)
  8. Richard Worth (Capital One)
  9. David Johnson (Apple)
  10. Rainer Enders (Keeper Security)
  11. Matt Gibson (Bitwarden)
  12. Kyle Spearrin (Bitwarden)
  13. Todd Schiller (PixieBrix)
  14. Jack Works (Sujitech)
  15. Ellie Epskamp-Hunt (Apple)
  16. Gaurang Tandon (Blaze Today)
  17. Timothy Hatcher (Apple)
  18. Larry Xu (Dropbox)
  19. Bradley Cushing (Dashlane)
  20. Bastien Granger (Dashlane)
  21. Topciu Maxim (AdGuard)
  22. Tyler Carson (Keeper)
  23. James Hycner (Keeper)

Meeting notes

PR 247: add: extension store issues are out-of-scope

  • [simeon] Clarification to our charter. Since it's a modification to the charter, I'd like to get approval from the other editors and chairs before merging.

Issue 255: Blocking webRequest usecase - Quick prototyping / deployment of defenses against new security threats (e.g. Leakuidator+)

  • [giorgio] This is a specific example of when complex logic is needed to make a request decision. Standardization of the necessary primitives in DNR would be infeasible, but prototyping was made possible with the blocking webRequest API. Waking up suspended background workers would also be prohibitively expensive. The example also shows the power of Firefox's async blocking listener (which suspends the request and resumes the request when the extension has resolved the listener), whereas Chrome does not support async blocking responses.
  • [giorgio] Also calling out the lack of resolution on the CSP modification use case at issue 169.
  • [simeon] Primary thing to express from the Chrome POV; DNR is not the end of our network modification journey. We recognize that there are unique capabilities and possibilities that are not possible with the declarative model. We'd like to offer more functionalities that are currently possible with the webRequest API, but in a safer way. It would be ideal if there is a way to allow extension authors to declare logic that can be executed (safely handed over to the browser) without leaking/exfiltrating user data.
  • [giorgio] You recognize that there are things impossible in MV3, so there will be extensions that disappear from Chrome in January.
  • [alexei] If the reason for removing blocking webRequest is to protect against data exfiltration, why will non-blocking webRequest remain available in MV3 Chrome?
  • [simeon] Role of it changes; from being the primary way to modify network activity to being purely observational. Most extensions that modify requests don't need to observe the request data.
  • [alexei] You could achieve the same without removing blocking webRequest, e.g. by making it clear extensions that choose to use blocking webRequest require longer review times in Chrome Web Store.
  • [simeon] Also impact of performance impact with blocking webRequest (spinning up worker etc). That's why it's supported for enterprise users.
  • [alexei] Aren't enterprise users going to lose support for blocking webRequest soon, only a few months after the general MV2 deadline?
  • [simeon] Sorry, I don't recall. Do other vendors have thoughts or concerns they'd like to share
  • [tomislav] I definitely agree with the stated goals of DNR and introducing it. We're also introducing DNR for performance and security aspects. It has desirable properties, but doesn't cover all important use cases, some of which Giorgio has mentioned. The other part that Simeon mentioned (offering safe ways of running code) sounds like a good idea, but seems hard if not impossible. Any way to interact with requests can already result in leaking bits of data. If we could come up with a way to do so, that would be great, but that seems rather infeasible.
  • [rob] Agree with Tomislav's comments. As Simeon was talking, I was thinking about worklets, but even in an isolated scenario you could gather information in one request and leak it in the next.
  • [rob] I do encourage extension devs to share specific use cases. E.g. if the extension wants to prompt the user for a decision before modifying a request, a potential primitive to support that could be to declare that in the API and the possible actions based on that (e.g. cancel a request).
    • [tomislav] This sounds like a good example. The request can be suspended until the user has made a decision, and extensions can declare the conditions & actions without leaking user data. If a detailed proposal were to be written, Mozilla would probably be supportive of this.
    • [timothy] Agreed from Apple too.
  • [georgio] Even in this case, if you want to show the user useful information, … if we work on dnr, we can surely find ways to exfiltrate information in a declarative way. Requirement for manual review will never fully go away. Deferring to tech will only hinder good actor's ability to act in the user's favor
  • [simeon] Should probably move on due to time.

Issue 256: Native messaging connection from service worker

  • [larry] For extensions that connect to a native messaging host, if the service worker is terminated while there's an open port, the SW can't reconnect. Chrome addresses this by extending the lifetime of the SW. Will other browsers adopt this behavior as well?
  • [tomislav] Firefox doesn't have a fixed time limit. As long as there is activity, the connection will stay. That's our current plan.
  • [larry] To clarify, “so long that there is activity” does that mean that the app is open, even without sending messages back and forth between the extension and native messaging host?
  • [rob] We do not terminate the native messaging host. In Firefox on desktop, the background worker/event page will be alive as long as it does something useful. On platforms where we cannot guarantee that, e.g. Android or resource-constrained (desktop) systems, the extension should be prepared to deal with being terminated at any time.
  • [timothy] (commented on the issue) Safari does not have a fixed timeout for service workers or background pages. As long as there is activity (events, messages, etc) the service worker will stay alive.

Issue 113 Proposal: Make extension APIs browser neutral - specifically would like to discuss the main API namespace "browser" as an alias of "chrome"

  • [richard] Looking for clarification on this. See that there was previous discussion
  • [timothy] No difference on Safari. Safari has both browser and chrome.
  • [richard] e.g. browser_specific_settings.
  • [simeon] To recap, Chrome is open to this and supporting it in the future; we are tentatively planning to address this in Manifest V4. Needs some internal discussion on some Chrome-specific behavior and broader cross-platform behavior to figure out a safer strategy for product differentiation, so that we don't end up with the prefix-based problems that we experienced in the JS APIs.
  • [carlos] Two proposals here. 1) have the browser namespace be available but not mentioned in docs. 2) for namespaces we already agree on, expose it in the browser namespace and have everything else on chrome.
  • [timothy] Sounds good to me. One anecdote that I'd like to share: when we recently added support for externally_connectable, we were unable to support the chrome namespace in the web page because of webcompat issues, and therefore we only supported the browser namespace. Web pages checked whether window.chrome exists and assumed to be running on Chrome.
  • [rob] That's a concern for web pages, but for extension contexts we can supply both chrome and browser. In Firefox's MV3 browser and chrome will be an identical object.
  • [timothy] In Safari chrome and browser are also identical in both v2 and v3.
  • [tomislav] when we exposed chrome and browser, we were conservative and didn't expose identical functionality on both
  • [simeon] Short version from Chrome's POV: we'd like to converge.

Issue 232: WECG at TPAC 2022

  • [simeon] Open question - how do we want to approach the normal session (this biweekly meeting) and the TPAC session a 5 1/2 hours later.
  • [tomislav] If we have enough to fill the two-hour session, we could keep that and hold the regular session.
  • [rob] I mentioned that moving the meeting could prevent regular participants from joining, so we should keep it. We can use the TPAC meeting to further the goals of the charter (spec work) and meet with other groups at TPAC.
  • [simeon] Agenda items? So far, Rob commented about the browser tools and testing meeting. We should probably reach out and let them know that we plan to attend and maybe encourage a representative of them to join our group.
  • [timothy] Service workers, web app manifest.
  • [rob] Visiting their sessions, discuss in our meeting, and/or encouraging them to join our meeting?
  • [simeon] Let's start with whom we'd like to meet, and then how.
  • [carlos] Maybe CSS, how browsers should approach resizing websites. E.g. popups and options pages.
    • [simeon] That sounds like an inconsistency that we should indeed discuss between ourselves; not sure about web use cases where this concern also applies.
  • [rob] Topic: User script use case.
    • [simeon] I discussed this with the engineering team, to have an earlier design discussion than what we did before. Instead of publishing a complete design doc, it would be nice to have earlier involvement.
  • [carlos] If we agree as a group to implement a specific API, where to go next?
    • [simeon] We have a template for API proposals
    • [carlos] The template is currently designed to have an internal Chrome owner etc. How do we get Chrome to implement features that we've agreed with?
    • [simeon] Example that I can think of is Oliver's secureStorage proposal. I'd like to see a process to flesh that out.
    • [rob] Someone needs to champion proposals. (Code) contributions of prototypes would be helpful.
    • [simeon] Trying to get a proposal in a good enough shape that browser vendors can evaluate/decide on, we need to iterate on the specification to get to that state.
    • [david] Standard process would make sense.
  • [simeon] Topic: how we pursue the specification and making progress on that.
  • [rob] If any of the WECG community members would like to suggest topics, please do so. E.g. a fleshed our version of the improvement to DNR like we discussed earlier.
  • [rob] FYI TPAC 2022 is in 4 weeks. The next WECG meeting will be the last meeting before TPAC 2022.

The next meeting will be on Thursday, September 1st, 8 AM PST (3 PM UTC).