-
Notifications
You must be signed in to change notification settings - Fork 56
/
2023-03-16-wecg.md
142 lines (117 loc) · 11 KB
/
2023-03-16-wecg.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
# WECG Meetings 2023, Public Notes, Mar 16
* Chair: Timothy Hatcher
* Scribes: Rob Wu
Time: 8 AM PDT = https://everytimezone.com/?t=64125c00,384
Call-in details: [WebExtensions CG, 16th March 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230316T080000)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)
## Agenda: [discussion in #360](https://github.com/w3c/webextensions/issues/360), [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**
* Google Introductions
* [PR 359](https://github.com/w3c/webextensions/pull/359): Add interface definitions for Chromium
* [PR 358](https://github.com/w3c/webextensions/pull/358): Add runtime.getContexts() proposal
* [Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules
* **Open discussion queue (add yourself at the bottom)**
* None
* **Check-in on ongoing issues**
* [Issue 111](https://github.com/w3c/webextensions/issues/111): Allow optional overriding default newtab/bookmarks/history pages
* (more issues were nominated but omitted due to the lack of time)
## Attendees (sign yourself in)
1. Timothy Hatcher (Apple)
2. Mukul Purohit (Microsoft)
3. Tomislav Jovanovic (Moziilla)
4. Luke Warlow (No affiliation)
5. Simeon Vincent (No affiliation)
6. David Johnson (Apple)
7. Giorgio Maone (NoScript, Tor)
8. Rob Wu (Mozilla)
9. Jackie Han (No affiliation)
10. Oliver Dunk (Google)
11. Sebastian Benz (Google)
12. Ali Spivak (Google)
13. Tim Heflin (Keeper)
14. Bradley Cushing (Dashlane)
15. Dmitriy Seregin (AdGuard)
16. Maxim Topciu (AdGuard)
17. Javier Fernandez (Igalia)
## Meeting notes
Google introductions
* [oliver] Having a get together with other Chromie folks. Attending today are Ali and Sebastian. Sebastian is also on Chrome DevRel. Ali is manager for both Oliver and Sebastian.
[PR 359](https://github.com/w3c/webextensions/pull/359): Add interface definitions for Chromium
* [simeon] Main note from Rob's feedback last week on the PR is that there are a large number of private API definitions. I want to clean these up before the PR is merged.
* [simeon] I want to create a computer-digestible summary of.
* [timothy] This would be more complete coverage than what we currently inlined in Chrome.
* [tomislav] Since Rob has already reviewed I won't review as well.
* [tomislav] I am working on Firefox's JSON files.
* [tomislav] Have you looked at [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data)? It sometimes features methods and sometimes supported parameters/options.
* [timothy] Side note, a way to auto-generate compat tables would be interesting.
* [rob] Method or namespace or option?
* [timothy] Methods would be great.
* [rob] I have built something like that before, “Tool to automatically collect API information from Chrome”: https://github.com/mozilla/webextension-polyfill/pull/122
* [simeon] What would be the language / runtime we want to use for building such tools?
* [rob] Node.js / JS would probably be best. Also has libraries to directly run extensions/code in browsers.
[PR 358](https://github.com/w3c/webextensions/pull/358): Add runtime.getContexts() proposal
* [timothy] I believe this is ready to go. Simeon reviewed it, Rob shared some feedback.
* [rob] I believe that Simeon had some comments. Do you want to resolve the comments before merging?
* [simeon] I believe that as a process we agreed to merge in principle. Pretty comfortable with the direction, some things can be polished later.
* [rob] I will take a final look and merge after that.
* [timothy] I imagine that after merging we can have additional PRs to update the document.
[Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules
* [timothy] API inspired by Safari's content blocking API to hide element based on CSS selectors. Mostly useful for ad blocking. When we previously discussed this briefly, we agreed to not tie to DNR because CSS-based hiding is not necessarily connected to DNR.
* [dmitry] We at AdGuard, we do not only mean CSS rules, but also scriptlets or script rules that will be executed in user pages by executing content scripts. The main purpose of the proposal is to cut the required permissions.
* [rob] A CSS selector can easily match everything; how would that reduce the required permissions? Effectively the proposal with JS would execute JS everywhere.
* [dmitry] (...) Starting with CSS would be fine.
* [tomislav] I would start the proposal restricted to element hiding through CSS, and if there are common scriptlets suggest specific actions for common cases.
* [tomislav] Safari has implemented something similar before. Could you share your experiences?
* [timothy] It is part of our Content Blocking API, a display:none CSS rule can be applied if the domain, etc. matches. We restrict it to display:none for privacy reasons, anything more, even color changes is not possible. The implementation is optimized using the same mechanism that we also use to block network requests (and backs Safari's declarativeNetRequest API).
* [timothy] If the scriptlet or something were to be added, we would require permissions.
* [tomislav] Do you just inject an additional stylesheet or do you something special?
* [timothy] Not sure.
* [tomislav] It's an implementation detail, we don't need to discuss that right now.
* [timothy] Author vs user stylesheet would be relevant for the design.
* [oliver] Similar to DNR it would be useful to see a breakdown of rules that people are using, so we can prioritize what's really needed.
* [simeon] In the proposal as written, there are placeholders for scriptlets, but nothing in the API to register scriptlets. But as Tomislav mentioned, it's probably best to defer the scriptlets to the future.
* [rob] Even if we don't include scriptlets now, it would be acceptable to design the API to be forward-compatible with including the scriptlets feature in a follow-up.
* [rob] Chrome's DNR API automatically hides some elements (e.g. images) when a request is blocked. How does that work in Safari, and how would that play with this API?
* [timothy] Not aware of that. Safari does not do that.
* [rob] Firefox's DNR implementation does not do that either.
* [timothy] I'll file an issue internally.
* [rob] If we decide on having this API, then there would not be a need to hide elements through DNR. Then extensions can decide what to do themselves.
* [timothy] I wouldn't want to support arbitrary CSS without additional permissions. If visibility:hidden is common we can consider that, but anything more than that or display:none.
* [maxim] We disallow all CSS that can load arbitrary URLs.
* [simeon] It's a bit trickier than that. This was a consideration for CSP in content scripts in Chrome. One of the concerns with remote CSS is data exfiltration through selectors matching input fields for example. Just worth noting that arbitrary CSS can be more dangerous than it seems.
* [timothy] We can explore expansion later, and even do it like DNR (e.g. declarativeNetRequestWithHostAccess) to expand the featureset later with permission requirements.
* [simeon] Curious about browser vendors' perspective. Some DNR actions (block, upgradeScheme) do not require host permissions, but others (modifyHeaders) require host permissions. Should this pattern be followed?
* [timothy] We've implemented redirect and modify headers that require host permissions. I think that makes sense.
* [rob] Similarly in Firefox, but unlike Chrome, we won't allow extensions to block other extensions' requests by default
DNR blocking requests from other extensions
* [rob] (forked off previous discussion) Unlike Chrome, Firefox won't allow extensions to block other extensions' requests (https://bugzilla.mozilla.org/show_bug.cgi?id=1810753).
* [sam] At DuckDuckGo we had user feedback that we were blocking requests made by another extension; https://bugs.chromium.org/p/chromium/issues/detail?id=1421697
* [rob] Oliver, would you consider this a bug?
* [oliver] My first inclination is that this is a bug, since we have a flag to explicitly allow extensions to run scripts and access other extensions.
* [rob] Timothy, what's Safari's behavior?
* [timothy] I don't know offhand.
* [rob] What would the desired behavior be? E.g. background script sends a request to a remote destination.
* [timothy] I don't think that we would/should apply DNR rules in other extensions. Background script request is safe; request in content scripts may not be.
* [rob] In Firefox background script fetches cannot be intercepted/blocked by other extensions, but requests from content scripts can.
* [simeon] How about sandboxed extension pages?
* [rob] That's a good one…
[Issue 111](https://github.com/w3c/webextensions/issues/111): Allow optional overriding default newtab/bookmarks/history pages
* [timothy] After the user has turned on the extension, the user can be prompted and approve, and the decision can be changed later.
* [timothy] We have shipped new tab override for a year now, with this opt in.
* [simeon] Does the user setting allow the user to choose among multiple extensions?
* [timothy] Any installed extension with an override appears there.
* [jackie] It is common for users to contact a developer and request the ability to
* [simeon] This is not a specification, but a product design decision. This is therefore more of a bug for Chrome.
* [oliver] Simeon, in a comment you wrote that Chrome has the Single Purpose policy. Should we want to keep the single purpose policy or support optional new tab pages? I have seen the request before, and it could be an interesting feature.
* [timothy] The API aspect here is that in Safari an extension does not know whether the extension overrides the new tab page.
* [rob] A hacky work-around would be to open a new tab and checking whether the new tab is the extension tab.
* [sam] Issue with new tab is that it is a fixed permission that disables the extension when added in an update.
* [rob] Firefox has solves that kind of issue; e.g. the devtools_page manifest key ordinarily triggers a permission warning, but by using the “devtools” permission the feature becomes opt-in (https://bugzilla.mozilla.org/show_bug.cgi?id=1606862).
* [tomislav] Even if individual browsers want to make features optional, I would not be inclined to specify that behavior - it's a product decision by individual browsers.
* [rob] Could anyone with interest in this functionality post a proposal in the issue, so we can revisit this later?
(ran out of time, dropped the remaining four issues from the agenda)
The next meeting will be on [Thursday, March 30th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6424d100,384).
Note: In Europe, winter time changes to summer time, so the meeting is now back to the “usual” time of the day, following the last meeting where the clock changed from PST to PDT.