From 72b641f13c2d3919a435a8e0270038c4d6c1fb35 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 20 Jun 2024 18:05:25 +0200 Subject: [PATCH] Publish minutes of 2024-06-20 meeting --- _minutes/2024-06-20-wecg.md | 161 ++++++++++++++++++++++++++++++++++++ _minutes/README.md | 5 +- 2 files changed, 164 insertions(+), 2 deletions(-) create mode 100644 _minutes/2024-06-20-wecg.md diff --git a/_minutes/2024-06-20-wecg.md b/_minutes/2024-06-20-wecg.md new file mode 100644 index 00000000..203e9ea9 --- /dev/null +++ b/_minutes/2024-06-20-wecg.md @@ -0,0 +1,161 @@ +# WECG Meetings 2024, Public Notes, Jun 20 + + * Chair: Timothy Hatcher + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=66737100,384 +Call-in details: [WebExtensions CG, 20th June 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240620T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #635](https://github.com/w3c/webextensions/issues/635), [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 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons + * [Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser + * [Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization + * [Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() + * [Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags + * **Timely issues** (10 minutes) + * [Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters + * [Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers + * **Check-in on existing issues** (20 minutes) + * [PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences + * **In-meeting topics** + * Automated extension API testing + * TPAC 2024 + + +## Attendees (sign yourself in) + + 1. Oliver Dunk (Google) + 2. Rob Wu (Mozilla) + 3. Giorgio Maone (Tor, NoScript) + 4. Timothy Hatcher (Apple) + 5. Solomon Kinard (Google) + 6. Simeon Vincent (Mozilla) + 7. Jackie Han (no affiliation) + 8. Tomislav Jovanovic (Mozilla) + 9. Maxim Topciu (AdGuard) + 10. Mukul Purohit (Microsoft) + 11. Rémi Pujo (Dashlane) + 12. Carlos Jeurissen (Jeurissen Apps) + + +## Meeting notes + +[Issue 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons + + * [timothy] Relevant to Firefox and Safari because Chrome requires service workers. + * [rob] In Chrome the solution is to use an offscreen document plus the manifest sandbox key. + * [oliver] Offscreen document should not be seen as the long-term solution. But at the same time it offers a way to do so, so not a priority to develop an alternative API. Current focus is on providing APIs to help with migrating to Manifest Version 3. + * [rob] manifest sandbox is currently supported in Chrome only. Is Safari going to support it? + * [timothy] On our timeline, but don't know when it will be supported. + * [tomislav] Firefox does support the regular CSP sandbox. + * [rob] sandbox on the web platform is inherit and can only be stricter; The manifest sandbox key enables extensions to specify documents that have a looser CSP, without access to extension APIs. + * [simeon] Chrome supports the manifest sandbox key to enable extensions to define a page that executes on a null origin. Sandboxed pages don't have access to extension APIs. For Chrome's MV3 transition efforts, this was a notable capability because the MV3 CSP restrictions prevented extensions from executing arbitrary code. + * [simeon] Any concerns against implementing manifest sandbox? + * [tomislav] No real concerns. + * [timothy] No objections. + * [rob] Might make sense to have sandboxed pages isolated to a specific subdirectory. + * [oliver] Since you have to declare the sandboxed page in the manifest, what benefit does a specific directory provide? + * [rob] Page wouldn't be able to include resources outside the directory. Reduces tracing work required to figure out exactly what code is executed. + +[Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser + + * [timothy] Essentially checking whether a condition is supported and would work. Rob suggested updateSessionRules and catch the error. + * [rob] The usual implementation in Chrome is to throw when an API receives an unexpected property or value, I guess that this may be an implementation detail where the flag that controls its availability is checked later. So the API recognizes the input, but the rule engine ignores it. + * [timothy] I see value in verifying whether a specific rule can be used. + * [oliver] [Issue 449](https://github.com/w3c/webextensions/issues/449) is about introducing a isRuleSupported() . + * [timothy] In Safari we return the original value. + * [rob] In Firefox the processed value is returned. I recall that Chrome stores the JSON separately from the compiled rules, so perhaps it returns the original value. + * [oliver] When we add a dynamic rule with an unrecognized value, we do throw. + * [timothy] Suggest closing this one in favor of [issue 449](https://github.com/w3c/webextensions/issues/449). + +[Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization + + * [timothy] This is more common these days; handling numbers/localization in different locales. + * [tomislav] The linked spec (https://github.com/tc39/proposal-intl-messageformat) is part of the Message Format 2 format, which is also worked on by Mozillians. Instead of bolting on more features on the existing JSON format I would be in favor of moving towards MF2. + * [timothy] I tend to agree. We don't need to reinvent the wheel. + * [oliver] I recall having discussed this before, but cannot find an issue. + * [carlos] The topic was suggested for TPAC 2023: https://github.com/w3c/webextensions/issues/385#issuecomment-1644126655 + * [rob] Briefly discussed before at TPAC 2023: https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-2023-09-14-tpac-extra.md?plain=1#L444-L447 + +[Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() + + * [timothy] We don't support bookmarks API in Safari, but this makes sense. + * [oliver] I don't see issues; I'll talk with the internal people at Chrome who work on the bookmarks API. + * [simeon] I'm supportive. Feels like a basic API ergonomics issue to me, and the pattern is well established with other APIs. + +[Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags + + * [carlos] Seems like there is no standard set of supported syntax for language tags in extensions. Suggest standardizing on BCP47. + * [simeon] Why BCP47? + * [tomislav] All modern web platform APIs use that. + * [simeon] tophf raised the concern in [a comment on the issue](https://github.com/w3c/webextensions/issues/642#issuecomment-2179107236) that existing tools use a different standard ([ISO/IEC 15897 standard](https://en.wikipedia.org/wiki/ISO/IEC_15897)). + * [carlos] That is why I suggest a manifest version bump. + * [carlos] Firefox already supports both. + * [timothy] We require underscores, but we can easily change it. I would be supportive of changing it or looking for both. + * [alexei] I think that this is a place where the browser should be forgiving. Accept the good way and continue supporting the legacy way. + * [rob] Sounds good to me. + * [oliver] Carlos, you mentioned that a BCP47 language tag is returned by i18n.getUILanguage. Were you able to test that? + * [carlos] I did some testing indeed. `i18n.getUILanguage` returns a BCP47 language tag (with hyphens) in both Chrome and Firefox. I believe the same is true for Safari. However in Chrome `i18n.getMessage(‘@@ui_locale')` returns underscores while in Firefox, it returns hyphens. + * [rob] What does it mean to declare “supportive” on the issue? + * [carlos] Summarize, support BCP47 in all areas we use language tags in the extension platform. While keeping support for the underscores as suggested by Alexei + * [rob] I would support that, and not discontinue the previous format for backwards-compatibility. + * [oliver] I'll follow up internally to check if this is feasible. + +[Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters + + * [oliver] Alexei shared feedback in a previous issue about wanting to redirect a request to a partial match of a URL. Rob already provided feedback, more feedback is welcome. We've wanted to tackle this for a bit and are considering adding it to our roadmap. + * [oliver] The use case is to handle when you click a link and are taken to a URL such as [example.com/redirect?url=something](http://example.com/redirect?url=something). Privacy Badger and other similar extensions want to be able to redirect directly to the destination from the query parameter using Declarative Net Request. + * [alexei] It is a way to clean tracking links. + * [rob] The issue appears to be very focused on this specific use case. My suggestion in [a comment on the issue](https://github.com/w3c/webextensions/issues/636#issuecomment-2165978322) was to make it a bit broader to be extensible for more use cases. + * [oliver] No strong feelings, want to balance implementation complexity. + * [timothy] I like Rob's suggestion, will read further. + +[Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers + + * [oliver] Exact match is very limited, we're looking into various ways of matching substrings. Multiple options considered, latest new question is whether to support globs (? and \*) + * [alexei] uBlock was interested in checking if the numeric value for a content length is over a limit. + * [oliver] Seems like a nice use case to address. + * [rob] Possible to create multiple patterns to match that, but it would be quite a hack. + * [rob] In the issue I proposed a simple substring match to enable the browser to easily/quickly reject a rule before evaluating a more complicated version of the pattern. + * [oliver] We were hoping that globs would offer the balance between functionality and performance. Would that work in Firefox? + * [rob] I would have to profile. Internally we transform globs to regular expressions except for very simple cases. + * [rob] Is there a timeline on settling the design? + * [oliver] Soon. This is the last major thing to resolve before we release the API. + * [timothy] I think globs would be okay. We have regexp in other places, so I wouldn't be opposed to that. + +[PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences + + * [timothy] Jackie opened a PR with a proposal for setting the language. + * [jackie] Feedback is welcome. + +[PR 569](https://github.com/w3c/webextensions/pull/569): Proposal: i18n-system-languages + + * [timothy] What is the status of this PR? + * [rob] Does not have a sponsoring browser. Our proposal process requires a sponsoring browser before merging proposals. + * [timothy] I'd be interested in sponsoring this. + * [carlos] Devlin also mentioned interest in sponsoring this. + * [oliver] On our side we would not mind sponsoring. + * [carlos] So Rob, what do you think about it? + * [rob] I'll take a look and probably sign off. + +End of meeting - random questions + + * Automated extension API testing + * [simeon] What is the status of automated testing of extension APIs? + * [timothy] We don't have support for that yet in Safari, but will look into developing the primitives to enable the prototype that Patrick built to work. + * TPAC 2024 + * [timothy] TPAC 2024 is in Anaheim. + * [simeon] We were waiting until an official announcement was made. + * [oliver] Registration is already open. + * [timothy] Without official announcement we cannot book the specific day, but if you are interested in participating you may as well register now. + +The next meeting will be on [Thursday, July 4th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6685e600,384) diff --git a/_minutes/README.md b/_minutes/README.md index f1e0a640..7ebfa4b2 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,23 +10,24 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2024-06-20 at 8 AM PDT = https://everytimezone.com/?t=66737100,384 - 2024-07-04 at 8 AM PDT = https://everytimezone.com/?t=6685e600,384 +- 2024-07-18 at 8 AM PDT = https://everytimezone.com/?t=66985b00,384 ## Past meetings +* 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)) * 2024-04-25 ([minutes](2024-04-25-wecg.md)) * 2024-04-11 ([minutes](2024-04-11-wecg.md)) -* 2024-03-28 ([minutes](2024-03-28-wecg.md))
All past meeting notes **2024** +* 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))