Proposal: allow for programmatic access to extension publisher information

[Matt Frisbie]

Problem

Ownership of extensions can be transferred without users noticing. [1] [2] This is problematic, as it encourages malicious actors to acquire extensions [3] and abuse the user base with the knowledge that they will A) remain ignorant of the ownership change, and B) automatically receive updates from the new owner.

There should be some mechanism to know when the owner of an extension changes. This allows for extension users to make an informed decision about who is managing their software.

Recommended Change

Given that:

• All extensions are tied to a registered account (Chrome extensions to a Google account, etc)
• The web extensions API already offers a vehicle [4] for inspecting and managing other extensions (browser.management)

The browser.management API [5] [6] should be augmented to include the publisher email, name, and website (if available) for the developer account who published the current package version. "Publisher email" should be an email address that:

• Cannot be spoofed (is the primary account ID and cannot be entered via unverified plaintext input)
• Uniquely identifies the entity controlling the extension

"Name" and "Website" don't need to be unique or usable as an identity proxy, although they would be useful indicators of a change of ownership.

Example of values that would be sufficient for detecting an ownership change

export interface ExtensionInfo {
  … 
  publisherEmail: string;
  publisherName: string;
  publisherWebsite: string?;
}

Context:
[1] https://news.ycombinator.com/item?id=39620060
[2] https://github.com/classvsoftware/under-new-management
[3] extesy/hoverzoom#670
[4] https://developer.chrome.com/docs/extensions/reference/api/management
[5] https://developer.chrome.com/docs/extensions/reference/api/management#type-ExtensionInfo
[6] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/chrome/index.d.ts#L5515

[Federico Brigante]

Honestly, this is big. I regularly get emails from poachers and my extensions aren't even that popular. If browsers are serious about safety, then they should absolutely implement steps towards making this visible to users.

Providing an additional API for "extension managers" sounds good, but honestly I want to see browsers immediately warn the users before a new update is pushed, and the update should be delayed so that users are given a chance before the code is downloaded/run on their machines.

It might be good to include an escape mechanism so that genuine account changes (e.g. I move an extension from my personal account to my company account) are ignored or have a less scary message, but I don't know how to detect that in practice.

[Timothy Hatcher]

Safari does not currently support the management API, so we are neutral in that regard. We also ignore the author and homepage_url manifest keys.

However, our distribution requires an app in App Store, which is tied to a Team ID. When an app is transferred in App Store, the Team ID changes, and the extension will be disabled in Safari after it updates with the new Team ID.

With all that said, "extension stores" are out of scope, so this issue might be borderline.

[Rob Wu]

This request consists of two parts:

• Expanding the management extension API to return more metadata, specifically the publisher of the extension.
• Require extension stores to validate the accuracy of this information.

While this group can consider standardizing on the first, it cannot on the second, as @xeenon mentioned in the last comment. And imagine that if the second part were not to be implemented, that you would not find much value in having the requested API additions.

FYI: There is a public, CORS-enabled API to query information about Firefox add-ons published at addons.mozilla.org, documented at https://mozilla.github.io/addons-server/topics/api/addons.html

[Matt Frisbie]

First, I sincerely appreciate the consideration this proposal is being given.

The ultimate goal of this proposal is to protect extension users from silent ownership transfer. I can think of a handful of ways to address this problem:

1. All extension stores disclose active ownership via API. The Mozilla Add-on API is an excellent solution for Firefox. Given the requisite coordination and development overhead, I assume that there is no path to CWS or other extension marketplaces offering such an API.
2. Browsers auto-disable extensions upon ownership change, similar to when additional required permissions are added. (Described here, when Team ID changes: #558 (comment)). This requires an in-browser understanding of the publisher's identity, which does not currently exist, hence this proposal.
3. Allow extensions to self-police ownership. Via the web extensions API, implement some mechanism to detect when v1.0.0 was published by Publisher X, and v1.0.1 was published by Publisher Y.

I am not locked into any particular solution, but (3) strikes me as the simplest and most feasible. As mentioned above (#558 (comment)), name/website/email are important, but not sufficient if they cannot be verified.

To supplement this, some sort of publisher ID is required. Any unspoofable publisher ID would work:

• Doesn't need to be cryptographically verifiable
• Doesn't need to be human readable
• Can be pseudonymous
• Just as the browser.runtime.id value differs by vendor, this ID too can be completely browser- and store-agnostic. Hash of a user's verified email/team ID, etc.

Caveat: This implementation wouldn't allow for differentiation of self-transfers (#558 (comment)), although inclusion of a non-verified name/website/email could help with this. However, I could also see these being used as a smokescreen to allow new extension owners to conceal a transfer.

[Timothy Hatcher]

browser.runtime.id does include the Team ID in parenthesis for Safari. (But without management APIs that isn't that useful.)

[Oliver Dunk]

Removing triage label. I know @patrickkettner was interested in this, but I don't think we have reached any alignment internally at this point. Not adding the follow-up label since I'm not sure if this is something we are actively investigating but feel free to add it Patrick.