-
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.
Merge pull request #377 from w3c/meeting-2023-04-13
Publish minutes of 2023-04-13 meeting
- Loading branch information
Showing
2 changed files
with
156 additions
and
2 deletions.
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,153 @@ | ||
| # WECG Meetings 2023, Public Notes, Apr 13 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=64374600,384 | ||
| Call-in details: [WebExtensions CG, 13th April 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230413T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) 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. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * None | ||
| * **Other new issues** | ||
| * [Issue 372](https://github.com/w3c/webextensions/issues/372): Inconsistency: DNR modifyHeaders supported headers | ||
| * [Issue 373](https://github.com/w3c/webextensions/issues/373): Inconsistency: Return type of chrome.scripting.executeScript | ||
| * [Issue 374](https://github.com/w3c/webextensions/issues/374): Proposal: manifest.json network_permissions | ||
| * [Issue 375](https://github.com/w3c/webextensions/issues/375): Proposal: event listeners registered by content scripts should have higher priority than page's own | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 366](https://github.com/w3c/webextensions/issues/366): Inconsistency: Style in options_ui, browser_action, action | ||
| * Issues [318](https://github.com/w3c/webextensions/issues/318) and [319](https://github.com/w3c/webextensions/issues/319): static rulesets limits, dynamic rules limit | ||
| * [Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Mukul Purohit (Microsoft) | ||
| 3. Luke Warlow (Unaffiliated) | ||
| 4. Richard Worth (Capital One) | ||
| 5. Timothy Hatcher (Apple) | ||
| 6. Andrey Meshkov (AdGuard) | ||
| 7. Dmitriy Seregin (AdGuard) | ||
| 8. Oliver Dunk (Google) | ||
| 9. Tomislav Jovanovic (Mozilla) | ||
| 10. Jason Waterman (Mozilla) | ||
| 11. David Johnson (Apple) | ||
| 12. Bradley Cushing (Dashlane) | ||
| 13. Carlos Jeurissen (Jeurissen Apps) | ||
| 14. Simeon Vincent (Unaffiliated) | ||
| 15. Sam Macbeth (DuckDuckGo) | ||
| 16. Maxim Topciu (AdGuard) | ||
| 17. Steven McLintock (1Password) | ||
| 18. Tim Heflin (Keeper) | ||
| 19. Benjamin Bruneau (1Password) | ||
| 20. Kiara Rose (Apple) | ||
| 21. Giorgio Maone (NoScript, Tor) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 372](https://github.com/w3c/webextensions/issues/372): Inconsistency: DNR modifyHeaders supported headers | ||
|
|
||
| * [timothy] In Safari we are under the impression that Chrome has a strict set of headers to support, and we recently had bug reports about Sec- headers not being supported. | ||
| * [simeon] Early on the plan was to not allow arbitrary header modifications, but that was never implemented. Over time the developer community raised concerns about the impact this would have and we decided to only block a subset of headers from being added. | ||
| * [timothy] Does Chrome have a deny list? | ||
| * [rob] I shared context on Chrome's behavior at https://github.com/w3c/webextensions/issues/372#issuecomment-1499320761. | ||
| * [sam] Use case for modifying arbitrary headers is to prototype new headers (e.g. Sec-GPC). | ||
| * [timothy] In Safari we are planning to allow Sec-GPC. We have an allow list instead of deny list. | ||
| * [rob] Is there a reason to have an allow list instead of a deny list? | ||
| * [timothy] Concern over privacy and tracking purposes. | ||
| * [rob] I'm generally supportive of not restricting header modifications unless there is a good reason to; historically DNR's predecessor (webRequest) has been used in research to prototype new header-based privacy features. That innovation is not possible if the core API to modify requests is very restricted. | ||
| * [carlos] The webRequest API in the past allowed many currently considered troublesome headers to be modified. At some point Chromium decided to limit this and only allow this with an additional flag (“extraHeaders”). Potentially a similar approach can be applied to DNR to make it easier to review extensions. | ||
| * [simeon] It would be easier to decide the direction here if we had a vision on what extensions should be allowed to do. Don't want to distract too much right now, but we should consider establishing guidelines | ||
| * [timothy] Good goal. Applies more broadly to everything we discuss related to capabilities or features. | ||
| * [timothy] Behaviors between Chrome, Firefox and Safari differ as discussed before. It probably makes sense to continue the discussion offline. | ||
| * [rob] Could you (Google and Apple) post a comment with the current behaviors (and intended behavior if any), so that we can have a common ground to start the discussion with? | ||
|
|
||
| [Issue 373](https://github.com/w3c/webextensions/issues/373): Inconsistency: Return type of chrome.scripting.executeScript | ||
|
|
||
| * [timothy] Planning to resolve it in Safari. | ||
| * [tomislav] Rob already responded on behalf of Firefox in the issue; we'll support documentId when the concept is introduced to our extension API. | ||
| * [timothy] Likewise in Safari. | ||
| * [sam] Is the fix going to be backwards-incompatible in Safari? | ||
| * [timothy] The top-level returned result is going to be an array, but changing from strings to objects is indeed a backwards-compatibility concern that we need to discuss internally. | ||
| * [simeon] Extensions can do type checking to be compatible with multiple Safari versions. | ||
| * [rob] Firefox supports “error”, will Safari support that? | ||
| * [kiara] I'll look up the documentation, but we would like to match other browsers. | ||
| * [rob] I filed an issue in Chrome for “error”, what's the status on https://bugs.chromium.org/p/chromium/issues/detail?id=1271527? | ||
| * [oliver] It's assigned, but I don't know the status. I can follow up here. | ||
| * [rob] While the implementations vary, there is clear consensus on converging towards a common return type. Let's add “supportive” labels for all browsers here. | ||
|
|
||
| [Issue 374](https://github.com/w3c/webextensions/issues/374): Proposal: manifest.json network_permissions | ||
|
|
||
| * [anton] As an extension author we'd like to increase the visibility of network request controls, so that extensions can differentiate themselves from other extensions by good privacy practices that limit access to data. | ||
| * [tomislav] Dark Reader works as a content script to apply dark mode to pages. | ||
| * [tomislav] Web pages are not designed to avoid data exfiltration, and extensions are built on top of the web platform. Supporting this feature would be near impossible. | ||
| * [rob] I linked previous discussion and context in https://github.com/w3c/webextensions/issues/374#issuecomment-1507068307. In short, the feature is infeasible to implement. I would gladly be proven wrong and am interested in ways to support this feature in a usable way. | ||
| * [andrey] If there is a way to prevent extensions from connecting to external websites, some abuse is limited. An issue is that extensions cannot control/block requests from other extensions. If DNR can block other extension requests, that would be a solution. | ||
| * [rob] Previously we decided to not allow extensions to modify requests from other extensions, in [issue 369](https://github.com/w3c/webextensions/issues/369). | ||
| * [simeon] Isolating execution and network access is a very hard problem that browsers simply can't support today. During my time on the Chrome team, I was especially excited about an isolated frame concept that was introduced as part of the privacy sandbox effort. This may be able to provide some of the primitive isolation properties extensions may want/need. | ||
| * https://developer.chrome.com/en/docs/privacy-sandbox/fenced-frame/ | ||
| * [andrey] Can browsers allow extensions such as AdGuard to block any request, including other extensions? Then AdGuard can protect the user. | ||
| * [rob] A browser cannot tell which extension is more trusted than another. Even the ability to block other extensions or privileged requests can cause issues, e.g. if (extension) updates are blocked. | ||
| * [andrey] Can't requests be restricted by CSP? | ||
| * [anton] Yes, but needs to be declared at install time. Be the most permissive CSP that the extension needs. It is not dynamic like permissions. | ||
| * [rob] As long as extensions can interact with external content, data leakage can occur and it is infeasible to restrict access. | ||
| * [andrey] Would be nice if there is a button to mark an extension as offline. | ||
| * [rob] There is already a button for that. It's called “Disable extension”. | ||
| * [anton] The goal is not to fully lock down access, but to add visibility to limited network access if implemented. | ||
| * [tomislav] There is a difference between prohibited by policy (of the extension stores) and disallowed in practice. | ||
| * [simeon] From my perspective, the challenge is the proposal's interaction between expressing the limitation and enforcing the limitation to effectively reach the goal. | ||
| * [timothy] All of all stores have some sort of field to specify privacy policies and such, but knowing the accessed domains would be useful. | ||
| * [tomislav] Because we cannot know what's at the other side of the server, we cannot make it granular. Access to one website can already result in exfiltration to another website (e.g. allowing access to google can be combined with a redirect to another site). | ||
| * [timothy] Related, I do like the idea of an explicit key to mark the required permissions, since host_permissions are optional. | ||
| * [tomislav] While host_permissions are optional, they are currently granted at install in Chrome. Firefox defaults to host_permissions being optional and not granted at install in MV3. | ||
| * [simeon] While the outcome here is negative towards the specific proposal, the browser vendors here have expressed interest in supporting the requested functionality if it is feasible. | ||
| * [oliver] 100% agreed with that. | ||
| * [timothy] Definitely agree with the goal, but it is a hard problem to solve. | ||
|
|
||
| [Issue 375](https://github.com/w3c/webextensions/issues/375): Proposal: event listeners registered by content scripts should have higher priority than page's own | ||
|
|
||
| * [timothy] This may need to be raised in the web platform standards group to give extensions a dedicated place to register events. | ||
| * [simeon] Extensions probably want to participate in the normal event flow. A way to opt in to the prioritized event dispatch for extensions would be nice. | ||
| * [alexei] Agree with Simeon. If there is a mechanism for extensions to guarantee injection of content scripts before scripts on the page execute, then this problem goes away. | ||
| * [simeon] Not completely; e.g. activeTab type extensions inject scripts after the start. These types of extensions may still need a way to run code earlier. | ||
| * [timothy] runAt is a suggestion, not a guarantee when scripts are only injected after the user opts in to running the script, at least initially. | ||
| * [simeon] If we have a way for extensions to override anything else, would we then have extensions fighting with each other or even itself? | ||
| * [timothy] That's a concern. If extensions can declare a priority, every extension would declare themselves as the highest priority. | ||
| * [tomislav] This might be worth raising an issue in the WHATWG's DOM working group for discussion. This could be easily implementable, and the API taking an options dictionary makes the API design. | ||
| * [oliver] This is one where concrete use cases could be useful. | ||
| * [anton] Thanks for the suggestion; I'll add use cases to the ticket and file an issue in the DOM WG. | ||
| * [rob] As an example of prior art, CSS has the concept of [Style origin](https://developer.mozilla.org/en-US/docs/Glossary/Style_origin), with UA / user / author styles. The scripting.insertCSS API allows extensions to insert user styles that override the page's author styles: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/insertCSS#origin | ||
| * [timothy] In Safari all content level stylesheets are user level. | ||
|
|
||
| [Issue 366](https://github.com/w3c/webextensions/issues/366): Inconsistency: Style in options_ui, browser_action, action | ||
|
|
||
| * [rob] Issue originally filed to complain about inconsistency, I reworded it to try to drive towards a resolution. Safari never implemented browser_style, Chrome dropped chrome_style in MV2, and Firefox will drop support for browser_style (at least in MV3). | ||
| * [oliver] I left a comment with Chrome's context: https://github.com/w3c/webextensions/issues/366#issuecomment-1506913718 | ||
| * [timothy] As mentioned, Safari never supported this. We had a similar feature in our previous extensions model but encountered similar issues to what other vendors noted. Sounds like we have consensus here. Should we close the issue? | ||
| * [rob] We can close it. We have consensus here and more discussion is unlikely. | ||
|
|
||
| Issues [318](https://github.com/w3c/webextensions/issues/318) and [319](https://github.com/w3c/webextensions/issues/319): static rulesets limits, dynamic rules limit | ||
|
|
||
| * [andrey] Status on Chrome? | ||
| * [oliver] We're looking into this and have no updates yet. | ||
| * [timothy] Safari and Firefox are supportive of the change. | ||
| * [rob] Firefox 113 includes support for declarativeNetRequest. Some limits have not been raised yet, but we are supportive of raising them, especially if the performance characteristics are favorable. | ||
| * [rob] About issue 319: Firefox has already separated the quota of session and dynamic rules. | ||
| * [rob] Another issue is the lack of way to easily determine the remaining quota, e.g. for regexFilter rules. | ||
| * [andrey] There is some way: try to add the rule and catch. | ||
|
|
||
| [Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules | ||
|
|
||
| * [timothy] This is quite an involved proposal. Please take a look and provide feedback offline. | ||
| * [rob] We discussed concerns before which are noted in the meeting notes of [2023-03-16-wecg.md (lines 79-107)](https://github.com/w3c/webextensions/blob/071839a55644bb8e5f700be5799652f094a41f1c/_minutes/2023-03-16-wecg.md?plain=1#L79-L107). | ||
|
|
||
| The next meeting will be on [Thursday, April 27th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6449bb00,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