Skip to content

Latest commit

 

History

History
174 lines (128 loc) · 13.4 KB

2022-06-09-wecg.md

File metadata and controls

174 lines (128 loc) · 13.4 KB
Raw

WECG Meetings 2022, Public Notes, Jun 9

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=62a13800,3c0 Call-in details: WebExtensions CG, 9th June 2022 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #220, github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
  • Other new issues
    • Issue 216: Support action.setBadgeTextColor()
    • Issue 217: Make WebExtension Javascript APIs available in WebWorkers spawned from a bundled document
    • Issue 218: Inconsistency: Meta description character length
    • Issue 219: Inconsistency: Right-click missing Options menu item for the browser extension
    • PR 221: Add host_permissions and optional_host_permissions
    • PR 222: Move list of meetings into a collapsible section
    • Issue 223: Proposal: if extension has "storage" permission it should be allowed to use Web Storage API and Cookies API
    • Issue 224: Extensions Store Badge (get the extension button)
    • Issue 225: Document DNR's regex validation rules
  • Open discussion queue (add yourself at the bottom) *
  • Check-in on ongoing issues
    • Issue 100: Inconsistency: Mandatory manifest keys
    • Issue 162: DNR: disable individual static rules

Attendees (sign yourself in)

  1. Simeon Vincent (Google)
  2. Rob Wu (Mozilla)
  3. Tim Heflin (Keeper)
  4. Mukul Purohit (Microsoft)
  5. Bradley Cushing (Dashlane)
  6. Oliver Dunk (1Password)
  7. Benjamin Bruneau (1Password)
  8. Carlos Jeurissen (Jeurissen Apps)
  9. Richard Worth (Capital One)
  10. Brian Weinstein (Apple)
  11. Gaurang Tandon (Blaze Today)
  12. David Johnson (Apple)
  13. Tomislav Jovanovic (Mozilla)
  14. Sam Macbeth (DuckDuckGo)
  15. Felipe Erias (Igalia)
  16. Alexei (Privacy Badger)
  17. Frederic Rivain (Dashlane)
  18. Tyler Carson (Keeper)
  19. Ellie Epskamp-Hunt (Apple)

Meeting notes

TPAC 2022 update

  • [simeon] Planning to draft a shortlist of topics soon. Sorry for the delay.

Issue 216: Support action.setBadgeTextColor()

  • [carlos] Applies to both browserAction and action.
  • [timothy] Largest concern with color APIs is dark mode. Should ideally have a way to specify two colors.
  • [tomislav] When the feature was originally introduced, the use case was to support different “levels”, e.g. warnings/error in the UI.
  • [simeon] Before the meeting I introduced the "Chrome: follow-up" label to help with tracking these kind of issues. I'm going to discuss this with the team and provide feedback.
  • [tomislav] To Tim's point, we welcome support for that.
  • [simeon] Reminds me that we have work in progress on allowing extensions to specify different colors that adjust based on browser/user/OS preferences. I'll get back with that.

Issue 217: Make WebExtension Javascript APIs available in WebWorkers spawned from a bundled document

  • [bradley] Reporter is working for Dashlane; I'll read into this and get back to this.
  • [rob] Let's postpone this topic to the next meeting.

Issue 218: Inconsistency: Meta description character length

  • [carlos] Different stores have different length / character requirements. Would make sense if we start with documenting the guidelines first.
  • [simeon] On the Chrome side, similar to the name field, there is no limit imposed in the field, whereas the Chrome Web Store imposes a limit.
  • [rob] Was discussed before in name/short_name (#60). We could consider looking into minimum requirements, but the webstore policies etc. are out of scope. Even minimums cannot be guaranteed, e.g. if the description does not fit in the UI.
  • [simeon] The current charter's scope is browser implementations, web stores are out of scope. How could we account for these kinds of developer concerns in the spec?
  • [timothy] I think that we talked about this before, and considered including notes in the spec
  • [tomislav] “Non-normative note” is the term you're looking for.
  • [simeon] In the context of this meeting, we could consider adding a normative note to describe “safe” lengths.

Issue 219: Inconsistency: Right-click missing Options menu item for the browser extension

  • [carlos] Would be nice if the Options menu option is available by default everywhere.
  • [timothy] No strong reason not do it
  • [tomislav] Similarly don't see a reason not to do this, but the UI is not a part of this group. File a bug in Firefox if a change is desired.
  • [mukul] Agreed with Tomislav, changes in UI is a differentiator for Edge.
  • [simeon] Another way to frame this is, not all browsers need to agree on the UI. Capabilities may be useful, e.g. exposing a boolean through the extension API to show whether the functionality is available.

PR 221: Add host_permissions and optional_host_permissions

  • [simeon] LGTM
  • [tomislav] Will LGTM today/tomorrow.

PR 222: Move list of meetings into a collapsible section

  • [simeon] List of minutes is overwhelming. Proposed PR moves notes in separate sections and mentions the latest meeting at the top.
  • [timothy] Approved
  • [rob] I'll provide feedback asynchronously, on the PR.

Issue 223: Proposal: if extension has "storage" permission it should be allowed to use Web Storage API and Cookies API

  • [rob] Browser/user settings can disable storage APIs. Reporter is asking for a way to guarantee the availability of these APIs, e.g. with extension permissions.
  • [simeon] This is the downside of building upon the web platform. Using extension-specific APIs is a way around this. I'd currently say that this is working as expected, but can follow up offline.

Issue 224: Extensions Store Badge (get the extension button)

  • [simeon] The reporter asks for images/resources. This seems more like a community question and is out of scope for this group. But on behalf of the reporter: browser vendors, please take a look at the issue and respond on the issue.

Issue 225: Document DNR's regex validation rules

  • [simeon] Chrome has constraints on regexp support, which needs to be documented/specified better.
  • [rob] Safari/Webkit's implementation has an even more constrained regexp format, but it does not have an arbitrary cut-off / length limit like Chrome's.
  • [timothy] I was trying to quickly look up the source, and it seems that there is indeed not a length limit.

Issue 100: Inconsistency: Mandatory manifest keys

  • [simeon] icons requirement?
  • [timothy] We require it in the App store, but not in Safari. It falls back to the icon of the app container (all Safari extensions should be packaged in an app).
  • [tomislav] Technically the ID is not required, but it is strongly recommended to include it. We are considering requiring it for submission of MV3 extensions to AMO.
  • [simeon] Let's define the 3 common keys as required and document browser-specific requirements in non-normative notes.

Issue 162: DNR: disable individual static rules

  • [felipe] Quick update from my side: worked on performance issues. Looked into a previously suggested solution, i.e. rate-limits.
  • [simeon] Last week I looked at this issue to see if there was anything specific that the Chrome team could do. I saw a CL, but the last update was a month ago. Does that patch represent the latest, or are you expecting the CL to change?
  • [felipe] The CL implements the current API proposal. Basically, I worked on it until I was able to do testing and use it to iterate on the proposal.
  • [simeon] So the API proposal is in a state where we can take a hard look at, or is it something we should take a look at once in a while?
  • [felipe] You could take a hard look at it to see if the API and the approach to implementing it make sense. If that's not the case, I will update the proposal and implementation.

(out of topics after 45 minutes) Issue 160: Ensure consistency of action.openPopup API across browsers

  • [oliver] I have looked at the behaviors of openPopup across browsers and documented the results. Would be great if everyone could take a look at it and see if it makes sense, and then implement it consistently everywhere.
  • [timothy] Looks sensible, thanks. I'll take a look.

PR 186: Add mock for browser.secureStorage proposal

  • [oliver] Renamed polyfill to mock.

PR 226: Update browser.secureStorage proposal with authentication levels

  • [oliver] Updated proposal based on last meeting where we discussed authentication levels.
  • [simeon] Will look at these two PRs after the end of the meeting.

Redundant labels

  • [carlos] We have quite a few labels that aren't being used, especially defaults provided by GitHub.
  • [carlos] Also thinking we could use the projects feature from GitHub to
  • [rob] We have considered using more Github features, but sticked to the basic issues/PR so that there is not too many places that we'd need to follow/triage.
  • [simeon] Just occurred to me that we could use GitHub's kanban board to track items that need follow-up from individual vendors. Getting back on track, I'm open to using more github features. If anyone has thoughts on how we can leverage GitHub to better achieve our goals, please let us know.

Host permission changes

  • [alexei] Opt-in host permission changes are a major source of concern. Don't understand the benefit of denying permissions by default, but can see it causing confusion. We know users don't read prompts.
  • [timothy] Safari's perspective: we introduced this model when we added support for WebExtensions. We saw that many extensions asked for broad host permissions upfront. Between the user installing the extension and the extension using the permissions, the user may already have forgotten about the extension, so we wanted to bring the permission request closer to the time of use, similar to the rest of the Apple ecosystem.
  • [alexei] What you're saying makes sense for extensions that work on a particular set of sites, but I don't see how that works for extensions that operate everywhere.
  • [simeon] Does this happen at install time, or is there an extra grant flow?
  • [timothy] There is an extra button and dialog flow.
  • [simeon] Briefly touched on in the last meeting, there will be an extra grant flow in Chrome too: extensions will need to get a user gesture and call permissions.request(). Sounds like Safari has an extra option to click when enabling an extension in the settings menu?
  • [timothy] Yes, there's another box to check in a menu. You cannot request <all_urls> via permissions.request() in Safari. The dialog allows the user to grant for everything, which is off by default or an additional button/dialog to grant all.
  • [oliver] Is there a user interaction requirement? Would be nice to document that. We have encountered issues where we send a message to our app and when we get a response we lose the user gesture that triggered the flow in the first place.
  • [tomislav] opening popups requires user gestures on the web platform side, but extension APIs are mostly async, and the gesture may be lost.
  • [alexei] When the user installs uBlock Origin, AdGuard or Ghostery, the user won't read and click approve. But now the user has to read/confirm another prompt. I don't see how it helps users. It harms extensions.
  • [simeon] This is where malicious actors are impacting legitimate actors. Our assessment is that users often don't understand the extent to which they have given extensions permission to run everywhere and potentially collect data and do nefarious things with it.
  • [tomislav] Even for good actors, people don't understand the implications of installing the extension. Users are surprised that the extensions are able to access all websites, including their banking websites. This is to give users more visibility and control.
  • [rob] End of meeting, let's file an issue for this topic so we can discuss it in more detail.

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