Skip to content

Latest commit

 

History

History
120 lines (100 loc) · 8.96 KB

2021-10-28-wecg.md

File metadata and controls

120 lines (100 loc) · 8.96 KB
Raw

WECG Meetings 2021, Public Notes, Oct 28

  • Chair: Timothy Hatcher
  • Scribes: Tomislav Jovanovic, Simeon Vincent

Time: 8 AM PDT = https://everytimezone.com/?t=6179e800,384 Call-in details: WebExtensions CG, 28 October 2021 event Zoom issues? ping @zombie (Tomislav Jovanovic) in chat

Agenda: github issues

Attendees (sign yourself in)

  1. Tomislav Jovanovic (Mozilla)
  2. Oliver Dunk (1Password)
  3. Nir Nahum (WalkMe)
  4. Mélanie Chauvel (Dashlane)
  5. Todd Schiller (PixieBrix)
  6. Alexei (Privacy Badger)
  7. Krzysztof Modras (Ghostery)
  8. Daniel Glazman (Dashlane)
  9. Rachel Tublitz (Mozilla)
  10. Carlos Jeurissen (Jeurissen Apps)
  11. Thierry Régagnon (Dashlane)
  12. Simeon Vincent (Google)
  13. Timothy Hatcher (Apple)
  14. Mukul Purohit (Microsoft)
  15. Eric Meyer (Igalia)
  16. Giorgio Maone (NoScript)
  17. Marwan Liani (Dashlane)
  18. Maxim Topciu (AdGuard)
  19. Jack Works (Sujitech)

Queue (add yourself at the bottom)

  • It would be good to invite somebody from Google who can speak about Google's MV3 SW plans. (Alexei)
    • [rob] ^ continued from last meeting since Simeon wasn't here.
  • Split up discussions about SW plans into two groups. (Carlos)
      1. Missing APIs and functionality in extension serviceWorkers
      1. Lack of the persistence of background scripts. See: #44
  • Unique frame ids, frame messaging and getting frameId from window object. #90 #12 #77 #91 (Carlos)
  • Do browser vendors have plans for addressing WASM startup times in MV3? (Oliver Dunk)

Meeting notes

Intro:

  • [timothy] TPAC week, he and Simeon joined WebApp manifest WG session, talking about manifest schemas and webidl/json schemas for APIs.
    • Biggest difference between manifests around icons
  • [simeon] question about types in the manifest, and handling failure
    • Mostly relying on spec text for now, were not happy with idl handling.
  • [daniel] topic handling of unrecognized manifest entries?
  • [timothy] All browsers should be more lenient.
  • [simeon] Will follow up with the Chrome team on position with respect to unknown keys
  • [tomislav] we have a compromise mostly ignoring totally unknown keys, but failing if a known type is incompatible.
  • [timothy] Think there are minimal differences between MV2 and MV3 manifests. Safari is very relaxed when it comes to erroring for unknown keys
  • [carlos] users are often confused about what is recognised or not.

Issue #109: Use cases not covered by DNR: POST payloads

  • [giorgio] possible with blocking WR, not with DNR. Preference for Firefox style WebRequest as it's non-blocking.
  • [tomislav] do you know a specific use case you need to address about POST request?
  • [giorgio] XSS filter – need to be able to analyze the POST request. Sites can work around content blocking by switching to POST
  • [timothy] Can we work around this with declarative rules?
  • [giorgio] Probably need to be a callback, based on heuristic, transform the data, perform pattern matching for XSS payloads.
  • [simeon] open to the possibility of logic execution, problem with applying function in browser environment, leaking info. How to tackle arbitrary code execution. Main problem is amount of data that extensions has access to.
  • [krzysztof] other APIs expose a similar level of access, like content scripts, cookies.
  • [tomislav] FF team is considering a DNR fallback "action" that will probably be something similar to a blocking webRequest event, but only fired for specific (matched) requests (that can't be handled via declarative means).
  • [simeon] Chrome teams MV3 initial motivators was wanting to change relation to broad host permissions (<all_urls>), we plan to change <all_urls> permissions to be opt-in by the user, temporary permission grants in response to user actions. DNR designed to address that usecase without exposing all the info to extensions.
  • [timothy] broadly in agreement about broad permissions.
  • [tomislav] we're working on similar user access controls for permissions, but once granted, there are usecases that can't be declarative.
  • [giorgio] want to understand the direction we're going. Are we going to have to see permissions prompts on every web page
  • [timoty] added “run on all websites” for common usecases like tab managers , password managers
  • [simeon] working on UI for a while, not ready yet. Napkin sketch is all we could commit a few months ago. Long term, we want to go to a model of only acting based on users actions. Don't think we can get rid of <all_urls>, but want to move to a more reactive model. One of the solutions is “in-context-badging”, text boxes on a page, input boxes on a page flagged with grammar extension/shopping assistant.
  • [tomislav] broadly in agreement with the goals and direction. Noscript is an example of something that requires all_urls.
  • [giorgio] understand that browsers want to restrict access to the narrowest set of permissions, think the judgement on this could be handled by extension store reviewers
  • [carlos] #119 optional_host_permissions not all permissions need to be asked at installation time, some might be required, but others truly optional.
  • [timothy] in favor
  • [simeon] missing optional_host_permission was too optimistic about timelines of rolling out MV3 and permissions UI. Personally in favor of optional, but can't commit on behalf of the team. Expect that
  • [oliver] question about stability of MV3 manifest and keys being still in flux.
  • [giorgio] if we get these permissions, can we get blocking WR back :)
  • [simeon] got sidetracked with permissions because of Chrome's MV3 motivations, if we were doing thing from scratch, how we would design. Blocking WR not compatible with long-term vision of MV3 and beyond. No proposal for missing use cases ATM.

Issue #103: Script injection in WorkerScope(s)

  • [giorgio] Use case for any anti-fingerprinting extension. Inject a script before the service worker script code runs.
  • [timothy] Makes a lot of sense, see the usecases.
  • [tomislav] Somewhat addressable in Firefox via blocking WR, but not trivial/elegant
  • [giorgio] yes, lots of corner cases around caching and similar.
  • [krzystof] extension authors can move much faster than browser vendors, talking with the good guys here (community).
  • [timothy] valid use cases, the permission model goes a long way towards
  • [tomislav] We are considering "negative permissions" – allow the user to grant access to almost everything, except some specific sites. Some complexities need to be worked through (e.g. allowing *.google.com doesn't necessarily mean mail.google.com is accessible, as implied by existing permissions API, and as expected by current extensions).
  • [timothy] Might not be clear, but this is possible in Safari. You can open preferences for a site to see what extensions have access & select deny
  • [tomislav] might need to expose an API to answer "can I access this URL?"
  • [timothy] Supportive of this plan
  • [nir] instead of limiting the API, bring more transparency to the user, via a dashboard of pass activity.
  • [tomislav, kzrysztov, simeon] too spammy, not sure if it's usable for regular users.
  • [mukul] extensions activity log in Chromium (and Edge)

Issue #103: Add an API to trigger extension update

  • [nir] sometimes critical updates are delayed up to a full day. If extension is communitinga with a backend, it might have metadata.
  • [simeon] we have runtime.requestUpdateCheck, tells Chrome to ping CWS. After that, runtime.reload() would complete the update process.

[carlos] Question about more frequent meetings or engaging more often offline/via issues.

  • [timothy, tomislav, simeon] probably not more meetings, but we're aiming to be more responsive, feel free to ping us.
  • [simeon] might be less available in the coming months, trying to make the most effective use of the time he does have.
  • [alexei] Will Google send alternate or additional representatives?
  • [simeon] Not that I'm aware.
  • [alexei] What does this say about google's dedication to the group?
  • [timothy, tomislav] appreciate any time you might have.
  • [simeon] what we're doing is very important, just trying to balance with other requirements.

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