-
Notifications
You must be signed in to change notification settings - Fork 54
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 #428 from w3c/meeting-2023-07-20
Publish minutes of 2023-07-20 meeting
- Loading branch information
Showing
2 changed files
with
167 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,165 @@ | ||
| # WECG Meetings 2023, Public Notes, Jul 20 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=64b87900,384 | ||
| Call-in details: [WebExtensions CG, 20th July 2023](https://www.w3.org/events/meetings/51a7d2ff-e00d-462b-9071-73b93e78b053/20230720T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #419](https://github.com/w3c/webextensions/issues/419), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields | ||
| * [Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 | ||
| * **Other new issues** | ||
| * [Issue 418](https://github.com/w3c/webextensions/issues/418): Security: fetch event in service worker can bypass the limitation of extension's CSP | ||
| * [Issue 422](https://github.com/w3c/webextensions/issues/422): Inconsistency: limits on browser.alarms.create() | ||
| * [Issue 424](https://github.com/w3c/webextensions/issues/424): Overview of Persistent States of Various APIs | ||
| * [Issue 425](https://github.com/w3c/webextensions/issues/425): Inconsistency: different permissions can be optional permissions across browsers | ||
| * [Issue 426](https://github.com/w3c/webextensions/issues/426): Inconsistency: Navigation to file:// URLs using tabs and windows APIs | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Timothy Hatcher (Apple) | ||
| 3. Oliver Dunk (Google) | ||
| 4. Jun Kokatsu (Google) | ||
| 5. Kiara Rose (Apple) | ||
| 6. Patrick Kettner (Google) | ||
| 7. Benjamin Bruneau (1Password) | ||
| 8. Carlos Jeurissen (Jeurissen Apps) | ||
| 9. Jackie Han (No affiliation) | ||
| 10. Tomislav Jovanovic (Mozilla) | ||
| 11. Simeon Vincent (Unaffiliated) | ||
| 12. Steven McLintock (1Password) | ||
| 13. Tim Heflin (Keeper) | ||
| 14. Giorgio Maone (NoScript, Tor) | ||
| 15. David Johnson (Apple) | ||
| 16. Rob Hudson (Apple) | ||
| 17. Sam Macbeth (DuckDuckGo) | ||
| 18. Mukul Purohit (Microsoft) | ||
| 19. Richard Worth (Capital One) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields | ||
|
|
||
| * [simeon] Last time I believe there were open questions on how browsers felt about the request after developers provided clarification. Let's check in with browsers now that they've had time to consider. | ||
| * [rob] Curious about feasibility notes from other browser vendors. | ||
| * [patrick] Technically feasible, but needs lots of convincing from engineering. | ||
| * [simeon] Counterpoint is that the ecosystem (particularly ad blockers) already does this and manages that. | ||
| * [patrick] The adblocker use case already has tooling to expand the wildcards as needed. It is unlikely for us to support this feature based on the given rationale. | ||
| * [tomislav] It is unlikely for a domain on every TLD to be owned by the same entity. Therefore I am against it. | ||
| * [rob] Are you talking about in general or in this API? I share the concern with permissions, but not so much in the specific API here. | ||
| * [tomislav] Probably not as concerning with the API. | ||
| * [simeon] If user prompts & permissioning is a concern, TLD wildcard TLDs could be <all_urls> can be used. | ||
| * [tomislav] But we want to move away from needing <all_urls>. | ||
| * [timothy] The DNR API can already match broadly, even with regexps. | ||
| * [tomislav] Good points, I withdraw my objection. | ||
| * [simeon] Besides the maintenance issue of having large lists. A challenge here is that the limited number of regexFilter rules. The resulting file can be very large. | ||
| * [patrick] If Safari is supportive, I can get it back to engineering to see if they can reconsider. Leaning negative, but not opposition. | ||
| * [timothy] That would be fine. We talked with the involved WebKit folks and they were supportive of TLD matching and offered guidance to do it. Technically possible. | ||
|
|
||
| [Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 | ||
|
|
||
| * [simeon] We have been approved for two sessions, on Monday and Tuesday, one and a half hours each. Proposals for topics are welcome. | ||
| * [oliver] Meeting with WebAuthn groups. | ||
| * [timothy] There may possibly be interest from our authentication teams as well. | ||
| * [tomislav] I'll also check if there are people from Mozilla interested in that. | ||
| * [tomislav] Maybe also localization, to discuss Message Format 2. | ||
| * [simeon] Could you share a link to the relevant spec and group? | ||
| * [timothy] JSC team also has interest in the internationalization format from Apple. | ||
| * [rob] Did we get the requested time slots or a different one? | ||
| * [simeon] The requested ones as written in the issue. | ||
| * [rob] In the same week on Thursday, we have the regular meeting (this one), which will continue to happen as usual, right? | ||
| * [simeon] Yes. | ||
| * [simeon] Who have confirmed their attendance at TPAC? | ||
| * [simeon] I'll attend. | ||
| * [oliver] I'll attend from the Google side. | ||
| * (inaudible - a bunch of people speaking at the same time) | ||
| * [simeon] If you are attending, could you drop a comment in the issue? Then I'll add you to the list of attendees | ||
|
|
||
| [Issue 418](https://github.com/w3c/webextensions/issues/418): Security: fetch event in service worker can bypass the limitation of extension's CSP | ||
|
|
||
| * [jackie] How do we solve this problem, via technical or policy means? | ||
| * [simeon] To summarize the issue: In a Service Worker, the “fetch” event listener can intercept requests including script requests and provide an arbitrary response. The Chrome team is aware of this issue, and the primary purpose of the restriction in MV3 is to limit the execution of remote code. Make it harder, not impossible. Remote code execution prevented through platform and policy enforcement. How do other browsers view this abuse channel? | ||
| * [timothy] This doesn't work in Safari, we don't hook up “fetch” events. | ||
| * [rob] Our objective at Firefox is to prevent arbitrary remote code execution in privileged extension contexts. The capability described here does not fit in our objectives. We are not limiting code execution in the web page context though. | ||
| * [tomislav] These events aren't hooked up in Firefox's prototype of extension service workers. | ||
| * [simeon] To emphasize - to Rob's point about privileged contexts - this “fetch” feature only works in the extension's origin. Foreign fetch is not supported, and web pages aren't affected by this “fetch” event of the extension. | ||
| * [oliver] Given that the other browser vendors feel similarly, I'll check with Chrome whether Chrome would restrict it. | ||
| * [simeon] Can you clarify what you have in mind? Are you thinking about removing the fetch handler or something else? | ||
| * [oliver] Haven't thought this through, but thinking similarly to CSP, e.g. enforcing it in the “fetch” handler. | ||
| * [simeon] Okay, we'll table this for now and revisit it in a future meeting. | ||
|
|
||
| [Issue 422](https://github.com/w3c/webextensions/issues/422): Inconsistency: limits on browser.alarms.create() | ||
|
|
||
| * [anton] Chrome has a limit on the number of alarms that it can create (500). But there are no limits on the name of the limits. Extensions can save arbitrary data encoded in the string. Firefox doesn't cap the number of alarms. My proposal is to limit the name and number of alarms. | ||
| * [rob] Not the only API where strings can be of arbitrary length. Should we make an effort to audit all APIs, or leave this as an implementation concern? | ||
| * [anton] I would suggest addressing them one at a time. | ||
| * [tomislav] I don't see a purpose for unlimited name lengths. The alarm limit of 500 seems arbitrary. | ||
| * [patrick] 500 alarms covered the 99.99 percentile usage and is well before the performance in Chrome becomes crappy. | ||
| * [patrick] Misusing this API as a storage hack is quite clever, but fixing this is probably not a high priority. | ||
| * [rob] At least for new APIs this is something we should actively consider in the API design. | ||
| * [mukul] On e.g. Android there is precedent for a limited number of alarms. | ||
| * [simeon] I'm not familiar with mobile development. Are there similar APIs for time-based callbacks? | ||
| * [timothy] Timers are a native API, but I don't think that there is a limit on iOS. I commented in the issue that there are no limits in Safari. | ||
| * [rob] Is that an intentional design or merely a statement of the current implementation? | ||
| * [timothy] Current limitation. I'm open to adding a cap. | ||
|
|
||
| [Issue 424](https://github.com/w3c/webextensions/issues/424): Overview of Persistent States of Various APIs | ||
|
|
||
| * [jackie] In relation to the previous issue (issue 422), this issue lists APIs with potential storage capabilities. Different APIs have different behavior on whether the state persists across sessions or updates. | ||
| * [oliver] Thanks for putting this together. I sympathize with the problem and have wanted to create such a table for a while. | ||
| * [simeon] Sync is missing as a state. | ||
| * [rob] What do we want to do with this list? | ||
| * [simeon] Should expand the table with data from other browsers. | ||
| * [oliver] I have Firefox and Safari data already. | ||
| * [timothy] What stands out to be is dynamic rules. We do persist. | ||
| * [rob] Well the intent was to clean, but the actual implementation in Chrome persists, even across uninstalls (which is a bug in Chrome). | ||
| * [tomislav] We are open to aligning. | ||
| * [rob] I propose that we put this in a document in the repo rather than in an issue? Let's move it to a pull request now. | ||
| * [simeon] When there is a document, please be generous with approving PR. | ||
| * [rob] For this specific PR, let's squash the commits before merging if there are many minor edits. | ||
| * [oliver] Jackie would you like to create a PR or should I? | ||
| * [jackie] I'll submit a PR. | ||
|
|
||
| [Issue 425](https://github.com/w3c/webextensions/issues/425): Inconsistency: different permissions can be optional permissions across browsers | ||
|
|
||
| * [anton] Different browsers have different optional permission support. Can all permissions be optional? E.g. the “devtools” permission is effectively a remote code permission, which should ideally be optional. | ||
| * [rob] I have some additional context. But first, is devtools an example or the primary permission you're interested in? | ||
| * [anton] Just an example. contextMenus as an example, users cannot disable them. | ||
| * [rob] Context menu case is different as it doesn't have a permission warning. Might be interesting to explore what we want to do with permissions that do not have a permission warning. For “devtools”, in Firefox this makes the devtools_page optional in firefox. In Chrome, it displays a scary warning. Whether APIs are optional or non-optional is primarily an API design detail and partly implementation. Revoking/granting API permissions can be expensive in some cases (e.g. DNR requires expensive computation). | ||
| * [simeon] I want to encourage the platform to move in the direction of optional permissions. | ||
| * [tomislav] Most of our APIs have optional permissions, with exceptions that Rob mentioned. To the topic of the “contextMenus” permission, which doesn't have a permission warning: revoking the permission and disabling an API may result in unexpected behavior to extensions. If others want opt-outs for promptless permissions, we'd be open to consider it. | ||
| * [timothy] We auto-grant API permissions without permission prompts. Everything is gated on host permissions. | ||
| * [sam] To echo from the DuckDuckGo side: existing extensions with large user bases cannot use permissions with warnings, because that prevents users from upgrading smoothly. Optional permissions or prompt-less grants help with this use case. | ||
| * [simeon] Expanding on that, in Chrome new required permissions will cause the extension to be disabled on update until the user approves any newly requested permissions. | ||
| * [timothy] API permission requests are granted silently, but there are some APIs where a new request results in disabling the extension, if they don't overlap with the bucket of similar capabilities. | ||
| * [rob] If permissions.request is used with a different-bucket extension, does that also disable the extension? Or is it silently granted? | ||
| * [timothy] Not sure, I have to check. | ||
| * [tomislav] In Firefox we don't disable the extension, but we don't upgrade it. The user is prompted to confirm new permissions and upgrade is delayed until they approve the request. | ||
| * [simeon] Pausing discussion in the interest of briefly discussing the final issue. | ||
|
|
||
| [Issue 426](https://github.com/w3c/webextensions/issues/426): Inconsistency: Navigation to file:// URLs using tabs and windows APIs | ||
|
|
||
| * [oliver] Security concerns with navigating to file:-URLs from extensions. Concern is less about abuse by extensions, more about vulnerable extensions being tricked into navigating to file:-URLs. | ||
| * [tomislav] Navigating to file:-URLs plus running scripts in file:-URLs is a potential attack surface. | ||
| * [timothy] Safari extensions cannot interact with file:-URLs. | ||
| * [oliver] Would you be interested in restricting extensions from opening local files by default? | ||
| * [rob] Is this just file:-URLs, or also other (privileged) schemes? | ||
| * [jun] Mostly about navigating to file-:-URLs. Attackers can use this to download and exfiltrate user files. | ||
| * [rob] In the past I reported various security vulnerabilities to Chrome that depend on navigation to privileged schemes. Is Chrome considering to remove the ability to navigate to privileged schemes? | ||
| * [jun] We'd like to, but usage is higher. | ||
|
|
||
| The next meeting will be on [Thursday, August 3rd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64caee00,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