From a8819284b14143db5e0041848f33919ae96b891f Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 18 Apr 2024 19:20:22 +0200 Subject: [PATCH] Publish minutes of 2024-03-18 - 2024-03-20 meetings in San Diego --- _minutes/2024-03-18-san-diego-meetup.md | 379 ++++++++++++ _minutes/2024-03-19-san-diego-meetup.md | 397 ++++++++++++ _minutes/2024-03-20-san-diego-meetup.md | 781 ++++++++++++++++++++++++ _minutes/README.md | 6 + 4 files changed, 1563 insertions(+) create mode 100644 _minutes/2024-03-18-san-diego-meetup.md create mode 100644 _minutes/2024-03-19-san-diego-meetup.md create mode 100644 _minutes/2024-03-20-san-diego-meetup.md diff --git a/_minutes/2024-03-18-san-diego-meetup.md b/_minutes/2024-03-18-san-diego-meetup.md new file mode 100644 index 00000000..dfd246d9 --- /dev/null +++ b/_minutes/2024-03-18-san-diego-meetup.md @@ -0,0 +1,379 @@ +# WECG March 2024 Meetup, Public Notes, Mar 18 + +Monday, the first day of the three-day in-person meetup of the WECG in San Diego ([#525](https://github.com/w3c/webextensions/issues/525)). + + +## Agenda + + * 9:00 - 9:30 What should we talk about? + * 9:30 - 10:00 3p Cookie Deprecation + * (break; transition from remote to in-person only) + * 10:40 - 11:00 Inconsistencies + * 11:00 - 12:00 Testing + * 13:00 - 15:00 Issue triage + + +## Attendees + + * Patrick Kettner (Google) + * Richard Worth (Capital One) + * Casey Garland (Capital One) + * Andrey Meshkov (AdGuard) + * Carlos Jeurissen (Jeurissen Apps) + * Tomislav Jovanovic (Mozilla) + * Rob Wu (Mozilla) + * Devlin Cronin (Google) + * Kiara Rose (Apple) + * David Johnson (Apple) + * Timothy Hatcher (Apple) + * Jessie Berlin (Apple) + * Mukul Purohit (Microsoft) + * Anton Bershansky (Independent, remote) + * Rob Wu (Mozilla) + * Oliver Dunk (Google) + + +## Meeting notes + + +### What should we talk about? + + * (introductions) + * [devlin] What should we talk about? + * [carlos] Host permissions + * [timothy] Site access + * [casey] Direction of mobile extensions + * [andrey] DNR and cosmetic rules + * [simeon] Safe imperative network modification + * [patrick] WECG issue management + * [timothy] Shared test suite + * [anton] 3p cookie deprecation + * [andrey] Proxy extension API inconsistencies. Chrome and Firefox are incompatible; Safari does not support it. + * [andrey] Firefox supports DNS API, Chrome does not. + * [patrick] dns API is supported in Chrome's dev channel, but we never shipped. + * [timothy] sidebar/sidePanel API unification. + * [andrey] Browser-specific APIs, prefix? + * [devlin] Considered separate chrome namespace, and then moving method over to e.g. the browser namespace. In practice, observations in CSS, -o-, -webkit-, etc don't work out that well. + * [devlin] Anything else? + * [simeon] We will revisit this at the start of Tuesday and Wednesday. + * [timothy] Icons – SVG + * [timothy] Dark mode + * [andrey] Inconsistencies between browsers + * [tomislav] Specific topics? + * [simeon] Could roll this into “WECG issue management” topic - establishing process to track and follow up on inconsistencies + * [carlos] Breaking changes + + +### 3p Cookie Deprecation + + * [anton] In Chrome, browser tools in iframes don't have access to DOM storage APIs. Extensions break when third-party cookies are disabled. + * [tomislav] To clarify, NOT the browser.cookies extension API but DOM APIs, right? + * [anton] Yes, sessionStorage, localStorage, etc. Would be nice to be able to store data independently of third-party storage access of the document. + * [devlin] We've discussed limiting extension access to 3rd party cookies. Anton mentioned that devtools extensions don't have access to 3rd party cookies because they're loaded in an iframe - that's a bug. + * [timothy] That is also a bug in Safari - we also load the devtools in an iframe. + * [devlin] We should disable third-party restrictions when embedded in an iframe in a devtools panel. + * [devlin] When extension frames are embedded in regular web content, the regular restrictions should apply, for consistency with the web. + * [andrey] May makes sense to extend this to privacy sandbox, specifically protected private audience API + * [tomislav] That has external dependencies and is not in the control of our group here. Firefox and Safari have not implemented it. + * [timothy] Yes. + * [devlin] Rob, how does FF handle an extension iframe have access to 3rd party cookies? + * [rob] Should have access to the host's cookies. + * [carlos] In Safari, an extension frame cannot access the browser.storage API + * [timothy] That would be a bug. + * [devlin] Rob, what about an extension main frame and another origin in an iframe. From a security and privacy point of view, the extension can already store data in its own storage. + * [rob] Depending on the use case of the extension, it may or may not be preferable for the extension to be partitioned. Perhaps the question is what is the default and how do we make it controllable? + * [devlin] Hesitant to make this controllable because of the complexity involved. Cookies are already complicated. + * [timothy] Switching it may break extensions + * [tomislav] Might be safer and easier to implement to partition; extensions that want to access unpartitioned cookies can send a request via the background script. + * [devlin] Sounds like we're aligned on fixing devtools, extension iframes in web main frames should be partitioned. If a dev wants to work around this they can. This more closely aligns with web behavior. + * [oliver] There is a difference between cookie partitioning and storage partitioning. Chrome already has an exception for an extension page embedded in a web main frame where the regular extension partition key is used for storage. For consistency, I think we should have the same exception for cookies. Code is [here](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;drc=353683321da2061bb47d7655d4b3fc04c1540ed3;l=4367). + * (this remark was discussed later, see “<reviewed Oliver's note above>” below) + * [timothy] Does Chrome load options in an iframe? + * [devlin] Not a frame, a webview. + * [timothy] We load all options as a separate tab. + * [rob] Should we agree on an API to send a request on behalf of a specific frame or context? + * [devlin] Would be against having an API that allows extensions to do things on behalf of a frame. There's an existing workaround (injecting in the frame) and a separate API adds lots of complications (e.g. lifetime) + * [rob] Then you'd have CORS issues + * [devlin] You would on behalf of the frame as well. “On behalf of” implies acting as. Another idea is to set an origin header on the request. I prefer the idea of extending the Fetch API to allow extensions to assign the origin header. + * [simeon] How are you thinking about origin overrides on a request? Does it inherit cookies, etc. or does it _only_ set this one header? + * [devlin] Not sure. + * [tomislav] I feel there are other cases where you may need to act as a frame, for example 3rd party nested iframes. Example of use case is a download manager that may want to initiate, pause and resume downloads. + * [devlin] Hesitant to copy the state of the frame. + * [rob] We can design the API that allows retrieval and passing an object describing the relevant context. E.g. in the cookies extension API, the partitionKey object has that kind of semantics, where the extension forwards whatever is in partitionKey back to the extension API methods. + * [devlin] Worth discussing more. Would need to look more closely at the spec to see what is contextual beyond origin and cookies. + * [timothy] Client hints come to mind. E.g. whether it's in dark mode. + * [devlin] Sounds like we are aligned that we should partition, that developers may need to make requests (that emulate) other contexts. + * [oliver] Note: There is further discussion including some concerns below. This may not be the right path. + * [timothy] Origin plays into our implementation. That makes it hard to have an endpoint restricted to a particular origin. + * [devlin] Any kind of stable id? + * [timothy] No. Ecosystem has worked around it. + * [devlin] threat model? + * [timothy] Fingerprinting. Not seeing what extensions you have installed if they inject content. + * [devlin] web accessible resources in theory masks this + * [timothy] Yes, but if it's a known host for a resource the page can detect the extension through the static host. + * [devlin] use_dynamic_urls should solve this. + * [timothy] We make anything that's a safari extension URL if the DOM tries to see it. webkit-masked-hidden + * [devlin] Would you consider having a stable ID for situations where it's not exposed to the web? + * [timothy] Possibly + * [devlin] I've seen cases where extensions say “to do this, copy and paste this extension URL”. + * [timothy] Started very restricted, could potentially relax. + * [rob] Oliver wrote a note in the document that we haven't discussed, regarding the difference between cookie partitioning and storage partitioning.. + * <reviewed Oliver's note above> + * [rob] Firefox uses the same partitioning for storage and cookies. + * [timothy] In Safari it is the same bucket for everything. + * [tomislav] Same in Firefox. + * [devlin] I'm not familiar with this code, but [the code Oliver linked](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;drc=353683321da2061bb47d7655d4b3fc04c1540ed3;l=4367) does seem to separate them. + * [timothy] So, Oliver is saying there's a carve out for extensions in Chrome? + * [rob] Looking at Chrome's code - isn't that carved out for ALL storage APIs, not just cookies? + * [devlin] Yes, which is strange because it implies that this would have taken effect for the DevTools case. We need to investigate and test. If we are not partitioning at all, then it becomes a breaking change to fix that. + * [rob] Would you be willing to make a breaking change? + * [devlin] In principle yes, in practice we would have to consider the impact on extensions. Lately we have made many breaking changes at once and I want to be mindful of the impact to extensions. + * [carlos] Would be nice to discuss a process to make breaking changes. + * [tomislav] let's add this topic to the agenda. + * (end of online+in-person part; the rest of the day continues in-person) + + +### Inconsistencies + +(Mostly about sidebar_action/sidepanel, tracked at [issue 128](https://github.com/w3c/webextensions/issues/128)) + + * [timothy] How do we resolve inconsistencies, e.g. to avoid needing browsers to require two implementations? + * [jessie] sidebar/sidePanel is a concrete example. + * [tomislav] The approach the web has taken for this is Origin Trials, where one can enumerate every user of a trial API. + * [patrick] And users of origin trials explicitly acknowledge that the API can go away. + * [tomislav] If we could lean into a similar design if not reuse it directly, + * [rob] Mixing future & present. We have a concrete list of issues that we can discuss. + * [timothy] Concrete example is sidebar/sidepanel. + * [devlin] sidebar is very tied to a browser surface that has not been shared. For example, Firefox doesn't have the difference between contextual and global sidebars. + * [timothy] In Safari sidebars are global, not contextual. + * [tomislav] We have a per-tab context, but by default it is global. Similar to the extension action APIs. + * [mukul] Edge also has a side panel, but our behavior diverges from Chrome and Firefox. + * [timothy] In Chrome, is it contextual or global? + * [devlin] The surface itself supports contextual and global, and the API too. User-facing differences when the user switches tabs. + * [timothy] Is edge contextual or global? + * [mukul] We are both, but there are some issues with contextual - there are some conflicts with the underlying Chromium implementation. + * [timothy] Main use of sidebars is to get content out of the page? (e.g. sidebars) + * [devlin] Multiple use cases for both global and contextual – e.g. a contextual one may show data from the page, while a global one may be something like a messaging app + * [timothy] Edge also has the manifest side panel for webapps. + * [mukul] That is different; a proposal from a different team. + * [rob] Link to this (non-extension) Edge proposal: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/SidePanel/explainer.md + * [devlin] If that were implemented, that mostly gets rid of the use cases for global sidepanels. + * [mukul] That's why we think contextual use cases are more interesting. + * [david] If extensions APIs are contextual, couldn't they ignore the context and display global content? + * [devlin] If it defaults to contextual and there is no way to declare global, … If you have a contextual panel, every page has a separate side panel instance. + * [rob] Although you're referring to it as “global”, there may be more than one, each window has their own sidebar document. + * [devlin] Yes, each window has its own sidepanel page instance. + * [rob] Back to the original question of sidepanel vs sidebar inconsistency; Chrome introduced sidepanel because it wanted an extension API for a new UI surface in Chrome, and had its reasons to not implement the previously existing sidebar API. Developers aren't generally interested in the nuance. Would suggest that Chrome adopt the pre-existing pattern. + * [devlin] Gaps. Get/Set pattern – single action. Can't batch updates (can, but it's racy). Batching them in the options bag improves that process. Would FF be open to aligning on sidepanel? + * [tomislav] Historically we prefer to align on an existing API. + * [rob] Would prefer to align on sidebar since it existed first. Ultimately, alignment & reducing friction for devs is the goal. Would be open to considering it. Don't want it to set precedent. + * [devlin] Would agree that the precedent should not be we align on Google's implementation just because it's Google. + * [devlin] As a less controversial, smaller change, what about unifying getters and setters? + * [tomislav] Yes. + * [timothy] Manifest key is the big sticking point. + * [devlin] If we named it from scratch today, what would we call it? + * [rob] Sidebar. + * [devlin] Probably, yes. + * [rob] Would you be willing to adopt that? + * [devlin] In principle yes. Could alias. Expect that there will be some differences. + * [rob] Resolution? Options: do nothing, move to sidebar_action, move to sidepanel, move to (new) sidebar. + * [devlin] Could further break this into smaller pieces. Mozilla could add batch actions. setPanelBehavior from Chrome will require more discussion. Sounds like FF will look to align on behavior for now. On the Chrome side we're supportive of aligning on a namespace. Safari will potentially adopt the new name for this API. + * [timothy] Will likely need to alias the old names for compatibility. + * [tomislav] Would Chrome adopt the single-property getters and setters? + * [devlin] Hesitant to add things we know are undesirable patterns. + * [timothy] If we choose to support this, we'll want to support both. + * [richard] If you're introducing a new namespace, back-compat doesn't seem as much of a concern to me. + +(there will be another session on inconsistencies in APIs on Wednesday) + + +### Testing + + * [patrick] In Seville we agreed that testing is good and we should do it. Met with WPT folks at TPAC and they were good with us integrating with that project. There are some inconsistencies with how WebDriver handles extensions across browsers. Chrome can load extensions dynamically, Firefox cannot. Safari doesn't (didn't?) support installation at all. I created a rough initial implementation during TPAC. + * [rob] Meeting notes from TPAC, search for “Automated compatibility testing” at: https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-wecg-tpac.md + * [timothy] I know WPT has a sub-project called Interop. An active area of interop is the “investigations” section: areas that WPT wants to improve. Maybe this is something we can get added to the list of active investigations for 2025? + * [tomislav] We could aim for more. + * [timothy] Fair, that might be a low bar. + * [patrick] We've been working with Mozilla folks on MDN, Baseline. + * [tomislav] Brief overview of Baseline? + * [patrick] Browsers agree that Feature X should be safe to use across all browsers. Based off WPT info, feedback from engineers, based on CanIUse / MDN Compat data model. CanIUse is one person. + * [tomislav] We don't have a dedicated person working on checking compat with other browsers. + * [patrick] Example: https://github.com/patrickkettner/web-platform-tests/tree/webextensions, specifically this one commit that shows changes to test the runtime API: https://github.com/patrickkettner/web-platform-tests/commit/5ef608ee6c07d3d294568e494824fb55e8ee3944 + * [patrick] General structure of WPT is that each test is a separate HTML file. In the branch you'll see there's an <API_NAME> subdirectory. Idea is that each file is a separate test, and each test is a separate extension. + * [timothy] We have WebDriver in Safari, might be able to use our existing mechanism to hook into wpt. + * [andrey] Every file is a separate extension, does the browser start fresh for each test? + * [patrick] By default WPT tries to reuse contexts, but you could do this. That would be done with a test harness which tells the browser what to do. + * [andrey] No immediately clear if/when the browser restarts. If I clone an existing test to create a new test, will the browser restart before running this test? + * [patrick] If you clone the existing test, yes. + * [tomislav] Can you load another extension while one is running. + * [patrick] It's possible, but not currently implemented that way. + * [timothy] I think our safari driver can also join the existing test. + * [devlin] Looks like WPT wants you to account for previous state. + * [patrick] That's true for the web platform stuff because they reuse domains. + * [devlin] that causes a lot of complications for extension behavior, which very commonly affects browser state + * [patrick] We can control for that, but we would have to write code to handle it. When writing tests you have to explicitly make it a clean context. + * [devlin] Can we expect a clean slate when designing our tests? + * [patrick] It's calvinball, we can do whatever we want. + * [devlin] Will other web platform tests poison our environments? + * [patrick] No. + * [timothy] What about more complicated tests? Specific tabs open, incognito, etc. + * [devlin] Have folks seen Chrome's testing framework? Tests are basically extensions, essentially our own JS testing library (kinda like e.g. Mocha). You can create tabs, query that the created tabs, and so on… + * [devlin] We need the ability to run an arbitrary number of extensions. + * [tomislav] Would we want to have an extension set up the environment, then load the other extensions? + * [rob] WPT has some internal only test APIs. Could leverage this concept. + * [devlin] There are things that we will want to verify that aren't exposed in the existing APIs. In those cases we'll need to implement them in the test runner. + * [tomislav] I think injecting a content script is a good example. Can't verify execution without use of timers. + * [devlin] If you're injecting at document_start or document_end, we can detect and test for those executions at set times. + * [devlin] If we could write a half dozen tests or so to explore how we should implement them in WPT. + * [tomislav] Could consult our existing tests and port them over. + * [patrick] Before we can merge into WPT, we need multiple platforms to support. We can use some breakout time to work on this. + * Timothy, Patrick, Tomislav tentatively planning to sync up to work on this. + * [timothy] Context menus sounds like a good one. + * [rob] Would like to focus on the requirements of what we want the test runner to do before diving too much in specific tests. + * [patrick] We can work on that in a breakout. + * [timothy] Will need multiple meta tags to handle loading multiple extensions + * [patrick] Would want to create a single meta tag that takes multiple extension declaration objects. + * [devlin] You mentioned most of them run in service workers, but there's a separate page for each test… + * [patrick] service worker is used to collect results. + * [devlin] Looks like the test runner injects tests as content scripts + * [patrick] Some, yes + * [devlin] One of the main things I'd want is to be able to test from the context of an extension service worker. Are the bindings to emit test results exposed to an extension service worker? + * [patrick] They weren't originally, but they may be. + * [devlin] Sounds like we have next steps for breakout session + * We need a Firefox & Safari implementation + * A few implemented tests to flex the API, work backwards to find gaps + * tabs, context menus, runtime + * Idea is to write the test as we would want it to be written, work backwards from there to find what we're missing & what we need to implement to enable the tests + * [rob] Given the expressed timeline, will Chrome already have the `browser` global as the extension namespace by that point? + * [devin] Best not to expect that, but it would depend on timing. + * [timothy] How would we handle permission requests? + * [devlin] Maybe auto-grant requested perms? + * [timothy] For now we'll likely want to implement as much as possible in a single extension manifest. + + +### Issue triage + + * **[Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG?** + * [rob] The existence of these old “specs” are confusing, and continue to occasionally confuse people who are not already familiar with the WECG.. + * [timothy] I'll resolve this task. + * **[Issue 7](https://github.com/w3c/webextensions/issues/7): request: separate extension permissions from site permissions** + * [devlin] From the Chrome side we are hesitant to do anything like this when the extension scripts are running in the main world. We are also very careful with exposing functionality to content scripts because they share the process. + * [timothy] In favor of closing. + * [rob] Recommend closing this topic, more specific topics are covered by other issues. + * **[Issue 9](https://github.com/w3c/webextensions/issues/9): New Issue Template** + * [devlin] We don't have a template, but have organically established a process. + * **[Issue 12](https://github.com/w3c/webextensions/issues/12): request: allow to retrieve a frameID from an <iframe> element** + * [devlin] There were some concerns about exposing the frameId directly to the web page, due to the amount of information captured by the ID. I'd like to follow up with security and follow up. + * [simeon] Issue is being tracked at https://issues.chromium.org/issues/40200404 + * [oliver] A recent comment requested documentId as an alternative, which would not have the same issue. + * [oliver] I'll follow up with Chrome Security about this + * **[Issue 14](https://github.com/w3c/webextensions/issues/14): request: manifest error handling for unknown properties** + * [patrick] The consensus is to not error on unknown values. Does Safari need to make any changes? + * [timothy] We don't. + * [devlin] Oliver made a change for background.scripts in MV3 ([CL](https://chromium-review.googlesource.com/c/chromium/src/+/4979885)). + * [richard] On the issue, Firefox linked an issue. + * [rob] That is about enforcing it easily by default. + * **[Issue 274](https://github.com/w3c/webextensions/issues/274): Proposal: i18n.getLanguageDictionary** + * [carlos] API to allow extensions to use a specific locale + * [timothy] I am in favor of supporting. + * [devlin] This proposal returns an object with methods (not a plain old JS object), which is unusual in the extension API. Wonder if there's another approach that might be more inline with existing patterns. + * [carlos] Alternative API shape is to pass an extra parameter with the initialized state to the getMessage method. + * [patrick] Next step is for Carlos to make a formal proposal. + * **[Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()** + * [timothy] We recently fixed this in WebKit, and match Firefox's behavior; to reset to the default. We also support windowId in the APIs. + * [devlin] Supportive of changing that. + * [rob] There is already a crbug filed, https://issues.chromium.org/issues/40073862. + * **[Issue 483](https://github.com/w3c/webextensions/issues/483): Proposal: API to embed pages in WebExtension bypassing CSP** + * [rob] The issue presents several potential ways to address the issue. Last time we discussed this, the decision was to await Chrome's preferred solution before Safari and Firefox look at the options in more detail. Especially because some suggested “solutions” are Chrome-only. + * [oliver] Don't think that we should block on window.top; some use cases are only concerned with the CSP and not window.top. + * [devlin] This is a topic for more discussion; let's cover it later + * **[Issue 252](https://github.com/w3c/webextensions/issues/252): Introducing browser.i18n.getOSLanguage** + * [carlos] All supportive, next steps example case. + * [carlos] I will file a proposal. + * (consensus) Yes. + * **[Issue 319](https://github.com/w3c/webextensions/issues/319): Increase the maximum number of dynamic rules to 30,000** + * [devlin] Implemented in Chrome. + * [rob] Not implemented in Firefox yet. Tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1803370. + * [timothy] We're supportive but not implemented yet. We can file an issue and link it from the issue. + * **[Issue 231](https://github.com/w3c/webextensions/issues/231): Extension API to find the public suffix (eTLD) of a given URL/domain** + * [devlin] Some more investigation needed; e.g. include vs exclude private registries. + * [devlin] Next step: have a concrete proposal + * [devlin] Wondering about the value of adding a new namespace for one method. + * [rob] In the issue I linked to the interfaces of the three browsers, take a look there for inspiration on what other methods we could add. + * [oliver] AI: Reach out to PSL maintainers + * **[Issue 318](https://github.com/w3c/webextensions/issues/318): Adjust the maximum number of static rulesets and enabled rulesets** + * [devlin] Implemented in Chrome + * [timothy] Implemented (but not yet shipping) in Safari + * [rob] Not implemented in Firefox yet, tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1803370. + * **[Issue 44](https://github.com/w3c/webextensions/issues/44): Proposal for Manifest V3: add permission allowing a background script to be persistent** + * [devlin] We won't do this in Chrome. Since Chrome and Safari are opposed and FF doesn't support service workers, can we close this out? + * <consensus> + * **[Issue 134](https://github.com/w3c/webextensions/issues/134): Proposal: Limited Event Pages for MV3** + * [simeon] It is opposed by chrome. Should we keep it open to spec it? + * [timothy] Implemented and supported by two browsers, so it is eligible for being specified. + * [rob] We could put the spec clarification limit on this. + * [simeon] We can close it - it is unlikely for us to forget about event pages when we start specifying. + * **[Issue 162](https://github.com/w3c/webextensions/issues/162#issuecomment-1993994033): Declarative Net Request proposal: disable individual static rules (comment)** + * [andrey] Chrome has implemented, but we've shared data suggesting the 5000 limit is too low. + * [devlin] Hoping to have support for faster review for ruleset updates. Wonder if that would address the need to raise the limit. + * [andrey] Differential updates require the same number of added rules and disabled rules. + * [devlin] That would imply filter list size never grows, which is probably not the case. + * [andrey] This feature was designed and implemented for the use case of differential updates. Why are we limiting the API such that it interferes with the use case? + * [devlin] If you are updating every day, and 5000 is enough for two weeks, isn't that enough? + * [devlin] There are no real privacy and security concerns, just performance and implementation concerns. Currently stored in prefs in Chrome, which makes it immediately available at browser startup. Changing that has negative implications for performance and potentially user-visible effects (the extension might not take effect immediately). Wonder if the issue goes away with faster extension updates. + * [andrey] We're discussing an extension API but you are creating a strange dependency on the Chrome Web Store. + * [rob] Current design relies on the assumption that an extension update is the right way to propagate these updates. When an extension is reloaded, there is a brief period where the extension is not active. Is disabling an extension across updates a concern? + * [devlin] Users should be restarting their browsers more than every 14 days. + * [simeon] 👀👀 + * [devlin] You could prompt your to request a browser restart. That would ensure the extension is always active (vs. disabling an extension, updating it, re-enabling it) + * [rob] Why are you suggesting that instead of `browser.runtime.reload()`? + * [devlin] The browser startup path ensures that there is no period when the filters are not active. + * [rob] Would that be an argument in favor of an option to `browser.runtime.reload` to suspend network requests until the extension has been updated? + * [devlin] Yes that is an argument, but I would not be in favor of supporting such an API. + * Next steps: re-evaluate once fast DNR store reviews are in place + * **[Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR** + * [devlin] Not sure I follow, can someone clarify the request? + * [andrey] The request here is to only redirect if blocked by another rule. + * [timothy] We talked about replacement resources, meant to fill in for the resources. + * [andrey] DNR already has support for rules to redirect. This request is a conditional request, basically a different redirect. + * [rob] Concern with the specific request, that it is an API to counter anti-adblockers. Even if we were to implement the requested feature, then anti-adblockers would switch to another mechanism. At that point, I wonder whether the API would serve any other purpose. + * [andrey] I'll write something and post on the issue. + * [devlin] Sounds good; let's discuss this at a deep dive later. + * **[Issue 24](https://github.com/w3c/webextensions/issues/24): Request: consider extension store implementation and review policy during specification process** + * [devlin] There is no actionable task here. + * [simeon] I'll comment and close. + * **[Issue 25](https://github.com/w3c/webextensions/issues/25): request: don't standardize around lowest common denominator platform (e.g., mobile)** + * [patrick] This issue is not actionable either. + * [devlin] Agreed. + * [patrick] I'll close the issue. + * **[Issue 21](https://github.com/w3c/webextensions/issues/21): How should sidebarAction be considered, since it's only implemented in two browsers?** + * [oliver] Almost a meta spec issue – how do we handle cases where we don't have consensus. + * [timothy] We are interested in sidebar_action, sidePanel, and (as discussed earlier today) sidebar. + * [rob] Issue raised at (closed) https://github.com/w3c/webextensions/issues/387. + * [devlin] On the meta question here - when there are multiple APIs without consensus, we don't specify them, but can discuss them. + * [patrick] Requiring a shipping implementation seems like it may be a prohibitively high bar. + * [andrey] Should we reach out to Opera about this? + * [carlos] Naver also supports it, should contact them. + * [simeon] Agreed. I can reach out to them to invite participation in sidebar related discussions. + * **[Issue 128](https://github.com/w3c/webextensions/issues/128): Proposal: agree on a unified sidebar_action API for mv3** + * [carlos] Duplicate, this is the other sidebar issue + * [rob] Let's use this as the canonical issue to track the discussion we had this morning. + * **[Issue 38](https://github.com/w3c/webextensions/issues/38): Support for the distribution of Web apps?** + * [devlin] Out of scope, close it. + * [timothy] Agreed. + * **[Issue 40](https://github.com/w3c/webextensions/issues/40): Provide consistent access to browser.permissions API in the devtools** + * [rob] This is about privileged extension APIs, including browser.permissions in devtools_page. + * [devlin] The old behavior was a carry-over from when extensions were in-process. When we supported out-of-process extension frames, we started to support this. + * [rob] I'm hesitant about exposing privileged extension APIs to extension frames, but am in favor of doing so for devtools panels. Tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1796933. + * **[Issue 541](https://github.com/w3c/webextensions/issues/541): Proposal: AI Assistant API** + * [oliver] Suggest closing the issue, because it is a request to expose powerful functionality without permissions. The request is not very specific. + * **[Issue 69](https://github.com/w3c/webextensions/issues/69): Use case of eval** + * [rob] What is this issue tracking? + * [devlin] One of the mentioned issue (WebAssembly) has been fixed + * [rob] Through ‘wasm-unsafe-eval'. For details see https://github.com/w3c/webextensions/issues/98#issuecomment-1106702230 + * [devlin] Don't know much about Secure ECMAScript, looks like it depends on ShadowRealms with fallback to eval. + * [rob] I don't consider that to be a significant enough use case to introduce eval. + * [carlos] default and enforcement CSP issues: + * https://github.com/w3c/webextensions/issues/98 + * https://github.com/w3c/webextensions/issues/99 + * [simeon] I'll comment on the issue diff --git a/_minutes/2024-03-19-san-diego-meetup.md b/_minutes/2024-03-19-san-diego-meetup.md new file mode 100644 index 00000000..4ddece13 --- /dev/null +++ b/_minutes/2024-03-19-san-diego-meetup.md @@ -0,0 +1,397 @@ +# WECG March 2024 Meetup, Public Notes, Mar 19 + +Tuesday, the second day of the three-day in-person meetup of the WECG in San Diego ([#525](https://github.com/w3c/webextensions/issues/525)). + + +## Agenda + + * 9:00 - 10:00 declarativeNetRequest + * (break; transition from remote to in-person only) + * 10:20 - 10:40 Cosmetic Rules + * 10:40 - 10:50 Imperative Blocking + * 10:50 - 11:35 Mobile extensions + * 11:35 - 12:00 Permissions and Related + * 13:00 - 15:00 WECG Leads session (no public notes) + + +## Attendees + + * Devlin Cronin (Google Chrome) + * David Johnson (Apple) + * Timothy Hatcher (Apple) + * Kiara Rose (Apple) + * Elijah Sawyers (Apple) + * Brian Weinstein (Apple) + * Tomislav Jovanovic (Mozilla) + * Jessie Berlin (Apple) + * Rob Wu (Mozilla) + * Anton Bershanskyi (Independent, remote) + * Carlos Jeurissen (Jeurissen Apps) + * Richard Worth (Capital One) + * Casey Garland (Capital One) + * Mukul Purohit (Microsoft) + * Oliver Dunk (Google) + * Andrey Meshkov (AdGuard) + + +## Meeting notes + + +### Declarative Net Request + +Future expansion in Declarative Net Request, including cosmetic filtering proposal and other improvements, safe imperative modification, header modifications, CSP, and more + +[Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR (part 1 of 2) + + * [andrey] Tricky to understand, but widely used. Many generic rules that block by file name in URL. Used by some websites to detect ad blockers, circumvent adblockers. Filter maintainers would like to use a different behavior on specific websites. Could be done like it's done right now in uBlock Origin/AdGuard. First (…) Second way changes how the blocking is done. There are 1000 rules like this and need a solution. + * [devlin] Do you have an example? + * [andrey] E.g. ads.js; Then a filter maintainer wants to override the behavior for a whole website, e.g. instead of a server error it wants to serve a replacement. To override how the request looks like to the website. + * [devlin] Why not use a higher priority redirect rule? + * [andrey] We can do that, but there are many websites. + * [devlin] When the redirect redirects to a static resource in the extension? + * [andrey] Basically yes. Instead of blocking on this website, return an empty JS/image, etc. Solution could be to provide a different action instead of block. One that does not return an error but emulates an empty response. + * [devlin] If you have the set of 1000 rules to block trackers, then you don't know which of these match on thousand websites, so you need to update them for the websites you want to match. + * [andrey] In content blockers there is a similar complication to how response headers are matched, because you cannot act on the response at the start of the request. + * [devlin] One of the proposals here is to have a new action type redirect-if-blocked, which would allow you to specify these rules. Having that as an action type seems weird. So we could also have a condition of block, and then an action of redirect from there. That would allow us to abstract it to other action types, in principle. + * [andrey] If we can have another action as a condition, then we can also use it for other scenarios. + * [devlin] Then we also would have to repeat matching multiple times. + * [andrey] Right, it's not a bad approach though. + * [jessie] + * [devlin] + * [andrey] + * _(this topic was revisited later, while discussing the next issue; Search for "issue 493")_ + +[Issue 468](https://github.com/w3c/webextensions/issues/468): [DNR] Redirect rule does not allow applying other redirect rules to the resulting request + + * [andrey] Removing params from URL, we have several rules to remove params. We want one rule per parameter, and not many intersections. Issue already got some feedback from Rob (Firefox), waiting for feedback from Safari and Chrome. + * [devlin] I don't think that the solution would be quite the same as what was discussed before (issue 493) because it is just removing params. + * [andrey] Maybe up the number of permitted redirects to e.g. 100 + * [devlin] Don't want to have so many redirects just remove params. + * [rob] That's not necessary; We can apply all transformations at once and then redirect once. + * [devlin] If those rules are applying query parameters. Those rules can be cumulative. Other types we wouldn't want to have multiple apply. + * [andrey] What's the risk? + * [devlin] Removing multiple query parameters allows you to, for example, remove trackers. Having a rule that redirects a host, another that redirects a scheme, etc. That's probably not how you'd want to compose those redirect rules. + * [andrey] Modify document location hash. + * [devlin] Generic case is anything that would perform a same document navigation? + * [rob] Same document nav doesn't have any network requests. What are you referring to? + * [devlin] If you're currently on a page, a modification of a URL wouldn't result in a new URL being loaded. Query parameter, hash, … + * [rob] Query parameters trigger a navigation. Sounds like you're saying any navigation on the same origin. + * [devlin] I don't think we'd want cumulative navigation on paths. + * [rob] For example, a site could embed tracking parameters in path components. + * [devlin] Note, we've jumped issues. Trying to draw a line between where cumulative rule applications does/doesn't make sense. Something that changes a path and certainly origin doesn't make sense. + * [rob] You're suggesting query modifications in the query string / reference fragment when it looks like a query param + * [devlin] Maybe another type of rule to address that: modify path rule parameter (bad name). + * [andrey]? + * [devlin] If we do redirects, every rule match results in a network request. + * [andrey] That's implementation specific. If you match and apply in order of priority, you may not need to execute a new network request. + * [devlin] What if you do something that results in a new match? That's a loop of N. + * [andrey] You have an exception that prevents this. + * [devlin] ? + * [carlos] Could you make this behavior optional in order to reduce the performance impact? + * [devlin] ? + * [andrey] I don't follow the limitation of applying a redirect rule to the result. + * [david] I think Devlin is suggesting we wouldn't want to make a rule that applies another redirect. + * [devlin] That's what I was originally suggesting, yes, but + * [jessie] You'll have to create another rule anyway, right? The name doesn't necessarily matter. + * [andrey] Right now we don't have to create new rules. + * [jessie] You are going to have to create a new rule, so even if there is a new name, I'm not sure how that adds complexity. + * [andrey] Adds complexity to the syntax. Generally prefer to not extend existing things with new functionality when it can be avoided. + * [jessie] Adding new functionality instead of updating something existing is additional complexity. + * [andrey] Both options (single redirect rule or applying multiple at the same time) are easier for a filter list maintainer to reason about. Introducing a new flag for an existing rule creates confusion as the maintainer has to learn about new behavior. + * [jessie] Applying a redirect and needing to apply new rules that now match is a major concern for me. + * [andrey] ? + * [devlin] I think the suggestion is first eval you get all matching rules, just one time, match and apply all in one go. + * [rob] Current situation. Browser has built in a certain number of redirects, at some point you hit a redirect limit, and you can no longer perform redirects. This is a problem if you want to make more changes than you can redirect. The suggestion is to apply all at once and redirect once. + * [devlin] Would this only apply on same priority rules? + * [rob] I was thinking so, yes. + * [andrey] Higher priority rules go first, lower priority go second so we don't need to apply them. + * [devlin] I think this is getting to what Carlos mentioned to provide a mechanism for specifying a cumulative redirect. Anything that should just redirect would not be cumulative. You would explicitly mark cumulative redirects if you are doing something like removing query parameters. + * [rob] Do we need multiple priorities? Removing a param just removes it. Doesn't apply anything else. + * [andrey] Generally I don't think we need them. So far what has been suggested seems reasonable. + * [devlin] Would have assumed there are times when you want to replace. In that case you might have a higher priority that you want to remove. + * [andrey] Replacing is not what we do right now. We do have transformers but this has some limitations and we don't allow everyone to use it. We may need such functionality in the future. + * [devlin] Time check. Curious for other browser vendors, intuition on if we have one pass of the rule set, apply all matches in the same operation, and output a single new URL. Potential performance hit ‘cause we can't early out, but may sufficiently contain that performance hit. + * [brian] When we match one, would we start over? + * [devlin] No, andrey's suggestion was that we'd find all potential matches in one go, then apply them. + * [rob] In removing parameters, the order of applying rules doesn't matter. + * [brian] + * [devlin] In order to avoid trying to fully design this API in the next 15 minutes, is this something we would want to explore? Rob it sounds like you are supportive. Is Mozilla supportive? + * [rob] Yes, we're supportive. + * [brian] Open to exploring this. + * [devlin] On the Chrome side we're in the same boat, if we can contain this to one loop through the rules and do one set of modifications, we are open to this. The open questions are how do we indicate if rules should be cumulative. + * [andrey] I like Rob's proposal. + * _(continues previously discussed [Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR)_ + +[Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR (part 1 of 2) + * _(while discussing issue 468 about multiple redirects, we circled back to issue 493)_ + * [devlin] Redirect if blocked rule would likely have a different approach to applying multiple redirects. + * [andrey] The condition redirect block doesn't apply if the request is actually blocked, but if there's a matching block rule. To make that conclusion, we first need to analyze block rules, then check redirect if blocked rules. + * [devlin] Exactly. If redirect if blocked is a condition, and you get a new request, and you search through all rules, there will no longer be a match because request has not been blocked. + * [devlin] For matching on response headers, a lower priority rule can take precedence over a higher priority rule, since we don't want to send a request to see if the block rule would match. + * [andrey] What's the blocker to making progress on redirect-if-blocked? + * [devlin] The biggest thing we want to ensure is that we cap the possible performance hit. We want to ensure this never becomes something where we continue looping indefinitely. Are there any situations where there is a rule that blocks, and the another rule that redirects if blocked, and then another rule that tries to do something based on that? + * [andrey] Like the case of multiple redirects, there needs to be something that prevents loops. + * [devlin] I didn't think it was only once, I thought there was a limit of 7 in Chrome. + * [rob] Limited, somewhere between 5 and 10. + * [devlin] We wouldn't want to hit that limit if possible. Want to add something where we are guaranteed to only use one. + * [andrey] It won't solve anything else, but the number of existing rules that use this format justifies this. Last year Gorhill said there were 600 rules. This morning there were 800. Usage is growing. + * [devlin] Wondering if a general form would address more use cases. Say a rule condition that applies to blocked rules. This may be the only case where such a feature is useful, but trying to consider what else might leverage it. If we cap this at one additional loop/evaluation of rules, is this something we're generally open to considering? Rob, you mentioned a concern that if we do this, then we get into the arms race between ad blockers & ads. + * [rob] Right. Was also trying to see what the use case behind this. If we implemented it in a different way, might that better address the issue? + * [andrey] I probably wouldn't design it differently. Hard to come up with a better way that's flexible enough to solve the task at hand. So far I don't see a better design. Agreed that it seems strange, but I believe it's needed. + * [devlin] I think there is a good counterpoint to Rob's concern. This is already being used in Manifest V2 and if ad networks were going to do something different, they would have likely already done so – at least, it's a good sign that it's not just something that will be used for a month, and then pivoted. + * [andrey] Generally, we could probably live without it, but it would require much more manual work by filter lists. Given significantly limited resources of maintainers, don't think that's the best path. + * [devlin] Apple folks, thoughts? + * [david] We always have concerns on performance, but we're open to investigating. + * [devlin] Andrey, sounds like this path is sufficient for your use case? + * [andrey] Yes. + +[Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields + + * [andrey] Would like flexibility in matching initiator, with wildcard. Safari provides a similar capability in Content Blocking API. Can't use this and matching on domain names at the same time (safari-specific issue). + * [rob] That doesn't apply to the general initiator. Safari's rule matches the top level only, not arbitrary parent documents that may be a subframe themselves. Which do you need? + * [andrey] Both. + * [oliver] When the issue was originally opened, there was a proposal to have a wild card. During discussion, there was a suggestion that it could only apply to the TLD. Allowed avoiding a RegExp which would mean needing the same limits we have to number of RegEx rules in other cases. + * [andrey] Initiator url filter is not a regexp. Not the same perf hit. DNR syntax for matching URLs is faster than regular expressions. Initiator url filter field would use a similar approach, avoiding RexEp overhead. + * [rob] By initiator, for documents, do you mean the initiator of the navigation or the parent document? + * [andre] I think of it as tab URL vs frame URL. In this case we check the frame URL. + * [rob] That makes sense for sub-resource requests, but what about document requests? Does initiator apply to the parent or the frame that triggered the navigation? + * [andrey] Does initiator mean tab URL? + * [rob] Could be either. Commonly the parent of an iframe, but could be a different frame or even window. + * [andrey] Intent in choosing “initiator” naming is to match the pattern of the existing DNR. I thought it was tab URL. + * [rob] I'll follow up later and record the answer in the notes. + * [devlin] We're over time and this will need more discussion. We're potentially open to it, this is easier than restructuring rules (previous topic). URL filter is cheaper than regexp, but isn't free. A combination of URL filter and a list of initiator URL filters, that could potentially significantly impact the performance of the URL filter. Could potentially result in 2x the time. I think we collectively don't want to add a “max number of initiator URLs” constant or something like it. + * [andrey] Original request was originally on eTLD, but that's not the only case so we expanded the scope. + * [devlin] Suggest we break, but consider for the future how many rules are satisfied with eTLD, how many are by full initiator URL filter, and if there's other variations of \*eTLD that would give us 99%, or whether we truly need full URL. + * [david] We also have performance concerns here and would like to discuss further. + + +### Cosmetic Rules + +[Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules + + * [devlin] Recap on cosmetic rules. Andrey, you mentioned this would be easier in Safari + * [andrey] I expect Safari to be able to implement this easily because Safari's Content Blocker API already has this feature implemented. + * [brian] Yep + * [andrey] It blocks us from migrating to web extensions. What's the next step? Proposal? + * [devlin] Does any browser have the bandwidth to start this? It sounds like we have consensus on this being a good idea. Hesitant to work on a proposal if no vendor has the bandwidth/intention to work on this for a long time. If we design now and start implementing in 18 months, we may not want that design (the world changes in 18 months). + * [andrey] Not a new thing for us. Doubt there will be drastic changes to the design. Could start with some kind of polyfill on our side as we'll need this functionality. Can start with a polyfill, experiment, gather feedback, and discuss. Anticipate that this will be easier on the Safari side. + * [david] Safari is interested in it, we see significant interest from content blockers. Are you interested in adopting Safari's approach? + * [devlin] Not familiar enough with existing syntax to comment on Safari's existing approach. Also wondering if this would make sense for declarative modification (blocking or addition). Canonical example is Pinterest adding pin buttons, but also things like a password manager badging a password field. Potentially another layer that would be interesting to consider. + * [timothy] Don't feel like this would fully address the password manager use case. + * [devlin] Could be used in combination with activeTab, but that's a larger discussion. + * [rob] Is it an objective to have this functionality without host permissions? + * [devlin] Yes, for at least some cases. + * [jessie] We're very interested in ways of allowing extensions to put content in front of users that they can interact with, but concerned that this blows up the scope far too much. + * [devlin] I think we're aligned. I'm thinking we'd start with just the blocking functionality and potentially introduce additional functionality in the future. I'd push back on a name like “declarative css hiding”, since that restricts our ability to expand. I'm thinking about making space in the scoping of this API to potentially introduce functionality in the future. + * [devlin] Would ad blockers share a common polyfill? + * [andrey] We share a lot of ideas with other content blockers, but we don't have a formal group where we do that. + * [devlin] We don't want to end up having a graveyard of proposals. If there was a canonical polyfill, that paves the road to baking it into the platform. Are browser vendors generally agreed that there's interest in exploring this? + * [david] Yes, we're interested. + * [rob] This is independent of DNR (declarativeNetRequest), right? If not then I wonder what conditions you require. + * [devlin] Yes, this isn't network related + * [andrey] We haven't yet decided where we'd put this, right? Would it be a new namespace or a part of an existing one? + * [devlin] Sounds like something that Safari can incorporate in the proposal. + * [david] Would be inclined to … . Do we see this going down a path of putting all declarative features in a single namespace? + * [brian] DeclarativeNetRequest API surface has a lot of APIs that may be useful to not duplicate in a new namespace. For example, dynamic/session rules. + * [rob] We can copy the same methods/API design in the new namespace. There is already some precedent for that in the scripting vs userScripts namespace. When we put everything (DNR and cosmetic rules) together, we have to think about the impact on style rules when we make new DNR features. + * [timothy] Have objected to this in the past. UserScripts isn't the best example because we have a lot of duplication. + * [devlin] Sounds like something to discuss in a proposal. + * [andrey] You said you had ideas of how to extend this in the future. For example putting something on the page declaratively. Isn't this what declarative content was supposed to be? + * [devlin] declarativeContent was an early pioneer in this. Never injected content in the page, allowed devs to conditionally show page action. + * [jessie] Hesitant. Would prefer to use DNR, but at this point I think we'd alias. + * [devlin] Want to identify which pieces of DNR we'd want to generalize. Haven't historically shared methods or features across APIs, but I think that's a good area to explore. I think we'd want concepts of the APIs to overlap (e.g. conditions + actions as a concept, having session, dynamic, and static rules, etc), but not all functionality or types. Would like to see what Apple has in mind in a proposal. + * [andrey] Declarative content, should we mark it as deprecated? + * [devlin] Nope. It still has non-trivial usage. Also depends on how you define usage – parts have more use than others. Used enough that we wouldn't want to throw it out wholesale. It may still also be a good home for this, TBD. + * [rob] I did an analysis 6 years ago. Around 11 million users across 1000 extensions. 163 extensions had over 1000 users. + * Source: declarativeContent usage: https://docs.google.com/document/d/1pOWsOXgDljhiN6hcLA2vojOR4cCh2sq7WfwO5j5cIyg/edit + + +### Imperative Blocking + + * [devlin] Simeon, you added imperative blocking. I'm guessing that's about doing a blocking webRequest-like thing in a safe, performant way. + * [simeon] Yes + * [devlin] From the Chrome perspective, a major concern is that it's very easy to tank performance. Additionally, if we did this, we'd want to use an established primitive (not create something new). For example, fenced frames as a container that would allow the platform to prevent network access. When we see that these ideas go and that they are going to stick around, we can revisit if those could be used + * [simeon] Was thinking of e.g. something like a WASM module in the network process. + * [jessie] Biggest concern is perf. We've seen this (ability to prevent a network request from going through) abused in the past. Very concerned about impact. + * [devlin] I think Chrome and Safari are generally opposed. + * [tomislav] I'm very skeptical that it's even possible for us to prevent extensions from leaking data. Even with a block/allow engine, I could extract data from bitfields. Could have a page with a 100 images and that's 100 bits of data you could leak based on block/unblock. + * [rob] Yes, that's true. As soon as there is any shared state and ability to extract bits of information, infoleaks can occur. + * [jessie] Could explore places where extensions can't read/write from disk, can't have network access. Still concerns about performance, but interested in exploring this area. + * [andrey] Can't escape the need for host permissions. + * [devlin] Sounds like participating browser vendors are collectively concerned. + * [rob] I think privacy concerns can be overcome by not carrying over any state. + * [devlin] Not fully agreed with that, but can catch up in a break-out session. + * [andrey] To summarize, if there's a way to safely and in a performant manner register something that could modify network requests + * [devlin] hypothetically if we can guarantee security, privacy, performance, and minimal complexity, then yes. But I think that's not going to be very feasible. + * [tomislav] If this also required host permissions to be usable, I wouldn't be supportive. + * [andrey] But Mozilla supports blocking webRequest? + * [tomislav] The alternative proposal should offer advantages over what we already have. + + +### Mobile extensions + + * [rob] Someone recently spotted that Microsoft was exploring bringing extensions to mobile, so that seemed like a good opportunity to begin discussing. Safari and Firefox have extensions on mobile, and seems like a good time to align on defining the “windows” extension API for mobile. + * [casey] We are interested in extensions on mobile. + * [devlin] I, personally, want to see them on Android. There's technical complexity, which we can potentially work around. UI is strongly opinionated on Chrome and there's limited surface on mobile, which adds additional challenges. Also interesting challenges and questions around distribution of extensions. I continue to personally want them, but it's not actively being worked on. + * [mukul] Clarify distribution? + * [devlin] E.g. whether to distribute through the Chrome Web Store or the Play store; whether we could distribute through the App store at all. iOS requires an app, leading to empty shell applications that only load an extension. There's a lot of additional complexity around look, feel, etc.. + * [mukul] Firefox approach is to have a single store (AMO) that covers Android and desktop. Is the concern for Chrome that Play is the distribution mechanism on Android? + * [devlin] Concern is there are multiple potential paths that require evaluation and consideration. + * [andrey] Is there any need to change MV3 API in order to make extensions viable on mobile? + * [timothy] We were happy to see MV3 going in the direction of non-persistent background contexts. Beyond that I don't think there's anything we need. + * [andrey] Sidepanel probably isn't needed. + * [jessie] There's multiple mobile sizes. Might be appropriate in some. + * [andrey] Is there a need for a mobile specific namespace? + * [rob] No. + * [devlin] Don't think so. There might be things that are only applicable on mobile, but they could just be used conditionally. + * [tomislav] Web platform talks in terms of form factors, input capabilities, etc. + * [timothy] One big limitation that Chrome and Firefox will run into is nativeMessaging. If app and extensions aren't bundled then that's an issue. + * [devlin] Does iOS nativeMessaging have the same behavior as on desktop? + * [timothy] Has the same JS API, yes. At the native level it's drastically different compared to other browsers. + * [andrey] Most apps are not empty shells. Would like to see this in other areas as well. For example, on Android we'd like to be able to communicate between our extension and app + * [rob] We could try to add something, but would require coordination and standardization. There are ways to do this on Android, but we wouldn't want to independently create our own solution. + * [andrey] <missed in notes> + * [rob] on iOS a user has to go somewhere to opt in. Whether the browser or OS, the user needs to opt in somewhere. + * [andrey] Yes, user has to opt in. On iOS we also have the challenge that users probably won't be able to install things outside of the store (current policy). We would also want to be able to communicate between our Firefox extension and app on iOS. + * [tomislav] Mozilla does not have an “app store”. Google (Play Store) or Apple (App Store) are in a better position to drive that. + * [andrey] Probably could provide a native messaging API on Android. Suspect that's true for Edge as well. Implies not just browser extension APIs, but also the app-side of the communication channel. That aspect hasn't been discussed yet. + * [rob] Is there any interest in implementing native messaging for Android from browsers that haven't implemented Android extension support support yet? + * [devlin] I work on the Chrome side. I can't comment on Android resourcing. At this moment I can't make any promises one way or another. + * [patrick] How much effort would it be for you (Firefox) to create a draft proposal? + * [rob] I don't have time for it. I think it would be a lot of effort, and app+extension developers are in a better position to create a proposal. + * [patrick] If you're blocked on there being a proposal and none of our teams have time, is the proposal onerous enough that (…) + * [david] Maybe we should put out a call to get feedback from developers. + * [rob] Agreed. The concern is that if we are the only group interested and other vendors do something different, then that is not beneficial to the platform. + * [devlin] <missed in notes> + * [david] We're aware of browsers that spoof Chrome's UA to install extensions from the web store. What is Chrome's stance on this? + * [devlin] We've historically allowed other browsers to leverage the Chrome Web Store. That's how Chromium-based browsers like Edge and Opera do it. + * [devlin] Is Firefox or Edge looking into extensions on iOS? + * [tomislav] We are looking into a Gecko-based browser on iOS. + * [mukul] Definitely have a desire to look into it. Open question on how we handle the app store. There isn't too much difference between capabilities of the underlying engines. + +(windows API on mobile) + + * [devlin] We've discussed APIs on mobile. In APIs, we have tabs, windows, and tab groups. UI-wise, we only have two of those on mobile, but I don't know which two – it depends on your interpretation + * [timothy] Currently we expose windows on iOS, but you can't close/open/create them so they can be feature detected in JS. + * [carlos] Seems to be an edge case. Potential solution is to check if there are two windows. + * [timothy] Gets more complicated on iPad and Vision because you can have multiple windows and each has two backing windows: a private and non-private window. + * [rob] If an extension wanted to open a private browsing tab and one wasn't open, how would that work? + * [timothy] I believe it's exposed as a window that exists with no tabs. Can't close windows on iOS Safari. We don't expose create, remove or update. + * [david] You can edit the tabs in a window, but you can't edit the window. + * [rob] Seems like a reasonable approach. Often when the last private browsing tab is closed, the window also closes. + * [timothy] Each private tab has its own session, so when a tab closes the session does as well. + * [oliver] Is this documented and if not should we? + * [timothy] We should and I think it is part of the browser compat data. + * [devlin] Should document that pieces may or may not be missing, but would not want to spec specifics around e.g. "there's only one inPrivate window" + * [rob] I'd be in favor of documenting it in spec, that there may be platforms where the number of windows is fixed. + * [timothy] We don't currently support context menus in Safari, but iOS changes may make that possible in the future. + * [oliver] Don't think it makes sense for Chrome to drive as we don't have an implementation, but makes sense for Firefox or Safari to do so, assuming interest. + * [rob] We don't have enough spec to add this to. May make more sense to use our notes to collect decisions and alignment. + * [oliver] Agree that the spec is too immature right now, but would like to start collecting. For example, a non-normative note that says “windows may not directly correspond to what the user can see.” + * [devlin] I think tabs, windows, and tab groups are obviously different on desktop and mobile, which makes it interesting to discuss here. Are there other APIs that don't translate or may not translate the same way? + * [timothy] Action is thankfully not called “toolbarIcon”. Can't think of anything else that doesn't directly translate. + * [devlin] it's almost like we thought of that (smiles) + * [rob] Windows API is a little weirdly named given the featureset on mobile, I view it as an ordered collection of tabs. We'll still use the “windows” API name for historical consistency.. + * [timothy] We don't support tab groups. We still need to figure out if we can fit our concept of tab groups into the existing tab groups API. + * [oliver] Windows works well – likely matches developer expectations. + * [timothy] Also there are windows on iPad and Vision OS. + * [devlin] Are we all aligned on using windows as the API namespace, even for small form factor devices? + * [timothy] Yes. + * [kiara] Yes. + * [rob] Yes. + * [carlos] If we go forward with the Safari approach we might get conflicted in a potential future in which it is possible to open additional windows? + * [timothy] We handle this by creating two windows, a private and non-private, per “window”. + * [devlin] Do you currently expose this because of the assumption that sessions are either in private or non-private mode? + * [timothy] Yes. Users can switch between a normal and private collection of tabs. + * [devlin] It is not like you have tab1 in private, tab2 not in private, etc, all in the same "window". + * [david] Correct. + * [rob] Similar considerations in Firefox. The collection of private and non-private tabs are separate. + * [devlin] Any specific concerns, Carlos? + * [carlos] I recall having issues with how Safari approached its implementation. Maybe we want to remove the assumption of having a private & non-private window. + * [firefox] We wouldn't do that, but in FF we have the concept of containers. We reuse the concept of a cookieStoreId to distinguish between different containers and regular browsing contexts. + * [timothy] I would be open to having a property on the window to have a relation with the “sibling”/”opposite” window. + * [devlin] Let's make a new window groups API (joking) + * [timothy] You're joking, but it is not a bad idea. A property on the window. + * [devlin] Yeah, a property on a window like groupId in order to associate pairs of windows makes sense – just wouldn't want a dedicated API. + * [rob] I think we've concluded. Safari and Firefox will work together to specify behavior. + * [timothy] Suggest adding Edge too. + * [devlin] I'd be interested in Chrome folks being a fly on the wall + * [carlos] Should also create an issue to track and organize work. + * [rob] Would like to be very specific when creating an issue (windows API for mobile). Want to avoid people +1ing requests for mobile. + * [mukul] Are there any other behavior changes Firefox implemented to support Android? + * [rob] Most APIs are common across desktop and mobile. Windows have special considerations. Also want developers to move to event pages. + * [andrey] We observed that limited event pages are very similar to service workers. Didn't quite expect them to be as limited as they are. May want to emphasize lifetime limitations more in documentation. + * [rob] We were stricter in the past, but as we discussed lifetimes in the group we've advocated for less strict behavior and aligned on common behavior with Chrome for extending lifetimes. + + +### Permissions and Related + + * [simeon] Besides declarativeContent I'd like to have more ways to show UI to users, especially when there are limited UI surfaces such as on mobile. + * [carlos] Another potential approach is to only allow an extension to access content when they're actively in view. Especially applicable to sidebars. + * [timothy] Sounds like activeTab to me. + * [devlin] Concrete example? Maybe an extension wants to communicate with its own server? + * [carlos] Yes. + * [oliver] Another example is sidepanels: if you have a reader view that summarizes the content on the page. When you open the sidebar you have activeTab and can access the page, but after navigation the access is lost. + * [devlin] Concern about tying sidebar open = have access to the tab. For example, you have a messaging in a side panel and navigate to your bank. Users would likely be surprised at the access they're giving away. Also the extension can control the tab URL, so can choose to navigate to a new origin. + * [tomislav] Another example of when this is needed? + * [carlos] When you need to communicate with a server without CORS or apply DNR with host permissions. + * [andrey] Browser UI makes it more difficult for extensions to signal functionality to the user, since extension icons are hidden by default. + * [devlin] Sounds like this may be covered by showSiteAccessRequest(). + * showSiteAccessRequest proposal: https://github.com/w3c/webextensions/pull/529 + * [andrey] Idea is not bad, but depends on how it is communicated to the user. + * [devlin] On Chrome desktop we are considering sliding out a message from the extension button. Goal is to be noisier than a subtle badge, but less noisy than a dialog + * [carlos] There are extensions that are useful generally and then such a notification would be there by default. Already got feedback from users about the difficulty of finding the extension icon. + * [andrey] What if there was an API where the extension could ask the user to "pin" it and then it'd be on the browser to explain to the user what the extension wants and how to do that. + * [tomislav] We understand your concerns, but we have to support the entire ecosystem. What extension wouldn't request this? + * [andrey] Pain is every extension has to explain how to pin/unpin. + * [devlin] Hear your pain. Other developers also in the past complained when we gave them an icon in the toolbar. There's no single solution that fits everything. We won't allow extensions to configure the UI in that regard, but I understand it to be painful to developers and we want to look at ways to ease that pain. + * [devlin] Carlos, you described extensions in the background with host permissions? + * [carlos] In the foreground. You would restrict an extension from using host permissions when the extension isn't actively being used. When you have activeTab, that is restricted to the current page. + * [devlin] Yes. And we won't change that. + * [andrey] If I open a panel, I have a panel that constantly nags for access. But it doesn't necessarily want access, it has activeTab. Should be a good thing because the extension is narrowing its scope, but in reality it's frustrating. + * [devlin] From a fundamental perspective, on the Chrome side we are against implicitly granting permissions without user consent. We have a number of ways to request consent, all websites, some sites, and some sites with user gesture. The goal of the showSiteAccessRequest API is to present a medium-level request to the user. + * [carlos] Concrete example: sometimes you need host permissions that aren't on the main page and the user may not want to grant them because the extension can use them in the background. + * [david] Are you worried about cases where a user wants access to Google, then the extension tries to access your gmail behind the scenes? + * [carlos] Yes. + * [david] I feel like that's a really hard problem because an extension could do this in a fraction of a second after a valid use. + * [tomislav] Maybe a way to address this is to have a way to request permissions temporarily, e.g. an option to permissions.request() + * [timothy] Safari has the ability to grant for one day and the grant expires. + * [tomislav] I mean an extension explicitly opts into this so the browser knows the extension doesn't want persistent access. + * [david] The hard thing is that we know some devs will do the right thing and a lot of devs will copy-paste Stack Overflow solutions that give them persistent access because it's easier. + * [timothy] Does anyone have host permissions being fully opt-in, like Safari? + * [tomislav] We do have that in MV3. + * [devlin] We do not. + * [tomislav] Any plans to change that? + * [devlin] We are working on ways to improve the flow to encourage runtime-based permissions rather than install-time based. + * [carlos] Host permissions are mostly seen with being associated with the current tab. That's why it makes sense to grant and remove them based on what the user has focused. + * [devlin] We understand there are capabilities that aren't related to a tab. Interested in expanding user control there, time based access, one-time access. Open to exploring, but don't expect this will result in major API changes. We don't want to have this associated with whatever the user happens to have active, because it can be surprising and because the extension can navigate the tab independent of user knowledge or consent + * [david] From our perspective this will likely have to be browser driven. + * [devlin] Agree with Tomislav that it would be useful for a way to signal that the permission is temporary. + * [tomislav] Browser could show a less scary warning, or default to temporary access. Gives new opportunities for well behaving extensions. Potentially could meet developers half way. + * [david] Could potentially also let users control grants – you're asking for permanent access, I'll give you access just this time. + * [casey] Has Chrome considered categories for permissions, e.g. the ability to signal that the extension will never work on sites or classes of sites? + * [devlin] We have considered it. Would love to be able to do this, but it's really difficult to do. We're very hesitant to do something with permissions when it's a guess, even if it's a good guess. There are a lot of ambiguous sites. Capital One is a great example, it's a bank and offer site (shopping). Amazon is a store and healthcare provider. + * [casey] What about saying everything but a host. + * [carlos] I had a request for disallowed host permissions. For example, blocking access to accounts.google.com for security reasons. + * disallow_host_permissions: https://github.com/w3c/webextensions/issues/123 + * [devlin] Think it makes sense to allow extensions to explicitly opt out. Proposals welcome. Doesn't seem like something that would be controversial, it's a matter of prioritization and resourcing. + * [tomislav] The UI would be the largest concern there. A large number of sites could confuse the user. + * [devlin] UI is out of scope of the spec. I suspect that we wouldn't show the list of sites in the UI. + * [rob] Could manifest as not showing activeTab on particular sites. + * [devlin] We could explore ways to present this. Extensions could also display their own banners that say “we never inject on X, here's how you verify” + * [rob] Agreed. There's no need for UI/UX. Someone could look at the manifest if they really want to. Extension declares it doesn't want access, browser enforces that it doesn't grant access. + * [casey] Users can't look at the manifest on mobile safari, right? + * [david] Correct. + * [andrey] We have to specify why host permissions are used when submitting an extension to the store. Can that be shown? + * [devlin] It's a known pain point we want to solve. May be outside the scope of this group. My ideal is to expose that through the store experience. + * [andrey] Alternative is to justify the request as part of the API. + * [devlin] Permissions request API already requires a gesture. Intent is you explain why you're requesting access and the user chooses to trigger the request. + * [david] We have a concept of transparency, consent, and control. Locations, permission, etc. We always require a reason. + * [andrey] Don't understand the reason that CWS doesn't expose the reasons. + * [devlin] Outside my control. + * [tomislav] Can't accommodate all use cases where a description of the reason fits inside the dialog itself. + * [devlin] Lots of precedent in mobile apps. For example, a camera app that requests camera access on first access and closes itself if denied. + * [carlos] But the extension is in the background. + * [devlin] You can open a tab and request permissions. + * [andrey] Lots of work for extension developers. You would save a lot of time for extension developers by integrating it in the browser. + * [timothy] Us doing it would also encourage the right behavior and give us more opportunity to control the experience. diff --git a/_minutes/2024-03-20-san-diego-meetup.md b/_minutes/2024-03-20-san-diego-meetup.md new file mode 100644 index 00000000..518c9560 --- /dev/null +++ b/_minutes/2024-03-20-san-diego-meetup.md @@ -0,0 +1,781 @@ +# WECG March 2024 Meetup, Public Notes, Mar 20 + +Wednesday, the third day of the three-day in-person meetup of the WECG in San Diego ([#525](https://github.com/w3c/webextensions/issues/525)). + + +## Agenda + + * 9:00 - 10:00 User Scripts + * 10:00 - 10:20 Embedding pages that don't want to be embedded + * 10:20 - 10:30 Icons: SVG + * 10:30 - 10:45 Icons: Dark Mode + * 10:45 - 11:00 DNS API + * (break; transition from remote to in-person only) + * 11:15 - 11:40 proxy API + * 11:40 - 12:00 Browser specific namespaces + * 12:00 - 12:10 Feature support detection + * 13:00 - 15:30 Issue triage + * 15:30 - 15:35 wrap up + + +## Attendees + + * Devlin Cronin (Google Chrome) + * David Johnson (Apple) + * Timothy Hatcher (Apple) + * Elijah Sawyers (Apple) + * Tomislav Jovanovic (Mozilla) + * Rob Wu (Mozilla) + * Anton Bershanskyi (Independent, remote) + * Carlos Jeurissen (Jeurissen Apps) + * Richard Worth (Capital One) + * Mukul Purohit (Microsoft) + * Oliver Dunk (Google) + * Andrey Meshkov (AdGuard) + + +## Meeting notes + + +### User Scripts + +Future enhancements of the userScripts API, including multiple worlds, inter-world communication, one-time script execution, and more. + + * [devlin] New capabilities in userScripts API: userScripts.execute, multiple user script worlds. Already referenced in the original userScripts API proposal + * https://github.com/w3c/webextensions/issues/477 + * https://github.com/w3c/webextensions/issues/565 + * [devlin] Another topic is inter-world communication. Recap is communication between multiple world, main world vs isolated world, userscript vs userscript, and any combination thereof. Current common mechanism is through the postMessage API. Extensions need to make an effort to capture the necessary APIs and hide the event from the other scripts in the (main) world. + * [rob] WRT postMessage, I want to call out that CustomEvent + dispatchEvent, the important part about this is that it is synchronous, unlike postMessage. + * https://github.com/w3c/webextensions/issues/77 + * [andrey] This is not about user scripts only, right? + * [devlin] Correct. + * [andrey] Event? + * [devlin] Don't think that the main world should be able to initiate a message. + * [rob] Shape of the API should have the content script pass a closure to the main world, with access to a private object or method for cross-world communication. Common way to hijack extensions is prototype hijacking. We should make that impossible. + * [devlin] ? + * [rob] Could fire an event. + * [devlin] Wonder how complicated it would be to block sending a message to the main world until resolution of the event. (...) + * [rob] Glad to hear you're considering synchronous responses as it's a long standing issue. + * [devlin] There are many prior proposals. One I like is … + * [rob] Wouldn't go that way. + * [devlin] Was thinking the API surface, not implementation. + * [rob] Would recommend + * [devlin] What considerations do we need for passing a message to a receiving world + * [rob] String methods, can be a common attack vector. + * [devlin] One time script execution may be relatively easy. Not sure how it would work with other types of script (js file). How would we expose the listener there? What prevents the main world from registering that listener? + * [rob] The code could be wrapped in an arrow function, and receive the communication mechanism through the function parameters. Main world code (of the web page) would not see that argument, unless the extension accidentally leaks that. + * [devlin] Say we want to do many worlds and content script execution, how do we know whether or not to wrap something in an arrow function for execution? + * [rob] This is mostly about the main world. + * [devlin] What about a content script in the main world? + * [rob] My understanding of a content script is that it executes in the isolated world, user script is in the user script world + * [devlin] I was thinking content script as in a bundled script, user script is dynamic + * [rob] New manifest key could be used. + * [devlin] Seems doable but clunky + * [rob] Don't want this for all scripts. Opt-in may be best. + * [tomislav] We may be trying to make the square solution fit in a round box in trying to make this work for files. Can we go back to globals? + * [rob] I'm open to other approaches that would prevent a variable from being leaked. Function closures, modules, etc. + * [devlin] Was focusing on files because it's a case we may need to address. + * [rob] As an alternative, add a new method to the isolated world to run a function in the main world. … + * [devlin] I get the idea of executing a …, but that includes exposing a handle, right? So if we serialize the function, we make exposing the handle part of the API. That seems viable. But if I have a 1k line file, how do I set up a function that …? + * [rob] I think developers are more concerned with having a way to do this. A large file is a nice to have. + * [tomislav] … + * [rob] As an example one of my extensions injects a script in the main world in order to know if some flags are set. In this case I'm not concerned about the hostility of the main world (e.g. prototype tampering). For extensions that are more privacy oriented that solution wouldn't work. We would need the handle-based approach we're discussing. + * [devlin] A few different pieces here. Synchronous execution of script in another world. The ability to add in another object to enable communication between worlds (message pipe of some kind). Are there any aspects not addressed? + * [rob] I don't think so. + * [devlin] Concerns with synchronous execution being able to execute in any world? That is, exposing this in both user script and isolated worlds and allowing any to communicate with any. + * [rob] User scripts not targeting isolated, but user scripts targeting each other. If someone wanted to create some user script worlds that are more privileged than others.. + * [devlin] That could be accomplished with the API we're discussing. + * [oliver] Can you clarify what the concern is with prototype modification? + * [rob] If we don't account for prototype hijacking, it would be possible for a main world script to modify an underlying prototype (e.g. Message.prototype.handle) and intercept every message exchanged. + * [oliver] Seems interesting because it seems like sending data to the main world at all may be dangerous. + * [rob] Userscripts aren't the only case. There are some situations where an extension may want to perform modifications in a page that require main world access, but + * [rob] Something that can be configured once wouldn't require this capability. Something + * [andrey] Unsure why we need to talk about synchronous message passing? We are trying to replace window.postMessage which is not. + * [devlin] We are talking about multiple mechanisms. Agree postMessage is not, but event dispatching is synchronous. + * [devlin] Note that chrome.dom.executeScript runs synchronously. + * [andrey] Should this be synchronous by default? + * [devlin] Don't see any concerns with that. + * [rob] Blocking while waiting for response is not a new problem, since this can happen with the dispatchEvent method getting blocked if an event dispatch is not immediately completed. + * [rob] The use case we are trying to solve is sending data safely between two worlds. + * [timothy] Could you clarify why we need the targetWorld parameter? Seems like this might be unnecessary given we pass to a specific world with executeScript. + * [devlin] I like having this because it makes it clear you cannot pass the port to multiple worlds. + * [rob] I think there is agreement on what API should do and should not do. We don't feel strongly about a particular API shape. + * [devlin] Agreed. We don't need to establish every piece but it is useful to agree on the type of approach we want to take. Prefer not to leverage message channels for example which would be a big difference and doesn't feel appropriate. + * [rob] We could also support return values from the onMessage handler. Something else we haven't touched is how we define the serialization of the arguments to executeScript. + * [devlin] Realistically from implementation on the Chrome side we would want to start with just JSON serialization. Limited but well known. In the future structured cloning and ideally transferables would be useful, including on other APIs. However this greatly changes the timeline within which we could ship this. + * [rob] It would also be nice if DOM elements could be forwarded without serialization. + * [devlin] Yes. Agree there is a use for this. Should be relatively trivial for developers to workaround. + * [simeon] Disagree for the average extension developer. + * [rob] You have to use the DOM APIs which could be hijacked. + * [devlin] For the first version we can agree to support a small number of values and look at changing this in the future. + * [tomislav] I don't like that we are introducing new APIs with JSON five years after we introduced structured clone in Firefox. We have some minor issues but other than these this is strictly better for performance, capabilities etc. + * [rob] Agreed. The API we're replacing (postMessage/CustomEvent) uses structured cloning already. + * [tomislav] Structured cloning is a web exposed API and closer to the web. Developers should be more familiar with this which alleviates other concerns. + * [devlin] Is there a risk of contamination between worlds? + * [tomislav] No, this is a deep clone and there is no ability to mess with prototypes. + * [devlin] I think we can probably implement structured cloning. Can have this as an initial target but will need to look into complexity. + * [rob] Next steps? + * [devlin] Need to write up a real API proposal that defines these different pieces. Can discuss more in WECG. Can loop in folk who have been involved in other threads. + * [tomislav] Timothy? + * [david] We can follow up. + * [devlin] Happy for Chrome to take on the action item of writing up the proposal. + * [devlin] I tentatively put these methods on the browser.dom API. + * [rob] This seems reasonable. When I described this capability at TPAC 2023, I also suggested this as an addition to the dom namespace. + * [devlin] Everyone ok with this? + * [tomislav] This won't match the API shape of extension messaging? + * [devlin] This will be different. + * [carlos] Yesterday we discussed a language dictionary proposal that also returns an object with methods. This appears to have a similar structure. + * [devlin] The complexity in that case arose because it was a return type from a browser-side API – those need to go through serialization. Here, the API is entirely on the renderer, so it's easier to implement custom types and handling (and we need custom code already). + * [patrick] Do we need a new permissions? + * [devlin] I don't believe so. + * [simeon] Do we want one? + * [devlin] I don't believe so. + * [rob] Do we want a way for the main world to receive additional data? + * [devlin] Assume we can transmit data onMessage on the port. + +A sketch of the API and usage was made during the above discussion. This is the final version of that sketch: + +```javascript +// Future work: structured cloning, transferables, DOM references + +// Port type TBD. Not a MessageChannel. +let port = browser.dom.createPort({targetWorld: 'MAIN'}); + +// This function will be executed in the other world synchronously. +// To make this operation async, use an async function. +function myFunctionInMainWorld(port) { + // NOTE: port prototype is not visible to the main world. + // This script executes in the main world. + port.sendMessage(getSomeMainWorldData()); + port.onMessage = () => { ... }; +} + +port.onMessage = (data) { + // Runs in the isolated world. + self.mainWorldData = data; +} + +browser.dom.executeScript( + { + func: myFunctionInMainWorld, // This runs synchronously + targetWorld: 'MAIN', + args:[port], + }); + +// Data is set because the `myFunctionInMainWorld` runs synchronously, +// dispatches the message synchronously, which is then received +// synchronously in `port.onMessage`. +console.assert(self.mainWorldData); +``` + + +### Embedding pages that don't want to be embedded + + * [oliver] Two parts. 1. Embedding pages that don't want to be embedded. 2. Embedding pages in a way that the page doesn't know it's being embedded + * [devlin] Chrome view here is that this fits within the model and makes sense as a feature. Not too worried about (1). On the Chrome side, we can selectively ignore the don't-embed signals. Not worried from a technical or security point of view. I am more worried about (2). There was some discussion of prior art that addresses similar concerns, e.g. webview, portals, etc. I don't know that we want to expose webview in extensions and I don't know that other browsers have that capability. + * [tomislav] We have a similar functionality and our platform team doesn't want to extend its use. + * [david] We don't have this. + * [devlin] Sounds like we don't want to extend/implement this. Challenge is that we end up creating something very similar to webview. Now, without 2 we could only address 1. + * [oliver] Not concerned with that, most uses I've seen are where the website doesn't want to be embedded in a website. + * [carlos] It's very hard to embed a page that really doesn't want to be embedded. + * [devlin] Unless you have a webview. + * [oliver] The simple option is to just ignore restrictions on iframes if you have host permissions. Is this enough, or are there problems with that that warrant something more? + * [devlin] That's the direction I'd lean, but curious if there are use cases where this break things. I'd prefer this to not be an opt-in. If we had a lever, it would be complicated. Per-origin? + * [devlin] Are there cases where an extension would want to respect a site's preferences? + * [carlos] Could use the non-blocking webrequest API to detect it? + * [devlin] Are there cases where we want to make it easy? I can't think of cases where we'd want to make it easy for an extension to say “don't embed this page I told you to embed.” + * [oliver] Sounds like it might be okay to not have this be opt-in. + * [rob] Can you recap? + * [devlin] I think we're aligned that we want to allow embedding if an extension has host permissions. Oliver raised the question of whether we can just do that or if we need an additional signal. + * [rob] Top-level documents OK. Would prefer to not do it by default in iframes. I'm afraid it could be too easily abused by web pages that exploit vulnerable extensions. + * [devlin] Good point. Taking it a step further, not just require opt-in, but maybe we should disable embedding like this in iframes. + * [oliver] So only allow this in cases where the top level document is on the extension's origin? + * [devlin] Allow embedding of frame independently of XFO, COOP, COEP etc., only when the full frame hierarchy above consists of same-origin and extension origins. + * [oliver] Is this feasibly implementable? + * [rob] In Chrome yes, the information is available for location.ancestorOrigins; In Firefox also possible. + * [oliver] Confused why there are security concerns with doing this for iframes and how this is different from stripping the X-Frame-Options header today. + * [devlin] It's not different. It's that the extension doesn't have to strip the header any more, which is a win for security (especially for e.g. csp-related headers) + * [rob] DNR/webRequest are generic APIs, where this capability is possible. In this case we're designing a new API that allows extensions to do what they want without compromising security. If use cases exist, I wouldn't mind an opt-in, but it should be off by default in iframes. + * [oliver] The impression I was getting was that we would never allow site -> extension -> site frame embeds. + * [devlin] Not never, would want strong evidence that this is a beneficial capability. It's possible for the top level frame to navigate a sub frame using iframe.frame.frame references. + * [rob] I've seen real world extensions vulnerable to this kind of attack. + * [oliver] Apple folks, thoughts? + * [timothy] Will need to talk to WebKit folks to explore this idea. Can't commit to anything right now. + * [devlin] In the cookie deprecation process in Chrome we did get some reports around samesite (I think) cookies not behaving as expected with nested frames. Could potentially start by saying it has to be embedded in the top level extension frame, has host permissions, and the limited frame hierarchy. + * [carlos] Would it be possible for an embedded frame to trigger a navigation to a frame you didn't want to embed? No. You can use frame-src csp on the extension. + * [rob] Are we going to move from this discussion to a proposal? + * [devlin] Think so, yes. + * [rob] When we do, we should detail exactly what features we want to bypass and handle. That would even make sense in general independently of this proposal; same-site / first-party / CSP bypasses, etc. are currently not well-defined across browsers when extensions are involved. + * [devlin] To recap, we are all on board (in principal) with this capability. We are not currently solving for embedding content that explicitly does not want to be embedded. Next steps are to write a proposal. + * [oliver] AI: I'll write the proposal. + + +### Icons: SVG + + * [devlin] SVGs are not supported in Chrome, are they supported in Firefox or Safari? + * [tomislav] Yes. + * [timothy] Yes. + * [devlin] We don't want to allow script execution. Do other browsers have a subset of SVG that doesn't permit script execution? + * [rob] SVGs can be rendered without scripting. SVGs in an `` do not execute code, when loaded as a document it could execute code. + * [tomislav] SVGs can be rendered in a separate process. + * [devlin] You render in a sandboxed process? + * [tomislav] I believe so. + * [devlin] I assume this also means you don't support dynamic SVGs. + * [tomislav] No. Same rules as for an image. + * [timothy] Same. Just the drawing parts of SVG. + * [devlin] Have you received bug reports about insufficient support for SVG capabilities? + * [tomislav] We've had requests for capabilities like dark mode. + * [patrick] Is it worth making sure we have the same subset? + * [tomislav] It's the same support as if you put an SVG in an img tag. I believe that's consistent across browsers + * https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:document-element + * [rob] Most SVG users want the scalable vector aspect of it; while some may also want automatic adoption to dark theme etc., that does not need to block support for SVG. + * [devlin] Timothy, were there more aspects that you wanted to discuss about this? + * [timothy] Cross-browser support for existing SVG support. + * [tomislav] Forgot that SVG supports declarative animations. + * [devlin] Is that supported? + * [timothy] Not in Safari. + * [tomislav] I think so. + * [rob] I'd say that we explicitly support static SVGs, without explicit support for animated SVG. Any existing support for animations is accidental and not guaranteed. + * [devlin] I think on the Chrome side supporting the subset of SVG that does static rendering of an icon should be do-able. Even with SVGs, I think it makes sense to have different keys in the icon dictionary. At different sizes you may have different rendering expectations. + * [patrick] SVG has the ability to have multiple different images that display at different sizes. Not saying we shouldn't support multiple breakpoints in the manifest, but that we should be able to also use a single SVG if so desired. + * [devlin] That makes sense. + * [mukul] Is that (defining multiple sizes in the manifest) already supported in Firefox? + * [carlos] Firefox supports. + * [timothy] Safari supports both, so you can declare both SVGs and PNGs. Basic styles are supported. We don't use WebKit SVG for this. We use the system's SVG parsing support. + * [patrick] Same support as for desktop icons? + * [timothy] Yes, same support as used for SF Symbols + * [devlin] Need to do some exploration on the Chrome side for what we could support. Scripting is out, but would like to explore stylesheet support. + * [mukul] We can explore this. + * [devlin] Great. + * [rob] You can pass a hash to select a specific area of an SVG. This code snippet shows the same image with different colors. If we were to support this explicitly, it could reduce the number of SVGs they need to create. Is this something we would support? + * https://github.com/Rob--W/bookmark-container-tab/commit/afd4aa5165d91b69841df2899ff615795417a0ad + * [timothy] Not sure if our implementation supports this. + * [devlin] Suspect that on the Chrome side we'd have very limited support for SVG. + + +### Icons: Dark Mode + +[Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icons for Light/Dark/Custom Theme + + * [timothy] Wanted to check in on this. We haven't begun implementation yet. + * [devlin] My recollection is that we had a proposal from quite a while back, and that there are no open questions. Is there anything left to do? + * [oliver] That matches my recollection. + * [timothy] I think we all largely agreed. Think we should proceed with that proposal. + * [rob] No objections. Someone just needs to implement it. + * [tomislav] Patches welcome. + * [devlin] Brought up themes when we were first discussing this and it's much harder. Custom themes in the browser don't typically have a great way to decide whether to use light or dark. One idea we discussed was giving extensions access to the theme color to let them decide how to handle the theme colors. We started with light and dark because we expected that would give developers most of the benefit. + * [carlos] Potential solution is to have the default icon be generic, use light/dark when the setting is more clearly one extreme. + * [devlin] That rings a bell. + * [carlos] I think I brought it up in the issue discussion. + * [devlin] I think that makes sense – light, dark, default fallback. + * [rob] Does the existing Google Doc capture the latest proposal? If not, then we should create a proposal with our new proposal process to document the latest state of the proposal. + * [oliver] We previously discussed having a light/dark in the icons manifest key, but that would be a hard error in earlier versions of Chrome. Introduced the idea of a icons_variant key to address this. + * https://github.com/w3c/webextensions/issues/229#issuecomment-1877038396 + * [carlos] Is there a way to update icons programmatically, to replace what is in the manifest? + * [devlin] That's one of the pieces we were planning on following up with. Would hope that would be a fast follow (but this hasn't been going fast so maybe just follow up). + * [oliver] Suggest creating an updated proposal to capture this. + * [devlin] Rob also suggested this. We should. + * [timothy] All black icons have given us some amount of light/dark mode support. + * [oliver] I've found this behavior hard to work with. First creating an icon, then trying to reason about how to convert that into an all-black icon. + * [patrick] I think Timothy was suggesting we potentially support this in addition to other approaches. + * [oliver] In Safari, if you only specified the light icon and it was pure black, would you auto-generate the other style? + * [timothy] Not sure. Seems like the extension developer is explicitly indicating something in that choice. + * [devlin] On the Chrome side we would not prefer that, and instead just add the dark key. + * [tomislav] Keep behavior of existing things, but no magic for new things. + * [devlin] Action item is to write up a refreshed proposal using the new process to capture the changes we discussed here. Are we also on board with exposing these keys to action.setIcon? + * [rob] Yes. All APIs where it makes sense. + * [devlin] Explicitly calling those out as potential future work or as part of the same proposal. Then, we just have to actually do it. + * [devlin] I'll ask Solomon (the original Googler who authored the proposal). + * [carlos] What about other areas where extensions are used? E.g. notifications. + * [rob] Suggest handling these on a case-by-case basis. + * [carlos] But they're related, right? + * [rob] In the case of the notifications API specifically, the way Chrome and Firefox are implemented, we pass the icon to the system for rendering. The browser's handling of icons may not match what the system does. If you want dark mode handling of notifications, it may be better addressed in a separate proposal. + * [devlin] Settings page in Chrome has dark theme support, in that case we would select the dark/light mode of choice. + * [carlos] You're saying that dark mode icons would also be handled from the icons field in the manifest? + * [devlin] Yes. + + +### DNS API + +[Issue 570](https://github.com/w3c/webextensions/issues/570): Inconsistency: dns.resolve() + + * [andrey] What about bringing Chrome DNS API to extensions? + * [devlin] Security team previously had concerns. + * [andrey] Why? + * [devlin] Accessing local DNS is my recollection. + * [tomislav] If you're in an enterprise, using public DNS can't reach in to scan the user's environment. With this you can see private DNS results. + * [andrey] Why is that not an issue in Firefox? + * [tomislav] It's also an issue for Firefox. The problem is we don't always know what a local address is in an environment. + * [andrey] I don't follow. + * [tomislav] Exposes IP addresses of devices on the local network. + * [andrey] … + * [rob] I see a potential solution if security is the concern - would the use of public DNS servers by the API address your use case? + * [andrey] We would prefer to use the user's DNS and not public DNS, because the latter would not be accurate. Can't always rely on public DNS services as they may be blocked. There are a number of issues here. Scanning of local network can be prevented or limited at the API level. + * [oliver] can you explain the use case? + * [andrey] Simple example is how it's used in uBlock Origin: checking if a domain name is an alias for a known tracker. + * [patrick] What's a use case that shows why public DNS is unreliable? + * [andrey] Implementing the uBlock Origin's CNAME blocking feature using Google DNS in China. Can't expect that every extension developer will run their own DNS over HTTPS server. + * [oliver] With the DNS API, would you be able to handle CNAME masking, even without the blocking version of the webRequest API? + * [andrey] The other thing we use with DNS is service discovery in our VPN extension. + * [devlin] What kind of discovery? + * [andrey] In the VPN extension we query DNS to figure out which backend server can be used at this point. Using public DNS services might not work due to blocking, but accessing user's DNS is more reliable. + * [devlin] If we exposed the DNS service that's currently implemented in Chrome, would that address your use case? + * https://developer.chrome.com/docs/extensions/reference/api/dns + * [andrey] Yes, I think so. + * [devlin] And you don't need access to browser.mdns, correct? + * [andrey] No, we don't need that. + * [oliver] I don't fully understand. Could you not just do an HTTP request to find if the device is there? + * [andrey] Point of DNS is that it's not centralized. If we do a fetch request, we need to point it somewhere. If we do that, the server could be blocked. + * [oliver] Say you do a fetch request for 5 domains and you only get a successful request for 1, you know that 1 is unblocked. + * [andrey] We would have to cascade our DNS resolution attempts. + * [rob] Back to the security issue, the webRequest API already offers the IP address of the server that served the response. What makes this different? + * [devlin] My recollection is that DNS exposes more information about the intranet the device is on. In enterprise environments, we allow admins to lock down resolution of HTTP requests, but not DNS. + * [andrey] I don't see how it allows additional scanning. ? What if we limited by host permissions, for instance. Only resolve DNS request for domains for which you have host permissions. + * [devlin] I would have to ask the security team. One the reasons I asked about mdns is that one is \*very\* scary. + * [rob] mdns is different. + * [rob] There's a difference between dns.resolve() in Firefox and Chrome. Would you consider adopting Firefox's signature before shipping dns.resolve from dev to stable release? + * [devlin] what's different? + * [rob] dns.resolve in Chrome returns an object with “address” and “resultCode”, Firefox may accept an optional additional object and returns an object with “addresses”, optional “canonicalName”, “isTRR”. + * https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve + * https://developer.chrome.com/docs/extensions/reference/api/dns#method-resolve + * [devlin] And they're both called “resolve?” + * [rob] Yes. + * [devlin] Dang. This API is also used by platform apps, so we can't change it without risk of breaking someone. If we can find a way to address this in a backwards compatible way, then I'm open to further discussion. + * [rob] There is a way to have a backwards-incompatible signature. + * [devlin] I am open to considering it. + * [andrey] I will open a WECG issue. + * https://github.com/w3c/webextensions/issues/570 + * (end of online+in-person part; the rest of the day continues in-person) + + +### Proxy API + +[Issue 573](https://github.com/w3c/webextensions/issues/573): Inconsistency: proxy API + + * [andrey] Many extensions use proxy APIs but there are large inconsistencies between Chrome and Firefox. Firefox is more advanced but maybe not fitting with MV3. Firefox has proxy.onRequest that enables extensions to asynchronously respond with how a proxy should be handled. Chrome either has a limited declarative API, where one thing is missing. There is also an option to configure a PAC script, but the inconsistencies are still there. We could use the same declarative approach there if there was an option. I don't mind the API, as long as the capabilities exist. In Chrome there is only a bypass list. If there is a “no-bypass” list, i.e. inclusions and exclusions, then that would cover our needs. There is a popular extension SwitchOmega that tries to emulate the inclusions and exclusions list, and had to remove the feature from the extension. + * [rob] Why? + * [andrey] Removed the PAC script. I don't know why. Anyway, if we had a capability across browsers to specify the inclusion and exclusion lists, then we could use it. + * [andrey] Extensions in Chrome use the PAC script, in Firefox proxy.onRequest + * [devlin] So you're basically asking for the inclusion list or a new API? + * [andrey] Yes. + * [devlin] Adding support for an inclusion list seems much simpler. + * [devlin] We're not deprecating the proxy API, but aren't adding much functionality to it. Open to inclusion lists. + * [andrey] Is it possible to have similar API and support inclusion lists? + * [oliver] There was recently a CL to add a bypass list to PAC scripts. + * https://chromium-review.googlesource.com/c/chromium/src/+/5227338 + * [andrey] PAC scripts is not an issue, can embed the bypass list there. + * [oliver] So you're referring to cases where the PAC script is not used? + * [andrey] Would be nice to have a common API so that we don't have to maintain two separate versions of extension code. + * [devlin] In terms of finding a more consistent API, is the primary ask that the API have the same names and properties etc., or to add the features to Firefox that Chrome doesn't? + * [andrey] Feature-wise, just inclusion list in Chrome, the other thing is a common subset of API in Firefox. + * [tomislav] Hesitant because that would be the fourth way to specify a proxy. Not sure if there is more use in it. + * [rob] The request is a declarative API. This would eliminate the need for proxy.onRequest. The proxy.settings API that we have applies globally without a filter. The requested declarative API can be more scoped. + * [tomislav] Do you know why we did not support the declarative API back then? + * [rob] Because it did not fulfill the full use case of proxy extensions. + * [tomislav] And it does now? + * [rob] With the addition of inclusion list, yes. + * [andrey] Removing the old API would be undesirable because it is more powerful and may be needed in some cases. + * [tomislav] We may need to remove some APIs eventually since we can't indefinitely maintain APIs when there are better ways of doing things. + * [rob] Andrey, would you be open to writing a patch? + * [andrey] Potentially, we can look at this. + * [andrey] Would Apple provide a proxy API? + * [david] We don't have plans to work on this. + * [tomislav] Would you want to be consulted on API design? + * [david] We will contribute as we see things opened. + * [andrey] We need an issue. Who will open this and where? + * [tomislav] We should have the API proposal opened in the WECG. + * [andrey] We can look at this. + * [rob] Are there parts of the chrome.proxy API that Chrome is considering to deprecate? + * [devlin] Not at the moment. + + +### Browser specific namespaces + + * [devlin] To recap, we've discussed a number of times an idea that APIs that are Chrome specific should be exposed on chrome, whereas APIs exposed on browser are the reliable, cross-browser ones. I'm not in favor of this since previous attempts like prefixing in CSS have not gone well. Don't think it makes sense to use a prefixed API set. + * [tomislav] Agreed. If one browser implements a specific namespace, that's fine. But how do we handle collisions in permissions or namespaces? + * [devlin] Going forward, new APIs would be raised in the WECG where we can catch collisions early. Individual fields in APIs that are browser-specific simply be supported in some browsers and ignored in others. Incompatibilities in the same method (e.g. addSiteAccessRequest) should be discussed at that time. + * [oliver] All browsers have at least one of the browser and chrome namespaces, there is history of adding private / non-standard APIs, and we don't hit the issue at the moment. May be premature to try and solve this. + * [tomislav] So do we bring every new extension API in the WECG? + * [devlin] Any (new) extension API should be discussed in the WECG. Might be worth documenting that the `*private` naming pattern is reserved for internal use. + * [tomislav] E.g. dns API. + * [devlin] These collisions happened before the WECG. + * [devlin] There is one area that may be worth noting: ChromeOS often has Chrome OS-specific APIs for enterprise installed extensions. So far have not brought to the WECG because these are out of scope for the WECG, potential risk for collisions there. Not sure if we can do something there. + * [andrey] Can there be a list of reserved namespaces? + * [devlin] We (extensions) cannot dictate what is or is not exposed on the `chrome` global. + * [andrey] I meant no secret namespaces. + * [rob] Chromium, Firefox, and WebKit all expose the namespaces they implement publicly. Suggest that whenever we introduce a new namespace, we check to make sure there's no collisions. + * [devlin] Whenever we bring something to WECG, we'll make sure there's no collision. Note that this wouldn't apply to other consumers of the chrome namespace, like ChromeOS (since these aren't usually WebExtension APIs). We'd be sure to work with them to avoid naming collisions. + * [rob] WECG would maintain a list of our namespaces. If Firefox or Safari introduces a new namespace, if we reserve it, then (e.g.) ChromeOS would not be able to use it. Browsers could regularly synchronize this list with their unit tests. + * [devlin] How do we do that without WPT? + * [simeon] Scripts that crawl browser source? + * [devlin] Haven't seen a human-maintained system that's consistently up to date. + * [tomislav] MDN? + * [devlin] Good, but not perfect. I think we're all aligned that we're not going to try to interfere with each other. I have no objection to creating a list, but I do worry about our ability to keep it up to date and act on it. + +Feature support detection + + * [andrey] Can we look at this from another step further. We're basically doing discovery of what's available and what's not, and that's not always reliable. Different browsers sometimes make things unavailable in different ways. Sometimes even in Chromium forks. Can there be a way to indicate availability of a given API in a consistent, cross-browser way? For example, supports() in CSS. + * [devlin] Can you elaborate on why feature detection doesn't work? + * [carlos] For example, detecting if there are features that don't work on the windows API giving the pairing of normal and private windows. + * [timothy] On mobile on iOS, windows.create, windows.remove are not defined. + * [] (...) a way of detecting whether APIs are supported. + * [rob] Don't think this is that big of an issue. We have the conventions of throwing. + * [carlos] Some browsers throw, some leave properties undefined. Maybe we can align more on the expected behavior when something isn't exposed. + * [rob] And sometimes we have methods/events that are not undefined because extensions that expect them to be present break if they were to be undefined. + * [rob] Similarly, a new method would report such inconsistent answers or offer a different source of truth. What would be the benefit of a new method to detect feature support? + * [carlos] Point is that browser use different approaches + * [devlin] And multiple methods for indicating whether something is supported within a single browser + * [carlos] Exactly. + * [devlin] Can generally assume it will be undefined if not available. But we can't always use that approach. For example, executeScript … + * [tomislav] Are you actually asking for a more explicit approach, like CSS supports? + * [carlos] Not exactly. + * [tomislav] mdn/browser-compat-data keys can be nested in order to enable more specific queries. + * [devlin] We already have some infrastructure for that in Chrome. + * [rob] Tom was describing a way to have a standard identifier that could be used to query support. With the userscripts API Chrome will throw if the extension tries to call but doesn't have access. + * [devlin] Specifically, if the extension has the permission but the user is not in developer mode. + * [carlos] 3 errors: didn't request permission, isn't in developer mode, permission isn't supported. + * [rob] I think we've discussed the problem in sufficient detail, would we be interested in pursuing this? + * [devlin] Open to it. + * [rob] We (Firefox) would be interested too, right? + * [tomislav] Nods. + * [simeon] Does Chrome support checking properties on an options bag that were introduced later? + * [devlin] It depends on the API, but it's something we could add. + * [devlin] I think we can say we're all generally supportive, and that a proposal is welcome. + + +### Issue triage + + * [Issue 12](https://github.com/w3c/webextensions/issues/12#issuecomment-942826300): request: allow to retrieve a frameID from an <iframe> element + * [devlin] We've already talked to it; short version was it got stuck and we need to talk with security about it. + * [oliver] I'm assigned to it. + * [Issue 91](https://github.com/w3c/webextensions/issues/91): Proposal: scripting.executeScript without specifying tabId + * [devlin] The request here is to specify only a frameId for certain methods like executeScript. + * [rob] How about documentId? + * [devlin] Specifying document ID or non-zero frameID are feasible on the browser side. We can't do frameId 0 because that always maps to "the main frame" in a tab and is repeated (goes into history of that decision) + * [rob] Frame ID 0 are ambiguous, but non-zero are not, and globally unique now, correct? + * [devlin] Correct. + * [rob] In Should we specify that behavior? + * [devlin] Are they unique in all browsers? They are in Chrome. + * [rob] In Firefox too. + * [timothy] Safari too. + * [timothy] In Safari the main frame has a unique frameId, and if passed instead of 0, it would also work. + * [devlin] How would you know the unique frame ID? + * [timothy] You wouldn't. + * [carlos] Add a method to retrieve the frameId for the top level. + * Request for unique frameIds: https://github.com/w3c/webextensions/issues/90 + * [devlin] Would be hesitant to do that for main frame since we know extensions rely on frameId 0 today + * [oliver] The implicit assumption here is that if you had a way to specify frameID, you would be able to execute in a popup since this already works. Is that the case? + * [devlin] Declared content scripts run in popups, I don't see issues from the permission perspective. + * [oliver] Same in Firefox and Safari? Being able to run content scripts in frames in popups + * [timothy] Yes. + * [devlin] A couple different use cases here. Iframes in popups. In that case you don't need the main frame. To message the main frame of a tab, would prefer to revisit ideas about contextID rather than using frames. + * [carlos] Another use case is replacement for postMessage API across frame boundaries. + * [devlin] We should be trying to unblock, but have covered 3 different cases. In the issue of focusing on 91, let's proceed with the assumption that we're not changing frameIDs. + * [devlin] In favor of supporting non-zero frameIds and omitting tabId, or any documentId . Request here is not requiring a tab ID. + * [rob] <missed in minutes> + * [tomislav] You need a magic number to mean ignore tab ID. + * [rob] Would need to make non-main-frame frame IDs globally unique. + * [devlin] Need to make that assumption. -1 doesn't specify where the frame is. So don't need to specifically add -1 as a tab ID since it already has to be unique across multiple potential contexts (e.g., multiple popups) + * [rob] Specifying -1 means we only need to look at certain contexts + * [devlin] That's only an optimization, doesn't allow us to avoid the uniqueness guarantee. If impl doesn't guarantee unique IDs across documents, that doesn't address the issue. + * [rob] Agreed. So to recap, support any of the following combinations: + - require tabId + frameId 0 + - Non-zero frame ID (tabId not required) + - documentId (tabId not required) + * [devlin] I will write up a comment in the issue to outline what we've discussed. + * [carlos] Should we create issues in browser bug trackers? + * [devlin] Sure. + * [Issue 34](https://github.com/w3c/webextensions/issues/34): Request: high precise timer + * [oliver] Seems to be two parts to this request. 1) smallest amount of time for a repeating alarm 2) potential delay when an alarm fires. Note: this issue says 1 minute minimum. Chrome recently changed to 30 seconds. + * [rob] Is there any reason why browsers wouldn't want to allow 1 second resolution? + * [oliver] This resolution is different between packed and unpacked. + * [rob] Firefox allows millisecond level resolution, it's not fully intentional. + * [timothy] Currently safari is 1 minute. Would be supportive of changing to 30. + * [oliver] What about 1 second? + * [timothy] That would likely work. + * [devlin] Historical reason for 1-minute timer is lot of trashing in the timer; introduced throttles in extension and web to reduce performance impact. We saw a quantifiable performance gain when we increased the minimum to 60 seconds. We later reduced this to 30 seconds (for service workers) because 60s and 30s aren't that different from a performance perspective, but 1s or lower _is_ significantly more detrimental. Use setTimeout for anything lower. + * [andrey] ? Talking about a need from a very small number of extensions. Example in the thread was tracking time in tabs. + * [rob] An extension can combine alarms and setTimeout to accomplish this goal. + * [andrey] Is it reliable? + * [oliver] You could have a 30 second alarm, then have a setTimeout every second to do the time tracking. + * [oliver] A comment suggesting that it may not work as expected as the Alarms API may have up to a 30 second delay. + * [devlin] Not what we would expect – that should be a very rare case. It may happen, if e.g. the OS is trashing, but then there's nothing we can do to help. + * [patrick] And it wouldn't be fixed by having a high precision timer. + * [devlin] Indeed. + * [patrick] My mental model is that alarms is for making sure you can run at some time in the future. It's not for exact times. + * [devlin] Exactly. + * [timothy] I'll update Safari's implementation to lower from 60 to 30 seconds. + * [rob] Let's close the issue. + * [Issue 26](https://github.com/w3c/webextensions/issues/26): Features exposed by both a browser's UI and the WebExtensions API should behave the same + * [devlin] Recap, issue requests that tabs.create() behaves the same as clicking the new tab button in the UI. Tomislav left a comment expressing concern about linking UI functionality directly to extension APIs. I agree, and would suggest we close the issue. + * [oliver] I think we all generally agree that tabs.create should open the same new tab. + * [patrick] That we shouldn't be introducing new behavior for no reason. + * [devlin] Agreed. + * [Issue 244](https://github.com/w3c/webextensions/issues/244): Better status labels for issues + * [rob] Let's close it. It was accidentally re-opened. + * [carlos] Agreed, let's close and move on. + * [Issue 272](https://github.com/w3c/webextensions/issues/272): Proposal: browser.alert.create() + * [devlin] Do you still need this if we were to support action.openPopup + * [carlos] Created this for other people requesting this functionality. I don't personally have much need for it. + * Tabled for later. + * [Issue 301](https://github.com/w3c/webextensions/issues/301): \_execute_action, \_execute_browser_action and \_execute_page_action commands + * [tomislav] This is a bug, has been fixed in Chrome. We have a bug on our issue tracker. This is not a spec issue. + * [Issue 382](https://github.com/w3c/webextensions/issues/382): Provide a mock way to test upgrade extensions from the extension store + * [patrick] Store behavior is out of scope. + * [rob] Yes, but this is not about the store, but testing generic update behavior. Currently documented on a per-browser basis. I think that we can close the issue though. + * [david] We've heard requests for this. We intend to explore it. + * [oliver] Would be nice to have an API method to simulate an extension update. + * [devlin] Can't put that on a button. Drag and dropping a CRX in Chrome also supports this. + * [oliver] Yeah, a bit of a clunky process, though. + * [devlin] I think we're all agreed that the extension store aspect of this is out of scope, but what do we want to do with this? + * [patrick] I'll reply & close out. + * [Issue 326](https://github.com/w3c/webextensions/issues/326): Any plans to implement "tab" context menu? + * [david] Not yet in STP. + * [timothy] Right, implemented but not shipped yet. + * [devlin] It is currently tracked in Chrome, personally supportive, may work on it in the future. + * [rob] Thanks for the clarification, I've labeled the issue. + * [Issue 279](https://github.com/w3c/webextensions/issues/279): User scripts in Manifest V3 + * [devlin] User Scripts API – this is implemented. Close it? + * [andrey] Not implemented everywhere. + * [rob] I have a comment at the top that I update whenever there are changes to the userScripts API proposals. + * [devlin] I'll add a comment & add the implemented: chrome label. + * [Issue 250](https://github.com/w3c/webextensions/issues/250): Current permission system and API design forces developers to create inefficient extensions + * [devlin] Doesn't seem like a short issue we can quickly triage. Next steps? + * [andrey] Ask Anton to break up the issue? + * [patrick] I'll comment. + * [Issue 101](https://github.com/w3c/webextensions/issues/101): META: background scripting + * [carlos] Can be closed now, many of the issues are tracked separately. + * [Issue 138](https://github.com/w3c/webextensions/issues/138): Proposal: let content scripts listen for event chrome.runtime.onUninstalled + * [devlin] I understand the purpose and don't know if we'd do it. Generally we want to limit the amount of information we expose to the render process. There are workarounds for not having this feature, but they're not ideal. Oh, take that back, this would be fine since it's only exposing _that_ extension, not any extension. + * [rob] No new capability here. Extensions can already detect it: APIs become inaccessible, which can be detected. + * [devlin] Agreed + * [andrey] Could introduce a new error type that would be thrown in the page to detect that an extension has been removed + * [devlin] Prefer the proposal as described modulo naming. + * [patrick] Sounds like we're open to discussing, yes? + * [devlin] Yes. + * [devlin] Would probably want to use something like onUnloaded to catch other cases like the extension being disabled. We're also looking at the related onLoaded event. + * [timothy] I'd be supportive of this. + * [andrey] Would you also support an event when the SW is unloaded? + * [timothy] I wouldn't want to. It will wake up next time you send a message. Doesn't seem eventful. + * [andrey] Naming is unclear then. + * [rob] Should fire when the content script context is unloaded, not tied to extension unload. + * [devlin] Next steps: conceptually supportive; need a concrete proposal. + * [Issue 466](https://github.com/w3c/webextensions/issues/466): Proposal: allow storing metadata in a static ruleset + * [andrey] Would like to store additional data in the DNR file for every DNR rule. Rules aren't written by hand, they're derived from filter lists. Chrome doesn't currently error when additional data is included, but ideally we would have a formally supported way of adding this data. + * [andrey] Initial motivation for this proposal is fasttrack review by CWS. Extension updates are fast tracked when the only changes are DNR static rules changes. We need to be able to maintain the association between the initial DNR rule list and the modified list updated post-install. + * [rob] Why do we need a new API for this? + * [andrey] Not a new API. + * [rob] Why not have this data in a separate file and have CWS consult that during review? + * [devlin] Untenable. We need to be able to detect DNR-only changes in an automated way and having other arbitrary files change is incompatible with that. + * [andrey] Cost to fetch this file on every extension every day is prohibitively high. + * [devlin] Can you address this through a JSON comment? + * [simeon] JSON doesn't support comments. + * [devlin] We do in Chrome. + [oliver] Could use “\_comment” as a key. + * [devlin] Would that work in Firefox? Andrey's comment indicates that an unknown field in a rule causes a rule to be ignored. + * [devlin] Sounds like we have 3 different behaviors. (1) We error and refuse to load the extension. (2) We ignore the rule. (3) We parse as much of the rule as we can. We're agreed that (1) is bad and goes against the direction we've been moving with accepting unknown keys. It sounds like FF does (2) and Chrome does (3). + * [timothy] Safari follows behavior 3. + * [andrey] + * [devlin] There are cases where either might be desirable. Adding a new condition that narrows a rule, and the condition matches too much content in browsers that don't support the new field. + * [rob] I'm willing to consider accepting otherwise valid rules with unknown keys. + * [devlin] Could have a well known field we all choose to ignore. + * [rob] E.g. “comment” + * [oliver] I like “metadata”, but that name does imply it's, well, data, not a comment. + * [andrey] “\_comment”? + * [devlin] A \_ prefix normally means reserved by the browser. That's the opposite of this case. + * [carlos] Someone suggested “userdata” + * [timothy] Does not like “userdata.” In favor of “metadata” or “comment” + * [devlin] suggest “comment”. "metadata" seems more likely to be a "real" part of the rule considered by the API. + * [patrick] If someone uses runtime.getManifest in Firefox today, would “comment” be included? + * [rob] No, that property would be discarded. + * [devlin] Out of scope. + * [rob] Relevant in that it's JSON normalization behavior. + * [oliver] `_comment` is a common convention. + * [patrick] FWIW, I have seen `__comment` (double underscore) + * [rob] Is the value always a string? + * [andrey] Anything would work; if a string we can serialize its value. + * [simeon] Does the key matter? + * [devlin] No. Just trying to understand ecosystem conventions. + * [oliver] Note that this field could be abused to load code. Also note that DNR rule files may become very large. + * [andrey] That's somewhat unavoidable. + * [oliver] You may have lots of DNR rule files in your extension, but you only need the metadata for the rules that are enabled. Another implementation could allow you to dynamically fetch this data. + * [devlin] We should work with our respective stores on this. + * [devlin] I see you have a couple of examples of the comment/metadata. Are these representative? + * [andrey] yes. + * [devlin] Then it isn't scaling the size significantly. + * [andrey] I'll add a comment. + * [Issue 441](https://github.com/w3c/webextensions/issues/441): Is there any interest in creating extension-specific test harness like the WPT one? + * [devlin] Is there any interest? Yes. But this is just a tracking bug. Patrick, thoughts? + * [patrick] I'm not a big fan of tracking issues. If this was my repo I'd close out. + * [simeon] I'm comfortable closing. + * [oliver] I'll close it out. + * [Issue 58](https://github.com/w3c/webextensions/issues/58): API to get organizational domains using public suffix list + * [andrey] Duplicate. + * [patrick] Discussed 231 yesterday. Technically this is a duplicate of that. + * [Issue 87](https://github.com/w3c/webextensions/issues/87): Specify declarativeNetRequest rules + * [devlin] Timothy, how accurate is this? + * [timothy] There are still some differences. We convert urlFilter into regExps under the hood. + * [timothy] I'll update and close out. + * [Issue 467](https://github.com/w3c/webextensions/issues/467): Proposal: change the static ruleset JSON structure (DNR format) + * [andrey] Current structure of the JSON file doesn't allow adding additional metadata about the ruleset. + * [devlin] Right now we're handling rulesets though the declarative_net_request key in the manifest. Could also see that data being handled in the file itself. Do you see a strong reason for having this information in the ruleset file itself rather than in the ruleset section of the manifest? + * [andrey] Not a high importance issue, but canonically you tend to put structured data in the file. + * [devlin] My intuition is that it's too late to tell developers to make this change and tell developers to move. We could perhaps accept both an object and an array. If there's no driving reason, questionable as to whether we should. + * [rob] Why not add a dummy rule containing this data? + * [andrey] Broader issue is that if we ever need to extend this spec it would be easier to do with a top level object than an array. + * [devlin] If we were starting from scratch I'd do this, but given that we're not I think this is low on the stack rank. I'm inclined to close this and explain that we'd be open to revisiting it if/when there's a concrete need. + * [rob] Question about metadata. You can currently fetch it. + * [andrey] It's expensive to fetch a JSON file. + * [rob] There's no API to expose the comments. + * [andrey] Ah, I see. Yes, there's no need for an API. + * [rob] My expectation is that we'd ignore the unknown rule. + * [devlin] I'll write a very nice comment & close out. + * [Issue 179](https://github.com/w3c/webextensions/issues/179): browser.secureStorage: Document user-gesture requirements + * [oilver] This was a proposal in the proposals directory. This was about editing that, but that isn't going anywhere at the moment. I'm inclined to close it. + * [Issue 449](https://github.com/w3c/webextensions/issues/449): Provide way of handling unsupported DNR rules + * [andrey] sammacbeth had some good additional information on this. + * [oliver] Yeah, that was added at TPAC. + * [andrey] Is the intent to have the same behavior in every browser? + * [oliver] I believe so. As well as having consistent behavior, it would be nice if there was a programmatic way of determining if rules in your ruleset weren't loaded. + * [rob] I think the intent of DNR was to catch invalid rules during development. + * [oliver] Yes, but there are cases where a rule may only be supported in certain versions of a browser. You may want to detect and react to those situations. + * [simeon] Next steps? + * [andrey] Seems that the only difference is that Safari ignores duplicate rule IDs while others don't. + * [timothy] Is that true? That doesn't sound right. + * [andrey] That's what Sam's test results show. + * [andrey] Since Chrome's behavior is the most strict, what happens if we push an update with invalid rules and it somehow makes it past review, what happens? + * [rob] In Firefox we try to avoid failing to load the extension if there is a non-fatal error. + * [andrey] Would be generally better if Chrome didn't error. Devlin? + * [devlin] I think we're all collectively moving away from hard erroring. Is there a reason we would expect extensions to have duplicate rule IDs, or is the concern just that fatal errors are scary? + * [andrey] Just that fatal error is scary. + * [devlin] Understood. + * [oliver] Do we see a need for isRuleSupported()? + * [timothy] I'm supportive. + * [rob] Same. + * [devlin] Oliver, add a comment and if we don't have a crbug create one? + * [oliver] Yes. + * https://issues.chromium.org/330579934 + * [Pull 562](https://github.com/w3c/webextensions/pull/562): Browser specific “needs triage” labels + * [rob] Was approved by all, just include the “engine” word. + * [simeon] Merged the suggestion. + * [rob] Merged PR. + * [Issue 440](https://github.com/w3c/webextensions/issues/440): Proposal: add dictionary operations to DNR modifyHeaders + * [carlos] Currently there's no way to easily modify existing headers, so developers strip them. + * [devlin] We discussed this at TPAC 2023 and Ad Filtering Dev Summit. Unlikely to do this due to additional complexity and security / performance risks. + * [andrey] What risks? + * [devlin] In order to do this, we have to parse and modify rules as described. + * [andrey] You already parse them? + * [devlin] In “the browser” as a whole, yes, but not where we're executing rules. Parsing is expensive and we can't do it with untrusted data. So we'd need to do this asynchronously in a sandboxed process, which then has performance hits. And this is a lot of complexity. + * [rob] I'm worried about the complexity of 440 for general cases. Recognize the value of specific headers such as Content-Security-Policy, but think that a dedicated API (not necessarily part of DNR) would make more sense. + * [timothy] No objection to closing. + * [devlin] I will close nad add a comment + * [Issue 439](https://github.com/w3c/webextensions/issues/439): Proposal: Add filter for DNR modifyHeaders + * [andrey] This implies that there's a modification using a regular expression. Given how sensitive browser reps are to performance, would that also apply to + * [devlin] I think we're supportive, will add a label. + * [timothy] Would likely be able to do this as well. + * [andrey] I assume these would count against regexp rule limits? + * [devlin] Ideally we'd avoid introducing additional constants (there's already too many), so yeah, maybe applied to the existing regexp limit. + * [rob] What syntax engine should we support? + * [devlin] We'll use RE2 + * [timothy] We would probably use something (closer to) the JS RegExp engine. + * [rob] Same in Firefox - JS RegExp. + * [andrey] Do you have a limited RE engine in Firefox? + * [rob] We could have one if we wish. + * [rob] I'll add a comment. + * [Issue 342](https://github.com/w3c/webextensions/issues/342): Create an API proposal template + * [devlin] Can be closed. We already have one. + * [rob] I'll close, fixed by https://github.com/w3c/webextensions/pull/543. + * [Issue 191](https://github.com/w3c/webextensions/issues/191): Should background pages be allowed to navigate + * [timothy] This is navigating to another extension page. + * [devlin] What happens when the page wakes up again? + * [timothy] We load the background page defined in the manifest. + * [rob] I think we can do this async. + * [timothy] I'd be fine blocking navigations. + * [rob] I'll put follow-up:safari on it. + * [Issue 457](https://github.com/w3c/webextensions/issues/457): Proposal for runtime.onConnectNative Event + * [timothy] Chrome has this, it's just not documented. + * [patrick] It's a dev channel feature, not in Stable. + * [oliver] I believe the behavior of this was odd & not in a good state to ship. + * [devlin] Biggest issue is that there's not a great way for a 3rd party binary to know how to communicate with Chrome. As far as I recall at least. A 3rd party binary doesn't necessarily know where Chrome is on the system, nor the profile directory to use. There isn't a good way for another binary to know which Chrome to communicate with. + * [carlos] Can an app not try the default browser? + * [andrey] No. Inaccurate assumption. + * [oliver] is the goal to get this implemented everywhere, or to just run it by the group for feedback because you're going to implement it. + * [timothy] Would be fine with me. + * [devlin] Have you seen the chrome impl? + * [timothy] Not yet. + * [devlin] I'd ask that you match that impl or discuss how to modify it so we match up. There's a possibility that we may add this in the future, so we don't want to get into a situation where we have a major divergence. + * [andrey] This proposal seems reasonable for mobile extensions. If Firefox or Edge ever add cross-app support on Android. + * [devlin] I'll also add a comment. + * [Issue 272](https://github.com/w3c/webextensions/issues/272): Proposal: browser.alert.create() + * [devlin] is this solved by openPopup()? + * [simeon] alert is especially useful for debugging purposes. + * [oliver] developer experience of trying to show another popup is weird. + * [rob] A prompt could also have a strong keepalive. + * [devlin] There are a couple of things I'm concerned about. We've largely been moving away from prompts & dialogs on the web as there are a lot of downsides to them. Specific concern with prompts in background contexts is that they render in weird places and it's unclear it's associated with an extension. We've seen them used in phishing, etc. There is a concern that the user doesn't know where the prompt is coming from. There are things we can do to mitigate it, but at that point we're opening a popup. + * [rob] The advantage of this API is that there is a clear signal for a request for input from a user via prompt() or confirm(), i.e. make it focusable. + * [tomislav] Whatever we want to support, we could do so with a popup. + * [carlos] openPopup API might work well for this use case; is that available in Chrome? + * [devlin] We had some security issues with that API, but I think we've worked through them. + * [rob] With these specific methods, the UI and prompt can be consistent with the native platform. In the case of Android, openPopup() is effectively a tab. With a dedicated API, we could potentially have more platform appropriate UI (e.g. using a notification on mobile). + * [devlin] Following device standards is a good point, but I don't think it persuades me for this case. + * [oliver] Keepalive that Rob mentioned could keep the background alive until the user resolves the prompt. With a popup, you'd have to implement custom logic to handle the message passing. + * [tomislav] Requiring the background to stay alive is a downside from my point of view. + * [rob] Not a blocking aspect of the design. + * [oliver] The web has been moving away, but I'm not sure it's fair to say browsers have been moving away. + * [tomislav] Respectfully disagree + * [patrick] Is this about a UI surface or the web API's behavior. + * [timothy] I'm in favor of a dialog or alert feature. Don't think it needs to share behavior with the web alert() method. + * [devlin] I think we're aligned that we wouldn't expose this as a synchronous API. + * [david] Seems like reusing things like openPopup would make sense. + * [rob] Status? I'd lean towards neutral. + * [devlin] We're not aligned in Chrome + * [tomislav] Firefox is not aligned either. + * Follow up to discuss more. + + +### Wrap Up + + * Action items – any in addition to those that are in the rest of the docs and meeting notes? + * [?] When will the notes get shared publicly? + * [david] Let's aim for publishing by the next public meeting. + * [devlin] We can merge the in-person minutes into the public ones. I think Rob volunteered to do that + * [rob] Assuming everyone reviews and approves, I can take on the final merge. + * [devlin] Other action items for the group before we meet again in person? <silence> Okay! + * [devlin] How do folks feel this went? + * [simeon] Very well. + * [patrick] Great. + * [timothy] Good + * [rob] How are we on remote friendliness? + * [timothy] Mic situation was a little tough. Handheld mics significantly improved things. + * [devlin] Impression from the point of view of extension devs? + * [andrey] Very productive. + * [richard] Felt like a good balance of how we spent our time. + * [carlos] Would like to do deep dives outside of our scheduled time. + * [richard] Liked issue triage. Given how much we covered in 2 hours, if we did that for an hour a month, we'd be able to stay on top of issues. + * [devlin] I think there's appetite for that. + * [devlin] Andrey and Carlos, given the amount that you had to travel, was it worth your time? + * [andrey] Was a good use of our time, next time Europe would be nice. + * [tomislav] Mozilla has a Berlin office. + * [timothy] We also have Cork and London offices. + * [devlin] Any other feedback on format, how it went? + * [tomislav] How did this compare to TPAC? + * [richard] TPAC 2023 was ad-hoc. It was nice to have structured time. + * [tomislav] And it was a bit broader, given the other groups. + * [carlos] At TPAC it was hard to find a place to actually meet. + * [simeon] I think TPAC room issues can be addressed. This event demonstrated that we can easily consume 3 days of meetings. + * [tomislav] 4 days would be better; traveling across the atlantic for just 3 days is a bit little. + * [patrick] Would also like to do 4 days. 3 makes the rest of the work week a bit weird. + * [oliver] Also wonder about starting on Tuesday rather than Monday. + * [david] I think we initially thought we'd do Tuesday - Thursday, but room was booked. Agree that 2 normal days at the end of the week makes those work days … odd. + * [rob] I'm okay with lengthening the day if we need the time for it, but also appreciate having some personal work time. + * [devlin] Did the individual sections work well? + * [carlos] Public sessions weren't well communicated in the community group. + * [andrey] In the future we could ping the issue? + * [devlin] I did. + * [rob] We emphasized that it was an in-person meeting. Maybe lean more into remote participation? + * [devlin] We also want to make sure we have in-person time, since it's much more efficient and is the reason we're traveling to do this + * [tomislav] agreed + * [rob] Deep dives – I didn't feel there was much difference between early session and the in-person sessions. + * [devlin] I suspect that if we had more remote people that wanted to participate it might have felt different. It was less about being private and more about being fast communication. + * [rob] Agreed. + * [devlin] Thanks everyone for participating. diff --git a/_minutes/README.md b/_minutes/README.md index e1265efb..526df94b 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -16,6 +16,9 @@ After the end of each meeting, meeting notes are published here. ## Past meetings * 2024-03-28 ([minutes](2024-03-28-wecg.md)) +* 2024-03-20 meetup at San Diego ([minutes](2024-03-20-san-diego-meetup.md)) +* 2024-03-19 meetup at San Diego ([minutes](2024-03-19-san-diego-meetup.md)) +* 2024-03-18 meetup at San Diego ([minutes](2024-03-18-san-diego-meetup.md)) * 2024-03-14 ([minutes](2024-03-14-wecg.md)) * 2024-02-29 ([minutes](2024-02-29-wecg.md)) * 2024-02-15 ([minutes](2024-02-15-wecg.md)) @@ -29,6 +32,9 @@ After the end of each meeting, meeting notes are published here. **2024** * 2024-03-28 ([minutes](2024-03-28-wecg.md)) +* 2024-03-20 meetup at San Diego ([minutes](2024-03-20-san-diego-meetup.md)) +* 2024-03-19 meetup at San Diego ([minutes](2024-03-19-san-diego-meetup.md)) +* 2024-03-18 meetup at San Diego ([minutes](2024-03-18-san-diego-meetup.md)) * 2024-03-14 ([minutes](2024-03-14-wecg.md)) * 2024-02-29 ([minutes](2024-02-29-wecg.md)) * 2024-02-15 ([minutes](2024-02-15-wecg.md))