Skip to content

Latest commit

 

History

History
131 lines (101 loc) · 10.7 KB

2022-02-03-wecg.md

File metadata and controls

131 lines (101 loc) · 10.7 KB
Raw

WECG Meetings 2022, Public Notes, Feb 3

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=61fb1b00,3c0 Call-in details: WebExtensions CG, 3rd February 2022 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #150, other issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • (none)
  • Other new issues
    • Issue 151: webRequest API alignment and support in MV3
    • Issue 152: it's impossible to integrate google analytics with MV3
    • Issue 153: geolocation API is not working with service workers
    • Issue 154: Proposal: browser.secureStorage API
    • Issue 155: Browser-specific issue tracking
    • Issue 156: Proposal: ES modules in content scripts
  • Open discussion queue (add yourself at the bottom)
  • Check-in on ongoing issues
    • Issue 93 Proposal: allow to use i18n.getMessage in a serviceWorker
    • Issue 119 Proposal: add optional_host_permissions
    • Issue 123 Proposal: add disallow_host_permissions

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Giorgio Maone (NoScript)
  3. Bradley Cushing (Dashlane)
  4. Oliver Dunk (1Password)
  5. Sam Macbeth (DuckDuckGo)
  6. Nir Nahum (WalkMe)
  7. Jack Works (Sujitech)
  8. Philipp Claßen (Ghostery)
  9. Tomislav Jovanovic (Mozilla)
  10. Igor Oleinikov (Grammarly)
  11. Carlos Jeurissen (Jeurissen Apps)
  12. Alexei (Privacy Badger)
  13. Krzysztof Modras (Ghostery)
  14. Mukul Purohit (Microsoft)
  15. SImeon Vincent (Google)
  16. Timothy Hatcher (Apple)

Meeting notes

Issue 151: webRequest API alignment and support in MV3

  • [bradley] Raised this during the last meeting, e.g. perf issues. Hoping to align the behavior between all browsers, and get clarification on blocking webRequest. Mentioned specific use cases in the issue. One of the use cases could also be addressed by Mozilla's getFrameId proposal (issue 12), but it seems that Google has reservations against it.
    • [timothy] Safari will support getFrameId.
    • [simeon] The extension team is favorable towards this feature, but we need sign-off from other parts of Chrome.
  • [timothy] webRequest is not supported in non-persistent background pages in Safari, because we looked at Chrome, which didn't support it either.
    • [rob] This lack of support for blocking webRequest in event pages in Safari was also a question at issue 148.
  • [tomislav] Declarative API is preferred for cases where they can be used. We're implementing DNR for compatibility, and are keeping blocking webRequest for other cases.
  • [giorgio] Would like to get more clarity on the concerns over the performance aspects of webRequest. Concerned about the lack of flexibility with DNR. Why does Chrome not take Mozilla's approach of supporting async listeners?
  • [simeon] The declarative design originated from the desire to support functionality without broad host permissions. During the implementation we saw that the implementation is also useful for general use. Blocking webRequest is not viable in the long term. With many changes in MV3, we are paving the road for the future, even if their use is not clear now.
  • [krysztof] Content blockers cannot work without host permissions, e.g. cosmetic filters require CSS in content pages. Removal of host permissions is a weak motivation for DNR.
  • [alexei] Browser vendors seem to have the mistaken belief that they can enumerate all use cases and include that in the design of DNR. Privacy and security extensions need to continue to be able to respond quickly to evolving tracker techniques, which a declarative API inherently does not support. Additionally, when browser vendors talk about improving performance with DNR, these concerns go against real world experience where webRequest-based extensions already make browsing faster and more performant. Browser vendor performance improvement claims seem like solving for the wrong problem.
  • [tomislav] I did not say that all use cases can be addressed by DNR, but that declarative APIs are preferable when they can be used.
  • [carlos] To make the discussion more productive, we can focus on keeping support for both webRequest and DNR side by side.
  • [oliver] One use case for the webRequest APIs at 1Password is filling basic auth. We'd still love to support this in MV3 but it could easily be solved by a new API that doesn't require access to web requests.

Issue 152: it's impossible to integrate google analytics with MV3

Issue 153: geolocation API is not working with service workers

  • [simeon] Merged with issue 72. More broadly, intent is to introduce these APIs in extension service workers. Features absent from Service workers in the web may still be exposed to extension service workers on a case-by-case basis.
  • [timothy] Agree, if there is an API that makes sense in a service worker, we may expose it to extensions instead of building a whole new API.
  • [simeon] Long term our desire is to bring APIs currently excluded from web service workers to extension service workers. Shorter term, we are working on a counter-proposal to the Limited Event page proposal to address these DOM use cases in service worker based extensions.

Issue 154: Proposal: browser.secureStorage API

  • [oliver] Shared on Matrix, feedback is welcome. Have received some feedback so far, was surprised to hear that the general feature of storing data is preferable over storing specific keys.
  • [bradley] Dashlane is also supportive of the 1Password proposal.
  • [tomislav] At Mozilla we are discussing this internally (security, password/logins team) before proceeding. We are not generally opposed, but are still discussing before continuing.
  • [timothy] At Apple also gathering feedback, also not opposed to it. We are the ones that preferred the general feature over storing keys.
  • [simeon] secureStorage sounds useful.
  • [mukul] Have you investigated other OS APIs besides macOS?
  • [oliver] Yes. We currently use nativeMessaging, whether that is macOS or Windows, and use platform-specific APIs, e.g. TPM APIs on Windows.
  • [timothy] Would it be a concern to password managers if the keys are only visible to extensions (and not externally, e.g. to other desktop applications).
  • [oliver] Would not be a large concern, extension can still use native messaging to sync data to external applications.

Issue 155: Browser-specific issue tracking

  • [carlos] It's best to keep the issue tracker clear of browser-specific issues, so I have listed the locations where the issues can be reported.
  • [timothy] For Apple the feedback assistant is preferred. I also respond on Twitter.
  • [mukul] For Edge, in-product feedback is the preferred method. There is currently no way to track issues. We also respond to users/devs at answers.microsoft.com.
  • [rob] Could we pin the issue so that it's more visible?

Issue 156: Proposal: ES modules in content scripts

  • [simeon] As a developer, I like it. Seems like there's a straightforward design in that we could add a "type" key to the object definition and accept the values "module" and "classic"
  • [timothy] In favor too, from Apple's perspective.
  • [rob] Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1451545
  • [jack] I like it. I tried it since 2 yrs ago and failed.
  • [tomislav] Module scripts are async by design, that may not work well with document_start scripts.
  • [jack] but files are local. Browsers can parse & cache them ahead of time.
  • [timothy] Even if the files are local, there is still disk IO, code signing checks etc.

Issue 93: Proposal: allow to use i18n.getMessage in a serviceWorker

  • [simeon] Chrome landed getMessage in Canary, targeting release 100
  • [rob] Since this was a browser-specific issue, can we close it?
  • [timothy] Safari did not have this issue. We can close it.

Issue 119: Proposal: add optional_host_permissions

  • [simeon] Intend to support this and may take up work on it soon.
  • [timothy] In favor, as noted in the issue.
  • [tomislav] Already written on the issue that we are in favor.
  • [carlos] This also relates to issue 123.
    • [timothy] This is also what we did in the old safari extension model. WebKit supports it, we could forward this data from the WebExtension's manifest to support this.

Mozilla is hiring for the extensions team

The next meeting will be on Thursday, February 17th, 8 AM PST (4 PM UTC).