2022-03-31-wecg.md

WECG Meetings 2022, Public Notes, Mar 31

• Chair: Simeon Vincent
• Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=6244ef00,3c0 Call-in details: WebExtensions CG, 31st March 2022 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #192, github issues

The meeting will start at 3 minutes after the hour.

• Carry-over from previous meetings
  • None
• Other new issues
  • Issue 190: Discuss how to handle platforms with limited control over authentication methods (Oliver)
• Open discussion queue (add yourself at the bottom)
  • Issue 192: Performance concerns regarding Offscreen Documents for Manifest V3 (tophf)
  • Issue 162: Declarative Net Request proposal: disable individual static rules
• Check-in on ongoing issues
  • Issue 170: Proposal: Offscreen Documents for Manifest V3

Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Frederic Rivain (Dashlane)
3. Giorgio Maone (NoScript)
4. Steven McLintock (1Password)
5. Jack Works (Sujitech)
6. Mukul Purohit (Microsoft)
7. Oliver Dunk (1Password)
8. Timothy Hatcher (Apple)
9. Bradley Cushing (Dashlane)
10. Larry Xu (Dropbox)
11. Tomislav Jovanovic (Mozilla)
12. Carlos Jeurissen (Jeurissen Apps)
13. Rainer Enders (Keeper Security)
14. Philipp Claßen (Ghostery)
15. Richard Worth (Capital One)
16. Krzysztof Modras (Ghostery)
17. Nir Nahum (WalkMe)
18. Alexei (Privacy Badger)
19. Igor Oleinikov (Grammarly)
20. Bastien Granger (Dashlane)
21. Tyler Carson (Keeper)
22. Simeon Vincent (Google)
23. Felipe Erias (Igalia)
24. Tim Heflin (Keeper)
25. James Hycner (Keeper)

Meeting notes

Issue 190: Discuss how to handle platforms with limited control over authentication methods (Oliver)

• [oliver] Some platforms (e.g Windows, Android) don't offer control over which biometrics are being used for authentication. The secureStorage API needs to be updated to account for that. IMO it would be unfortunate if this limitation were to be copied to the API. Wondering about Microsoft's/Mukul's perspective.
• [mukul] Looks to be a limitation of current Windows APIs. Curious what you are using as part of your native app.
• [oliver] We're using the Windows Hello APIs and currently have to settle.
• [mukul] Sounds like each platform has a completely different implementation is that correct?
• [oliver] Yes
• [tomislav] I agree with what Simeon said in the issue, that it should be modeled after existing APIs. May need to standardize on the 3 levels that are currently supported.
• [oliver] Would that mean only using "weak" on Windows?
• [tomislav] the OS would need to respond with an appropriate set of options for the request.
• [timothy] That would be a query api in addition to what's in the proposal now?
• [tomislav] We can use whatever is available.
• [timothy] I think that Oliver based much of the API on the API from iOS/macOS, we would be able to implement the proposed APIs without much difficulty. We still support some devices where not all authentication mechanisms are available.
• [simeon] timothy, do you know how ios/macos intermediate yubikeys and hardware credential managers
• [rob] Let's introduce the “topic: secureStorage” label?

Comment on issue 192: Performance concerns regarding Offscreen Documents for Manifest V3 (tophf)

• [simeon] Summary of comment, which was partly copied from issue 170: starting a Service worker has lots of overhead, which has a net loss of battery and CPU performance.
• [simeon] Not guaranteeing the lifetime of the background: This is a trade-off that's going to be a better solution for most users.
• [dashlane] Any data to back up that statement?
• [timothy] From Apple's perspective. Similar to Chrome, any page that the extension creates is in the same process. A new page would spawn in the same process. If we were to implement the API, there would be a cost, but not an entirely separate process.
• [simeon] Unfortunately we don't have any data to share. We performed some internal analysis. The bar between what's available to us internally and publicly shareable is unfortunately very high. I'll gladly resurface this question with the team and leadership to see what we can do.
• [timothy] If I read between the lines, if extensions were to use the Off-screen documents proposal all the time, that it would be a worse end state (at least two contexts) than an extension that uses just Limited Event pages, which is just one context with similar lifetime guarantees.
• [krysztof] Could Google reconsider …?
• [simeon] This again comes back to the guarantees of the platform. Part of the design from this proposal is to make it explicit that the spawning of the page and its lifetime is different from the previous behavior (i.e. of event pages).
• [krysztof] It's not clear how that offers more value than an ephemeral background page (i.e. event pages).
• [alexei] What are the use cases where Chrome cannot guarantee the lifetime of extensions?
• [simeon] Chrome's longer term goals to bring Chrome to more platforms/environments with such constraints.
• [tomislav] As an example on our end, Firefox on Android's processes may be killed without notice, e.g. by resource constraints.
• [timothy] That's also why we require non-persistent pages on iOS as well. Safari 15.4 supports non-persistent background page in MV3 extensions if you need them.
• [simeon] Part of a goal of Service workers is to encourage an event-based model for extensions. This may not work for all extensions, but it's the direction where the average extension can and should go.
• [simeon] Chrome was actively driving towards a new version of the extension platform before this WECG group was founded. We believed that the previous model was not sustainable long-term, and were already in the process of going down this path before we have had broader discussions with other browser vendors and the community. Now with this group we are trying to find a way to work more publicly and with other browser vendors to get to a solution that we can all agree with, but we cannot abandon the initial drive and motivations that led us down this path.
• [rob] What's Chrome's status on this proposal?
• [simeon] Don't think that we've started the implementation, but we intend to start with the implementation in the near future, to land in the next couple months.
• [rob] Is the proposal pretty much fixed?
• [simeon] The API surface is open to discussion, the set of reasons that we would allow too. The concept itself is the direction that we'd like to go.
• [tomislav] To get back on the unfortunateness of the timing of the WECG. A good aspect of it is that we now have a forum to drop proposals such as this off-screen document proposal before the finalization / implementation. Although we don't agree with this specific proposal because we believe that Limited Event Pages address the use cases in a better way, the opportunity to have this discussion is valuable.
• [simeon] I was referring to the criticism that we aren't accepting significant changes tot MV3, because that is true - we have started this before.

Issue 162:** **Declarative Net Request proposal: disable individual static rules

• [felipe] Working on this in Chromium (1225229). Occasionally individual rules are found in already-distributed rules, but it is currently not possible to disable that rule in the DNR API in a clean way, as rule sets are loaded as a whole.
• [timothy] Can dynamic rules be used to support this use cases?
• [felipe] A problem with this is that the number of dynamic rules is smaller than the number of static rules.
• [krysztof] Ghostery also hits this problem; users would like to control which rules can be enabled. The low number of dynamic rules hinders the ability of Ghostery to offer customizability.
• [timothy] If I recall correctly, the number of rules recently got bumped from 10 to 50.
• [simeon] 10 enabled, 50 registered.
• [rob] Reason for the static rules is that compiling them can be expensive. Offering the ability to disable individual rules basically means that the rules need to be recompiled, or that the updates rules need to be prioritized before static rules.
• [timothy] In safari this triggers batching up rules, sending them to another process, compiling the result, sending them back. Performance is potentially a concern here
• [krysztof] We have encountered that kind of issue before and we've solved it before. Feel free to reach out to us for help.
• [timothy] Slight mismatch in the API. Static rules are static and expected to change rarely.
• [felipe] When designing the API, integrated the list of rules to be disabled into the static list registration. From the point of view of the developer, it should be clear that it can take some time to process.
• [mukul] In the issue you mentioned “malice”, what do you mean by that?
• [felipe] Most of the issues that we mentioned are human errors.
• [krysztof] In our case it's mostly broken websites, e.g. due to website changes.

Issue 170: Proposal: Offscreen Documents for Manifest V3

• [simeon] FYI: going to respond to a handful of questions in the next day or two.

Issue 169: Blocking webRequest usecase - add, modify and remove CSP directives

• [carlos] Currently not possible to modify CSP directives, other than just removing or replacing the CSP entirely.
• [simeon] On the Chrome side we're hesitant to provide a way to completely strip a page's CSP and compromise end user security. We do have selective allowances for extensions to load resources, such as ignoring X-Frame-Options when embedding an iframe in an extension page. Are you looking for a way to poke holes in CSP or to strip the CSP entirely?
• [carlos] Ideally I'd change specific directives, but DNR only supports the removal of the directive entirely. E.g. add an origin to the CSP directive or remove something.
• [timothy] DNR has a way to replace headers with regexps, would that work?
• [carlos] I don't know.
• [giorgio] Another issue is that the CSP needs to be cached. Knowing the CSP of the page enables the extension to restore the CSP if desired.

The next meeting will be on Thursday, April 14th, 8 AM PST (3 PM UTC).