Display avatar and profile name from Firefox Accounts

[pdehaan]

Firefox Accounts can provide additional human-oriented information about the user:

• A user-configured avatar image
• A user-configured display name or nickname

To do:

• retrieve and remember all profile information (with fallbacks)
• resolve fallback avatar asset (static bundled in, discovery, etc)
• resolve fallback display name to user email address
• display avatar and display name in account details

Original
I signed up for a dummy FxA account and set my avatar and display name, but they aren't being displayed on the Lockbox site. Not sure if we get those from FxA, or if we have to query the profile server or something.

[linuxwolf]

The current visuals closely match the design from @changecourse; would need feedback/opinion from UX before we do that.

Technical-wise, the FxA userinfo endpoint can provide all this information, if the user has entered it. In the case of the avatar, it's a URL to the image.

There are also some additional considerations here, such as:

• what is displayed if the user does not set an avatar?
• what is displayed if the user does not set a display name?
• if the user has set a display name, where (if anywhere) is their "username" (email) displayed?

[pdehaan]

what is displayed if the user does not set an avatar?

I can't remember if FxA returns a default avatar, otherwise, we could just display a lockbox icon, I imagine.

what is displayed if the user does not set a display name?

If there isn't a display name, I think it'd be safe to fall back to displaying their FxA email address (which is what we display currently).

if the user has set a display name, where (if anywhere) is their "username" (email) displayed?

I think we'd only display their display name, if set. And otherwise show their email. If they've set a display name in the FxA settings, it's probably safe to say that's what they'd prefer to see.

[linuxwolf]

@pdehaan those are possibilities we can consider, with vetting from UX and product ( @mozilla-lockbox/product ).

We ought to reconcile anything done here in this regard with what is planned for mobile.

[changecourse]

@pdehaan I agree with much of your expectation here for what we should do, assuming we have that information... (in fact, I originally designed it that way, heh)

With this first pass on FxA, we went with the lowest common denominator of what we'd have access to and what was required for account creation (the email address)

I think we'd want to have an enhanced option that includes any and all information...

Here are my initial thoughts:

1. Do we have display name? Use it instead of email address for that field (but do we need to consider edge cases for length and whether or not both the first and last name have been filled... just first name?)
2. If we have a display image, use it, both with email or with name... (Do we move towards a situation where the display image is enough of an indication of the user's account that we no longer need the label of email or user name? Not a huge need currently because we have the space, but may be an issue in the future.

[linuxwolf]

Here are the things FxA lets a user specify (today):

The results from the userinfo endpoint look something like this:

{
  "email": "[email protected]",
  "uid": "e7e172ed4af74e589cf086253b5a66a7",
  "displayName": "Matthew A. Miller",
  "avatar": "https://s.gravatar.com/avatar/ee091916d54a5c32c7d9ad81651fd204"
}

We cannot safely separate first name and last name.

[pdehaan]

@linuxwolf, what does the userinfo endpoint return if you don't have a displayName or avatar set?
Do we get empty strings, default values, or missing fields in the response?

[changecourse]

Pending prioritization of this issue, I can mock up the 2-3 different states of your FxA account depending on the rules we set forth.

This could and should be coupled with some of the other needs for this area, including the ability to access preferences, sign out, and potentially access your FxA account via dropdown, covered in #384

[linuxwolf]

@pdehaan if anything is not set by the user, it is omitted. The only things that are guaranteed to be there are (given the scope profile):

• uid
• email

The former is the account identifier, and the latter is required to create and maintain an account.

[pdehaan]

what does the userinfo endpoint return if you don't have a displayName or avatar set?

Looks like we get missing fields:

{
  "avatar": "https://firefoxusercontent.com/9e864377b53e688ad25397e97e060d41",
  "displayName": "Petern Stuff",
  "email": "...",
  "uid": "..."
}

{
  "email": "...",
  "uid": "..."
}

And FxA seems to use the following default avatar: https://accounts.firefox.com/images/0e592e73.default-profile.svg

[jimporter]

If we do show the avatar, what can we do to minimize the remote network requests for it? I'd like to avoid loading remote resources in our main UI so that the kind of users who'd check their network logs won't feel uncomfortable about what we're doing. An unexpected network request could at least give the appearance of us doing something sneaky.

[pdehaan]

I'm not sure we could avoid the avatar network request. My dummy Firefox Accounts avatar is https://firefoxusercontent.com/9e864377b53e688ad25397e97e060d41 which is resized+optimized+hosted by FxA (or the profile server?). Not sure how we could convert that into a data-uri and make sure it still keeps in sync w/ FxA.

Although +1 to inlining a default avatar if the user doesn't have a value set.
I haven't talked to the FxA folks lately to see if they have stats on the %% of users that set an avatar and display name, versus leaving it blank (default).

[jimporter]

I don't know when we already talk to the FxA server (just during setup? every time we unlock?), but I think that would be the best time to do it. If that only happens once and we want to keep this in sync, I'd probably lean towards just showing the email address. I've seen lots of instances of people getting (probably unnecessarily) nervous about "random" network requests, and I can imagine these users would be even more upset if those were happening in their password manager.

[linuxwolf]

FxA servers are contacted when:

• When the user is upgrading/linking their guest mode to an FxA account
• When the user is signing in (unlocking)
• (some point between startup and the first FxA server action, to discover config information)

Once synchronization is implemented, remote servers are contacted when:

• A user adds/updates/removes an entry locally
• periodically to find remote changes

We can look into the base account slurping it into a data: URI.

(for @rfk et al) Regarding the default avatar, I wonder if it might be appropriate to discover that somehow, similar to how we (are supposed to) discover authentication/authorization information. We can bundle one, but I can see value in discovering it.

[rfk]

If we do show the avatar, what can we do to minimize the remote network requests for it?

I believe the OIDC spec has some provision for returning userinfo data directly in the id_token, which we might be able to use to save a network request if you're interested. We probably don't implement it yet, but it's a possibility.

Regarding the default avatar, I wonder if it might be appropriate to discover that somehow

I agree, I think it would be useful for consistency is nothing else. We also have a little animation that we do while the avatar is loading that could be re-used.

Would it make sense to just always return an "avatar" in the userinfo response, defaulting it to the placeholder image if the user did not upload one? Otherwise, let's bikeshed a way to discover this from the openid configuration document.

Not sure how we could convert that into a data-uri and make sure it still keeps in sync w/ FxA

I'd prefer to avoid this if we can; can we rely on browser caching to do an acceptable job here, perhaps with some tweaks to caching headers sent by FxA?

[changecourse]

So if I'm understanding correctly, ideal state would be something like this?

Then we'd account for situations involving no avatar uploaded (display placeholder image) or no display name entered (display email instead)

[linuxwolf]

@rfk

I believe the OIDC spec has some provision for returning userinfo data directly in the id_token, which we might be able to use to save a network request if you're interested. We probably don't implement it yet, but it's a possibility.

Right now the id_token contains some identifiers, but nothing that is really considered personally identifiable information. Adding avatar changes that, and potentially changes how we'd keep track of it.

I agree, I think it would be useful for consistency is nothing else. We also have a little animation that we do while the avatar is loading that could be re-used.

Would it make sense to just always return an "avatar" in the userinfo response, defaulting it to the placeholder image if the user did not upload one? Otherwise, let's bikeshed a way to discover this from the openid configuration document.

I think always returning an "avatar" URI would be just as effective here. Would there need to be an indicator that this avatar was not set by the user? Personally am not sure if it makes a difference to Lockbox.

Either way, this is looking like a new feature/discussion to add to FxA somewhere (-:

I'd prefer to avoid this if we can; can we rely on browser caching to do an acceptable job here, perhaps with some tweaks to caching headers sent by FxA?

I needed to refresh my understanding on HTTP caching, and then we need some understanding on how these avatars are published. It appears (for accounts.firefox.com) it's always from "firefoxusercontent.com", a Mozilla-owned domain. What's not clear is if the content's full URL changes for each avatar or not. If it does, then it seems fine to rely on browser caching.

A glance at the headers I get for my own avatar don't seem to include a Cache-Control header, but do include ETag, Last-Modified, and Date.

[rfk]

What's not clear is if the content's full URL changes for each avatar or not

Yes, I believe the URLs are intended to be immutable, with a new avatar upload generating a new URL.

[linuxwolf]

PR #486 is pending code review.