Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Publish minutes of 2023-11-09 meeting #486

Merged
merged 1 commit into from
Nov 10, 2023
Merged

Publish minutes of 2023-11-09 meeting #486

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
175 changes: 175 additions & 0 deletions _minutes/2023-11-09-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
# WECG Meetings 2023, Public Notes, Nov 9

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=654c2100,3c0
Call-in details: [WebExtensions CG, 9th November 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20231109T080000/)
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**
* [Issue 471](https://github.com/w3c/webextensions/issues/471): getPackageDirectoryEntry in service workers
* [Issue 472](https://github.com/w3c/webextensions/issues/472): Add support for opening side panel without user interaction
* [Issue 473](https://github.com/w3c/webextensions/issues/473): Handle special URLs, avoid hard coding
* [Issue 474](https://github.com/w3c/webextensions/issues/474): Behavior of extension message ports and bfcache
* [Issue 475](https://github.com/w3c/webextensions/issues/475): Proposal: StorageArea.onChanged filters
* [Issue 476](https://github.com/w3c/webextensions/issues/476): Proposal: API to programmatically open the developer tools to a particular panel
* [Issue 478](https://github.com/w3c/webextensions/issues/478): Expose some or all SecureContext-restricted APIs in content scripts on insecure schemes (http)
* **Other new issues**
* [Issue 480](https://github.com/w3c/webextensions/issues/480): Proposal: A persistOnNavigation property for the action API proposal
* [Issue 482](https://github.com/w3c/webextensions/issues/482): match_origin_as_fallback in content_scripts declaration
* [Issue 483](https://github.com/w3c/webextensions/issues/483): Proposal: API to embed pages in WebExtension bypassing CSP
* **Open discussion queue (add yourself at the bottom)**
* None
* **Check-in on ongoing issues**
* [Issue 433](https://github.com/w3c/webextensions/issues/433): Alarms API time slipping


## Attendees (sign yourself in)

1. Oliver Dunk (Google)
2. Rob Wu (Mozilla)
3. Jarek Samic (1Password)
4. Tim Heflin (Keeper)
5. Todd Schiller (PixieBrix)
6. David Johnson (Apple)
7. Timothy Hatcher (Apple)
8. Carlos Jeurissen (Jeurissen Apps)
9. Dmitriy Seregin (AdGuard)
10. ​​Jackie Han (No affiliation)
11. Tomislav Jovanovic (Mozilla)
12. Patrick Kettner (Google)
13. Sam Macbeth (DuckDuckGo)
14. Richard Worth (Capital One)
15. Maxim Topciu (AdGuard)
16. Kiara Rose (Apple)


## Meeting notes

[Issue 471](https://github.com/w3c/webextensions/issues/471): getPackageDirectoryEntry in service workers

* [simeon] Originally filed in response to a question from a MDN maintainer. I figured that it would probably best to open the issue here for discussion.
* [simeon] The API currently returns a DirectoryEntry, not exposed in Service workers, so little utility in Chrome's MV3 because of that. Do we want to modernize it, make it work in the future?
* [rob] This API is built upon the Chrome-only long-deprecated fileSystem API. I recommend to just leave the issue at this and do nothing until there is demand for this functionality.
* [oliver] We're currently not prioritizing the implementation/refactoring of this API.
* [simeon] I don't expect other browsers to implement this, but I'm wondering if there is something else that we could agree on.
* [timothy] Would be good to know the use cases.
* [rob] And rather than this API in isolation, I'd like to consider broader fileSystem APIs.

[Issue 472](https://github.com/w3c/webextensions/issues/472): Add support for opening side panel without user interaction

* [timothy] We have action.openPopup, this is a request for the side panel. Safari doesn't have sidebar at the moment. I'll defer to the Mozilla/Google folks on this one.
* [todd] Our extension is used in the enterprise, and we'd like to move our current extension over to using the sidepanel. It would nice if we can get a permission to open the sidebar.
* [oliver] When we introduced the sidepanel we started with features (...). In Chrome, we're usually cautious with jarring UI interactions. In the action API we've understood the use cases and made a decision here.
* [tomislav] <all_urls> is overloaded for too many things, so we'd like to avoid overloading it.
* [rob] I second that. If desired, Chrome supports collapsing permissions. Firefox doesn't, but extension authors can declare a permission as optional in that case. action.openPopup is implemented in Firefox but the user interaction relaxation is currently not enabled by default.
* [timothy] My concern is that the sidebar can resize content.
* [rob] Extensions can already resize windows, that's not a new issue.
* [todd] Extensions currently try to run a content scripts and resize the content.
* [rob] Considering that, I'd be in favor of supporting a dedicated API to show sidebar content.

[Issue 473](https://github.com/w3c/webextensions/issues/473): Handle special URLs, avoid hard coding

* [timothy] Request to expose special URLs as constants or to tag them in a special way in the tabs API.
* [timothy] I'd be willing to consider a constant, but constants would then reflect the built-in and not any user/extension-defined overrides.
* [carlos] Last meeting we discussed this. This one is more about the ability to open special pages, rather than detecting them. E.g. extension management/shortcuts page.
* [simeon] It's worth noting that some of these capabilities are not necessarily exposed in URLs. E.g. in Firefox bookmarks cannot be visited through a URL, it's a panel/window.
* [jackie] The purpose of this is to avoid hard-coding URLs. Browsers could provide functions to do these. Developers can feature-detect the availability.
* [timothy] Offering methods to various APIs to open the UI would indeed enable the functionality without hardcoded URLs.
* [oliver] Constants are nice for comparisons, while functions are nice to open UI whose URLs cannot be accessed by extensions.
* [timothy] In Safari and Firefox some of this content does not have any (public) URL.
* [rob] This is a recurring feature request in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1269456). It looks like we're all converging towards dedicated methods to open such special pages.
* [oliver] There is precedent with this in openOptionsPage.
* [timothy] Indeed. Let's continue async.

[Issue 474](https://github.com/w3c/webextensions/issues/474): Behavior of extension message ports and bfcache

* [timothy] This was discussed at TPAC.
* [oliver] At TPAC we were largely in agreement that a port should be disconnected when a page enters cache. That was predicated on whether or not this matched Firefox's current behavior.
* [tomislav] I'll look into this and follow up.

[Issue 475](https://github.com/w3c/webextensions/issues/475): Proposal: StorageArea.onChanged filters

* [timothy] Supportive from Safari; adding a filter to onChanged to express interest in keys would be nice.
* [simeon] More broadly, it would be nice to have filters in more listeners (beyond just storage.onChanged).
* [oliver] Main hesitation at the moment is our filters are currently inconsistent. We don't want to have a bunch of different filters for different event types. Also not sure how feasible some of the requested filters are.
* [rob] Could you look into this and post the results on this issue?
* [oliver] Yes.
* [rob] FInal note, I'd be supportive of adding more filters. This enables extension authors to write more efficient extensions that don't wake up the event page or notify all content scripts all the time.
* [tomislav] This is global and therefore potentially very expensive to dispatch to all contexts. Would be very much in favor of filtering here.

[Issue 476](https://github.com/w3c/webextensions/issues/476): Proposal: API to programmatically open the developer tools to a particular panel

* [todd] This comes up from our use case. Basically user scripts; would be useful more broadly, to avoid requiring the user to click in several places, and help with onboarding. Could probably b.
* [rob] I see in the issue this is for calling from a content script. I'm very hesitant about exposing this to a content script. Even a background script. I think it would be fine to open a panel if DevTools is open, but not to open it directly.
* [rob] Also surfaces devtools specific issues that are not currently considered high severity security.
* [todd] Interesting thread modeling question. There are controls available to admins to restrict access to devtools. Agree that you'd want to have user interaction to open this.
* [timothy] I agree, as someone who has been around the Web Inspector for a long time, this would be quite dangerous. I'm supportive of switching when the devtools is already open, but I am opposed to open the devtools directly.
* [timothy] We have special messaging in the console to protect users from copy-pasting code snippets.
* [tomislav] We have onboarding guidance in DevTools to help confirm that the user is a developer. We wouldn't want to interrupt that experience.
* [oliver] Why devtools instead of sidepanel?
* [todd] That's possible now, but the sidepanel is restricted in size. Our customers are in countries with smaller screens, they'd have to undock the tool. Previously the consideration is when the tab navigates away, but that's indeed solved with the sidepanel.
* [timothy] You can always open a popup window (the windows.create() API).
* [rob] I think we're all opposed to the feature if the focus is on allowing the extension to open Devtools, but everyone is initially favor if it's focused on switching panels while DevTools are already open – more discussion is necessary.
* [todd] We'll investigate the option to open a popup and circle back.
* [rob] I'll close the issue after the meeting for the reasons above; if you want to morph the feature request in something else, feel free to file a new one.

[Issue 478](https://github.com/w3c/webextensions/issues/478): Expose some or all SecureContext-restricted APIs in content scripts on insecure schemes (http)

* [rob] Feature request is about exposing secure APIs in content scripts. The request is to expose these APIs in content scripts even on HTTP contexts. There are certain APIs that are not designed to run outside of a secure contexts. There are others that are introduced in secure contexts in order to encourage adoption of HTTPS. From Firefox's perspective, we're opposed to exposing all SecureContext APIs by default. Individual APIs can be considered on a case-by-case basis.
* [oliver] I agree with what you said; One thing from Chrome's side: we'd like consistency. We would ideally not expose some APIs to content scripts only, but if there are compelling use cases we'd consider that.
* [timothy] In agreement with Chrome. I'm concerned about opening up an avenue where something is exposed because there wasn't a security concern, but later becomes a security concern, that opens up potential for a cross-world exploit.
* [rob] I think we can mark this as opposed by all vendors and ask that requests for specific capabilities be filed as separate issues.

[Issue 480](https://github.com/w3c/webextensions/issues/480): Proposal: A persistOnNavigation property for the action API proposal

* [timothy] Request for persistOnNavigation to allow action overrides to persist across navigations.
* [timothy] I think that I'd prefer just “persist” because it's shorter.
* [rob] I'd prefer the original suggestion (“persistOnNavigation”) because it is less ambiguous than “persistent” (persist across sessions? Persist across updates? etc).
* [tomislav] Only persists if you don't include windowId or tabId. Inconsistency in API design: sometimes tabId is used to associate the call with a given page rather than tab.
* [rob] This issue can be marked as “supportive: edge” since the original feature request was filed by Eric Law from Microsoft. What's Google Chrome's position on this?
* [oliver] Wasn't aware of this behavior. Should we be looking to change the default in the future?
* [rob] We shouldn't change the default. Think of the use case of displaying a badge number showing the number of blocked requests in the tab; that's tab-specific.
* [tomislav] Been the default for a long time, should avoid breaking the ecosystem. We could introduce a flag and if we see significant adoption we can consider changing it for a future manifest.

[Issue 482](https://github.com/w3c/webextensions/issues/482): match_origin_as_fallback in content_scripts declaration

* [timothy] Safari doesn't currently support this, but we're interested in exploring it.
* [oliver] The backstory on this one: I was doing some work on the spec with Simeon, and we realized that this wasn't supported everywhere. It was buried in some issue.
* [rob] The history goes back further. I co-designed this with Devlin on the Chromium issue tracker, but never got around to implementing it in Firefox.
* [timothy] One question that I have, it's not always the parent frame, it's the opener frame.
* [rob] It's called the precursor principal. It's essentially the opener of the frame.
* [timothy] We should be able to implement it, but needs further investigation.
* [jackie] There's also a new key since Chrome 111, world, with values “MAIN” or “ISOLATED”.
* [rob] On Firefox's end we support world in the scripting API, but not in the manifest yet as we don't support the MAIN value yet (https://bugzilla.mozilla.org/show_bug.cgi?id=1736575).
* [timothy] Safari supports it in the scripting API, but not in content_scripts.
* [oliver] We support world in both the scripting API and manifest.
* [timothy] We're supportive of the world key.

[Issue 483](https://github.com/w3c/webextensions/issues/483): Proposal: API to embed pages in WebExtension bypassing CSP

* [timothy] Based on what's currently being discussed, we'd be opposed to a webview tag and it's not something we'd like to support.
* [oliver] I've seen a common pattern of using DNR to remove x-frame-options. Generally when developers do this, they don't filter by requesting frame, which weakens security across the web.
* [simeon] I understand the hesitation with exposing <webview>. In the shoes of extension developers: Extensions enhance the user agent. Browsers can embed arbitrary web content, but that's closed off to extension developers. Web pages can inspect their frame hierarchy and refuse to continue, but extensions cannot counter that.
* [oliver] There's precedence where we allow extensions to do things that we don't allow websites to do. Bypassing CSP for example.
* [rob] I have seen the request for X-Frame-Options bypass before in Firefox, and we have changed the direction a few times before, ultimately settling on enforcing X-Frame-Options in extensions: https://bugzilla.mozilla.org/show_bug.cgi?id=1595652
* [rob] What's Google's position here? Proposals are discussing Chrome-specific capabilities – it doesn't make sense to pursue something Chrome doesn't intend to support. Would like to see use cases where extensions can't do something and proposals to discuss specific solutions. This is a generic feature request with significant implementation complexity.
* [timothy] I second this desire for use cases.
* [oliver] I don't think that there is a single one that we want to pursue. We can already reject some, such as portals.
* [rob] I was thinking of limiting the options to choose from rather than choosing a specific option right now.
* [tomislav] Example is one of Carlos' extensions: embedding Gmail in a popup or sidebar.
* [simeon] Another example is an extension that scrapes & instruments a website to expose capabilities in a new custom UI. For example, a multi-service messenger client.
* [rob] Another approach could be to permit loading http(s) in sidepanel, action popups, etc.

[Issue 433](https://github.com/w3c/webextensions/issues/433): Alarms API time slipping

* [oliver] We discussed at TPAC; I checked the behavior as a follow-up and posted the observed behavior at https://github.com/w3c/webextensions/issues/433#issuecomment-1803974896. I suggest using the wallclock time.
* [rob] We're running out of time, let's revisit this topic next time.

The next meeting will be on [Thursday, November 23rd, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=655e9600,3c0)
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,25 +10,26 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2023-11-09 at 8 AM PST = https://everytimezone.com/?t=654c2100,3c0
- 2023-11-23 at 8 AM PST = https://everytimezone.com/?t=655e9600,3c0
- 2023-12-07 at 8 AM PST = https://everytimezone.com/?t=65710b00,3c0

## Past meetings

* 2023-11-09 ([minutes](2023-11-09-wecg.md))
* 2023-10-26 ([minutes](2023-10-26-wecg.md))
* 2023-10-12 ([minutes](2023-10-12-wecg.md))
* 2023-09-28 ([minutes](2023-09-28-wecg.md))
* 2023-09-14 ([minutes](2023-09-14-wecg.md))
* 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md))
* 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md))
* 2023-09-11 until 2023-09-14, extra meetings at TPAC ([minutes](2023-09-11-2023-09-14-tpac-extra.md))
* 2023-08-31 ([minutes](2023-08-31-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2023**

* 2023-11-09 ([minutes](2023-11-09-wecg.md))
* 2023-10-26 ([minutes](2023-10-26-wecg.md))
* 2023-10-12 ([minutes](2023-10-12-wecg.md))
* 2023-09-28 ([minutes](2023-09-28-wecg.md))
Expand Down