1232311 - Show `${name} submitted by ${submitter}` in installation doorhanger for signed add-ons

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect, P4)

Description

[Giorgio Maone [:ma1]]

+++ This bug was initially created as a clone of Bug #1196797 +++

1. Run Firefox 39 or 40 which don't require signing by default.
2. Install an extension that is unsigned and requires a restart to install, don't restart when told to.
3. Exit Firefox and start Firefox 41 or later which does require signing by default.

The staged extension install is thrown away as it doesn't meet the signing requirements of the new build. This is a little different to what happens to unsigned add-ons that are already installed, they are left in place and can be updated later to signed versions.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

I don't think we need (b) in this way. What we need to verify before signing is just that the developer can justify the value in the 'submitter' field.

We could have an option in the user management pages, where the user can request a submitter value, with a justification. An admin evaluates it and assigns the submitter value if everything's okay, and then the developer can use it. If a developer submits a version with an unassigned or incorrect submitter, it's auto-rejected with an explanation of how to request it. This way we separate it from the review process, which is already overburdened.

Comment 2

[Giorgio Maone [:ma1]]

(In reply to Jorge Villalobos [:jorgev] from comment #1)

> We could have an option in the user management pages, where the user can
> request a submitter value, with a justification. An admin evaluates it and
> assigns the submitter value if everything's okay, and then the developer can
> use it. If a developer submits a version with an unassigned or incorrect
> submitter, it's auto-rejected with an explanation of how to request it. This
> way we separate it from the review process, which is already overburdened.

Sounds like a plan, I really like it. Should we spin off your description as an AMO bug and leave this one in place for the add-ons manager / UX side?

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

I'd like to hear from Mossop and Andy first, since it's a non trivial effort that will only benefit a small group of developers who need this sort of extra verification.

Comment 4

[Andy McKay]

(In reply to Jorge Villalobos [:jorgev] from comment #3)
> I'd like to hear from Mossop and Andy first, since it's a non trivial effort
> that will only benefit a small group of developers who need this sort of
> extra verification.

I agree that it might be useful, but like with other installation changes I don't rate it as high priority.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Jorge Villalobos [:jorgev] from comment #3)
> I'd like to hear from Mossop and Andy first, since it's a non trivial effort
> that will only benefit a small group of developers who need this sort of
> extra verification.

The work to display such a field from install.rdf in the install UI is pretty straightforward, the work here would be all on AMO to ensure that is correct and meaningful to users. If I create an AMO account named "Norton Utilities" for example are you going to do the time and work to verify that I am Norton? If not this is an avenue to spoof the user into trusting an extension more than they should. The bar here should probably be pretty high. We don't generally display the owner of SSL certificates unless they are EV in Firefox for example because we know that CAs don't do enough verification for DV certificates for the information to be beneficial to users.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Dave Townsend [:mossop] from comment #5)
> The bar here should probably be pretty high.

I agree. Not only should we need to actually verify the user's identity, but it should only be done for cases where it's really needed (security-related add-ons, major software firms).

(In reply to Giorgio Maone from comment #2)
> Sounds like a plan, I really like it. Should we spin off your description as
> an AMO bug and leave this one in place for the add-ons manager / UX side?

Yes. Please please file the AMO bits on Github: https://github.com/mozilla/olympia

Comment 7

[Giorgio Maone [:ma1]]

(In reply to Jorge Villalobos [:jorgev] from comment #6) 
> Please please file the AMO bits on Github:
> https://github.com/mozilla/olympia

https://github.com/mozilla/olympia/issues/1177

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 9

[Jorge Villalobos [:jorgev] (he/him)]

We have no plans for doing this in the foreseeable future. Other forms of confirmation exist or are being worked on, and we haven't heard any user feedback on this particular issue.