2023-09-11-wecg-tpac.md

WECG TPAC 2023, Public Notes—Sep 11, 2023

• Chair: Simeon Vincent
• Scribes: Devlin Cronin, Rob Wu
• Location: Seville, Spain
• Time: Mon 11 sep, 5pm - 6:30 PM CET (https://everytimezone.com/?t=64fe5880,384)
• Call-in details: WebExtensions CG, 11th September 2023

Agenda: TPAC 2023

Start	Duration	Description
17:00	5 min	Intro
17:05	20 min	WECG meeting structure and follow-up
17:25	20 min	Automated compatibility testing
17:45	10 min	Break
17:55	20 min	Web API integration
18:15	15 min	Open discussion
18:30	---	End

Attendees (sign yourself in)

1. Oliver Dunk (Google Chrome)
2. Devlin Cronin (Google Chrome)
3. Rob Wu (Mozilla)
4. Sam Macbeth (DuckDuckGo)
5. Humero Noor (eyeo)
6. Javier Fernand (Igalia)
7. Kiara Rose (Apple)
8. Simeon Vincent (Unaffiliated)
9. Carlos Jeurissen (Jeurissen Apps)
10. Tomislav Jovanovic (Mozilla)
11. Maxim Tsoy (DuckDuckGo)
12. Richard Worth (Capital One)
13. Andrea (Igalia)
14. Mukul Purohit (Microsoft)
15. Patrick Kettner (Google Chrome)
16. David Johnson (Apple)
17. Timothy Hatcher (Apple)

Meeting notes

(Intro)

• [simeon] Welcome!
• [simeon] This is our second time for the WECG at TPAC. WECG was founded by four browsers, Chrome, Firefox, Safari, and Edge.
• [simeon] One of the goals we had in the group was establishing the API surface and platform, though we haven't made as much standardization headway as we'd like, which is one of the things I'd like to talk about today

(Meeting Structure and Followup)

• [simeon] Since we formed this group we've been quite loose, and the public meetings usually cover new issues filed since the last meeting. We've become a bit better on following up on previous topics.
• [simeon] What can we do to make more progress on producing a spec? What can we change in our meeting format or interaction on public issues to improve?
• [tomislav] I think it's important to respond to issues from the community. There are several big changes with MV3. We've mostly been discussing issues top-of-mind for the community; most have been addressed, discussed, we've come up with some plans, some very far out. New issues mostly related to things that are brought up in the last two years. I see this dying down a bit, so we can focus on driving these down and aligning on behavior, resolving issues. I think we've been doing good by the community by addressing the issues.
• [rob] Before we can produce a spec, there needs to be alignment on desired behavior. Current mechanism to express support is by adding labels to GitHub issues. Can add more labels to indicate consensus, mixed, opposed, etc. This signals the state of consensus more clearly. In the process of writing the spec, we can build on those labels.
• [simeon] Building from Tomislav, I think we had a lot of input early on, and now the set of what we look at is a bit more targeted. I think we'll be getting more into the implementation rather than abstract "this is an area of a problem".
• [sam] We're making some progress establishing current behaviors, but we have struggled turning that documentation into an actual spec, especially when there's different behavior
• [simeon] A critical missing part is that we don't have a spec to add to. Making sure we all understand what next steps are – should we be filing issues with browser vendors, etc? How do we take this thing we all agree on and get the implementation work started?
• [oliver] There's also been something holding us back; we don't want to just document the inconsistencies, but we haven't added anything that's consistent
• [devlin] Don't know that we need to get caught upon that. We've agreed in abstract that there will be inconsistencies. We can start with the things we align on.
• [devlin] One question I have for the group - being a Community Group, we cannot produce anything with a bit of weight. If we write a spec, how does that work? Would it be a recommendation? Do we want to turn into a Working Group?
• [tomislav] Formality doesn't matter as much as the work. We've seen plenty of formal specs that never went anywhere. I don't think we need to worry about CG limitations. One way that would make it more official in my opinion would be automated tests (common testing platform); that would make it much more real. Let's focus on the work.
• [rob] We'll cover testing after this topic.
• [rob] Currently, our meeting notes and GitHub issue comments document differences and desired behavior. We can look back at these as a point of reference.
• [simeon] Taking a step back to what Tomislav mentioned. Formally, we aren't able to produce standards (we produce technical reports). If we want to produce something, maybe turning into a WG is the right thing. But the most important thing is that our collaboration works. I think we've established good lines of communication between browsers.
• [richard] Could we start with an outline of the spec? Crowdsourcing, taking two weeks to talk about one portion at a meeting?
• [simeon] I like that. I think that it's a good idea to sketch the format of the spec: the major components, etc.
• [oliver] We already have a bikeshed document as a starting point for the document: https://github.com/w3c/webextensions/blob/main/index.bs
• [simeon] Other than adding that to the list of things we can do in our breakout sessions, other things we can do or consider in the group's work aligning behavior cross-browser?
• [rob] What's the difference between someone spending time on writing the expected behavior in a “spec” and someone writing on MDN and developer.chrome.com? What is the added value?
• [timothy] Using the documentation as a starting point is valuable, but there are gaps that can be filled in the spec.
• [simeon] Sounds like "completeness" is a notable difference?
• [timothy] Yes.
• [simeon] I think one notable difference is us agreeing on the desired behavior and intent, rather than just the implementation
• [devlin] We don't want to produce a spec that doesn't match reality. Rob has mentioned in the past that we should document the actual behavior and not some ideal behavior that no one implements. There are inconsistencies, some intentional and others are not.
• [richard] Is that an example of something that we'd document but not spec?
• [devlin] We want to document things that are not specified. E.g. not every browser has the concept of a reading list. The browsers that do should document it, browsers that don't shouldn't. This is something we should not specify because it is browser-specific. There are topics in easy-buckets that we can specify, which we could then make more progress on.
• [tomislav] An issue that has come up before is that more differences come up as we try to write about the (current) behavior of an API. Writing up about issues is easy, specifying behavior is difficult.
• [sam] A question to ask is: What is cross-platform? What is specific to this platform? That can be the most useful to developers to see – even if we don't specify it, having that be consolidated into a single resource would be useful.
• [devlin] Time check, let's move on
• [tomislav] Next steps?
• [simeon] Let's dive more into it in the breakout sessions to highlight the set of things to cover in the spec. Maybe be able to share at a public session soon some guidance.
• [tomislav] I agree with Sam that documenting behaviors would be useful
• [simeon] Documenting what the behaviors, inconsistencies are, how to work within them, then how to align and move forward.

(Automated compatibility testing)

• Issue 441: Is there any interest in creating extension-specific test harness like the WPT one?
• [rob] As Tomislav has mentioned in the previous topic, (automated) tests are an effective way to document what behaviors are, and how to document differences and maybe resolve them. I think there's consensus across vendors that automated tests would be nice, but there's no clarity on how we can get there. I was hoping we could walk away this week with the idea of how we can have automated tests, including the framework to use and maybe the tests. There's the WPT (https://github.com/web-platform-tests/wpt) tests, leveraging that would be nice, but might have complexities (extensions aren't available in the web platform).
• [patrick] There's not a secret way to test extensions in the different browsers, so I think it will require engineering to make it work. I think we should make it work in WebDriver with whatever hooks we need to leverage WPT.
• [simeon] I believe when people test their extensions, they use commandline flags to load the extension as part of the webdriver config. Are you describing a runtime API in WebDriver for loading / unloading extensions?
• [patrick] WPT ultimately wraps around WebDriver. In theory we could standardize the flags, but that is not necessary as wpt abstracts that.
• [simeon] Limitation there as I understand it is that the extension is tied to the WebDriver's session lifetime. Are you saying that we should be able to load and unload extensions during a WebDrive session?
• [patrick] I don't have a strong opinion. But I think we should invest the engineering hours in the WebDriver / WPT area.
• [simeon] My understanding of wpt is that individual tests are in a single file. If I translate that to extensions, then the equivalent approach would be a single test or test suite per extension.
• [patrick] Haven't written WPT lately, but when I did, pretty much anyone could write a WPT and it was accepted. Can have standalone extensions for different APIs, use cases, etc. My intuition would be each test would be its own "packaged" extension, so we might have hundreds of test extensions.
• [rob] From my experience in both Chrome and Firefox, a common need in the testing framework is the ability to load extension code. I would like the extension to be embedded in the test.
• [patrick] Wouldn't be necessary. Could also just have HTML files, etc as static files that could then be loaded as extension resources.
• [rob] In my understanding, you're proposing to have a separate extension that's loaded in the test. I would like the common case of loading extension code to be supported by the test framework.
• [patrick] In the WPT repo, we'd either have one large extension with different HTML files, or a zip file
• [devlin] From the Chrome side, we have automated testing for extensions APIs. The way a lot of these are implemented is essentially writing a small extension to perform that test. I think this model has a lot of benefit. I'd push back on packaging all tests in a jsion per module because a lot of capabilities can change based on what capabilities you declare in your manifest. E.g. if you have the "tabs" permission in your manifest affects the result of "tabs.get".
• [patrick] Having run platform tests briefly, I think it makes sense to have multiple tests in a single extension.
• [timothy] Yeah, I'd prefer the approach of having many standalone test extensions to test specific functionality. I'd note that I'd want them to be flat files, rather than zipped files. This gives us source control, diffing, etc, and Safari doesn't support loading zips
• [rob] I would ask we expose some kind of test API (browser.test) rather than a test that serves a boilerplate for loading a blackbox extension followed by marking the test as “passed”.
• [patrick] WPT tests are mocha-style tests. Individual files for a test, load up that file or a zip of files to WPT for execution, hand them over to the execution framework to run.
• [oliver] Chrome Devtools Protocol has most of the support to see the popup context, but no ability to open the popup (but could potentially use action.openPopup()). That should maybe be something in the testing API.
• [devlin] A lot of this sounds very similar to how Chrome handles these tests. In the interest of concrete next steps, it sounds like there's general agreement to pursue this as an extension to WPT. Does that sound right? (silent agreement in the whole room)
• [timothy] Safari also has a browser.test namespace. I have designed that to be very similar to Chrome and Firefox's “test” APIs.
• [devlin] Extensions to webdriver… Should we start with trying to get an extension to run in Web Platform Tests and get a signal of pass/fail. We can use this as a starting point and figure out what we need to build on from there.
• [oliver] Based on the earlier conversation, it sounds like we don't know if you can load a single extension per WPT instance.
• [tomislav] Yeah, having a single test per instance is probably best to start with. Some test scenarios require multiple extensions. I would not limit the goal to be 1 extension, but I think we should start with that.
• [oliver] That makes sense. We can design it to allow dynamic extension loading in the future.
• [tomislav] I would be supportive of having a runtime method to at least load a manifest to verify its behavior. Doesn't have to run the extension, just reporting whether it is a valid manifest.
• [simeon] We've talked about that in the past; I think there was some hesitation on the Chrome side about implementing a CLI like that. Is that accurate, Devlin?
• [devlin] I don't think so.
• [tomislav] CLI entry point was an implementation detail.
• [rob] Taking a different angle, is there any objection to loading an extension in WebDriver at runtime?
• [timothy] No objection, the biggest concern is that it is secure. We require a special opt in to enable this functionality, so that covers it.
• [oliver] Sounds like there would be some browser implementation work. If browsers are willing to sign up for that work, then I don't have any concerns. But it may be desirable for the CG to focus on what we can do without introducing new engineering work.
• [rob] We can abstract out the loading mechanism, but if we can get the test infrastructure to load the extension, then we have our goal.
• [timothy] Assuming the framework can report errors, that sounds good.
• [rob] We need consensus on how it looks. Browser implementations already have their own ways to load extensions in tests at runtime, but there is no common API. If we can achieve consensus on how the load-extension mechanism looks like, it can be hooked up to the common test API.
• [devlin] I think there's more risk for anything that requires browser integration. Would need to look at the security model we have with WebDriver. Chrome doesn't require device level bio-auth, but introducing hooks to load an extension at runtime might be a longer conversation. Leveraging the CLI flags would be ideal.
• [oliver] Could we get results from extension-to-extension messaging?
• [rob] You want an extension to drive tests of other extensions?
• [oliver] Or even just a library that communicates it back.
• [timothy] Yeah, I would support a library – cross-extension communication isn't supported in Safari today
• [oliver] We don't need to change the browsers for this.
• [simeon] Out of time.
• [rob] We'll revisit this topic tomorrow.

(​​Web API integration)

• [devlin] One of the topics I wanted to discuss was integrating extensions use cases in web platform APIs where extensions are a special or sole consumer of that capability. … The web has historically been reticent about including extensions terminology and concepts in their APIs, but in this case we're not talking about extension-exclusive capabilities. Example: web push (issue 208). If userVisible is true, a notification will be displayed, if false a notification is not required when a push message is received. In Chrome this is always true. I'm curious what other opportunities there are for capabilities.
• [devlin] Another example is fetch requests setting the origin header. On the web this is a forbidden header, but in extensions customizing the origin header is acceptable. This allowance could be integrated into the web platform API. There are other discussions happening in TPAC around powerful APIs.
• [andrea] I don't work on extensions, but I work on WinterCG and some of what we discuss is allowances for special capabilities that don't make sense on websites, but do make sense in server side use cases and extensions. We have had similar discussions around fetch.
• [carlos] Talking of headers. Being able to set headers like the Permissions-Policy, Content-Security-Policy and their report-only equivalents can be very useful.
• [devlin] How would this differ from setting CSP in the manifest file.
• [carlos] In the past CSP has been seen mostly to make things less strict, but you can also add additional restrictions to reduce the attack surface.
• [javier] I'm working on protocol_handlers in the manifest, so you can register handlers for specific handlers. But the next step is to let the extension do something with the response. Now that you can register the protocol for these, if the extension could intercept the response from the browser.
• [simeon] I think what you just described is foreign fetch on protocols?
• [devlin] I'm confused - If you specify a “steam” protocol handler in the manifest, then the extension is already opened when the user opens a “steam:”-URL.
• [javier] Not just receiving requests for a protocol, but also doing something with the response. For example, an email-focused extension could implement some of it's features.
• [tomislav] you want to use an extension as a service worker to set the response for a custom protocol URL. That's a bit different, I think
• [rob] Also can always raise this topic at the recurring WECG meeting (next time this Thursday). Devlin's topic is specifically about augmenting web platform APIs with functionality specific to extensions.
• [tomislav] We all have special capabilities for existing DOM APIs, can formalize that in some way. What's the hesitance with calling it an extension?
• [devlin] Historically there has been a distinction between the web and the user agent. For example, we don't reference the "search bar" in web specs. Historically, not all browsers had extensions or the same extensions. The web platform should be the same across all browsers, regardless of whether or not they have extensions.
• [tomislav] To me extensions are part of the web platform in the same way that WebDriver is part of the web platform.
• [devlin] WebDriver is a separate spec on top of web platform. I'm more wondering about cases where we want to make small additions to an existing spec for extensions.
• [simeon] Another use case I've been interested in is getting media streams from the user's current tab without asking the user for permission. You can do that today via extension APIs, but can't do it in the same ways.
• [rob] Do we want other specs to support extension concepts, or do we want to extend other specs?
• [devlin] I want to have a way to live in these other specs. E.g. don't ask them to write it, but send a pull request for them to review. Web platform APIs can often do 90% of what we want and in many cases can do it better. Being able to leverage web platform APIs directly would lead to better outcomes than trying to copy web platform APIs and implement the specific parts we want.
• [mukul] Separate example, integrating service workers into extensions. One more would be Storage APIs
• [devlin] Extension Service Worker is not from scratch, it's built upon service workers. Storage extension API is another example, its design and behavior is quite limited (JSON, available to content scripts) that has mostly been covered on the web; its unique feature is the storage.sync API.
• [carlos] How would you apply this to properties where there's no call. For example, navigator.languages. I'm aware the list of languages might be restricted for fingerprinting reasons. This would allow to remove the i18n.getAcceptLanguages extension API.
• [devlin] I'd suggest that we don't shrink the list for extensions. In cases where a developer does want the restricted set, we'd have to explore that.
• [simeon] A use case for integrating into the web platform (besides it being easier to implement by browser implementers) in extension is that it lowers the learning curve of developing extensions.
• [tomislav] Do you expect all of the text for those additions to the APIs to live in other specs?
• [devlin] Yes, I'd expect it to live in their specs.
• [tomislav] Do you want to see those concepts directly included in their specifications or extension specific allowances defined separately?
• [devlin] I want to see these concepts reflected in those specifications. These options may or may not be exposed directly to the user, but the spec should describe what other capabilities a user agent may provide.
• [oliver] I see a couple of benefits to integrating these concepts directly in the spec - one is that it would allow the spec to be self-contained. I think this makes sense because specs probably don't want to link to our text that could change under them.
• [devlin] These capabilities that are specified can also be applied to other UAs. And we do this kind of thing in other specs. For example, we have allowances for "secure contexts." We could have similar allowances for "privileged consumers" (or whatever) and make those available to extensions and other consumers.
• (only 6 minutes left, let's move to the open discussion topic)

(Open Discussion)

• [javier] Basic idea is to allow extensions to handle special protocols. After an extension registers for a protocol, it could receive messages delivered over that scheme and process the messages as appropriate.
• [oliver] Another example might be FTP. You could add an extension that would allow you to handle FTP requests.
• [javier] Now you mention it, FTP would be a good use case
• [sam] The requirement here is that extensions would be able to register another protocol rather than mapping a custom protocol to a given URL as is currently exposed.
• [devlin] What's the current behavior when a Service Worker intercepts a request for a protocol that has a protocol handler registered by an extension?
• [sam] Doesn't work. This only fires for top frame navigations.
• [devlin] That's the foreign fetch part.
• [devlin] For most of the use cases that you're envisioning, is this for 3rd party applications running on the user's device as opposed to requests from e.g. other websites (in a browser context)?
• [javier] yes
• [tomislav] Did you prototype using webRequest.filterResponseData API in Firefox?
• [rob] You can't – that API is HTTP(S) only.
• [sam] Years ago this kind of protocol handler was implemented in Firefox, so it was possible to write. But there are obviously security considerations for this kind of capability.
• [javier] I think this is potentially possible, but this way could be more simple
• [tomislav] This could be resolved in two ways: foreign fetch (integrating in the web platform API), or a new API such as Firefox's webRequest.filterResponseData.
• [rob] It's not a limitation of HTTP/HTTPS. It's not a design decision, but an implementation constraint.
• [rob] (post-meeting) Related issues:
  • Issue 365: Support "protocol_handlers" in manifest
  • Issue 317: Get clicked registerProtocolHandler (protocol_handlers) links in background

This is the first out of two WECG meetings at TPAC. The next meeting is tomorrow, at the same time as today.