[Task]: Display addon ID on listing page

[Rob--W]

Description

It is currently difficult for a user to know the addon ID for a given extension listing page.
An example of a use case is an enterprise administrator: to configure the behavior of an extension, they need to know the extension ID (reported at https://bugzilla.mozilla.org/show_bug.cgi?id=2009824).

Currently, the only way to discover the extension ID is either by installing an add-on, using third-party tools (e.g. my crxviewer) or interfacing with the API. These are not user-friendly.

Once we fix this issue, we should also update the documentation, currently pending at mozilla/extension-workshop#2237

Acceptance Criteria

• Extension listing shows extension ID somewhere, e.g. near the metadata / version fields.

┆Issue is synchronized with this Jira Task

[abyrne-moz]

This seems like a sensible idea. Can we add this to the More Information section of the listing page in a new field called Add-on ID?

[diox]

This is trivial to add, but the add-on ID can be confusing, since it can look like an email, even though it's not. Displaying it could be abused by developers looking to boost the legitimacy of their extension even though they don't necessarily control the "domain" part.

[Rob--W]

This is trivial to add, but the add-on ID can be confusing, since it can look like an email, even though it's not. Displaying it could be abused by developers looking to boost the legitimacy of their extension even though they don't necessarily control the "domain" part.

That is a good point. And against better practice, some even put a real email there.

A mitigation could be to only display the ID by default if it looks like a guid, and otherwise hide it by default (also not indexable by search engines). And then only show it when the user clicks through and confirms a warning that this ID is provided by the developer and carries no meaning other than being unique.

[wagnerand-moz]

A mitigation could also be to make sure it's never linkified and looks like like code, potentially by using a monospace-font or using code style formatting like this: extension@service.

[eviljeff]

Seems like a bit of a niche use-case for average Firefox users to me - anyone updating group policies will be able to understand JSON, so they can just go to https://addons.mozilla.org/api/v5/addons/addon/<addon-slug>/ and get all the details they need.

[Rob--W]

Seems like a bit of a niche use-case for average Firefox users to me - anyone updating group policies will be able to understand JSON, so they can just go to https://addons.mozilla.org/api/v5/addons/addon/<addon-slug>/ and get all the details they need.

Provided that they knew how to go there, and how to interpret it. If we already assume a technically inclined user, I could also suggest them to parse the extension package directly (maybe even with user-friendlier tools such as my crxviewer or Will's xpidump tool at https://williamdurand.fr/xpidump/). But these are not user-friendly to AMO users.

Besides enterprise policies mentioned in the first report, there are also other purposes of knowing the extension's unique identifier. @wagnerand-moz requested that at mozilla/extension-workshop#2237 (comment)

While this wouldn't work for enterprise users, it would help developers if we do not call it "UUID" but something like "Extension ID / UUID" in the developer details view, as a user noted at mozilla/extension-workshop#2237 (comment)

[eviljeff]

Provided that they knew how to go there, and how to interpret it. If we already assume a technically inclined user, I could also suggest them to parse the extension package directly (maybe even with user-friendlier tools such as my crxviewer or Will's xpidump tool at https://williamdurand.fr/xpidump/). But these are not user-friendly to AMO users.

I would suggest that "go to this url" (that is just replacing "/en-US/firefox/" with "/api/v5/addons/" from the detail url) is a significantly easier instruction than installing some 3rd party tool and downloading xpis. And interpreting the output it is easier than writing group policies, or any of the other use cases (though I'm not actually clear what the other use cases are, for someone who isn't the developer).

[willdurand]

I am proposing that we combine Andreas' and Rob's suggestions to address mat's concern, which isn't about whether we should do it or not since Product is OK with the idea but, instead, about preventing abuses. We could do something like this:

The text is an example, we'll need to refine it.

[abyrne-moz]

I agree with this approach and will find a string we can use.