Skip to content
This repository has been archived by the owner on Apr 27, 2023. It is now read-only.

Provide a signed version of the Core Addon; potentially enable “Badging" (CA-P0, CA-P1) #159

Closed
marniepw opened this issue Nov 13, 2020 · 14 comments
Assignees

Comments

@marniepw
Copy link
Contributor

marniepw commented Nov 13, 2020

Provide a signed version of the Core Addon

  • And potentially enable “Badging"
@marniepw marniepw changed the title Provide a signed version of the Core Addon; potentially enable “Badging Provide a signed version of the Core Addon; potentially enable “Badging" Nov 13, 2020
@rhelmer
Copy link
Contributor

rhelmer commented Nov 18, 2020

I discussed this in email with amo-admin folks, Jorge thinks that this is all OK and should work fine. We should determine the format of the JSON file we need here and land it in our repo (normally it's added by AMO during signing but since we're using the privileged addons-pipeline thing we need to add it ourselves)

@rhelmer
Copy link
Contributor

rhelmer commented Nov 21, 2020

For the badging piece (which also allows installations from arbitrary origins like the rally website ;)), the signing automation on AMO seems to handle this and it generates a file like:

{
  "addon_id": "{c2c003ee-bd69-42a2-b0e9-6f34222cb046}",
  "states": ["recommended"],
  "validity": {
    "not_after": "2024-06-13T18:45:15Z",
    "not_before": "2019-06-14T12:45:15Z"
  },
  "schema_version": 1
}

This file is named mozilla-recommendation.json and must be present in the root of the extension (sibling to manifest.json) before it is signed. I took this example from https://addons-dev.allizom.org/en-US/firefox/addon/auto-tab-discard/

@rhelmer
Copy link
Contributor

rhelmer commented Nov 21, 2020

Tracking releasing a signed v2.2 in #195 which is currently blocked by #66, once those are ironed out we can get the signed version going. We'll want to make sure to include the recommendation JSON file. Ideally we can test this with a dev-signed build but we'll have to see.

@Dexterp37 Dexterp37 removed their assignment Dec 1, 2020
@rhelmer rhelmer changed the title Provide a signed version of the Core Addon; potentially enable “Badging" Provide a signed version of the Core Addon; potentially enable “Badging" (CA-P1) Dec 7, 2020
@rhelmer
Copy link
Contributor

rhelmer commented Dec 7, 2020

@rhelmer
Copy link
Contributor

rhelmer commented Dec 7, 2020

I think the synopsis here is that we are OK with CA-P1, but without a recommendation badge we will get an additional "unknown site" prompt (since we're triggering install from our website not AMO). The AMO signer handles this but the privileged signing automation currently does not.

I'll add this prompt to the proposal and give it a label so it's clearer what we are talking about here.

One alternative to getting the privileged signer working for this (which is owned by addons-pipeline folks, add-on and releng), we should talk to webextensions team about the idea of privileged extensions being automatically badged "By Mozilla".

This is covered further in https://blog.mozilla.org/addons/2020/10/05/new-add-on-badges/ although that does not go into detail about this prompt, that's the feature that enables it.

@Dexterp37
Copy link
Contributor

@rhelmer is the "unknown site" the only prompt that badges allow us to suppress? If so, is there any concrete value in hosting outside of AMO?

@rhelmer rhelmer changed the title Provide a signed version of the Core Addon; potentially enable “Badging" (CA-P1) Provide a signed version of the Core Addon; potentially enable “Badging" (CA-P0, CA-P1) Dec 7, 2020
@rhelmer
Copy link
Contributor

rhelmer commented Dec 7, 2020

@rhelmer is the "unknown site" the only prompt that badges allow us to suppress? If so, is there any concrete value in hosting outside of AMO?

No, hosting on AMO makes our lives a bit easier too as it's more self-serve (including an API) and handles updates for us. Unfortunately hosting on AMO doesn't make a difference for suppressing the prompts since the issue is getting the "Recommended" badging in place, which requires that the signer understands how to do this.

The real problem here is that we're starting an install from an unknown origin (our website), if the core add-on is hosted on AMO then triggering an install from there won't have this problem, this really comes down to signing.

Since the core add-on requires privileged signing right now we have to use the privileged signer in any case, and then can upload the output of that to AMO for hosting.

This all gets much simpler if/when we can make the core add-on unprivileged :) However I think there's a case to be made that privileged add-ons are "By Mozilla" and should be able to be self-hosted like this, and we should leave the door open for needing to use a privileged core add-on in the future in case we need to handle some tricky problem.

@rhelmer
Copy link
Contributor

rhelmer commented Dec 7, 2020

Chatted w/ @kewisch in slack, this is something they'd like to support in the privileged signer (ability to handle badging/mozilla-recommendations.json). I'll figure out where this needs to happen upstream and link to the bug/issue here.

@rhelmer
Copy link
Contributor

rhelmer commented Dec 7, 2020

@rhelmer is the "unknown site" the only prompt that badges allow us to suppress? If so, is there any concrete value in hosting outside of AMO?

One confusing bit I should point out - it's not really about where the add-on itself is hosted, it's about what origin the user is on when the install is triggered.

Concrete examples:

  1. user is on https://mozilla-ion.github.io/ion-core-addon/ and starts core add-on install
  2. user is on moz-extension://[...] and starts study install

Both of these add-ons could be hosted on AMO but we will still get this prompt, unless we redirect users to the AMO page and the install is started there (this is the workflow we're forced into for Chrome so this is strictly about improving the Firefox-specific user experience)

@Dexterp37
Copy link
Contributor

One confusing bit I should point out - it's not really about where the add-on itself is hosted, it's about what origin the user is on when the install is triggered.

Got it, now it's much clearer, thanks! So it's not so much about the origin, but about the referrer?

@rhelmer
Copy link
Contributor

rhelmer commented Dec 9, 2020

One confusing bit I should point out - it's not really about where the add-on itself is hosted, it's about what origin the user is on when the install is triggered.

Got it, now it's much clearer, thanks! So it's not so much about the origin, but about the referrer?

Yeah the terminology here is a bit confusing, I think that's fair to say :) It's not technically using the HTTP referrer since this is all client-side code, but it's conceptually similar enough. It's basically the origin that was loaded when the install was triggered (it could be triggered by linking to a XPI with the proper mime-type, this does not change the origin or do a referrer check but the client knows to check this)

@rhelmer
Copy link
Contributor

rhelmer commented Dec 9, 2020

Actually even simpler for our purposes, there is a patch up for Firefox now that will remove this prompt for all privileged add-ons, without requiring the badging: https://bugzilla.mozilla.org/show_bug.cgi?id=1681331

If that patch lands in time for Firefox 86 then it will go live on 2021-01-26

@rhelmer
Copy link
Contributor

rhelmer commented Dec 9, 2020

On the signing front, our part for the 0.6.0 ion-core-addon release is done there and we are waiting for final sign-off from the add-ons folks (confirmed with them in slack).

@rhelmer
Copy link
Contributor

rhelmer commented Dec 17, 2020

We've done a github release with our production signed extension, and pointed our GitHub Pages site at it.

Instead of badging, the WebExtensions team landed a patch in Firefox 85 (currently Beta) which automatically bypasses this prompt for privileged add-ons, so I think we're good here!

@rhelmer rhelmer closed this as completed Dec 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants