-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2023-08-17 meeting
- Loading branch information
Showing
2 changed files
with
164 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,161 @@ | ||
| # WECG Meetings 2023, Public Notes, Aug 17 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=64dd6300,384 | ||
| Call-in details: [WebExtensions CG, 17th August 2023](https://www.w3.org/events/meetings/51a7d2ff-e00d-462b-9071-73b93e78b053/20230817T080000/) | ||
| Zoom issues? Ping @robwu (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #435](https://github.com/w3c/webextensions/issues/435), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 362](https://github.com/w3c/webextensions/issues/362): Declarative cosmetic rules | ||
| * [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
| * [Issue 154](https://github.com/w3c/webextensions/issues/154): Proposal: browser.secureStorage API | ||
| * **New issues** | ||
| * [Issue 436](https://github.com/w3c/webextensions/issues/436): Freeform inconsistencies | ||
| * [PR 434](https://github.com/w3c/webextensions/pull/434) (merged): Create persistence-of-states.md (part of [issue 424](https://github.com/w3c/webextensions/issues/424)) | ||
| * [PR 421](https://github.com/w3c/webextensions/pull/421) (merged): Update affiliations in charter | ||
| * [PR 420](https://github.com/w3c/webextensions/pull/420): Add an API proposal for browser.readingList() | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 319](https://github.com/w3c/webextensions/issues/319): Increase the maximum number of dynamic rules to 30,000 | ||
| * [Issue 433](https://github.com/w3c/webextensions/issues/433): Inconsistency: Alarms API time slipping | ||
| * [Issue 169](https://github.com/w3c/webextensions/issues/169): Blocking webRequest usecase - add, modify and remove CSP directives | ||
| * [Issue 439](https://github.com/w3c/webextensions/issues/439): Proposal: Add filter for DNR modifyHeaders | ||
| * [Issue 440](https://github.com/w3c/webextensions/issues/439): Proposal: add dictionary operations to DNR modifyHeaders | ||
| * [Issue 208](https://github.com/w3c/webextensions/issues/208): Consider common API for push messages across browsers | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * <end of list> | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Luke Selker (Dashlane) | ||
| 3. Arthur Coruble (Dashlane) | ||
| 4. Benjamin Bruneau (1Password) | ||
| 5. Jason Waterman (Mozilla) | ||
| 6. Timothy Hatcher (Apple) | ||
| 7. Kiara Rose (Apple) | ||
| 8. Richard Worth (Capital One) | ||
| 9. David Johnson (Apple) | ||
| 10. Matt Gibson (Bitwarden) | ||
| 11. Carlos Jeurissen (Jeurissen Apps) | ||
| 12. Maxim Topciu (AdGuard) | ||
| 13. Dmitriy Seregin (AdGuard) | ||
| 14. Oliver Dunk (Google) | ||
| 15. Mukul Purohit (Microsoft) | ||
| 16. Jackie Han (No affiliation) | ||
| 17. Justin Lulejian (Google) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 362](https://github.com/w3c/webextensions/issues/362): Declarative cosmetic rules | ||
|
|
||
| * [rob] Andrey (AdGuard) is not here, let's move this to the next meeting. | ||
|
|
||
| [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
|
|
||
| * [rob] Similarly, Andrey also wanted to revisit this topic. | ||
|
|
||
| [Issue 154](https://github.com/w3c/webextensions/issues/154): Proposal: browser.secureStorage API | ||
|
|
||
| * [timothy] This API may be a better fit for the web platform. Are there other interested parties? | ||
| * [oliver] Would be nice to make this a web platform API, which would also result in more people available to work on the implementation across all OSs. | ||
| * [simeon] Is this connected to WebAuthn? | ||
| * [oliver] I wanted to check whether relevant Googlers are attending TPAC, but it looks like that is not the case. | ||
| * [luke] Interest from Dashlane. | ||
| * [benjamin] Also interest from 1Password. Wondering about details about browser/OS, and how security is guaranteed. | ||
| * [timothy] We're checking internally (WebKit) how this would or should look like, whether this would or should be a web platform thing. | ||
|
|
||
| [Issue 436](https://github.com/w3c/webextensions/issues/436): Freeform inconsistencies | ||
|
|
||
| * [carlos] (see issue) Goal is to reduce inconsistencies of freeform pages. | ||
| * [rob] Web pages in general or extension UI pages? | ||
| * [carlos] Extension UI pages (e.g. options UI pages); It could be helpful to define explicitly how these should be handled. | ||
| * [simeon] A comparison table describing the differences could make it easier to identify actionable parts for the browser. | ||
| * [carlos] The issue links to a repo with screenshots. | ||
| * [rob] An explicit comparison with suggestion of desired behavior would make it easier to discuss. | ||
| * [timothy] Think that this is a good area to focus on. E.g. on WebKit we trigger a special layout mode for autosizing. | ||
| * [rob] I'm supportive of converging towards something common when it's clear that we should be heading towards one behavior. | ||
| * [oliver] ... | ||
| * [carlos] There are inconsistencies which go beyond the freedom of letting web browsers make their own decisions in terms of UI. It is currently hard for an extension to work properly across browsers with the same CSS code. | ||
| * [simeon] CSS groups may be a better fit. | ||
| * [timothy] We talked about this before in the context of the <dialog> element. | ||
|
|
||
| [PR 434](https://github.com/w3c/webextensions/pull/434) (merged): Create persistence-of-states.md (part of [issue 424](https://github.com/w3c/webextensions/issues/424)) | ||
|
|
||
| * [simeon] FYI I merged the proposal from #424. Feel free to open PRs to add more data. | ||
| * [oliver] I'll submit a PR with the data I mentioned. | ||
|
|
||
| [PR 421](https://github.com/w3c/webextensions/pull/421) (merged): Update affiliations in charter | ||
|
|
||
| * [simeon] I've merged this as well, and wanted to explicitly call out this, because modifications to the charter should be called out for visibility. | ||
|
|
||
| [PR 420](https://github.com/w3c/webextensions/pull/420): Add an API proposal for browser.readingList() | ||
|
|
||
| * [simeon] Any objections to merging? | ||
| * [timothy] No concerns. | ||
| * [rob] Could we include the author / driver in the document, so that it is obvious whom to contact for questions and pull requests? | ||
| * [simeon] We've actively got an intern working on this, and the feature will probably be available within a few Chrome releases. | ||
|
|
||
| [Issue 319](https://github.com/w3c/webextensions/issues/319): Increase the maximum number of dynamic rules to 30,000 | ||
|
|
||
| * [oliver] The issue is [a proposal](https://docs.google.com/document/d/1srkkCJkl4X2KOOUwnpDd-kvm8AY70eZBAYI4m836bvQ/edit?usp=sharing) to increase the number of dynamic rules to 30k. I posted a proposal ([comment on #319](https://github.com/w3c/webextensions/issues/319#issuecomment-1682073791)) to identify a subset of rules (tentatively “safe rules”) for which a higher quota can be supported. | ||
| * [timothy] Examples of safe rules? | ||
| * [oliver] E.g. redirecting cookies elsewhere. | ||
| * [rob] how would the number of rules affect security? | ||
| * [oliver] If we did this earlier, we would have done things differently. But introducing the concept of “safe rules” could make it more secure. | ||
| * [simeon] Does the concept of dangerous map to rules requiring host permissions? | ||
| * [oliver] No. block/allow and maybe allowAllRequests. In the comment I mentioned that the name “safe rule” is subject to change. | ||
| * [timothy] Can extensions determine whether a rule is “safe” without trying to register and catch the error? | ||
| * [oliver] Could be supported. | ||
| * [timothy] I'd be in support of upping the limitation without additional concerns. | ||
| * [simeon] For visibility I also cross-posted the issue/proposal to the WECG Matrix room. | ||
|
|
||
| [Issue 433](https://github.com/w3c/webextensions/issues/433): Inconsistency: Alarms API time slipping | ||
|
|
||
| * [anton] The alarms API implementation in Chrome and Firefox counts the time elapsed, without pausing the time during which the laptop is asleep. I described an experiment in https://github.com/w3c/webextensions/issues/433#issuecomment-1681435807 and explained the behavior in Chrome's implementation. | ||
| * [arthur] In Dashlane we rely on the alarms API, and the slipping alarms issue causes spikes in requests to the server. | ||
| * [simeon] At this point browser vendors should look at the issue. I think that Safari's behavior of relying on the wall clock makes sense. | ||
| * [anton] At least in Chrome the change would be a few-line fix. | ||
| * [simeon] A CL in Chrome would probably be welcome. | ||
| * [oliver] I'm not sure if the sleep behavior is the wrong behavior or not, but it has existed for a long time, so I want to take a close look at the desired behavior. | ||
| * [simeon] We should investigate whether we want to use a relative or fixed time, in the API design. | ||
| * [oliver] I wonder what the drift is - if it is minor (a few seconds) that may be acceptable, if it's significant, it may be a larger issue. | ||
| * [anton] It's the time that the computer is asleep, for the first alarm across all extensions. | ||
| * [oliver] An alarm firing affecting other extensions seems like a bug. | ||
| * [rob] Are the bugs you've discovered Chrome-only or also in Firefox? | ||
| * [anton] Firefox is not affected by the issue discussed last (one extension affecting others), but the slipping alarm. | ||
| * [simeon] At this point it looks like there are two points here (1) Desired behavior of delayInMinutes? (relative? Fixed time?) (2) are there specific concerns with normalizing the behavior? | ||
| * [anton] That is an accurate summary. | ||
| * [arthur] And thirdly the Chrome-specific AlarmManager bug is unrelated to the topic. | ||
| * [rob] Agreed - the AlarmManager bug is a Chrome-specific bug, and in this group the desired API behavior would be more on-topic. Anton, could you describe the desired and current behavior from the API perspective? | ||
| * [anton] Yes. | ||
|
|
||
| [Issue 169](https://github.com/w3c/webextensions/issues/169): Blocking webRequest usecase - add, modify and remove CSP directives | ||
| [Issue 439](https://github.com/w3c/webextensions/issues/439): Proposal: Add filter for DNR modifyHeaders | ||
| [Issue 440](https://github.com/w3c/webextensions/issues/440): Proposal: add dictionary operations to DNR modifyHeaders | ||
|
|
||
| * [carlos] Multiple issues related to modifying headers based on their current value. I posted multiple proposals (#439, #440 as ways to address the use case) | ||
| * [oliver] Initial thought is that it may make more sense to describe specific actions instead of using regexp-based header matching. | ||
| * [simeon] Specific API to punch holes in CSP can also make it feasible to support CSP relaxation beyond just headers (e.g. CSP in <meta> HTML tags). | ||
| * [timothy] I agree with preferring a CSP-specific way to replace it, whether by DNR or a separate API. | ||
| * [simeon] Would this be a different kind of modification rule in DNR? | ||
| * [timothy] I was indeed expecting a different action type. I have to see what it looks like before being fully onboard. | ||
| * [oliver] Timothy or Rob, how complex is it to modify a page's CSP? | ||
| * [rob] Implementation details aside; it depends on the goal. E.g. for the user script use case, I would very much prefer a dedicated API to run a “user script” in the main world (or future user script world), over offering a broad API to relax the CSP everywhere. | ||
| * [timothy] I agree with Rob here. | ||
| * [carlos] I also agree with Rob and Timothy here - if there is another way to enable scripting, that would be preferred. But there are other headers that wouldn't be covered by such APIs. | ||
| * [rob] We should start with the use cases, and from that continue with solutions. Can we close #439 and #440, collect use cases and only then look for solutions (which may potentially be different from DNR)? | ||
|
|
||
| [Issue 208](https://github.com/w3c/webextensions/issues/208): Consider common API for push messages across browsers | ||
|
|
||
| * (out of time - not discussed) | ||
|
|
||
| The next meeting will be on [Thursday, August 31st, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64efd800,384). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters