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 2021-09-30 meeting #89

Merged
merged 1 commit into from
Oct 7, 2021
Merged

Publish minutes of 2021-09-30 meeting #89

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

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=6154fe00,384

Call-in details: [WebExtensions CG, 30 September 2021 event](https://www.w3.org/events/meetings/f13adee3-d80c-4348-bc2a-64e006b0db4a/20210930T150000)

Zoom issues? ping @zombie (Tomislav Jovanovic, Mozilla) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)

## Agenda: [github issues](https://github.com/w3c/webextensions/issues)

* New issues carried over from last meeting
* [Issue 74](https://github.com/w3c/webextensions/issues/74): `content_security_policy` property
* [Issue 79](https://github.com/w3c/webextensions/issues/79): Request for History API Improvements
* [Issue 82](https://github.com/w3c/webextensions/issues/82): Malware / Phishing protection not possible in Manifest V3
* [Issue 87](https://github.com/w3c/webextensions/issues/87): Standardize declarativeNetRequest rules
* [Issue 12](https://github.com/w3c/webextensions/issues/12#issuecomment-930545112): request: allow to retrieve a frameID from an `<iframe>` element
* [Tomislav] Have a prototype design and implementation in Firefox
* Please take a look/test it out and provide feedback
* Unless there are objections from other implementations, we can probably ship as an experiment soon
* [Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021

## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Tomislav Jovanovic (Mozilla)
3. Timothy Hatcher (Apple)
4. Krzysztof Modras (Ghostery)
5. Giorgio Maone
6. Carlos Jeurissen (Jeurissen Apps)
7. Alexei (Privacy Badger)
8. Richard Worth (Capital One)
9. Nir Nahum (WalkMe)
10. Bradley Cushing (Dashlane)
11. Mukul Purohit (Microsoft)
12. Thierry Régagnon (Dashlane)
13. Daniel Glazman (Dashlane)
14. Jack Works (Sujitech)
15. Simeon Vincent (Google)

## Queue (add yourself at the bottom)

* Website vs. extension Service Worker lifetimes: https://github.com/w3c/webextensions/issues/72#issuecomment-921070548 (Alexei)
* Do Mozilla and Google agree on main world script injection vs CSP behavior? (Giorgio Maone)

## Meeting notes

[Issue 74](https://github.com/w3c/webextensions/issues/74): `content_security_policy` property

* [carlos] Inconsistencies can be resolved as discussed last time. (...)
* [carlos] Proposal to restrict default CSP (but allow making it less restrictive), so it's more clear what an extension does and what it's permissions are used for. And reducing potential attack surfaces during security vulnerability.
* [timothy] FYI issue 2 of the list (sandbox CSP) fixed in Safari and upcoming release.
* [tomislav] CSP is not designed for extensions, hoping to have improved consistency for CSP in extensions in the future.
* [rob] CSP in extensions is used to restrict features, to establish a baseline that browsers/reviewers can rely on (unlike websites, that can relax CSP and use things like report-sample for debugging purposes).
* [krysztof] manifest v3 default CSP is strict beyond being useful as there is not option to relax it at all. Nonces, hashes, unsafes are not supported. Edge case: on chrome canary extension pages cannot use importmaps as inline scripts are not allow and remove importmaps are not supported.
* [jack] use case: use webpack to develop extension; configured to use eval-source-map for good quality stack traces. Chrome MV3 bans unsafe-eval and prevents this use case from working. Hope to at least allow it in development mode.
* [timothy] Without Google present in this meeting today, we cannot comment about MV3-specific issues now.

[Issue 79](https://github.com/w3c/webextensions/issues/79): Request for History API Improvements

* [tomislav] This is not controversial.
* [timothy] Safari does not support the history API at the moment, but if implemented this would be trivial to support.

[Issue 82](https://github.com/w3c/webextensions/issues/82): Malware / Phishing protection not possible in Manifest V3

* [krysztof] (summarized what’s mentioned in the issue)
* [rob] Can you think of new primitives in the extension API that would support the use case? E.g. supporting bloom filters for the first pass.
* [krysztof] some form of shared memory would work best as different data structures serve different use-cases differently. So having an ArrayBuffer would be best.
* [timothy] Safari has increased the rule limit for content blockers from 50,000 to 150,000. This also applies to the declarativeNetRequest implementation.
* [krysztof] There is a limit per rule set, but are there an unlimited number of rule sets?
* [timothy] Yes, that is correct for Safari.

(simeon joins the meeting, he is now able to represent Google)

[Issue 87](https://github.com/w3c/webextensions/issues/87): Standardize declarativeNetRequest rules

* [timothy] Aware of inconsistencies, like Safari only supporting regexps and not urlFilters, and Chrome only supporting a limited number of regular expressions.

[Issue 12](https://github.com/w3c/webextensions/issues/12#issuecomment-930545112): request: allow to retrieve a frameID from an `<iframe>` element

* [tomislav]
* Have a prototype design and implementation in Firefox
* Please take a look/test it out and provide feedback
* Unless there are objections from other implementations, we can probably ship as an experiment soon
* [glazou] Proposal would be a perfect fit.
* [rob] In response to the request to be able to get the parent (at https://github.com/w3c/webextensions/issues/12#issuecomment-931075170), with the current proposal it would be possible to do that with `getFrameId(parent)` (or `top` or `opener`).
* [tomislav] Prototype proposal also supports frames/embeds even though it may not strictly be necessary (it’s possible to use frame.contentWindow, but possibly not for `<embed>`).
* [timothy] Supportive of this from Safari’s side. Reasonably easy to implement.
* [glazou] Simeon, could you take this back to Google and check whether this is feasible?
* [simeon] Yes, I’ve already pinged engineers.
* [krysztof] Some issues with WebKit, will file bugs.
* [simeon] Is there any security concern with exposing frameId?
* [rob] This frameId number is equivalent to the existing window proxy (reference to cross-origin windows): it’s an opaque handle that isn’t useful on its own, and only useful for use with extension APIs.
* [tomislav] If someone can think of a (security) concern, please comment.
* [carlos] Slightly unrelated, but in a popup tabId=-1, and just the availability of frameId does not help with the ability to run content scripts in frames in popups.
* [rob] frameIds appear to be globally unique in Safari (Tim confirms, but seconds-guesses and needs to double-check), Firefox and Chrome. If that is the case we could consider updating APIs (e.g. scripting API) to support script injection without requiring tabId. Carlos, can you file a bug with your use case?
* [carlos] Yes.

[Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021

* [simeon] Reached out to organize group meetings right before the deadline. Nothing new yet, no new meetings scheduled. Our meetings are held in the regularly scheduled timeslots. Let’s try to plan better next year.

Queue: Website vs. extension Service Worker lifetimes (Alexei):

* [alexei] https://github.com/w3c/webextensions/issues/72#issuecomment-921070548
* [alexei] Taking a step back, what are SW? SW are meant to progressively enhance websites, by providing offline functionality and helping with performance. SW can survive beyond the lifetime of a web page. These are wonderful for web pages. If we apply this concept to extensions, then the “web page” is the browser. In this case, limiting the lifespan of extension SW doesn’t make sense. Objecting strongly to the arbitrary lifetime here. There are real use cases that the SW proposal is meant to address (extension lifetimes in a multiprocess environment on mobile), but SW are not the solution.
* [glazou] +1
* [maone] +1
* [bradley] +1
* [marwan] +1
* [thierry] +1
* [tomislav] Part of what all browser implementers are considering for MV3 is the ability to gracefully shut down extensions from external conditions, especially on mobile (where Apple already requires non-persistent pages in mv2), but also to some degree on desktop. Extensions should be designed to account for being shut down. As for arbitrary time limits, that’s a separate issue, and we agree that an one-size-fits-all rule probably isn’t a good solution, so we’re open to adjusting that based on needs and use cases, but we are not there yet in our implementation.
* [alexei] +1 to separating ability to gracefully shut down (on mobile) from the SW proposal (which is fundamentally user hostile (editorial note: see also [issue 51](https://github.com/w3c/webextensions/issues/51))).
* [glazou] disagree with being designed to shut down. Extensions should get a say before being shut down.
* [tomislav] This is not a choice, e.g. on Android.
* [glazou] you’re speaking of exceptional events like a crash. I hope we’re not going to impact 99.99% of extension vendors based on Android crashes only?
* [simeon] Tomislav said what I wanted to better than I could. From the Chrome perspective, extensions need to be able to handle less-than-ideal conditions and unexpected interrupts. Chrome is very hesitant to relax the 5 minute maximum for web service workers. I personally don't understand this [after meeting edit: but I'm not familiar enough with the thinking behind this decision to really comment].
* [timothy] Safari is currently not imposing arbitrary lifetimes, even for mobile devices where event pages are required. Don’t think that we would be imposing maximum lifetimes even if we were to implement SW.
* [simeon] Quick clarification, I want to emphasize that the hesitation to relax the 5 minute limit is specifically a web concern. Given that the extension SW implementation is different, there's more room for customization, but the extensions team is still very hesitant to relax this limit.

Queue: Do Mozilla and Google agree on main world script injection vs CSP behavior? (Maone)

* [rob] Ran out of time. Please file an issue so we can discuss it at the next meeting.

The next meeting will be on [Thursday, October 14th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=61677300,384).
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 @@ -11,11 +11,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

* 2021-09-30 at 8 AM PDT = https://everytimezone.com/?t=6154fe00,384
* 2021-10-14 at 8 AM PDT = https://everytimezone.com/?t=61677300,384
* 2021-10-28 at 8 AM PDT = https://everytimezone.com/?t=6179e800,384

## Past meetings

* 2021-09-30 ([minutes](2021-09-30-wecg.md))
* 2021-09-16 ([minutes](2021-09-16-wecg.md))
* 2021-09-02 ([minutes](2021-09-02-wecg.md))
* 2021-08-19 ([minutes](2021-08-19-wecg.md))
Expand Down