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 2024-04-11 meeting #589

Merged
merged 1 commit into from
Apr 23, 2024
Merged

Publish minutes of 2024-04-11 meeting #589

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
173 changes: 173 additions & 0 deletions _minutes/2024-04-11-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,173 @@
# WECG Meetings 2024, Public Notes, Apr 11

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=66172800,384
Call-in details: [WebExtensions CG, 11th April 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240411T080000/)
Zoom issues? Ping @robwu (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #579](https://github.com/w3c/webextensions/issues/579), [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format.

* **Announcements** (2 minutes)
* **Triage** (5 minutes)
* [Issue 580](https://github.com/w3c/webextensions/issues/580): Proposal: Match pattern matches ([@Jack-Works](https://github.com/Jack-Works))
* [Issue 588](https://github.com/w3c/webextensions/issues/588) Tab-specific sidePanel inconsistencies when opening new tabs/switching tabs ([@twschiller](https://github.com/twschiller))
* **Timely issues** (20 minutes)
* [PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API ([@aselya](https://github.com/aselya))
* [PR 585](https://github.com/w3c/webextensions/pull/585): dark-mode: Add a proposal for dark mode extension icons ([@solomonkinard](https://github.com/solomonkinard))
* [PR 586](https://github.com/w3c/webextensions/pull/586): Proposal: documentId in tabs.query() filter ([@bershanskiy](https://github.com/bershanskiy))
* Related to [Issue 553](https://github.com/w3c/webextensions/issues/553)
* [PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash() ([@bershanskiy](https://github.com/bershanskiy))
* **Check-in on existing issues** (20 minutes)
* [Issue 536](https://github.com/w3c/webextensions/issues/536): Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection) ([@hackademix](https://github.com/hackademix))
* [Issue 539](https://github.com/w3c/webextensions/issues/539): Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection ([@hackademix](https://github.com/hackademix))


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Timothy Hatcher (Apple)
3. Anton Bershanskyi
4. Giorgio Maone (NoScript, Tor)
5. Simeon Vincent (Mozilla)
6. David Johnson (Apple)
7. Oliver Dunk (Google)
8. Solomon Kinard (Google)
9. Dylan Cutler (Google)
10. Maxim Topciu (AdGuard)
11. Dmitriy Seregin (AdGuard)
12. Richard Worth (Capital One)
13. Carlos Jeurissen (Jeurissen Apps)
14. Aaron Selya (Google)
15. Kiara Rose (Apple)
16. Tomislav Jovanovic (Mozilla)
17. Jackie Han (no affiliation)
18. David Tota (AdGuard)


## Meeting notes

[Issue 580](https://github.com/w3c/webextensions/issues/580): Proposal: Match pattern matches

* [simeon] Request here to match match patterns at runtime. Would like to better understand use case.
* [timothy] Sounds useful. Different engines accept different things (e.g. Safari doesn't accept anything but http, https and \* in the scheme).
* [simeon] Related to [issue 575](https://github.com/w3c/webextensions/issues/575).
* [rob] Like others mentioned in the issue, match patterns are not useful on their own and are context-dependent. E.g. some extensions want to know whether they are able to run scripts in certain URLs given a pattern. The answer is not just dependent on the pattern, but also other factors such as whether the browser or enterprise has blocked script injection in the given URLs. The match pattern matching logic can already be implemented trivially by a JS library. I want to see more use cases before considering support for this new extension API.

[Issue 588](https://github.com/w3c/webextensions/issues/588): Tab-specific sidePanel inconsistencies when opening new tabs/switching tabs

* [rob] Can the Chrome and Edge folks investigate the inconsistencies before involving the larger group?
* [oliver] Yes, let's do that.

[PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API

* [aaron] Thanks for feedback from Oliver and Rob so far. I am working on the cross-site ancestor bit in Chrome and working on supporting this in the extension API. Looking forward to feedback from the community on what this should be.
* [aaron] One part where we're going back and forth on is the default value of hasCrossSiteAncestor.
* [rob] Concerns with defaulting to false?
* [aaron] (...) Open to defaulting to false.
* [rob] With the introduction of hasCrossSiteAncestor, the mechanism to generate a partitionKey for a cookie has become less trivial than before. Would it be a good time to introduce a getPartitionKey method to generate a partitionKey object for a given tab/document/frame?
* [dylan] Thoughts about it before. Yes, it makes sense, given tabId/frameId to get partitionKey back.
* [oliver] We also have the concept of documentId.
* [rob] Sounds like there's some support for a method to get a partition key for a given frame/document. May be best as a separate proposal.
* [aaron] If you're implementing such a method, I'd be interested in collaborating on this.
* [oliver] Status of implementing cross-site ancestor bit?
* [rob] Active development. One area where web and extensions capabilities are developed in parallel.
* [timothy] Safari does not support the partitionKey API, but we're looking into implementing this soon.
* [rob] Timothy, partitionKey or firstPartyDomain?
* partitionKey - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#storage_partitioning
* firstPartyDomain - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#first-party_isolation
* [timothy] Might have been firstPartyDomain. That fits better in our model.
* [rob] I recall that from our discussions before. partitionKey is more flexible, so if possible it would be nice to use that primitive instead. Let's discuss further offline.

[PR 585](https://github.com/w3c/webextensions/pull/585): dark-mode: Add a proposal for dark mode extension icons

* [solomon] Thanks everyone who commented on the proposal, which I put together with help from Oliver and Devlin.
* [solomon] Question about ImageData. I was initially considering not supporting ImageData, but am considering this now. Another suggestion is to support path_variants and imageData_variants.
* [rob] May make more sense to support image data and path separately.
* [timothy] I think it's useful to support all in parallel. When the user switches mode, all necessary data is available synchronously.
* [carlos] In the past you mentioned passing a SVG.
* [timothy] Would be nice. Need to think more about how to handle declaring this in the manifest - could balloon quickly.
* [oliver] What was the justification for individual properties?
* [solomon] path_variants, imagedata_variants.
* [oliver] backwards compatibility concerns?
* [carlos] Not backwards compatible now.
* [rob] Another option is to provide an array of paths or image data. Addresses multiple variant keys.
* [timothy] That was mentioned in Carlos' latest proposal (unified dictionary), which seems like a good approach.
* [carlos] Idea was that browsers could ignore values they don't support.
* [rob] Array of dictionaries looks very similar to icons from web manifest. https://developer.mozilla.org/en-US/docs/Web/Manifest/icons
* [carlos] That was an inspiration. Could potentially use their structure. Dark mode support is an ongoing discussion in that group.
* https://github.com/w3c/manifest/issues/1045
* [rob] In web manifests, “icons” is the top-level key, but in extensions that is already an object. In the “action” key icons does not exist yet, so the “icons” (web manifest) syntax can be re-used there.
* [solomon] May be talking about two different things. Are we talking about icon_variants in the manifest or the setIcon
* [carlos] My proposal covered both.
* [solomon] Taking a step back, is this creating complications for devs?
* [timothy] We don't have to go to mime-type. String values for type generally makes sense. Being able to specify SVGs and bitmap data in the same value would be idea.
* [simeon] Is file extension insufficient for that signal?
* [timothy] No, we currently use extensions in some contexts.
* [rob] Next step appears to be to have Solomon iterate on the proposal and discuss it again in the next meeting.

[PR 586](https://github.com/w3c/webextensions/pull/586): Proposal: documentId in tabs.query() filter

* [anton] Proposal to implement documentId in tabs.query; There is a potential race condition.
* [rob] Can you elaborate on the race condition? The result you get back can always be out of date again.
* [anton] E.g. run tabs.query() and get some documentId information back. And then you want to inject some script there. Call scripting.executeScript on documentId.
* [timothy] Confused. Is this about getting a documentId from a given tab, or verifying the documentId
* [anton] This proposal is about adding documentId to the tabs.query filter.
* [rob] Ah, you're looking to get information for a given tab. During discussion of runtime.getContexts we discussed the possibility of expanding the idea of contexts more broadly. Adding documentId to tabs.query has limited utility as it wouldn't cascade to sub-frames.
* [anton] Yes it does limit use cases, but provides a way to migrate to documentId.
* [tomislav] Wouldn't webNavigation.getFrame be a better place for something like this? Pass in documentID, get tabId and frameId back.
* [anton] Yes. If we expand getContexts that might be a better place.
* [rob] Note that webNavigation has a permission warning but tabs does not (assuming host permissions).
* [oliver] For clarity, AI is for others to review, correct?
* [rob] Yes. That and provide feedback on the proposal. What's the status of the CL?
* [anton] Small CL. Devlin suggested we get feedback from the group before proceeding.
* [tomislav] Might not be obvious, but if used in a non-supporting browser with documentId will error.
* [timothy] Safari does not throw for unknown keys, so passing documentId would be silently ignored.
* [simeon] Gets back to a challenge developers have around knowing what they can/can't use. Should revisit the idea of a supports() method that we discussed during the in-person meeting in San Diego.
* [rob] I will publish the meeting notes from the in person discussions within a week, so if you are interested in the topics discussed, the notes will be public soon ([issue 525](https://github.com/w3c/webextensions/issues/525)).

[PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash()

* [anton] Proposal of downloads.getFileHash() for [issue 401](https://github.com/w3c/webextensions/issues/401). Currently defaults to SHA-256 as that's what browsers use. Potential concern is if the file is relatively small, then the hash can reveal the actual file content.
* [rob] Partial downloads can be an issue. Downloads API supports custom headers, to issue range requests.
* [anton] There are many ways extensions can use partial URLs to gather data. This creates another way.
* [rob] This API is currently introducing a new permission. Could we re-use origin permissions? May be easier for users to understand what they're consenting to.
* [anton] Good suggestion. Want to avoid situations where an extension might request all origins in order to get hashes from arbitrary URLs.
* [oliver] Was initially thinking a permission warning is unfortunate, but after hearing this discussion, it sounds like a permission warning or host permission would be essential.
* [timothy] We'd likely only use host permissions.
* [oliver] Could allow you to download any page in an authenticated manner.
* [tomislav] Indeed, because the downloads API uses the user's cookies.
* [oliver] Could be used to download data from a email server, perform small range requests, and use that to extract data about the contents.
* [rob] I'd be in favor of a new permission without warning, and relying on host permissions to guard access.
* [simeon] I'm leaning that way.
* [oliver] Sounds good.

[Issue 536](https://github.com/w3c/webextensions/issues/536): Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection)
- related to -
[Issue 539](https://github.com/w3c/webextensions/issues/539): Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection

* [giorgio] Requesting check in from Google on these.
* [oliver] Hasn't followed up yet on our side.
* [timothy] Not generally supportive of tabIds on registerContentScripts. Seems out of place and would be hard for WebKit to support.
* [rob] Is tabId available synchronously from the relevant process?
* [timothy] Not in the web process in Safari.
* [tomislav] Don't think it's available in Firefox either. Very different layers of the browser.
* [rob] Is there any other capability that allows you to do what you want?
* [giorgio] I'm afraid not. Want to enable users to turn features on/off from a given tab. Can't do this without declaratively registering a content script.
* [oliver] Agree that this is normally odd, but there are a lot of extensions that do this kind of thing – toggling a certain protection for a given tab.
* [rob] Is it top level document or does it cascade to child frames?
* [giorgio] Depends on user perception of what's happening. Users want to disable for what they're looking at. Other extensions try to monkeypatch the JS environment.
* [rob] DNR API has a way to filter by depth. If we could connect an DNR rule action to a content script injection, that _could_ work. Not saying we should do this, just suggesting there may be other strategies.
* [timothy] Which DNR API?
* [rob] Session rules can have tabIds and excludeTabIds to make tab-specific rules. DNR could set a flag to say whether or not content scripts may be injected. Most document requests are preceded by a navigation.
* [giorgio] An action for DNR that sets a flag?
* [rob] That's the idea. It is not pretty and I am not suggesting to support it, but would be the kind of alternatives if we are unwilling to have the concept of tabId at the content side.
* [timothy] Would prefer to implement something closer to registerContentScript API.

The next meeting will be on [Thursday, April 25th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66299d00,384)
4 changes: 3 additions & 1 deletion _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2024-04-11 at 8 AM PDT = https://everytimezone.com/?t=66172800,384
- 2024-04-25 at 8 AM PDT = https://everytimezone.com/?t=66299d00,384
- 2024-05-09 at 8 AM PDT = https://everytimezone.com/?t=663c1200,384

## Past meetings

* 2024-04-11 ([minutes](2024-04-11-wecg.md))
* 2024-03-28 ([minutes](2024-03-28-wecg.md))
* 2024-03-14 ([minutes](2024-03-14-wecg.md))
* 2024-02-29 ([minutes](2024-02-29-wecg.md))
Expand All @@ -28,6 +29,7 @@ After the end of each meeting, meeting notes are published here.

**2024**

* 2024-04-11 ([minutes](2024-04-11-wecg.md))
* 2024-03-28 ([minutes](2024-03-28-wecg.md))
* 2024-03-14 ([minutes](2024-03-14-wecg.md))
* 2024-02-29 ([minutes](2024-02-29-wecg.md))
Expand Down