Agenda discussion for public meeting on 2024-02-29

[Rob--W]

This issue is used to collect topic suggestions for our February 29, 2024 meeting. We will stop accepting suggestions ~48 hours before the meeting and the final agenda will be added to the meeting notes doc ~24 hours before the meeting.

The content below this line will be copy-pasted to the agenda section of the meeting.

Agenda

The meeting will start at 3 minutes after the hour. See issue 531 for an explanation of this agenda format.

• Announcements (2 minutes)
• Triage (15 minutes)
  • (nominated issues here)
  • Timely issues (10 minutes)
  • (nominated issues here)
• Check-in on existing issues (20 minutes)
  • (nominated issues here)

[twschiller]

I nominate https://github.com/w3c/webextensions/issues/547 for triage/discussion. It's an important one to drive stability of enterprise deployments of extensions

[ghostwords]

It would be good to discuss #302, an undocumented, unaddressed critical functionality regression in Manifest V3.

I'm not sure we are on the same page or even talking about the same issue given the most recent response from Google.

We previously wrote about this problem in a blog post last year: https://www.eff.org/deeplinks/2023/09/new-privacy-badger-prevents-google-mangling-more-your-links-and-invading-your

Google’s Manifest V3 (MV3) removes the ability to redirect requests using the flexible webRequest API that Privacy Badger uses now. MV3 replaces blocking webRequest with the limited by design Declarative Net Request (DNR) API. Unfortunately, this means that MV3 extensions are not able to properly fix redirects at the network layer at this time. We would like to see this important functionality gap resolved before MV3 becomes mandatory for all extensions.

[hackademix]

I nominate #539 for triage and discussion.

At this stage it is even more urgent then the other RegisteredContentScript enhancement proposals I've filed (i.e. #536 & #538, which could be to a certain extent and in a brittle way hacked around for limited use cases, on Firefox at least): in fact it's required for the transition from MV2-based script injection techniques relying on blocking webRequest hacks whenever you need to turn off/on on a certain tab a feature depending on timely document_start injection, e.g. NoScript's Remove all restrictions for current tab and similar Disable on this tab commands offered by other extensions.

[EmiliaPaz]

I nominate #540 for approval. Discussion has been opened for 3 weeks and there hasn't been any objections to the proposal itself. Would like to get approval from other browsers to start implementation as soon as possible, to aid with MV3 migration.

I nominate #529 for discussion. Proposal has been updated so it can fit every browsers model. Specifically, adds a url option parameter, with this requirements:

• In Chrome, we can require tab ID or document ID, but not url.
• In Safari, they can require url, but not tabId or documentId.
• If both are provided, they'll both be respected.

Additionally, we specified the return value for the methods (although we are open to discuss it more) We (chrome) hope that with can move forward with this API