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-09-01 meeting #268

Merged
merged 1 commit into from
Sep 13, 2022
Merged

Publish minutes of 2022-09-01 meeting #268

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

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=630ff600,384
Call-in details: [WebExtensions CG, 1st September 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220901T080000)
Zoom issues? Ping `@robwu` (Rob Wu) 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**
* [todd] Optional permissions affordances for enterprise security/compliance use cases
* [Issue 260](https://github.com/w3c/webextensions/issues/260): "Runtime allowed hosts" on Enterprise to pre-grant optional host permissions without user action
* [Issue 261](https://github.com/w3c/webextensions/issues/261): API to retrieve user email or well-known identifier on Enterprise deployments
* [Issue 262](https://github.com/w3c/webextensions/issues/262): Inconsistency: oldValue in storage.StorageChange inconsistency
* [Issue 263](https://github.com/w3c/webextensions/issues/263): undefined value in StorageArea.set()
* [Issue 264](https://github.com/w3c/webextensions/issues/264): Supply credentials for proxy authorization in MV3
* [Issue 267](https://github.com/w3c/webextensions/issues/267): Proposal: declarative way for opening an extension page in a new tab when click the extension icon
* **Open discussion queue (add yourself at the bottom)**
* None
* **Check-in on ongoing issues**
* [Issue 244](https://github.com/w3c/webextensions/issues/244): Better GitHub status labels
* [Issue 232](https://github.com/w3c/webextensions/issues/232): WECG at TPAC 2022
* [Issue 242](https://github.com/w3c/webextensions/issues/242): Inconsistency: extension popup's prefered color scheme
* [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Todd Schiller (PixieBrix)
3. Timothy Hatcher (Apple)
4. David Johnson (Apple)
5. Juha-Matti Santala (Mozilla)
6. Richard Worth (Capital One)
7. Kyle Spearrin (Bitwarden)
8. Matt Gibson (Bitwarden)
9. Steven McLintock (1Password)
10. Rainer Enders (Keeper Security)
11. Oliver Dunk (1Password)
12. Carlos Jeurissen (Jeurissen Apps)
13. Simeon Vincent (Google)
14. Bradley Cushing (Dashlane)
15. Bastien Granger (Dashlane)
16. Lucas Selker (Dashlane)
17. Benjamin Bruneau (1Pasword)
18. Felipe Erias (Igalia)
19. Tyler Carson (Keeper)
20. Jack Steam (CRXJS)
21. Mukul Purohit (Microsoft)
22. Tim Heflin (Keeper)


## Meeting notes

[Issue 260](https://github.com/w3c/webextensions/issues/260): “Runtime allowed hosts" on Enterprise to pre-grant optional host permissions without user action

* [todd] Extension used by both individuals and enterprises. Aim to keep permissions limited. Enterprise needs a minimal setup process to minimize risk of incorrect setup. Chromium has runtime_allowed_hosts in policy. What is the intention of browser vendors here?
* [timothy] Safari does currently not have force-installed extensions at all, and probably not something we'd do in the meantime.
* [simeon] (Chrome) Personally, I think the interaction between runtime_allowed_hosts and runtime host permissions is confusing. There is room for improvement, and we should probably talk with other teams to figure out how to do better. Chances of taking action would improve if clear use cases are demonstrated that are currently difficult to address.
* [mukul] (Microsoft) Agreed to what Simeon said.
* [rob] (Firefox) Would not be opposed to improving this.
* [todd] What are the next steps?
* [simeon] Next step is clearly outlining the current situation, and the challenges - what are the problems we're trying to solve.
* [timothy] Is this in scope for this CG? Deployments are explicitly out of scope in our charter.
* [rob] It's not in scope, but we're all here and can answer this.
* [simeon] Deployment is indeed out of scope. Like storage.managed this is part of the platform, even though it's management is elsewhere.
* [todd] Also has direct implications for the permissions that extensions request in the marketplace. Part of that is a reasonable deployment strategy.

[Issue 261](https://github.com/w3c/webextensions/issues/261): API to retrieve user email or well-known identifier on Enterprise deployments

* [todd] Chrome has a chrome.identity API that offers access to the e-mail (up to Jan 2021 in Chromium). Need a way to retrieve the well-known identifier on enterprise deployments.
* [simeon] Potentially challenging that it presumes that the user is logged in to the browser. Using managed storage API it's possible to expose the LDAP-authenticated user in enterprise policies. Browser does not have visibility on the authentication system that the user used to sign in to the OS.
* [rob] Is managed storage user-specific? I thought that it was global.
* [simeon] On Windows, I believe that this can be configured per user via the Windows registry which has multiple levels such as machine and user.
* [todd] Managed storage is a potential workaround, but it's also very onerous for developers.
* [rob] Let's move on to the next topic; this is not something that we can currently address in a cross-browser way.

[Issue 262](https://github.com/w3c/webextensions/issues/262): Inconsistency: oldValue in storage.StorageChange inconsistency

* [timothy] Safari is similar to Chrome here.
* [simeon] Feels like the kind of thing where it will potentially lead to unexpected results and therefore may result in subtle bugs, but I'm not aware of any material impact from this issue.
* [timothy] The absence of a key could prevent extensions from doing feature detection.
* [rob] In this case it does not really matter.
* Resolution: close issue

[Issue 263](https://github.com/w3c/webextensions/issues/263): undefined value in StorageArea.set()

* [timothy] Safari matches Chrome's behavior.
* [rob] Firefox accepts undefined as a value, and overwrites the key with undefined. Changing that could break extensions that expect `storage.local.set({key: func()})` to overwrite `key` with the result. Will reconsider by re-opening the existing bug report in Firefox.
* [timothy] In Safari null can be used to overwrite.

[Issue 264](https://github.com/w3c/webextensions/issues/264): Supply credentials for proxy authorization in MV3

* [simeon] Believe that the intent is to support webRequest.onAuthRequired in Chrome.
* [rob] To confirm, is Chrome going to suspend requests until an extension has responded to webRequest.onAuthRequired events?
* [simeon] That's my understanding.
* [timothy] We don't support this event currently. Generally support declarative behavior, but in this case a callback could indeed make more sense.

[Issue 267](https://github.com/w3c/webextensions/issues/267): Proposal: declarative way for opening an extension page in a new tab when click the extension icon

* [timothy] Not opposed to this, but if extensions can already do it anyway, with a one-liner, do we need another API?
* [simeon] In general in favor of making developers lifes easier. No strong objections, but in terms of relative priority this feels like something as an Available issue.
* [rob] Given how easy it is already, I am inclined to not add a specific manifest entry to support that functionality. API enhancements are more well suited for functionality that is difficult to achieve with existing APIs.
* Resolution: close issue

[Issue 244](https://github.com/w3c/webextensions/issues/244): Better GitHub status labels

* [timothy] When possible we should use these labels to mark our positions.
* [simeon] Should Accepted be changed to Supportive?
* [timothy] Accepted sounds a bit strong indeed.
* [simeon] We could document the meanings of the labels in the README.
* [rob] Or we can just rename Accepted to Supportive...
* [timothy] I added the “proposal” label and also took a stab at labeling existing issues.

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

* [timothy] I wanted to create an agenda. With the new labels it should be easier to find relevant topics to discuss. The TPAC meeting is split in two parts: first to discuss topics, the second part to make progress with the charter objectives (spec, etc.).
* [mukul] How many people are going to attend?
* From this group: Simeon (Google), Rob and Tomislav (Mozilla), Timothy (Apple; remotely). Mukul (Microsoft; remotely)
* [simeon] Last time we spoke we discussed Service Workers, but I don't have specific topics yet. May be useful to get clarity on how we should collaborate to agree on a common API.
* [timothy] Seems to be an opinion that a lot of APIs are missing from service workers and whether we want to bring them over to extensions or web service workers more broadly.
* [simeon] Of the topics discussed during the last session, user script managers & dynamic content scripts sounds like one of the main topics that we can cover during TPAC.
* [rob] We should probably also get in touch with the Browser Testing and Tools WG. We already have an issue, but I'm not sure if they are aware of our intent to discuss this topic.
* [simeon] I will reach out to them.

[Issue 242](https://github.com/w3c/webextensions/issues/242): Inconsistency: extension popup's prefered color scheme

* [timothy] Safari will look for the color-scheme meta tag and try to match.
* [simeon] I believe we have an opaque white background by default for popups.
* [timothy] Does it change to dark in dark mode, or is it unconditionally white?
* [simeon] Dark when dark mode is forced.
* [oliver] We support a preference to allow the user to configure the color scheme.
* [rob] A way to avoid the white flash is to use a different HTML page.
* [rob] The meta tag approach seems like an elegant approach to the issue.
* [timothy] color-scheme can be used in a meta tag. As long as it is very early in the HTML there is usually not a flash.
* [simeon] Can media queries be used here?
* [rob] A media query can respond to browser settings, but in this case the browser wants to read the intent from the extension.
* [simeon] Ah, I misinterpreted the issue, sorry.
* [rob] Next steps is to get this topic to the engineering teams of the browser vendors to discuss the desired approach.

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

* [felipe] Updated API proposal in response to feedback. Current status: https://github.com/w3c/webextensions/issues/162#issuecomment-1234129962. Going to implement the three approaches, and experiment & benchmark.
* [timothy] The browser implementations are out of scope for the group (e.g. flatbuffers specific to other browsers). The extension API is relevant to other browsers though.
* [timothy] Since we (Safari) combine the rulesets together, updating individual rules can trigger expensive computation in the background.
* [rob] Safari uses a state machine, so the third approach from the issue could conceptually work (storing disabled rules separately) - before exiting the state machine, check whether the rule is disabled, and if so, continue as usual.

The next meeting will be on [Thursday, September 15th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=63226b00,384).
8 changes: 4 additions & 4 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,16 +3,16 @@
The [WebExtensions Community group](https://www.w3.org/community/webextensions/) meets virtually every other week, for one hour.
The instructions to join the meeting and agenda are available at https://www.w3.org/groups/cg/webextensions/calendar.

* Thursday 8 AM PST (3 PM UTC)
* Thursday 8 AM PDT (3 PM UTC)
* To convert to your local time zone, see https://everytimezone.com/

After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2022-09-01 at 8 AM PST = https://everytimezone.com/?t=630ff600,3c0
- 2022-09-15 at 8 AM PST = https://everytimezone.com/?t=63226b00,3c0
- 2022-09-15 at 13:30 AM PDT = TPAC 2022 ([issue 232](https://github.com/w3c/webextensions/issues/232) - [agenda item with time zone conversion](https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-67ede8b0a1a1)
- 2022-09-15 at 8 AM PDT = https://everytimezone.com/?t=63226b00,384
- 2022-09-15 at 13:30 AM PDT = TPAC 2022 ([issue 232](https://github.com/w3c/webextensions/issues/232) - [agenda item with time zone conversion](https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-67ede8b0a1a1))
- 2022-09-29 at 8 AM PDT = https://everytimezone.com/?t=6334e000,384

## Past meetings

Expand Down