2023-01-05-wecg.md

WECG Meetings 2023, Public Notes, Jan 5

• Chair: Simeon Vincent
• Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=63b61300,3c0 Call-in details: WebExtensions CG, 5th January 2022 Zoom issues? Ping @robwu (Rob Wu) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

• Intro (welcome to 2023 🙂)
• Check in on PRs
  • PR 333: Add IDL files for Safari as reference
  • PR 331: Add User Scripts API proposal
  • PR 334: New API proposal : extension.getContexts()
• Carry-over from previous meetings
  • Issue 332: Stable, documented and secure Auth API
  • Issue 307: Proposal: extend extend browser.action API to display popup in the middle of the screen
  • Issue 162: DNR proposal: disable individual static rules. Increase limit to 20k rules (comment).
• Other new issues
  • Issue 336: Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()
  • Issue 337: Inconsistency: CSP for inline web page elements added by extension
  • Issue 338: Inconsistency: runtime.onMessage Promise return
  • Issue 339: Inconsistency: Proxy Bypass list
• Open discussion queue (add yourself at the bottom)
  • None
• Check-in on ongoing issues
  • None; moved to next meeting for the lack of time.
• Wrap up

Attendees (sign yourself in)

1. Simeon Vincent (Google)
2. Jason Waterman (Mozilla)
3. Giorgio Maone (NoScript, Tor Project)
4. Rob Wu (Mozilla)
5. Mukul Purohit (Microsoft)
6. Nikita Vasilyev (independent)
7. Timothy Hatcher (Apple)
8. Oliver Dunk (independent)
9. Steven McLintock (1Password)
10. Benjamin Bruneau (1Password)
11. Mike Selander (1Password)
12. David Johnson (Apple)
13. Tyler Carson (Keeper)
14. Kiara Rose (Apple)
15. Tim Heflin (Keeper)

Meeting notes

PR 333: Add IDL files for Safari as reference

• [simeon] First of the many. Merged. Part of the effort to see what we're implementing, to work towards aligning between browsers.
• [timothy] Planning on adding a README.
• [simeon] I'll look into adding API definitions from Chrome's side.

PR 331: Add User Scripts API proposal

• [simeon] Check in
• [rob] There's been active discussion in the PR between me, Devlin, Toph, and others about the shape of the API (https://github.com/w3c/webextensions/pull/331/files#r1048532828). Next steps are for Emilia or Devlin to comment or revise.
• [simeon] When I last reviewed this the main point of contention was whether or not a secure message channel between the user script and extension was a strict requirement. We (Chromium) don't think it is but Rob (Firefox) and participating extension devs do. Let's try to resolve this in comments on the PR.

PR 334: New API proposal : extension.getContexts()

• [simeon] The Chromium engineer (Justin) has addressed some feedback from Timothy. Please take another look & resolve conversations as appropriate.
• [rob] I commented most recently at #334.
• [simeon] Address the issue without broadcast messages, and … hope is that by doing message passing with a specific target, similar results can be achieved but slower.

Issue 332: Stable, documented and secure Auth API

• [simeon] Anyone here to speak more about this issue?
• [rob] Let's continue this discussion async.

Issue 307: Proposal: extend extend browser.action API to display popup in the middle of the screen

• [simeon] Content rendered in the content area could potentially be spoofed by web pages.
• [timothy] Without sufficient space around the popup or clear association with the extension button, there may be concerns about abuse.
• [simeon] With regards to sizing, we have opinionated constraints on the sizing. Extensions that want more size can open a popup.
• [timothy] An argument in favor of a dedicated permissionless UI area is that it removes the need for extensions to inject content in web pages.
• [simeon] Related to exposing extension UI surface without giving extensions access to user data unnecessarily, that's one of the considerations for the Sidebar API – providing extensions with a way to show useful data without granting page access.
• [oliver] I linked to issue 235 in the issue.
• [rob] Note also that there is a difference between “centering” in the window vs screen.
• [nikita] When the user clicks on the extension action button, it already receives permissions via activeTab. Using the popup for
• [giorgio] NoScript already renders popups etc. Concern is not that it's difficult to do. The concern is that your extension UI within the content is susceptible to spoofing / click-jacking. The windows.create() is very heavy-weight and can take a lot of time to render the UI. A light-weight API to open trusted UI would be desirable.
• [simeon] This also raises a question about how this would be exposed on mobile devices (Safari, Firefox)
• [rob] This discussion doesn't seem to be specifically tied to the Action API. Should we continue discussing this as an Action API capability or address it in a separate API.
• [simeon] Chromium would prefer to keep the Action API as it is. I think it would be best to discuss this request as a new API.
• [giorgio] Could we repurpose the windows.create() API (type: “panel”) to support this use case?
• [rob] That resulting API would not be heavy-weight. On Firefox for Android the windows API doesn't even exist.
• [timothy] On iOS windows can be accessed but not closed.
• [simeon] Random thought: maybe a "browser.modal" extension API to open a modal/lightbox etc. Allows browsers to choose appropriate presentation of this content for the device/platform.
• [timothy] I'm supportive of that. Reminds me of the <dialog> element which is well-supported.
• [rob] I'm supportive of the capability, but there are a lot of different directions we could go. I think we need an API proposal in order to discuss something specific. The API in its current form has an unsurmountable issue (inability to associate the UI with the extension button), and we would therefore vote against it. There is a favorable sentiment for the feature in a different shape.

Issue 162: DNR proposal: disable individual static rules. Increase limit to 20k rules (comment).

• [simeon] Is Felipe here? No. Suggest we table this until next session. Before we move on, any concerns on the shape of the APi?
• [rob] Shape of the API looks good, as proposed at: #162 (comment)
• [timothy] Shape of the API looks good. I can see a feasible path towards an implementation of this in Safari.
• [rob] Timothy, please label this as “supportive: safari”? I'll put the “supportive: firefox” label on it.

Issue 336: Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()

• [simeon] These issues are minor and very specific, let's continue the discussion async in the issue.

Issue 337: Inconsistency: CSP for inline web page elements added by extension

• [rob] The issue here is the lack of clarity and agreement between browsers on what the CSP of content scripts cover. I recently expanded the documentation on MDN, which is basically that the CSP in content scripts is browser-specific. I know that Chrome has made an effort to cover as much by the content script CSP as possible, and that Firefox mostly follows the web page's CSP with some exceptions. How about Safari?
• [timothy] The CSP mostly follows the content script of the page.
• [simeon] CSP for content scripts exists to block remotely hosted code.
• [simeon] As an action item, let's continue discussion on the issue to align on the desired CSP behavior in content scripts.

Issue 338: Inconsistency: runtime.onMessage Promise return

• [simeon] Looks like a Chromium-specific issue, so I'll follow up async.
• [rob] Does Safari support Promise return values in runtime.onMessage listeners?
• [timothy] Yes.
• [rob] If there are multiple runtime.onMessage listeners that return a promise, which one is returned to the sender?
• [timothy] I don't know that right now.
• [rob] This is a relevant edge case, and one of the disadvantages with the broadcast aspect of the messaging API.

Issue 339: Inconsistency: Proxy Bypass list

• [simeon] Let's revisit this next meeting.

The next meeting will be on Thursday, January 19th, 8 AM PST (4 PM UTC).