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-08-01 meeting #666

Merged
merged 1 commit into from
Aug 15, 2024
Merged

Publish minutes of 2024-08-01 meeting #666

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

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=66aad000,384
Call-in details: [WebExtensions CG, 1st August 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240801T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #661](https://github.com/w3c/webextensions/issues/661), [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** (15 minutes)
* [Issue 662](https://github.com/w3c/webextensions/issues/662): Proposal: Support PrivateToken authentication scheme on webRequest.onAuthRequired ([@thibmeu](https://github.com/thibmeu))
* [Issue 663](https://github.com/w3c/webextensions/issues/663): Should browser.tabs.create send SameSite=Strict cookies? ([@oliverdunk](https://github.com/oliverdunk))
* [Issue 664](https://github.com/w3c/webextensions/issues/664): Proposal: Support loadReplace for tabs.update() ([@mshibanami](https://github.com/mshibanami))
* **Timely issues** (10 minutes)
* **Check-in on existing issues** (20 minutes)
* Supporting browser in Chrome
* [Issue 532](https://github.com/w3c/webextensions/issues/532)
* WebExtensions in WPT
* [Issue 19](https://github.com/w3c/webextensions/issues/19): request: APIs and infrastructure to simplify cross-browser automated testing of extensions
* [Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024
* **Open discussion**
* [PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API - [@aselya](https://github.com/aselya)


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Oliver Dunk (Google)
3. Giorgio Maone (Tor, NoScript)
4. Timothy Hatcher (Apple)
5. Patrick Kettner (Google)
6. David Johnson (Apple)
7. Carlos Jeurissen (Jeurissen Apps)
8. Solomon Kinard (Google)
9. Tomislav Jovanovic (Mozilla)
10. Simeon Vincent (Mozilla)
11. Aaron Selya (Google)
12. Maxim Topciu (AdGuard)
13. Mukul Purohit (Microsoft)
14. Thibault Meunier (Cloudflare)


## Meeting notes

[Issue 662](https://github.com/w3c/webextensions/issues/662): Proposal: Support PrivateToken authentication scheme on webRequest.onAuthRequired ([@thibmeu](https://github.com/thibmeu))

* [thibault] WebExtensions can handle authentication, mostly restricted to basic auth. Basic auth usage is going down, and here I am proposing handling the Authentication header with standardized PrivateToken values. Use case include handling challenges to avoid captchas on websites in an automated fashion.
* [tomislav] What is the adoption of this feature by browsers (broader than extensions)?
* [thibault] I am not from the browser side; adoption is at the OS level by some APIs. E.g. request for picture receives a challenge and is served a response with the PrivateToken.
* [tomislav] This is not the private state token API, right?
* [thibault] Private State Tokens was forked out of PrivateToken. Requires websites to register in some central place, e.g. a registry by Google. PrivateToken is slightly different, closer to what the IETF had defined as an authentication scheme. Private state tokens are handled at the JS application level, PrivateToken is at the network request level.
* [oliver] Is the extension the only place to provide the token? Or would the user be able to provide the token, or even other cases (e.g. the OS).
* [thibault] There may be other cases, e.g. on iOS the OS may populate it at the platform level. If not configured on the device it may pass through to the browser and be handled by e.g. an extension. It can be handled at multiple places in the stack.
* [oliver] I asked because Basic auth can be implemented in the browser, so even if the extension does not provide credentials, the browser can fall back to the default, prompt the user if needed.
* [oliver] Question about shape of API: server serves a challenge, and the client/extension would serve a response to the challenge. Would the details parameter include the challenge, and the return value receive the result?
* [thibault] Yes. As long as the extension is able to receive the header and respond to it, it would work.
* [simeon] How would it differ from other authentication mechanisms? E.g. bearer token. Wondering for browser engineers, would it make sense to expand beyond this specific authentication mechanisms?
* [thibault] I don't know if other authentication schemes were discussed.
* [rob] Wouldn't make sense for extensions to intercept bearer tokens. For this case, this mechanism should be opt-in with new flags to the API method. This authentication scheme is well defined and backed by a specification, I'm supportive from a Firefox perspective.
* [timothy] We don't support webRequest.onAuthRequired API at all, but if we did, I'd be supportive of it.
* [oliver] In principle supportive, but probably no engineering capability to implement this.
* [rob] So what I am hearing is patches are welcome.
* [oliver] Yes. Generally useful to see evidence of interest or desire to adopt.
* [tomislav] We'd need to also consult with our internal standard team before finally deciding on the patch.

[Issue 663](https://github.com/w3c/webextensions/issues/663): Should browser.tabs.create send SameSite=Strict cookies?

* [oliver] For context, a call to `chrome.tabs.create` includes SameSite=strict cookies by default, and there was a reporter that believed this to be a bug. Discussion on the issue is about whether it would make sense to add an option to opt out of including SameSite=strict.
* [aaron] Generally it makes sense to be private by default, but I'd like to give it more thought. As I just gained awareness of the issue
* [rob] Proposing to include initiator (origin that triggered the navigation request) in the API to offer control to extensions on whether SameSite=strict cookies are included.
* [aaron] That's worth exploring.

[Issue 664](https://github.com/w3c/webextensions/issues/664): Proposal: Support loadReplace for tabs.update()

* [simeon] Proposal is to add a loadReplace option to tabs.update to allow extensions to trigger a navigation that replaces the tab's current entry in the history.
* [timothy] Sounds useful, supportive of implementing this from Safari.
* [rob] Firefox has already implemented this, so remaining question is what is Google's position on this?
* [oliver] A case where patches are welcome. Haven't seen demand for this, but cannot imagine why we would not accept it.
* [simeon] What are examples of use cases?
* [oliver] For example, Tampermonkey offers a way to download a user script, this could be a way to erase the temporary intermediate URL from the history.
* [simeon] Any potential abuse concerns with this feature?
* [rob] There is the opposite problem, of history entries being added by websites that prevent the back button from working. That kind of issue does not appear here.

[Issue 532](https://github.com/w3c/webextensions/issues/532): request: Determine the nuances of aliasing chrome and browser #532

* [patrick] Devlin and Rob were discussing this and the email thread died out.
* [rob] Oops, I did miss the email response. I'll take a look.

[Issue 19](https://github.com/w3c/webextensions/issues/19): request: APIs and infrastructure to simplify cross-browser automated testing of extensions

* [simeon] The broad objective is that we as a CG would like to be able to run tests that verifies interoperability of extension APIs.
* [patrick] In the previous TPAC 2023 meeting in Spain we created a prototype, which was incompatible with the lifecycle model of extensions. When we met again in San Diego earlier this year, we decided to integrate deeper in WebDriver. I met with our WebDriver folks at Chrome and added more APIs, including installation and uninstallation of extensions. There are nuances between installing from the store and developer mode. Installation is currently comparable to install of extension by policy, like dragging a crx file to the chrome://extensions/ page. Current implementation calls a private webstore API to call it.
* [tomislav] Can we also participate in these discussions to design the capabilities, ahead of the meeting at TPAC 2024 in Anaheim? And at which layer in the protocol is this implemented?
* [patrick] This is built in the ChromeDriver portion of the WebDriver protocol. This is a thin wrapper around APIs that we are using internally. I can draft something and solicit feedback on Matrix, email, or wherever.
* [tomislav] Is this a state where it can already be called from the wpt runner?
* [patrick] Yes.
* [rob] Clarification request: is the installation like install from developer mode? Chrome has some nuances in API availability, e.g. declarativeNetRequest.onRuleMatchedDebug is only available to Developer Mode only.
* [patrick] I think it might.
* [simeon] Based on the response I think that it is opposite.
* [patrick] I will double-check and update the meeting notes.
* https://chromedevtools.github.io/devtools-protocol/tot/Extensions/ . It maps to loading an unpacked extension.
* [tomislav] Exact details can be figured out later.
* [simeon] So far the discussions have focused on Chrome and Firefox, what about Safari?
* [timothy] Supportive of WebDriver hooks to dynamically load extensions. We haven't started yet, and would like to start soon.
* [tomislav] Would be nice if we have a public repo and can push there so that Timothy and the Safari team can also look there.
* [simeon] IIRC where we left it off in San Diego, Safari cannot load extensions yet. Was hoping to do a small workshop to hack something together, but that unfortunately didn't work out due to illness.
* [timothy] We do have support internally, but need to hook it up. Once solidified how it works with wpt we should be able to hook it up easily.
* [patrick] Circling back to the earlier question, we load the extension as unpacked. The plan would be for packed and unpacked to be supported in the protocol though.
* [timothy] We would prefer unpacked in Safari.

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

* [aaron] The Chromium work has landed; some wpt tests that I wanted to add are also landing or will land. Would like to resolve the remaining points in this group. There is no debate on whether to do this.
* [rob] Do you know of any specific unresolved comments?
* [aaron] One regarding how crossSiteAncestor was calculated in the middle of the frame tree.
* [rob] Main priority is to ensure that the extension API is sufficiently capable of managing all cookies that the browser and user can encounter. This then touches on edge cases such as what should happen when the third-partyness changes (due to a public suffix list update).
* [aaron] We don't update cookies based on public suffix changes. We update cookies upon access. Abuse concern is when SameSite is set when it is cross-site. Ability to do that – get invalid cookies or remove them at runtime – makes sense to me. Other things like cookies getting deleted (expiration etc.). Cookies.remove supports invalid cookie combinations, whereas cookies.set has more stricter validation.
* [rob] I'll read the PR after the meeting & provide feedback after. Anyone from Apple have thoughts?
* [timothy] We don't have anything like this exposed to extensions. We do have cross-origin cookies internally, but we haven't exposed partitioning in the cookies API yet. I'm supportive of this proposal though.
* [aaron] Let me know if there's anything I can do to help.
* [rob] While I'm here as a browser rep, I've also authored a cookie manager extension so I'm familiar with the challenges of getting this API right.
* [timothy] And that's why I'm mostly deferring to you Rob when it comes to things like this.

[Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024

* [simeon] TPAC Is coming up, it is next month already. We should collect topics and set the schedule. Definitely wpt and getting it functional, anything else?
* [timothy] wpt was also on my list.
* [patrick] There were a few topics that we wanted to revisit at San Diego, probably worth revisiting the notes.
* [simeon] Probably also good to spend some time on the high level area that we'd like to cover in the specification.
* [timothy] I think that it is due time to start writing spec test. Previous hold-up due to MV3 transition, now that's behind it's time to start writing.
* [tomislav] browser namespace and testing would be a good start.
* [oliver] Chicken and egg situation; if anyone is interested, submit a PR and we can continue from there.
* [rob] Should discuss alignment on APIs. Chrome doesn't support promises in runtime.onMessage & webRequest.onAuthRequired.
* [timothy] We support promises in runtime.onMessage.
* [oliver] runtime.onMessage not much discussion, we agreed but didn't find time to implement yet. webRequest.onAuthRequired has some open questions.
* [simeon] DevTools APIs are all callback based, which is odd from a developer experience perspective.
* [rob] Chrome's devtools API binding implementation is independent of the regular extension API bindings, I have filed an issue before at https://crbug.com/1510416.
* [timothy] We support Promises and callback in the devtools API in Safari.

The next meeting will be on [Thursday, August 15th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66bd4500,384)
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,23 +10,24 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2024-08-01 at 8 AM PDT = https://everytimezone.com/?t=66aad000,384
- 2024-08-15 at 8 AM PDT = https://everytimezone.com/?t=66bd4500,384
- 2024-08-29 at 8 AM PDT = https://everytimezone.com/?t=66cfba00,384

## Past meetings

* 2024-08-01 ([minutes](2024-08-01-wecg.md))
* 2024-07-18 ([minutes](2024-07-18-wecg.md))
* 2024-07-04 ([minutes](2024-07-04-wecg.md))
* 2024-06-20 ([minutes](2024-06-20-wecg.md))
* 2024-06-06 ([minutes](2024-06-06-wecg.md))
* 2024-05-23 ([minutes](2024-05-23-wecg.md))
* 2024-05-09 ([minutes](2024-05-09-wecg.md))

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

**2024**

* 2024-08-01 ([minutes](2024-08-01-wecg.md))
* 2024-07-18 ([minutes](2024-07-18-wecg.md))
* 2024-07-04 ([minutes](2024-07-04-wecg.md))
* 2024-06-20 ([minutes](2024-06-20-wecg.md))
Expand Down