-
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.
Merge pull request #166 from w3c/meeting-2022-02-17
Publish minutes of 2022-02-17 meeting
- Loading branch information
Showing
2 changed files
with
137 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,135 @@ | ||
| # WECG Meetings 2022, Public Notes, Feb 17 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=620d9000,3c0 | ||
| Call-in details: [WebExtensions CG, 17th February 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220217T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #159](https://github.com/w3c/webextensions/issues/159), [other 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** | ||
| * [Issue 160](https://github.com/w3c/webextensions/issues/160): Ask Mozilla for their position on action.openPopup API | ||
| * [Issue 163](https://github.com/w3c/webextensions/issues/163): Inconsistent support for wildcards in content security policy overrides | ||
| * [Issue 99](https://github.com/w3c/webextensions/issues/99): Inconsistency: custom content_security_policy browser restrictions | ||
| * [Issue 98](https://github.com/w3c/webextensions/issues/98): Inconsistency: Default content_security_policy | ||
| * [Issue 96](https://github.com/w3c/webextensions/issues/96): Inconsistency: content_security_policy syntax | ||
| * [Issue 95](https://github.com/w3c/webextensions/issues/95): Proposal: content_security_policy.content_scripts | ||
| * [Issue 97](https://github.com/w3c/webextensions/issues/97): Proposal: replacement for deprecated report-uri for content_security_policy | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * [Sumant Modakl] Manifest V3 vs native messaging - Update on progress or timeframe for resolution? (https://github.com/w3c/webextensions/issues/120) | ||
| * [Issue 154](https://github.com/w3c/webextensions/issues/154): browser.secureStorage - general update and moving to a GitHub repo | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Tomislav Jovanovic (Mozilla) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Oliver Dunk (1Password) | ||
| 4. Frederic Rivain (Dashlane) | ||
| 5. Timothy Hatcher (Apple) | ||
| 6. Sumant Modak (Microsoft) | ||
| 7. Krzysztof Modras (Ghostery) | ||
| 8. Bradley Cushing (Dashlane) | ||
| 9. Bastien Granger (Dashlane) | ||
| 10. Simeon Vincent (Google) | ||
| 11. Alexei (Privacy Badger) | ||
| 12. Giorgio Maone (NoScript) | ||
| 13. Sam Macbeth (DuckDuckGo) | ||
| 14. Igor Oleinikov (Grammarly) | ||
| 15. Mukul Purohit (Microsoft) | ||
| 16. Carlos Jeurissen (Jeurissen Apps) | ||
| 17. Jack Works (Sujitech) | ||
| 18. Nir Nahum (WalkMe) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 160](https://github.com/w3c/webextensions/issues/160): Ask Mozilla for their position on action.openPopup API | ||
|
|
||
| * [tomislav] Chrome had a private version of browserAction.openPopup, which Mozilla had implemented with the user interaction requirement. The public action.openPopup method doesn't have this requirement any more, which looks reasonable, and I filed a bug to track this at https://bugzilla.mozilla.org/show_bug.cgi?id=1755763. Some differences between proposal doc and current implementation in Chrome (tabId vs. windowId) | ||
| * [simeon] don't know why Chrome diverged on tab id vs. window Id, will follow up with the eng team | ||
| * [tomislav] stance on user gesture requirement? | ||
| * [timothy] originally was going to require it, but agree that extensions have other, more invasive ways of stealing attention | ||
|
|
||
| [Issue 163](https://github.com/w3c/webextensions/issues/163): Inconsistent support for wildcards in content security policy overrides | ||
|
|
||
| * [timothy] A developer reported an issue in Safari, where wildcards aren't supported in the CSP. This doesn't match Chrome's / Firefox's behavior. Currently planning on fixing this in Safari to be compatible with other browsers. Only script-src will disallow \*. | ||
| * [rob] In general, the idea behind disallowed wildcards in the CSP is to block remote code via the CSP. Remote images are allowed and will continue to be allowed. | ||
|
|
||
| [Issue 99](https://github.com/w3c/webextensions/issues/99): Inconsistency: custom content_security_policy browser restrictions | ||
|
|
||
| * [timothy] Reported inconsistencies in CSP implementations. e.g. Safari stripping sandbox from CSP (fixed in Safari preview), strict-dynamic not being supported in Firefox/Safari | ||
| * [carlos] Proposal 1: Instead of a hard error on load, just warn. Proposal 2: Suggesting to default to default-src ‘none' (very restrictive) by default, so extensions can opt in. | ||
| * [simeon] Worried about treating instead of warning, in favor of failing loudly over warning. The intent for extension CSP is to relax default policy, but accepting multiple is opposed to how multiple CSP headers work on the web. | ||
| * [rob] Proposal 2 can already be done by extensions without requiring this by the browser, by prepending default-src ‘none' to the CSP. | ||
| * [rob] Re proposal 1. We apply a default CSP where e.g. insecure remote scripts are ignored, and apply the extension CSP on top of it. We validate the CSP in the manifest and show warnings to help extensions with debugging. | ||
| * [timothy] We also don't fail on bad CSP and load with the default one. | ||
| * [simeon] Given that other browsers have a more compatible approach, I'll need to sync with the eng team to discuss why we take such a hard position against CSP values. | ||
| * [carlos] I have an issue open with Chrome to not error on unknown keys | ||
| * [simeon] As far as I know our stance is that unknown keys should not error, but again I will sync with the team to clarify this | ||
|
|
||
| [Issue 98](https://github.com/w3c/webextensions/issues/98): Inconsistency: Default content_security_policy | ||
|
|
||
| * [timothy] Report states that Chrome has a longer default CSP than Firefox. | ||
| * [rob] Default CSP used by Chrome and Firefox is basically the same. [Chrome's source code](https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/csp_info.cc;l=33;drc=ce6c3b02c5cc847a3febdef23416e1ae7feaa9f9) confirms this. The referenced CSP in the issue is about legacy “Chrome apps” which aren't supported. | ||
| * [simeon] Our MV3 docs are missing CSP documentation. It's on my backlog. | ||
| * [rob] Rather than creating a new one on the Chrome website, how about linking to MDN? | ||
| * [simeon] That's a more complicated issue worthy of it's own topic. For now let's continue to focus on CSP. | ||
| * [simeon] Sounds like we need to gather more information. Suggest that we gather more information in issue 98 and follow up next session. | ||
| * [carlos] Chrome used to require a CSP exception for WebAssembly, but a recent update to Chrome made it optional with a Chrome flag. | ||
| * [bradley] With the recent Chrome update, the wasm-eval directive can now be specified to allow WASM execution in extensions for MV3. After the update however, there is no longer the need to specify any CSP for WASM to work properly whether the extension is run as MV2 or MV3. WASM being used is locally packaged in the extension. | ||
|
|
||
| [Issue 96](https://github.com/w3c/webextensions/issues/96): Inconsistency: content_security_policy syntax | ||
|
|
||
| * [rob] Object syntax is the only syntax going forward in MV3 extensions. Object syntax is currently only supported in MV3; the string version is MV2-only, and we may support the object syntax in MV2 in Firefox to help with transitioning. | ||
| * [timothy] Since there's a manifest version change, I think it makes the most sense to expect developers to update to the new syntax. Polymorphism is not great. | ||
|
|
||
| [Issue 95](https://github.com/w3c/webextensions/issues/95): Proposal: content_security_policy.content_scripts | ||
|
|
||
| * [simeon] We intend to provide a mechanism to allow extensions to run code in the main world via the scripting API, mainly for userScripts. | ||
| * [alexei] In MV2 it's possible to run code in the main world from the content script before anything happens. This doesn't work in MV3 because of the CSP. | ||
| * [rob] Adding a method to the scripting API requires the extension to call the method from the background script, it's not available in content scripts. https://bugs.chromium.org/p/chromium/issues/detail?id=1207006 | ||
| * [jack] if arbitrary code is not allowed in MV3, how can Tampermonkey run user scripts? | ||
| * [simeon] The scripting API will be expanded to support user scripts. (post meeting edit: we plan to gate access to this capability similar to Chrome's current "allow access to file URLs" control) | ||
| * [tomislav] Two features are being mixed up in this discussion: 1) running scripts in the main world synchronously and 2) running arbitrary scripts (not shipped with extension) in the main world from a content script. | ||
| * [simeon] The world property of the scripting API allows the selection of the world. We believe that this allows extensions to schedule scripts in the desired order. | ||
| * [simeon] Let's try a different framing. In order to inject a content script into the main world, an extension developers would declare a content script object in manifest.json, but add a new "world" property. This prop takes a value of either MAIN or ISOLATED. The scripting API's dynamic content script support will also be expanded to support this property. | ||
| * [simeon] This is an example of a communication issue that we (Chrome) have. We have solutions/ideas in mind that we'd like to pursue, but not a good way to communicate that. | ||
| * [giorgio] Do these issues affect the MV2 deprecation timeline? | ||
| * [simeon] We are very conscious of the time remaining and the capabilities that have yet to land. We don't have updates on that front. | ||
|
|
||
| [Issue 97](https://github.com/w3c/webextensions/issues/97): Proposal: replacement for deprecated report-uri for content_security_policy | ||
|
|
||
| * [timothy] This change causes issues because it requires a separate header. Might need to introduce a new mechanism to declare the report endpoints for extensions. Would essentially get turned into a header that the browser attaches to extension resources | ||
| * [tomislav] Do we need to support more than one reporting endpoint? | ||
| * [rob] Do we even need this functionality? This functionality can be abused for data exfiltration, and the securitypolicyviolation events can be used to detect CSP violations and aggregate them, without specific support in the extension API. Automatic CSP violation reporting can result in data leakage via content scripts (if supported there). I suggest that we table this feature for now. | ||
| * [simeon] Agreed that there may be issues, agree with tabling the topic. | ||
| * [timothy] Agreed with concerns of content scripts. Limiting to extension pages may be an option. | ||
|
|
||
| [Sumant Modakl] Manifest V3 vs native messaging - Update on progress or timeframe for resolution? (https://github.com/w3c/webextensions/issues/120) | ||
|
|
||
| * [simeon] Mentioned in the last meeting: recently landed a change in Canary to allow extensions with native messaging connections to extend the duration of the Service Worker to the lifetime of the native messaging port. | ||
| * [artemis] Is there a limit on this? Can a native app keep the SW alive indefinitely? | ||
| * [simeon] External pressures can still terminate the SW, but it will not unnecessarily be terminated after 5 minutes. Chrome's goal is to be able to run in environments where the OS can terminate child processes. That means that extensions can die at any time. | ||
| * [tomislav] Simeon means that Chrome will not purposefully kill the extension, but that external factors such as the OS can do that. In Firefox we also want to account for this scenario in our Firefox for Android build. | ||
| * [simeon] We're examining scenarios such as video/audio processing (side note: such streams are currently not supported in Service workers today), where termination of SW have a significant adverse effect on user experience. | ||
| * [simeon] How does Safari feel about actively extending lifetime with active ports. | ||
| * [timothy] As long as there is activity on the port in the last 30 seconds, the lifetime is extended. | ||
|
|
||
| [Issue 154](https://github.com/w3c/webextensions/issues/154): browser.secureStorage - general update and moving to a GitHub repo | ||
|
|
||
| * [rob] Ran out of time, let's revisit this topic next week. | ||
| * [tomislav] No updates on our end FYI. | ||
| * [timothy] No updates on our end either. | ||
| * [oliver] Quick note: Thinking of moving the file to the Github repo. | ||
|
|
||
| The next meeting will be on [Thursday, March 3rd, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=62200500,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