Skip to content

Latest commit

 

History

History
169 lines (137 loc) · 12 KB

2024-03-14-wecg.md

File metadata and controls

169 lines (137 loc) · 12 KB
Raw

WECG Meetings 2024, Public Notes, Mar 14

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=65f23e00,384 Call-in details: WebExtensions CG, 14th March 2024 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #556, github issues

The meeting will start at 3 minutes after the hour. See issue 531 for an explanation of this agenda format.

  • Announcements (2 minutes)
    • Simeon's affiliation
    • Meetup in San Diego next week, March 18-20 (issue 525)
  • Triage (15 minutes)
    • Issue 557: Proposal: Extension Loading Priority
      • Creator: @erosman
      • Goal: Discuss whether this is an issue we should address and, if so, identify next steps.
    • Issue 558: Proposal: allow for programmatic access to extension publisher information
      • Creator: @msfrisbie
      • Summary: In order to allow "extension manager" extensions to react to ownership changes, browser.management should expose information about an extension's developer.
      • Goal: Discuss whether it makes sense to expose developer metadata to other extensions.
    • Issue 563: ExecutionWorld and StyleOrigin should use lowercase values
      • Creator: @xeenon
      • Summary: Issue suggests aligning on how we handle the casing of constant and enum string values.
      • Goal: Determine next steps for this issue.
    • Issue 565: Support multiple user script worlds in the user scripts API
      • Creator: @rdcronin
      • Goal: Identify how this issue is different from PR 560. NOTE: 560 is the next topic.
  • Timely issues (10 minutes)
    • PR 560: Proposal: Multiple user script worlds
      • Creator: @rdcronin
      • Summary: New proposal expanding the userScripts API to support per-script worlds.
    • PR 529: Add permissions.requestSiteAccess() API proposal
      • Creator: @EmiliaPaz
      • Summary: Emilia has updated the proposal based on feedback since last meeting.
  • Check-in on existing issues (20 minutes)
    • Issue 547: Proposal: document browser.storage.managed initialization semantics and provide initialization event
    • Issue 538: Proposal: RegisteredContentScript.workers property to inject WorkerScope(s)

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Rémi Pujo (Dashlane)
  3. Todd Schiller (PixieBrix)
  4. Patrick Kettner (Google)
  5. Carlos Jeurissen (Jeurissen Apps)
  6. Tomislav Jovanovic (Mozilla)
  7. Dávid Tóta (AdGuard)
  8. Mukul Purohit (Microsoft)
  9. Tim Heflin (Keeper)
  10. Simeon Vincent (Mozilla) (left after announcements)
  11. Kiara Rose (Apple)
  12. Timothy Hatcher (Apple)
  13. Ayooluwa Isaiah (Unaffiliated)
  14. Richard Worth (Capital One)

Meeting notes

Simeon's affiliation

  • [simeon] For the past year I had been officially Unaffiliated in the WECG; I am currently in the process of switching to represent Mozilla officially in this group.
  • [timothy] I approved the change in the W3C system.

Meetup in San Diego next week, March 18-20 (issue 525)

  • [simeon] Short version, we're going to spend time in person to discuss many issues.
  • [timothy] David is going to send an e-mail with the logistics. If you have any dietary restrictions, let us know.
  • [rob] We are going to take meeting notes and publish them in the repo, similar to what we did in the TPAC 2023 meeting.
  • [tomislav] Have we already put the meeting slots in the calendar?
  • [timothy] Good question, I will double-check and follow up on that.
  • [carlos] Do we have a schedule of topics?
  • [simeon] We have a list of topics suggested by Chrome folks.
  • [patrick] I will post the schedule in the issue.
  • (Simeon left the meeting because of a schedule conflict, Tomislav continues chairing this meeting today)

Issue 557: Proposal: Extension Loading Priority

  • [timothy] Don't know if we need to standardize on this. We're currently starting on startup, because extensions like content blockers need to start early.
  • [tomislav] We have similar implementation details for content scripts and such.
  • [patrick] Agree, this is something we could record as a Chromium issue.
  • [rob] The question of what the APIs do around startup comes up occasionally. Let's add a non-normative note to our future spec to call out the relevance of startup.
  • [timothy] Sounds good to me.

Issue 558: Proposal: allow for programmatic access to extension publisher information

  • [tomislav] This is an interesting thing, not sure if it is in-scope for our group since it is about publishing.
  • [patrick] I asked Matt Frisbie, who is a GDE (not Googler). The use case is around publishing, but not specific to publishing. Safari doesn't support the API, how about Mozilla?
  • [rob] We do support the management API.
  • [patrick] Anyone against adding this functionality to the API?
  • [rob] I'm not opposed to exposing the metadata from the extension, but question how it would help the extension author when stores are not verifying/enforcing the value. Anyone can put anything in the manifest.json file, without it having any relevance to the actual extension owner. Addons.mozilla.org has an API with CORS that offers information about add-on metadata, including ownership. That would be more useful than the requested addition to the management API.
  • [rob] And even if there was validation, it wouldn't catch ownership changes by transferred developer accounts.
  • [patrick] Focusing on good enough rather than perfect, we cannot catch transferred developer accounts with this API.
  • [rob] In the interest of time, let's continue this discussion on the issue itself.

Issue 563: ExecutionWorld and StyleOrigin should use lowercase values

  • [timothy] I noticed an inconsistency in the case used in the extension APIs. Suggest to standardize on lowercase string values. If exposed to JS, I am still in favor of what Devlin calls the screaming case, but the values being lowercase.
  • [tomislav] Is the streaming case about the identifiers or the actual string values?
  • [timothy] It seems that Chrome is starting to prefer both. Is that accurate Patrick?
  • [patrick] That is my understanding, but I have to double-check.
  • [tomislav] No strong preference.
  • [rob] No strong opinions here, consistency would be nice though. What are the next steps here?
  • [tomislav] Maybe a topic for the in-person meeting next week.

Issue 565: Support multiple user script worlds in the user scripts API

  • [rob] There is a pull request associated with the issue, at #560.
  • [tomislav] Wasn't it part of the original proposal but not implemented by Chrome?
  • [rob] It was descoped from the MVP.

PR 560: Proposal: Multiple user script worlds

  • [rob] This is the PR that we just mentioned. Please take a look and comment if you have feedback.

PR 529: Add permissions.requestSiteAccess() API proposal

  • [rob] Emilia is not here, but this is a request for feedback.
  • [tomislav] I have a question to Timothy: you had a question about whether unsupported options are allowed or not. E.g. when tabId+url is passed, Chrome/Firefox could match both (AND), consistent with other extension APIs. But if an engine does not recognize a value (e.g. Safari), then what happens with the request?
  • [timothy] We can support tabId if it is provided. Side note, I suggested renaming url to patterns.
  • [tomislav] If an extension passes an object with both values, with one of them ignored in some browsers (OR), the experience would be inconsistent across browsers.
  • [timothy] Wondering what Chrome plans; if documentId is provided, then tabId isn't relevant.
  • [rob] If an extension use case exists where it wants to interface with the tab without knowing the URL, then Safari could still support tabId, right?
  • [timothy]
  • [rob] So to summarize, if an extension knows the tabId or url/pattern, it can include the fields, and the browser can then show the access request, using AND.
  • [timothy] I think we can agree on that.
  • [timothy] If documentId is passed, what would happen? Firefox doesn't support it, right?
  • [tomislav] Like any API, an error is thrown.
  • [rob] We don't support documentId at all, so extensions cannot get a meaningful documentId to pass to the API. Does Safari support documentId?
  • [timothy] We have a bug tracking it.

Issue 547: Proposal: document browser.storage.managed initialization semantics and provide initialization event

  • [todd] Our extension is extensively used by enterprises, and relied upon for compliance use cases. Issue we run into is inconsistencies in detecting whether it has been set up or is empty at all. Also differences in behavior in Firefox vs Chrome. Can we have an event handler to determine whether managed storage is ready.
  • [tomislav] In Firefox there is no late loading of managed storage; It is there or not.
  • [todd] Related to behavior discussed earlier, what is available near startup.
  • [rob] The API could wait for the managed storage initialization to be ready before returning.
  • [patrick] I will check in with the engineering team and get back.
  • [rob] Does Chrome support detecting managed preferences, by design.
  • [patrick] I don't know.
  • [todd] There is also a chrome://policy tab where the policy can be reloaded.
  • [tomislav] If that is the case, then it could make sense to support storage.managed.onChanged.
  • [todd] The event exists but does not fire on initial load.
  • [timothy] We don't support storage.managed.
  • [rob] Next step is for Chrome to follow up and get back.

Issue 538: Proposal: RegisteredContentScript.workers property to inject WorkerScope(s)

  • [rob] This is a feature request to support content scripts in workers.
  • [] Use case?
  • [rob] Patching evil workers.
  • [timothy] I would be fine with adding it.
  • [tomislav] Implementation concerns.
  • [rob] Besides implementation difficulty, I also have concerns about abuse/security. Among workers are service workers, which can have long-lasting effects, potentially post extension uninstall.
  • (Giorgio joined the meeting now, mixup due to timezone switch)
  • [giorgio] The need for this feature is to patch the environment of the script, e.g. fingerprinting.
  • [giorgio] Service worker could be unregistered when an extension is uninstalled.
  • [rob] The security and implementation issues can be addressed, but the effort required to do that would not fit in our current roadmap, and it is unlikely for us to prioritize this work anytime soon.
  • [timothy] Similarly, it would not be a high priority to us either.
  • [giorgio] Noting that in Firefox it is already possible to modify the worker environment with webRequest.
  • [rob] That's why we require the webRequestFilterResponse.serviceWorkerScript permission.

The next meeting will be on Thursday, March 28th, 8 AM PDT (3 PM UTC)