-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2022-07-21 meeting
- Loading branch information
Showing
2 changed files
with
143 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,141 @@ | ||
| # WECG Meetings 2022, Public Notes, Jul 21 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=62d89700,3c0 | ||
| Call-in details: [WebExtensions CG, 21st July 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220721T080000) | ||
| 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 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 238](https://github.com/w3c/webextensions/issues/238): WebExtensions should use asset links model for WebAuthn RP ID | ||
| * [Issue 240](https://github.com/w3c/webextensions/issues/240): Support high DPI image assets on the extension store | ||
| * [Issue 241](https://github.com/w3c/webextensions/issues/241): Event listeners in Content Scripts and communication between main and isolated CS worlds | ||
| * [Issue 242](https://github.com/w3c/webextensions/issues/242): Inconsistency: extension popup's prefered color scheme | ||
| * [Issue 244](https://github.com/w3c/webextensions/issues/244): Status labels for WECG GitHub issues | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 12](https://github.com/w3c/webextensions/issues/12): allow to retrieve a frameID from an <iframe> element | ||
| * [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules | ||
| * [Issue 170](https://github.com/w3c/webextensions/issues/170): Proposal: Offscreen Documents for Manifest V3 | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (Google) | ||
| 2. David Johnson (Apple) | ||
| 3. Tim Heflin (Keeper) | ||
| 4. Oliver Dunk (1Password) | ||
| 5. Rob Wu (Mozilla) | ||
| 6. Tomislav Jovanovic (Mozilla) | ||
| 7. Craig Lurey (Keeper) | ||
| 8. Gaurang Tandon (Blaze Today) | ||
| 9. Felipe Erias (Igalia) | ||
| 10. Kiara Rose (Apple) | ||
| 11. Timothy Hatcher (Apple) | ||
| 12. Mukul Purohit (Microsoft) | ||
| 13. Jack Works (Sujitech) | ||
| 14. Tyler Carson (Keeper) | ||
| 15. Todd Schiller (PixieBrix) | ||
| 16. Carlos Jeurissen (Jeurissen Apps) | ||
| 17. Bradley Cushing (Dashlane) | ||
| 18. James Hycner (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [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 | ||
|
|
||
| * [simeon] Continued this discussion from the last meeting. This issue appears to be a canonical place for this topic, but although we have talked about this during meetings, it has not received comments from browser vendors. Raising this point to encourage the browser vendors among us to participate in the topic, and post supplementary material if available. | ||
| * [alexei] Thank you, I have no further comments at this time. | ||
|
|
||
| [Issue 238](https://github.com/w3c/webextensions/issues/238): WebExtensions should use asset links model for WebAuthn RP ID | ||
|
|
||
| * [bradley] I can describe at a high level why this was created. Currently working on integrating support in WebAuthn; currently the only way to do so is by monkey-patching the web APIs through content scripts to hijack the API calls and add itself. Would ideally have a way to register the extension as a RP without having to rewrite these web APIs. | ||
| * [oliver] Issue open in the Chromium tracker for an internal capability to interact with WebAuthN (https://bugs.chromium.org/p/chromium/issues/detail?id=1231802). Our interest is to offer passkeys in the context of WebAuthN APIs. Ideally some extension API where we could say "here are passkeys we can offer". | ||
| * [timothy] Preferred approach for Apple as well, extension can add supplemental passwords or passkeys as part of an authentication flow. | ||
| * [tomislav] No specific comments from me, need to read up about it first. | ||
| * [craig] Passkeys are about to roll out for Apple devices. With upcoming changes to passkeys, Apple first and Google and Microsoft to follow, want to make sure that extensions aren't boxed out. | ||
| * [simeon] In these discussions, I'd like to distinguish between access to data (credentials) and offering the ability for extensions to integrate (e.g. integrated in password fill without necessarily having access to the page/credential data). | ||
| * [craig] Google created an autofill API on Android, but on desktop browsers we don't have equivalent capabilities. Users have to juggle enable/disable extensions to avoid conflicts. WebAuthN is a new space that we can't directly integrate with or have to hack into. Android and iOS do a good job of giving the user the opportunity to choose between providers. | ||
| * [bradley] We're not able to give the user the choice between hardware authenticators or our experience. We need to insert ourselves in between the user and the actual handling. | ||
| * [simeon] Can anyone speak to the actual WebAuthn RP idea? | ||
| * [oliver] If you have a hardware authenticator, it needs to store an ID, such as a website. The request is whether the extension can identify itself as the website. | ||
| * [tim] The ID is automatically the website domain; In Keeper we use postMessage with the web page and communicate with our own native application that sends the request. | ||
| * [tomislav] How is this different from the [identity.launchWebAuthFlow API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity/launchWebAuthFlow)? | ||
| * [rob] Given the silence here, it looks like none of the attendees can speak to this topic in detail, so let's ask questions in the issue and continue with the rest of today's meeting topics. | ||
| * [timothy] Would be helpful to have a spec writeup. Would love to tag in the appropriate folks at Apple. | ||
|
|
||
| [Issue 240](https://github.com/w3c/webextensions/issues/240): Support high DPI image assets on the extension store | ||
|
|
||
| * [simeon] Extension store issues are out-of-scope in this CG, but I'm open to hearing from developer concerns right now. | ||
| * [gaurang] I created [a thread in the chromium-extensions google group](https://groups.google.com/a/chromium.org/g/chromium-extensions/c/obZ9t7b8hPk/m/uRm6_aqTAwAJ), Jackie followed up with discussion of Firefox and Edge's stores. The source images have a high quality but are pixelated after uploading to the CWS. | ||
| * [simeon] I'm familiar with this problem & actively discussing it with the CWS team. | ||
|
|
||
| [Issue 241](https://github.com/w3c/webextensions/issues/241): Event listeners in Content Scripts and communication between main and isolated CS worlds | ||
|
|
||
| * [jack] I don't believe we can do this (breaking change). | ||
| * [rob] The issue filer is asking to stop firing event listeners in content scripts in response to scripted actions from the web page. This is not a good idea in my opinion; extensions should be prepared to deal with events fired by web pages. | ||
| * [rob] [event.isTrusted](https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted) can already be used if the extension really cares that the event was triggered by the user. | ||
| * [someone] event.isTrusted is only available to events such as click, but not to CustomEvent. | ||
| * [todd] externally_connectable is a static way to register whether an extension is receptive to events, and the event has information about the source of the message. | ||
| * [tomislav] custom events also have a known source (the page that is triggering the event). There are no differences in trust. | ||
| * [rob] Regarding communication between content scripts and host pages and trust concerns, there have been prior issues raised in the group. | ||
| * https://github.com/w3c/webextensions/issues/57 | ||
| * https://github.com/w3c/webextensions/issues/76 | ||
| * https://github.com/w3c/webextensions/issues/77 | ||
| * https://github.com/w3c/webextensions/issues/78 | ||
| * [alexei] Extension developers want a secure way to communicate between page scripts and extensions. There may be technical issues that prevent browsers from providing this, but we should acknowledge that the desire for this capability exists. | ||
| * [tomislav] Yes, while we can provide good assurances for the source of actions and messages coming from a content script, once that content script injects a “page script”, it is almost completely separated from the originating extension, and this is a very tough, (if not impossible) technical challenge in most current implementations, as far as I know. | ||
| * [timothy] Safari is shipping externally_connectable soon. Currently in STP and the Safari 16 betas. | ||
|
|
||
| [Issue 242](https://github.com/w3c/webextensions/issues/242): Inconsistency: extension popup's prefered color scheme | ||
|
|
||
| * [simeon] It appears that the OP is describing how the CSS `prefers-color-scheme` is interpreted in the popup. Chrome and Safari default to OS setting, Firefox defaults to browser theme. | ||
| * [tomislav] The intention behind the changes in Firefox is that the popup (dark) theme should follow the one of the browser UI. | ||
| * [timothy] That's also what we do in Safari: it's supposed to match the browser's UI, not the web pages. | ||
| * [simeon] Next steps here is to get browser vendor comments on this issue. | ||
| * [tomislav] FYI on terminology: “chrome” (lower-case “c”) refers to the browser UI, not to be confused with Chrome (upper-case “C”), the web browser from Google. | ||
|
|
||
| [Issue 244](https://github.com/w3c/webextensions/issues/244): Status labels for WECG GitHub issues | ||
|
|
||
| * [simeon] Crated a suggested initial set of "status" labels. Curious for feedback. | ||
| * [timothy] Carlos's label suggestions reflecting the state of consensus from each browser looks like a good addition to me. | ||
| * [tomislav] ES proposals have 4 stages. Something like that could be useful for our purposes. Mozilla has a [standard-positions Github repo](https://github.com/mozilla/standards-positions), with some standardized statuses (e.g. harmful, worth prototyping, etc. to reflect the support sentiment). | ||
| * [simeon] Would you be open to creating a half-pager or something like that? | ||
| * [tomislav] I'll write a comment on the issue. | ||
| * [rob] We now have three issues about labels. We should consolidate them: | ||
| * https://github.com/w3c/webextensions/issues/205 | ||
| * https://github.com/w3c/webextensions/issues/233 | ||
| * https://github.com/w3c/webextensions/issues/244 (the one being discussed now) | ||
| * [simeon] Based on initial feedback, we're not going to proceed with my suggestion here. | ||
| * [tomislav] Goal is to have consensus tracking. | ||
| * [rob] If we want to consolidate discussion, suggest using issue 233 as it's the most generic, non-prescriptive one. | ||
|
|
||
| [Issue 12](https://github.com/w3c/webextensions/issues/12): allow to retrieve a frameID from an <iframe> element | ||
|
|
||
| * [gaurang] This was raised a few weeks ago with a “Chrome: follow-up” label. | ||
| * [simeon] While reviewing issues with the label, it wasn't clear to me what exactly needs to be followed-up upon. Could you comment on the issue to clarify? | ||
| * [gaurang] I'll create a comment. | ||
| * [simeon] FYI Dave came up a while back to talk about the frameId proposal a while back. | ||
| * [rob] You meant documentId, right? | ||
| * [simeon] That's right, but I still need to follow up on that one. | ||
|
|
||
| [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules | ||
|
|
||
| * [felipe] Devlin [provided feedback on the current design document](https://docs.google.com/document/d/1NTOTr6iwm0dJbewWjnABmPo6h1QD1mKTpX60s6Klj-8/edit?disco=AAAAc3D154o); wanted to mention that here in case other parties are interested. Also wanted to encourage members to provide feedback on potential use cases for this capability. Delvin is asking if there are more specific use cases where extensions may leverage this capability, such as providing a user-facing control to disable individual static rules. | ||
| * [simeon] Are there any reps from content blockers present? | ||
| * [alexei] Privacy Badger. | ||
| * [simeon] That uses dynamic rules, right? | ||
| * [alexei] The extension API forces extension devs to build on static rules as a foundation to create the best experience. If there are no static rules and only dynamic rules, then we wouldn't have this issue. I think that this request is about simplifying the API usage for extension developers. While one can disable entire static rulesets, if you require greater flexibility (because your extension lets users control what gets blocked, for example), the current API requires you to create dynamic rules to overwrite the appropriate static rules. This is complicated/easy to get wrong for extension developers. | ||
| * [simeon] I think that this is about giving content blockers with static rules the ability to override individual static rules without being forced to create some convoluted new rules with potentially negative side effects. | ||
|
|
||
| The next meeting will be on [Thursday, August 4th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=62eb0c00,3c0). |
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