-
Notifications
You must be signed in to change notification settings - Fork 54
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2022-09-15 TPAC meeting
- Loading branch information
Showing
2 changed files
with
167 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,165 @@ | ||
| # WECG TPAC 2022, Public Notes—Sep 15, 2022 | ||
|
|
||
| * Second meeting of the day, at TPAC - https://github.com/w3c/webextensions/issues/232. | ||
| * Chair: Simeon Vincent | ||
| * Scribes: Timothy Hatcher, Rob Wu | ||
|
|
||
|
|
||
| ## Agenda – [W3C calendar](https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-67ede8b0a1a1) | ||
|
|
||
| * 13:30 - 14:30 (60 min) Charter & progress review ([deck](https://docs.google.com/presentation/d/1U1NHzcotEcadL9NKiFd_6sxrmxeTSoluhnYFYilEOj0/edit#slide=id.p)) | ||
| * In this section we will review the scope of work and deliverables sections of our charter, discuss potential modifications to these sections, survey progress made on deliverables, and discuss next steps. | ||
| * 14:30 - 14:40 (10 min) Break | ||
| * 14:40 - 15:30 (50 min) Dive into specific topics | ||
| * 14:40 - 15:30 (20 min) User script manager support in MV3 | ||
| * 15:00 - 15:20 (20 min) Offscreen Documents for Manifest V3 or Limited Event Pages for MV3 | ||
| * 15:20 - 15:30 (10 min) Make extension APIs browser neutral | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (Google) | ||
| 2. Timothy Hatcher (Apple) | ||
| 3. Rob Wu (Mozilla) | ||
| 4. Luca Greco (Mozilla) | ||
| 5. Shane Caraveo (Mozilla) | ||
| 6. Mukul Purohit (Microsoft) | ||
| 7. Cornelius Witt (eyeo, observing) | ||
| 8. Daniel Huigens (Proton, observing) | ||
| 9. Sarah Heimlich (Google, observing) | ||
| 10. Nina Satragno (Google Chrome, observing) | ||
| 11. Carlos Jeurissen (Jeurissen Apps) | ||
| 12. Richard Worth (Capital One) | ||
| 13. Bradley Cushing (Dashlane) | ||
| 14. Bastien Granger (Dashlane) | ||
| 15. Lucas Selker (Dashlane) | ||
| 16. George Henderson (Capital One) | ||
| 17. Oliver Dunk (1Password) | ||
| 18. Brian Weinstein (Apple) | ||
| 19. David Johnson (Apple) | ||
| 20. Kiara Rose (Apple) | ||
| 21. Ellie Epskamp-Hunt (Apple) | ||
| 22. Ben Morss (Google, observing) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Charter & progress review | ||
|
|
||
| * [simeon] Presenting slide deck | ||
| * https://docs.google.com/presentation/d/1U1NHzcotEcadL9NKiFd_6sxrmxeTSoluhnYFYilEOj0/edit | ||
| * [simeon] Diverging from our normal format, primarily discussing how the group works and work more effectively. | ||
| * [simeon] Scope of work and deliverables. | ||
| * [simeon] Out of scope, like deployment, WebDriver, and stores. | ||
| * [simeon] Should reconsider putting WebDriver in scope since we have been discussing it more lately. | ||
| * [simeon] Modifications to the charter, open up for discussion. | ||
| * [simeon] In talking to the Browser Tools and Testing folks. They intend the WebDriver spec to be extended. They are not going to take on the work to test extensions, but we are welcome to do that. | ||
| * [rob] (editorial note) This is tracked at [issue 19](https://github.com/w3c/webextensions/issues/19). | ||
| * [timothy] I agree we should change WebDriver from out-of-scope to in-scope. | ||
| * [simeon] Another thing that has some up is enterprise policies. They are part of distribution. | ||
| * [simeon] How do schools/enterprises install extensions in Safari? | ||
| * [timothy] Safari does not have any extension enterprise policy mechanism currently, but an enterprise can force install apps. The user needs to enable the extensions. | ||
|
|
||
| Deliverables | ||
|
|
||
| * [simeon] Perhaps we should consider listing more optional deliverables, such as test suites and compatibility reports. | ||
| * [timothy] That may make sense; we have some issues labeled “inconsistency”. | ||
| * [simeon] Anything else? | ||
| * [shane] Documentation? | ||
| * [simeon] Do you think that the CG should produce documentation for vendors to consume? | ||
| * [shane] In the web API world all docs are on MDN. Would it be a good idea to consider that the main spot for extension documentation, and a place to highlight differences? | ||
| * [timothy] In favor of using MDN as the main source of truth for extension documentation. | ||
| * [simeon] Personally I like the idea of MDN being the canonical source for compatibility differences, even if we don't agree on the location for reference docs. Not sure how that would look like in terms of deliverables. | ||
|
|
||
| Meeting to achieve deliverables | ||
|
|
||
| * [simeon] So far the biweekly WECG meetings have been discussions on extension API issues. While useful and I don't want to stop doing that, we haven't made much progress on our declared objectives of producing a spec, aside from the brief overview of manifest keys. As chair of the group, I would like to see how we could do better here. A possibility of addressing this is to start another meeting to explicitly focus on the thing that we want to deliver, basically the spec. A challenge here is that we are already short on time. | ||
| * [simeon] Right now we have very little structure; basically whatever we discussed at the last meeting plus new issues that have been filed. | ||
| * [carlos] How about doing one API a week? | ||
| * [simeon] Hesitant about that; I like the regular checkin as a driver for making progress. | ||
| * [george] How about splitting in smaller deliverables? | ||
| * [shane] Has anyone sit down and written down what exists already? | ||
| * [simeon] No, we have not had a concerted effort to break it down. Think that it would be a very valuable exercise. | ||
| * [oliver] Get a basic outline of the APIs in GitHub to give more people a way to jump in and start. | ||
| * [simeon] Sounds like a great exercise that we should start soon. | ||
| * [rob] We already have MDN to document behavior and incompatibilities. How could the write-down exercise add value over what we already have on MDN? | ||
| * [simeon] Value of spec: behavior documented in MDN. IDL in spec. | ||
| * [rob] And like regular web APIs, MDN could link to the spec. | ||
|
|
||
| Common format for API specification (JSON / IDL) | ||
|
|
||
| * [shane] With IDL there would be one shared starting point. | ||
| * [simeon] Currently Chrome has custom IDL and JSON schema files. | ||
| * [luca] Firefox has JSON schema files. | ||
| * [timothy] Safari uses the IDL format, similar to the format for the web, plus modifications for extension purposes. | ||
| * [simeon] WebKit recently moved to Github. Are the relevant files there? | ||
| * [timothy] All extension stuff is internal, part of Safari. | ||
| * [simeon] Would it be possible to share that publicly? | ||
| * [timothy] We could share that if we get approval internally. | ||
| * [simeon] We should try to get these into GitHub for the WECG from all the browsers and combine them where they overlap. | ||
| * [timothy] Willing to contribute our IDL files. | ||
| * [simeon] Will be good to see what all the browsers support from this and get into a common IDL format. | ||
| * [simeon] This is all we have for the first hour, we have some time before the break. We can continue ideating or move on to the next section of topics. | ||
| * [oliver] What is the hesitation of using JSON schema? | ||
| * [simeon] We would not use it for Chrome, so JSON schema would be side data that we don't consume. | ||
| * [timothy] In Safari we would likely not consume it as input either, but it would be a good reference as a point of reference. | ||
| * [shane] Whatever the target is, we could run a script to update the central source to make sure that the central source stays in sync with whatever the universe (i.e. browser implementations) is. | ||
| * [simeon] Would be good to have a set of tests to validate and check against. | ||
| * [timothy] Very supportive of this. | ||
| * [simeon] Maybe consider adding test command line flags to the browsers to support manifest parsing and validation? | ||
| * [shane] What does the Firefox web-ext tool use? | ||
| * [luca] That's the addons-linter (https://github.com/mozilla/addons-linter). | ||
| * [timothy] Chrome is more strict here than the other browsers, with regards to unknown entries in the manifest. This might be hard to drive to an end with lots of errors being thrown for things like browser-neutral names. | ||
| * [simeon] Will try to encourage the team to consider ways to solve this in the name of inter-op. | ||
|
|
||
| [break] | ||
|
|
||
| User script manager support in MV3 | ||
|
|
||
| * [simeon] In short, one of the big gaps between the MV3 platform is user script manager support. A user script manager is an extension that allows any user to author/install scripts to run in web pages. In MV3 one of the big changes is preventing extensions from hosting remotely hosted code. Extensions have to bundle all code that they're using, but this is incompatible with the functionality of user script managers. | ||
| * [simeon] The Chrome team is planning to address this by expanding the scripting API. Our plan is to add a code (string) option to the scripting.registerContentScripts method, with a caveat. We are looking for two signals: the end user has to be comfortable with and consent to this functionality (i.e. opt-in). Secondly, the extension should announce the desire for this functionality (i.e. a permission). | ||
| * [rob] Exposing the string-based code execution capability could help user script managers to migrate to MV3. A pre-existing fundamental issue with the user script manager extensions is that their implementation is insecure by design (i.e. all scripts running in the same privileged execution context), mostly due to the lack of supporting extension APIs. Now is the opportunity to improve; do you plan to cover this aspect as well? | ||
| * [simeon] Not at the moment. Goal is to allow the extension to run as before. | ||
| * [rob] Maybe expose a way to have multiple isolated worlds? | ||
| * [simeon] That has not been talked about yet, since there does not seem any desire. Trying to address features lost to MV3 changes. | ||
| * [rob] There is no obvious desire because extensions can already have their functionality with hacks, at the expense of the user's security. | ||
| * [luca] A concern is that the user script has full access to the capabilities of the host extension. That's why we'd like to design a new API to allow extensions to sandbox user scripts in a restricted sandbox. | ||
| * [simeon] Aware of concern of user scripts hijacking privileges / functionality from other user scripts. Agree with the concerns, basically “running as root”. A lot of the motivation for the current approach is our timeline (i.e. deprecating MV2 in favor of MV3). | ||
| * [luca] Not sure if the opt-in/permission is a big blocker to other extensions getting functionality. | ||
| * [simeon] This feature is specifically to support user script managers; our intent is to enforce this in reviews. | ||
| * [luca] We would probably do the same if we follow this path. At the same time, the video downloader example could also offer user script functionality. | ||
| * [shane] In terms of opening up remote code execution in MV3. I'm in favor of introducing a single-use policy. And re-iterating what Luca said about the sandboxes; I'd be hesitant on downgrading the security of the API from MV2 in the transition to MV3. My personal preference is to keep at least the security from the user script API. | ||
|
|
||
| Offscreen Documents for Manifest V3 or Limited Event Pages for MV3 | ||
|
|
||
| * [timothy] There are two different APIs for background scripts | ||
| * Chrome's offscreen documents proposal: https://github.com/w3c/webextensions/issues/170 | ||
| * Firefox's Limited Event Pages proposal, which Safari also implements: https://github.com/w3c/webextensions/issues/134 | ||
| * [shane] We have implemented event pages, which we offer in MV2 and MV3. In Firefox 106 in MV2, ahead of the MV3 availability. We are committed to event pages in MV3, and will be doing Service workers at a later time. | ||
| * [simeon] Historically, Firefox did not have an event page. What happened if persistent: false was present? | ||
| * [rob] We used to ignore it and print a warning to the console. | ||
| * [timothy] In Safari persistent: true was an error on iOS/mobile in MV2; in MV3 persistent: true is ignored and a warning is shown. | ||
| * [simeon] On offscreen documents: Initial implementation is a singleton, and we may consider allowing multiple instances in the future. Extensions creating an offscreen document must pass a reason, which impacts the allowed lifetime of the page. Example of use case is audio: when the user/extension is playing audio, the page lives, until the extension stops playing audio. The API is currently available for testing, planning to enable it on Chrome Stable in the next few weeks. Starting with an initial set of reasons and expanding it based on developer feedback. Explicitly not intended as support for a persistent background context. Service workers should be used for background stuff. As we support more functionality in the extension's background service worker, we expect that some reasons will become unsupported in the future. | ||
| * [george] Do offscreen documents have access to extension APIs? | ||
| * [simeon] Very limited. It is a chrome-extension: document that currently only has access to extension messaging (chrome.runtime.sendMessage). | ||
| * [rob] SInce the origin is shared with the rest of the extension, and therefore share the same origin in regular web APIs, this is clearly not a security feature, but exists primarily to discourage extensions from putting significant functionality in their offscreen document. Can you confirm that? | ||
| * [simeon] This is to allow extensions to support functionality that would otherwise require APIs from an event page. | ||
| * [richard] You said that the reason determines the lifetime; does it have any other effect? | ||
| * [simeon] The reason comes with a justification. That may potentially be used as a signal to verify intended behavior, and offer users control over the situation. | ||
| * [oliver] If it is a singleton, how should multiple use cases be supported? E.g. when independently of the existing reason for an offscreen document, a small API call is needed (e.g. window.matchMedia), would we have to close the existing document and open a new one? | ||
| * [siimeon] That's a good piece of feedback. I'll see if we should reconsider sticking to a singleton before we ship. | ||
|
|
||
| [Issue 113](https://github.com/w3c/webextensions/issues/113): Make extension APIs browser neutral | ||
|
|
||
| * [timothy] Currently browser and chrome namespaces exist. Wonder whether the browser namespace would be supported in Chrome, and chrome_url_overrides / browser_url_overrides. | ||
| * [simeon] Amenable to switching from chrome.\* to browser.\*, in a manifest version bump. I think that many users use `chrome === browser`, don't want to make assumptions there though. Favorable, but not a high priority. If the extension community feels that this is a high priority, we may shift our perspective here. | ||
| * [simeon] Another possibility is supporting both chrome and browser, which is a challenging approach. On the web we have had multiple features where we had to support multiple (slightly) different behaviors with prefixes etc. I'm very hesitant to go in the same direction in the extension namespaces. | ||
| * [timothy] Note that in Safari, we do support both namespaces, with `chrome === browser`. | ||
| * [shane] We do the same for Firefox in MV3, `chrome === browser`. | ||
| * [shane] Before Chrome switches to browser.\*, it would be nice if there is an established approach to handling cross-browser differences. | ||
| * [simeon] I'll take the hint that I should write up my thoughts on this and share it in the near future WECG | ||
| * [simeon] There are web platform concerns there as well. In Chrome, we special-case the “chrome” name to be a name exposed on the web platform despite it not being on the web platform. Unlikely to expose “browser” in content scripts because of implementation issues in Chrome, where it would also affect the web. | ||
| * [timothy] FYI we recently shipped `externally_connectable` in Safari, and were unable to expose`window.chrome` in the main world (to the web) because of websites that used “chrome” for feature/browser detection. Only `window.browser` is exposed in the main world in Safari. | ||
| * [simeon] Long-term, we're onboard with changing “chrome” to “browser”. | ||
|
|
||
| The next meeting will be on [Thursday, September 29th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6334e000,384). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters