Set fxa device name for standalone mobile libraries via user agent

[mcomella]

I'm creating a standalone sync library for Android (and there's a counterpart on iOS) and these should have reasonable names in the fxa device list. Currently, my device name is showing up as Firefox @MOZ_APP_VERSION@, Android, which I believe is getting set from my user agent (see code in userAgent.js) when I request my account to go from Engaged to Married.

Proposal
I propose we standardize the user agent for these libraries so the server can properly set the device name on sign-in (or Engaged->Married). The user agent may want to take into account (including debugging info):

• OS & version
• Form factor (on Android, "Mobile" or "Tablet"; on iOS, device name instead)
• The library name & version
• The name of the application using the library.

While the device name, for the user, should specify:

• OS
• The name of the application using the library
• Form factor (the user can own multiple Android devices using the same applications)

For user agent, I propose:

Mobile-<OS>-Sync/(<form factor>; <OS> <OS-version>) (<Application-name>)

("Mobile" is consistent with our request for the sign-in context)

Which can be parsed to the initial device name:

<Application-name>, <OS> <form factor>

For context, the current iOS user agent looks roughly like:

Firefox-iOS-FxA/<AppInfo.appVersion>b<AppInfo.buildNumber>(<DeviceInfo.deviceModel>; iPhone OS <UIDevice.current.systemVersion>) (<DeviceInfo.appName>)

Thoughts on my proposal? What kind of timeline can we expect for an implementation?

Questions:

1. Do we provide too much PII in the user agent?
2. The application name comes from the application itself, which could be used to create forgeries – are we concerned? Are there solutions?
3. Should the user agent remain the same between FxA sign in requests, sync token server requests, & sync requests? They're different on iOS.

---

A possible work-around is to call POST /v1/account/device after the initial connection but this is an inferior solution because 1) push will notify open Firefox browsers with the initial name and 2) it's an extra request.

CC @liuche @rfk

[rfk]

/cc @philbooth who has the most experience with our current user-agent-parsing logic

[rfk]

1. push will notify open Firefox browsers with the initial name

If you do the device registration before doing the call to get a signed certificate, then the push notification should go out with the updated name.

[rfk]

Regardless of doing explicit registration or not, I'm a big 👍 to using a consistent UA format and to us doing some sensible parse of it on the server side.

[rfk]

Do we provide too much PII in the user agent?

It seems OK to me, more-or-less in line with the amount of info sent in other UA strings in other contexts. We treat UA strings as potential PII in all our metrics infrastructure on the backend.

The application name comes from the application itself, which could be used to create forgeries
– are we concerned? Are there solutions?

I expect we'll do our best to only allow this for Official Mozilla Apps, and I'm not sure there's anything much we can do to prevent forgeries anyways. A malicious app can always talk directly to the server with whatever UA it wants.

Should the user agent remain the same between FxA sign in requests, sync token server requests,
& sync requests?

I think it should, yes. Having to work with two slightly-different formats across FxA and Sync has a slight pain in the past, and I don't recall the distinction delivering any value in practice.

[philbooth]

/cc @philbooth who has the most experience with our current user-agent-parsing logic

I'm 100% cool with both the UA string and the device name as proposed.

What kind of timeline can we expect for an implementation?

If we're all agreed on that UA string format, we could get it in to FxA train 88 which should ship early-June-ish if my maths is right. Any good?

[mcomella]

If we're all agreed on that UA string format, we could get it in to FxA train 88 which should ship early-June-ish if my maths is right. Any good?

@philbooth 👍 Let's do it!

[mcomella]

@philbooth How can I find out which train this ended up on and when it'll be in release?

[philbooth]

@mcomella, this will be part of FxA train 88, which we will cut on Monday. Deployment times tend to be somewhat fuzzy but it should go live roughly 2 weeks from now. Waves hands about.

I've made a note to CC you in the deploy bug when it gets created, that is probably the surest way to keep you in the loop. But if you want an independent signal then you're looking for when this endpoint returns "version":"1.88.0" (or greater).

Sorry I can't be more precise!

[mcomella]

Hey @philbooth. The endpoint returns 1.88.2 and the name for my device is different than the one I initially filed the bug for so I believe this is live but my code doesn't appear to create the expected name: it's Android 6, Android 6 rather than Unknown app, Android 6.0.

Any ideas what's going on?

My user agent is Mobile-Android-Sync/(Mobile; Android 6.0) (Unknown app) and I'm using the fx_fennec_v1 signin-context at the moment (because mob_android_v1 is not in production yet).

[philbooth]

Any ideas what's going on?

Sigh, my bad regex skills are going on, that's what. I'll add the one above as an extra test-case and make sure it passes. This will be on train 90, which won't be deployed for a couple of weeks-ish. Sorry for the delay.

[mcomella]

Hey @philbooth – would there be any way for me to test this before it hits release?

[rfk]

@mcomella you could try pointing your app at https://nightly.dev.lcip.org/ which should have the changes within 24 hours.

[mcomella]

Testing is blocked in the nightly build because of mozilla/fxa-dev#330

[philbooth]

@mcomella, this should now be on stage, you can point your app here:

https://accounts.stage.mozaws.net/