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 2022-06-23 meeting #234

Merged
merged 1 commit into from
Jul 7, 2022
Merged

Publish minutes of 2022-06-23 meeting #234

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
156 changes: 156 additions & 0 deletions _minutes/2022-06-23-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# WECG Meetings 2022, Public Notes, Jun 23

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=62b3ad00,3c0
Call-in details: [WebExtensions CG, 23th June 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220623T080000)
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 217](https://github.com/w3c/webextensions/issues/217): Make WebExtension Javascript APIs available in WebWorkers spawned from a bundled document
* [PR 186](https://github.com/w3c/webextensions/pull/186): Add mock for browser.secureStorage proposal
* [PR 226](https://github.com/w3c/webextensions/pull/226): Update browser.secureStorage proposal with authentication levels
* [Issue 227](https://github.com/w3c/webextensions/issues/227): Making host permissions optional by default appears to be harmful for extensions with global host permissions
* **Other new issues**
* [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icon Design for Light/Dark/Custom Theme on Browser Toolbar
* [Issue 230](https://github.com/w3c/webextensions/issues/230): Inconsistency: browser.runtime.OnInstalledReason
* [Issue 231](https://github.com/w3c/webextensions/issues/231): Extension API to find the public suffix (eTLD) of a given URL/domain
* [Issue 232](https://github.com/w3c/webextensions/issues/232): WECG at TPAC 2022
* [Issue 233](https://github.com/w3c/webextensions/issues/233): [housekeeping] Reorganise github labels
* **Open discussion queue (add yourself at the bottom)**
* None
* **Check-in on ongoing issues**
* [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Craig @ Keeper
3. David Johnson (Apple)
4. Timothy Hatcher (Apple)
5. Steven McLintock (1Password)
6. Alexei (Privacy Badger)
7. Danny Colin (Multi-Account Containers)
8. Rainer Enders (Keeper Security)
9. Richard Worth (Capital One)
10. Oliver Dunk (1Password)
11. Benjamin Bruneau (1Password)
12. Simeon Vincent (Google)
13. Gaurang Tandon (Blaze Today)
14. Brian Weinstein (Apple)
15. Kiara Rose (Apple)
16. Carlos Jeurissen (Jeurissen Apps)
17. Felipe Erias (Igalia)
18. Tyler Carson (Keeper)
19. Jack Works (Sujitech)
20. Giorgio Maone (NoScript)
21. Mukul Purohit (Microsoft)
22. Tim Heflin (Keeper)


## Meeting notes

[Issue 217](https://github.com/w3c/webextensions/issues/217): Make WebExtension Javascript APIs available in WebWorkers spawned from a bundled document

* [bradley] We're in an ephemeral process and want to leverage workers more. E.g. we'd like access to messaging API (runtime.sendMessage) and in-memory storage (storage.memory).
* [timothy] Are these workers spawned from the background service worker?
* [bradley] No, from the foreground, an extension tab. We see this scenario becoming more common due to the constraints imposed by the switch to ephemeral service workers.
* [rob] Extension APIs are currently not exposed to workers. Work has started to expose extension APIs to background service workers, but that does not automatically imply that it's easy or desirable to expose extension APIs to dedicated workers.
* [simeon] When discussed with the Chrome team, they were open to the idea, but no concrete implementation plans. Concerns over waking other worker contexts in response to an event. E.g. a scoped service worker extension wouldn't be able to register in a tab.
* [bradley] In our case we'd expect the worker to be awake in the process.
* [simeon] Let me clarify: a worker would behave like extension page's behave today: when the extension tab is closed, the context is closed.
* [bradley] How would the APIs be exposed? Inherit from worker?
* [timothy] Any worker spawned by an extension would also have access to the APIs.
* [jack] Concern about security: if we are going to expose browser APIs to web workers, it should be an explicit opt in. e.g. A new option in the Worker constructor.
* [oliver] Should be a flag in the manifest.
* [simeon] In summary, it sounds like we're all tentatively in support, but no browsers have immediate plans to implement. As such, we'll continue discussing and attempting to align as we move forward.

[PR 186](https://github.com/w3c/webextensions/pull/186): Add mock for browser.secureStorage proposal

* [simeon] I'll review and merge.

[PR 226](https://github.com/w3c/webextensions/pull/226): Update browser.secureStorage proposal with authentication levels

* [oliver] Simeon posted feedback about being willing to merge, but I'd like to also see some feedback / review if possible.
* [simeon] I have looked at the PR last night, I'll follow up with a more meaningful response in the PR.
* [timothy] Was about to comment. I preferred the previous API format that was more generic. Currently the fields are very specific, e.g. would the “macos” keyword apply to iOS too?

[Issue 227](https://github.com/w3c/webextensions/issues/227): Making host permissions optional by default appears to be harmful for extensions with global host permissions

* [alexei] We touched on this in the last two meetings already. I opened [an issue](https://github.com/w3c/webextensions/issues/227), so we can discuss this offline. It would be good to learn more about the browser vendors' motivations for this. The current design may work on mobile where permissions/access can be controlled (you can use a weather app without giving it precise geolocation access), but I don't think that this applies to extensions. Password manager and privacy/security/ad blocking extensions require global host access for core functionality. The host permissions are not an optional component for such extensions. Users want to install an extension and expect it to work.
* [craig] When did this change? Is this going to ship?
* [timothy] In Safari this has already shipped.
* [simeon] In Firefox this will ship by default in MV3. In Chrome we wanted to ship in MV3, but haven't shipped yet because we weren't satisfied with the user experience. I would tentatively expect this to be released in the coming months.
* [craig] So we would have to prompt the user to grant additional permissions?
* [simeon] Potentially. But there is work being done. We are looking at declarative APIs, e.g. APIs to support password managers.
* [craig] One click or on every host?
* [simeon] Idea behind the badged action is for the user/browser to have the ability to ease the experience. E.g. if the user has granted twice in a week, prompt the user to grant permissions more persistently.
* [rainer] Are you performing user studies?
* [simeon] Yes. It may actually be useful to write an open letter or something in order for browser vendors to consider this kind of feedback in more detail than some anecdotal experiences mentioned in passing.
* [giorgio] I have not heard a clear story for a way to perform whitelisting where it doesn't act. Where the user wants to temporarily disable the extension.
* [rob] The user can choose to allow the extension to access all sites.
* [simeon] An extension can always declare host permissions with access to all URLs. The extension will however not be granted all access by default. It can request specific access, or the user can grant access.
* [giorgio] So NoScript would have to nag the user on every page?
* [rob] For NoScript it would make more sense to introduce an onboarding flow where the user opts in to granting access to all URLs by default.

[Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icon Design for Light/Dark/Custom Theme on Browser Toolbar

* [timothy] The issue has a design doc with an API proposal to support dark themes.
* [simeon] If I recall correctly, there has been a proposal for a runtime API, the proposal only covers a static API.
* [timothy] For the most part, the design looks good to me.
* [rob] Is there any difference between this API and media queries?
* [simeon] This is similar to media query APIs. Both media queries and this draft design defer to the browser to select the appropriate image.
* [timothy] Extensions can implement this today with media queries. This is about getting JS out of the picture and letting the browser automatically pick the right variant.
* [carlos] There are situations where the OS is using light mode, but where the toolbar has a darker color. Just relying on dark/light theme detection or media queries wouldn't cover this, as it could result in a bad contrast.
* [timothy] Agreed. There are a lot of situations where we need to be creative and take what's available in order to display an appropriate icon.
* [carlos] Firefox has a theme_icons property to allow extensions to declare dark/light icons.

[Issue 230](https://github.com/w3c/webextensions/issues/230): Inconsistency: browser.runtime.OnInstalledReason

* [rob] What does Safari do here?
* [timothy] I don't know if we even support this.
* [simeon] Our hesitation with changing chrome_update to browser_update is that Chrome extensions are currently expecting the current strings. Any such change should be in a new manifest version.
* [timothy] I just checked; we don't support this in Safari at the moment. We generally support both the Chrome and browser APIs where possible.
* [rob] In this case it's not possible, because the onInstalled event is fired with this specific value.
* [timothy] I think that we would prefer the browser_update value here.

[Issue 231](https://github.com/w3c/webextensions/issues/231): Extension API to find the public suffix (eTLD) of a given URL/domain

* [timothy] This is a feature request to expose the public suffix list to extensions.
* [rob] Would we want this API, and if so, what should the API look like? E.g. namespace, whether it takes a URL or domain.
* [oliver] Would love to see this.
* [timothy] In favor of this. Can take a domain or URL.
* [simeon] On Chrome's side we are hesitant. A number of PSL maintainers at Chrome have concerns. Extension-specific concern is that this capability can be served in JS code itself, and that it is not necessary to have this exposed by the browser.
* [rob] If the goal is to have a consistent interpretation of the public suffix, then there's no other way for the extension to have the same behavior as the browser.
* [giorgio] I wanted to raise exactly the same point. In the pre-WebExtension extension APIs, NoScript used Firefox's internal APIs, but now it has to update PSL in the extension, and there are still inconsistency issues with potential security impact.
* [timothy] Agreed.
* [alexei] Agreed, Privacy Badger would benefit from this functionality.

[Issue 232](https://github.com/w3c/webextensions/issues/232): WECG at TPAC 2022

* [timothy] Coming up soon in september.
* [simeon] Last night I started to read the TPAC documentation and gather notes. I'll update the issue with an overview of TPAC and a recommendation for our participation on this issue within the next few hours
* [rob] Do you intend to attend TPAC?
* [simeon] Tentatively, yes. Still watching the global health situation.
* [rob] At Mozilla's side we're also considering attending, with multiple members of the extensions engineering team.
* [timothy] Likewise for Safari.
* [mukul] (Microsoft) I am also considering.

[Issue 233](https://github.com/w3c/webextensions/issues/233): [housekeeping] Reorganise github labels

* [carlos] Last meeting we talked about this. I filed an issue to start a discussion on cleaning up labels.
* [timothy] I like some of your suggestions.

[Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules

* [felipe] I have continued to work on the implementation, wrote an extension with benchmarks. I posted an update with the benchmark results in the issue. Talked with extension developers and asked about update frequency. It's ranging from once an hour to once a day. So if we want to introduce rate limits, this order of magnitude can be a starting point.
* [simeon] I saw the “Chrome: follow-up” label yesterday, which is too short notice before this meeting, but I'll follow up with the Chrome team and get back.

The next meeting will be on [Thursday, July 7th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=62c62200,3c0).
3 changes: 2 additions & 1 deletion _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2022-06-23 at 8 AM PST = https://everytimezone.com/?t=62b3ad00,3c0
- 2022-07-07 at 8 AM PST = https://everytimezone.com/?t=62c62200,3c0
- 2022-07-21 at 8 AM PST = https://everytimezone.com/?t=62d89700,3c0

## Past meetings

* 2022-06-23 ([minutes](2022-06-23-wecg.md))
* 2022-06-09 ([minutes](2022-06-09-wecg.md))
* 2022-05-26 ([minutes](2022-05-26-wecg.md))
* 2022-05-12 ([minutes](2022-05-12-wecg.md))
Expand Down