Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Publish minutes of 2023-01-05 meeting #341

Merged
merged 1 commit into from
Jan 18, 2023
Merged

Publish minutes of 2023-01-05 meeting #341

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
132 changes: 132 additions & 0 deletions _minutes/2023-01-05-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,132 @@
# 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](https://www.w3.org/events/meetings/0d503f74-3cfb-4bc5-9f9f-4db86c6ea2f3)
Zoom issues? Ping @robwu (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

* **Intro (welcome to 2023 🙂)**
* **Check in on PRs**
* [PR 333](https://github.com/w3c/webextensions/pull/333): Add IDL files for Safari as reference
* [PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal
* [PR 334](https://github.com/w3c/webextensions/pull/334/): New API proposal : extension.getContexts()
* **Carry-over from previous meetings**
* [Issue 332](https://github.com/w3c/webextensions/issues/332): Stable, documented and secure Auth API
* [Issue 307](https://github.com/w3c/webextensions/issues/307): Proposal: extend extend browser.action API to display popup in the middle of the screen
* [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR proposal: disable individual static rules. Increase limit to 20k rules ([comment](https://github.com/w3c/webextensions/issues/162#issuecomment-1318618540)).
* **Other new issues**
* [Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()
* [Issue 337](https://github.com/w3c/webextensions/issues/337): Inconsistency: CSP for inline web page elements added by extension
* [Issue 338](https://github.com/w3c/webextensions/issues/338): Inconsistency: runtime.onMessage Promise return
* [Issue 339](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/pull/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](https://github.com/w3c/webextensions/pull/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](https://github.com/w3c/webextensions/pull/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 https://github.com/w3c/webextensions/pull/334/#issuecomment-1366125078.
* [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](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/issues/162): DNR proposal: disable individual static rules. Increase limit to 20k rules ([comment](https://github.com/w3c/webextensions/issues/162#issuecomment-1318618540)).

* [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: https://github.com/w3c/webextensions/issues/162#issuecomment-1245662951
* [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](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/issues/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](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy#csp_for_content_scripts), 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](https://github.com/w3c/webextensions/issues/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](https://github.com/w3c/webextensions/issues/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)](https://everytimezone.com/?t=63c88800,3c0).
8 changes: 6 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,20 +10,24 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2023-01-05 at 8 AM PST = https://everytimezone.com/?t=63b61300,3c0
- 2023-01-19 at 8 AM PST = https://everytimezone.com/?t=63c88800,3c0
- 2023-02-02 at 8 AM PST = https://everytimezone.com/?t=63dafd00,3c0

## Past meetings

* 2023-01-05 ([minutes](2023-01-05-wecg.md))
* 2022-12-08 ([minutes](2022-12-08-wecg.md))
* 2022-11-24 ([minutes](2022-11-24-wecg.md))
* 2022-11-15 User Scripts API kickoff ([minutes](2022-11-15-wecg-userscripts.md))
* 2022-11-10 ([minutes](2022-11-10-wecg.md))
* 2022-10-27 ([minutes](2022-10-27-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2023**

* 2023-01-05 ([minutes](2023-01-05-wecg.md))

**2022**

* 2022-12-08 ([minutes](2022-12-08-wecg.md))
Expand Down