1548404 - Update UITour to expose other FxA services used

Status: RESOLVED FIXED

(Firefox :: Tours, enhancement, P2)

Description

[Justin Crawford [:hoosteeno] [:jcrawford]]

After Trailhead lands, FxA users will be encouraged to opt-in to a Trailhead journey. Many will, and many will not. That means we'll want to split messaging for these two categories of users going forward. For example, on the Whatsnew 68 page, we might say one thing to upgraded FxAs ("Check out the latest benefit" -> marketing page) and a different thing to "legacy" FxAs ("Upgrade to get the latest benefit" -> upgrade journey).

Historically we have used UITour to accomplish such split messaging on www.mozilla.org. Specifically, we use getConfiguration('sync' ...) to determine if a Firefox user is signed in to a sync account.

In the far future it would be ideal to get much more insight from UITour or similar, so we can talk to people about account benefits that they have not used.

In the near future, we should expose something via UITour or similar that enables www.mozilla.org (and other privileged sites: SUMO, others?) to message Trailhead-opted-in FxAs differently than legacy FxAs.

Comment 1

[Matthew N. [:MattN]]

This seems important but I'm lacking context to know what we would have to actually expose as I'm not familiar with this account upgrade idea.

Alex, maybe you can find an engineer to implement this or provide more details when they are ready?

Comment 2

[Alex Davis [:adavis]]

I've only heard today for the first time through the TLDR of an official mention of an upgraded state.

I currently do not even know what being an upgraded account completely entails.

hoosteeno, if you can help me get clarity here, I'd appreciate it.

Comment 3

[Justin Crawford [:hoosteeno] [:jcrawford]]

It sounds like "upgrade" really means opting in to some additional communications, and it may not be called "upgrade". Copy is still in development.

That said, the need here is the same. After June 4, we will have an additional segment of FxA users -- people who have opted in to the June 4 CTA -- and we will want to give this group different copy on e.g. Whatsnew pages 68, 69. We'll need some way to identify them via e.g. UITour.

Comment 4

[Justin Crawford [:hoosteeno] [:jcrawford]]

So, people who accept the CTA on the whatsnew 67.0.5 page will...

1. Get signed up for Monitor breach alerts
2. Get added to a new email journey managed via Salesforce

Is there any way we can surface this information in UITour, :adavis?

Comment 5

[Lauren Niolet]

Yes, so another way to think about "upgraded" is a user who has seen and taken action on one of our calls to "Join."

Comment 6

[Alex Davis [:adavis]]

That said, the need here is the same. After June 4, we will have an additional segment of FxA users -- people who have opted in to the June 4 CTA -- and we will want to give this group different copy on e.g. Whatsnew pages 68, 69. We'll need some way to identify them via e.g. UITour.

Can you give an example of when and why we might not want to display the same copy?

Get signed up for Monitor breach alerts

Should be possible to work something out with bug 1547120

Get added to a new email journey managed via Salesforce

I'm not sure how we would get that to the browser. Accounts doesn't know what newsletters folks have opted-in to.

Comment 7

[Justin Crawford [:hoosteeno] [:jcrawford]]

Can you give an example of when and why we might not want to display the same copy?

Sure. On the Whatsnew 68 page, we might say one thing to upgraded FxAs ("Check out the latest benefit" -> marketing page) and a different thing to "legacy" FxAs ("Upgrade to get the latest benefit" -> upgrade journey).

Comment 8

[Matthew N. [:MattN]]

(In reply to Alex Davis [:adavis] [PM FxA+Sync] from comment #6)

Get added to a new email journey managed via Salesforce

I'm not sure how we would get that to the browser. Accounts doesn't know what newsletters folks have opted-in to.

We can record if it happens from a www.mozilla.org page but is that sufficient for this bug or does it have to be perfect? (e.g. user subscribes another way or user later unsubscribes?)

Comment 9

[Justin Crawford [:hoosteeno] [:jcrawford]]

Get added to a new email journey managed via Salesforce

I'm not sure how we would get that to the browser. Accounts doesn't know what newsletters folks have opted-in to.

We can record if it happens from a www.mozilla.org page but is that sufficient for this bug or does it have to be perfect? (e.g. user subscribes another way or user later unsubscribes?)

Truly, Salesforce is an incidental here. Our primary requirement is to know what services FxA users have opted in to, so we can avoid marketing those services and can instead offer more relevant content. Since Monitor opt-in is the gateway to Salesforce, exposing Monitor opt-in status is totally adequate.

Comment 10

[Alex Davis [:adavis]]

Our primary requirement is to know what services FxA users have opted in to

In that case, the work being done in bug 1547120 that I linked to above should be relevant here.

We're adding that context to snippets, new tab, account menu, etc. It seems like we should be able to use that across the browser.

Comment 11

[Justin Crawford [:hoosteeno] [:jcrawford]]

Here's an additional state that we should try to expose with this work:

• User has an FxA, but is not signed in to sync right now.

Comment 12

[Chris Karlof [:ckarlof]]

As I see it right now, this bug is currently not actionable because of unclear requirements. I understand what the goal is at the high-level, but the details are unclear to me.

Justin, who is the owner of these requirements? It would be helpful if we could get something written down outside this bug (e.g., a requirements doc and prioritized breakdown of functionality needed), and then we can identify the best people to get it implemented.

Comment 13

[Justin Crawford [:hoosteeno] [:jcrawford]]

Thanks :ckarlof.

I can represent the user stories for this system, but I doubt I could write a requirements doc and prioritized breakdown of functionality for the browser without an owner who understands the system better. Is there a technical or product owner for the components of the desktop browser that expose the UITour API? Since this bug has been deemed overlapping with bug 1547120, does that imply a technical or product owner?

Comment 14

[Chris Karlof [:ckarlof]]

I think a prioritized list of stories or scenarios would be a helpful start here. I think there's an underlying assumption that the UITour API is the right technical approach here (and it might well be), but I'd prefer we start with the list of stories/outcomes and go from there. I'll work on getting you a technical lead on our side to assess the best approach.

Comment 15

[Justin Crawford [:hoosteeno] [:jcrawford]]

:ckarlof, I added a user story to this bug. Happy to workshop it with you to make it clearer.

Comment 16

[Jim T]

:jcrawford, let's connect on this. Given current PM coverage I can help prioritize on our end, but I want to make sure sure I have a clear picture of the ask.

Comment 17

[Justin Crawford [:hoosteeno] [:jcrawford]]

:jimt, how does the user story look? https://bugzilla.mozilla.org/show_bug.cgi?id=1548404#module-user-story-title

Comment 18

[Jim T]

:jcrawford Can we think through the impact / benefit from an end user perspective as well? What specific user experiences do we want to unlock by having that info available?

Comment 19

[Jim T]

Thanks Justin, this makes a lot of sense and is likely key for faster experiments on the moz.org side. Let me check in with the team about the level of effort involved and whether that's something we need to adjust scope for to get in for Fx70.

Comment 20

[Liz Henry (:lizzard) (relman/hg->git project)]

Thomas, is this still intended to be part of 70/Skyline? I'm not sure who to ask, here .

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

Peter, Javaun, do you know if this is still planned? It may have missed the train for 70 unless you think there is an urgent need to do this.

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Matt, can you try chasing down whether any of the issues mentioned here still need work? I think some of it is likely already incorporated into Skyline. But, if not, and if it's something we're still intending to do, please let me know.

Comment 23

[Justin Crawford [:hoosteeno] [:jcrawford]]

Our window for designing any marketing experience around this capability is probably closed. Giving the browser some insight into an account's opt-ins, and exposing that to a small list of websites, would be a valuable tool for cross-promotion and interoperability. But it doesn't seem likely to impact Skyline at this point. I suggest removing it from the list of Skyline concerns.

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, I'm untracking this for 70 and removing the skyline tag in the bug summary. Maybe put it into a backlog of enhancements for future releases.

Comment 25

[Mark Hammond [:markh] [:mhammond]]

I'm hijacking this bug on the path to fixing bug 1593353. I propose that we take this opportunity to make the UITour capabilities more flexible for FxA, even if we aren't able to go as far as we'd like right now. For example, I'm proposing a data format that should make it easy to add information about, say, monitor, without breaking other services.

I propose that we deprecate the UITour 'sync' configuration command and create a new one named 'fxa'. This would have the following shape:

  signedIn: boolean, // Whether an FxA user is signed in or not.
  numOtherDevices: int, // The number of other devices connected to this account.
  otherDevicesByType: object, // A set of counts by device type. The valid
                              // values for device types are defined by FxA, and
                              // "unknown" is used if the FxA APIs do not supply a
                              // type value.    
                              // For example, we might see something like:
                              // {desktop: 3, phone: 2, vr: 3, unknown: 1}
  services: object, // Information about each service connected to FxA
                    // Currently, the only supported service is "sync". If that
                    // exists, the user is signed in to sync. The contents of the
                    // related object is identical to what the current "sync" command
                    // returns, although there is no "signedIn" value - this is
                    // implied by "sync" existing in this object.
}

For example, if a user was signed in to FxA but not Sync, we'd get a result like {signedIn: true, services: {}}

I'll put a patch up for feedback from various people, but anyone with a vested interest here is invited to have a look. I'm completely open to the spelling and shape of all this, but I figured it's easier to get concrete feedback with a straw-man.

Note that I have not actually tested this via a page which uses UITour-lib.js, so any advice about how I would actually do that is welcome.

[Tracking Requested - why for this release]:
We really want bug 1593353 fixed for 71 given that's the first version where Sync and FxA are decoupled.

Comment 26

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1548404 - Update UITour to reflect the decoupling of FxA and Sync. r?MattN,rfkelly

Comment 27

[Matthew N. [:MattN]]

Can we make this bug public now that Trailhead and Skyline have passed?

Comment 28

[Justin Crawford [:hoosteeno] [:jcrawford]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #27)

Can we make this bug public now that Trailhead and Skyline have passed?

Done.

I propose that we deprecate the UITour 'sync' configuration command and create a new one named 'fxa'. This would have the following shape:

This proposal seems like a reasonable one.

This will be a breaking change for consumers of the UITour API.

The breakage might look like this:

• Person in Firefox 73 loads resource implementing UITour. Resource has not been updated. It asks browser for something from UITour that is gone, replaced by the new fxa command. Unexpected things happen?
• Person in Firefox 68 loads resource implementing UITour. Resource has been updated, hooray! It asks browser for fxa. Unexpected things happen?

www.mozilla.org uses UITour quite a lot, so we'd have to think those breakages through and might need to collaborate a bit on implementation of the API. I am not sure what other sites depend on UITour now. Snippets? SUMO? (Pinging :giorgos)

:agibson is a good person to connect with to help find a website to test on.

Comment 29

[Mark Hammond [:markh] [:mhammond]]

(In reply to Justin Crawford [:hoosteeno] [:jcrawford] from comment #28)

This will be a breaking change for consumers of the UITour API.

Yes, but it's basically broken now - if a 73 Firefox is using 'sync' it's already broken as reported in bug 1593353. We could add a new attribute to 'sync', but then 68 is going to be broken when it looks for that attribute but it doesn't exist. So I don't see a way to avoid all existing consumers of the 'sync' config object to become aware of what Firefox version they are dealing with.

Happy to be informed that's a very simplistic view and I should do something different though :)

Comment 30

[Matthew N. [:MattN]]

For Monitor I think we can do the following:

await fxAccounts.getOAuthToken({ scope: SCOPE_MONITOR })

https://searchfox.org/mozilla-central/rev/d061ba55ac76f41129618d638f4ef674303ec103/browser/components/about/AboutProtectionsHandler.jsm#275,279

Comment 31

[Alex Gibson [:agibson]]

www.mozilla.org uses UITour quite a lot, so we'd have to think those breakages through and might need to collaborate a bit on implementation of the API.

For mozorg I think we can do some conditional logic to handle both the new and old API, using a regular UA check. One thing that would make this easier, is if we could try and keep the data format returned by each function as similar as possible (where it makes sense). This would help alleviate special casing when property names are different etc.

Comment 32

[Mark Hammond [:markh] [:mhammond]]

After chatting with Ryan and Matt in slack, I've come up with a slightly different format. In short:

• There's an accountClients object which lists all OAuth clients connected to the account. Thus, you will be able to determine whether the lockwise app has been used with this account, or whether monitor has been connected - regardless of what device this was done on. Indeed, there's currently no way to know whether monitor is logged in on this device - that might be something we can add later - but this is subtle - see below

• There's a browserServices object which lists things we know are directly connected to this browser. Currently only 'sync' can appear here. It's possible that in the future we will add new services here, but we are yet to work out what the semantics of that might mean. Taking "monitor" as an example, it's unlikely we'd include monitor here if the user just did a web-based login on this browser - but it's likely we might include it if the user was "signed in to the browser" and "connected" that account to monitor. It's a subtle but important distinction.

From the tests in the attachment I'm about to put up, you might expect an object like:

{
    setup: true,
...
    accountClients: {
      "802d56ef2a9af9fa": {
        name: "Firefox Monitor",
        lastAccessTime: 1569263031000,
      },
...
    },
    browserServices: {
      sync: {
        setup: true,
        mobileDevices: 5,
        desktopDevices: 4,
        totalDevices: 9,
      },
    },
  }

The list of client IDs can be found here, and my patch has added jsdoc strings for everything, so I won't go into much further detail here.

(In reply to Alex Gibson [:agibson] from comment #31)

if we could try and keep the data format returned by each function as similar as possible (where it makes sense). This would help alleviate special casing when property names are different etc.

The sync sub-object returned here is identical to the object returned by the existing sync config request.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #30)

For Monitor I think we can do the following:

await fxAccounts.getOAuthToken({ scope: SCOPE_MONITOR })

FTR, that's how we could connect to monitor, not check if it is connected. ie, after making that call, you would find monitor starts appearing in accountClients if it wasn't before. In my current proposal, you'd check if monitor is in use by the account with something like:

const MONITOR_OAUTH_ID = "802d56ef2a9af9fa"
let isMonitorEnabled = config.setup && config.accountClients[MONITOR_OAUTH_ID];

Comment 33

[Ryan Kelly [:rfkelly]]

For Monitor I think we can do the following:
await fxAccounts.getOAuthToken({ scope: SCOPE_MONITOR })
FTR, that's how we could connect to monitor, not check if it is connected. ie, after making that call,
you would find monitor starts appearing in accountClients

Not quite, and this is an example of where we haven't yet done a good job of teasing apart the semantics of the different moving parts here. Doing the above makes an OAuth token with SCOPE_MONITOR, but the token itself will be issued to the Firefox Desktop client_id, not to the Monitor service client_id. So Monitor would not start appearing in accountClients in this case.

You could use such an OAuth token to ask the monitor backend service whether this user has enabled Monitor for their account, but it won't tell you anything interesting about whether the user has ever accessed monitor on this particular device. The former is probably what you want, but it's also probably cheaper to find this out by checking in accountClients as :markh suggests.

Comment 34

[Giorgos Logiotatidis [:giorgos]]

(In reply to Justin Crawford [:hoosteeno] [:jcrawford] from comment #28)

www.mozilla.org uses UITour quite a lot, so we'd have to think those breakages through and might need to collaborate a bit on implementation of the API. I am not sure what other sites depend on UITour now. Snippets? SUMO? (Pinging :giorgos)

Snippets doesn't use UITour anymore, thanks for the heads up though! Redirecting ping to :tasos re SUMO

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c5c7e5fc0307
Update UITour to reflect the decoupling of FxA and Sync. r=MattN,andreio,rfkelly

Comment 36

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/c5c7e5fc0307

Comment 37

[Tasos Katsoulas [:tasos]]

(In reply to Giorgos Logiotatidis [:giorgos] from comment #34)

(In reply to Justin Crawford [:hoosteeno] [:jcrawford] from comment #28)

www.mozilla.org uses UITour quite a lot, so we'd have to think those breakages through and might need to collaborate a bit on implementation of the API. I am not sure what other sites depend on UITour now. Snippets? SUMO? (Pinging :giorgos)

Snippets doesn't use UITour anymore, thanks for the heads up though! Redirecting ping to :tasos re SUMO

SUMO does use the UITour but we can also add some conditional logic to handle the breaking changes. Thanks for the heads up!

Comment 38

[Punam Dahiya [:pdahiya]]

With this fix, listAttachedOAuthClients returns data in format
{
id: clientId,
lastAccessedDaysAgo: daysAgo,
}
breaking 'attachedfxaoauthclients' targeting that uses this API regressing 1550720, 1591584
https://github.com/mozilla/activity-stream/blob/master/content-src/asrouter/docs/targeting-attributes.md#attachedfxaoauthclients

NI Mark for inputs and help fix targeting. Thanks!

Comment 39

[Punam Dahiya [:pdahiya]]

Regressed Steps 7 and 8 in https://bugzilla.mozilla.org/show_bug.cgi?id=1591584#c4 as targeting of 'Firefox Monitor' card depends on getting name from attachedfxaoauthclients

Comment 40

[Matthew N. [:MattN]]

If a bug causes a regression you should file a new bug and put this bug in the "Regressed by" field so please do that. I think you will need to change your implementation btw., I don't think we should revert what was done here since you are relying on fields that are sensitive and shouldn't have been exposed to Snippets in the first place: high precision timestamps and device names (which could include the user's name).

Comment 41

[Punam Dahiya [:pdahiya]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #40)

If a bug causes a regression you should file a new bug and put this bug in the "Regressed by" field so please do that. I think you will need to change your implementation btw., I don't think we should revert what was done here since you are relying on fields that are sensitive and shouldn't have been exposed to Snippets in the first place: high precision timestamps and device names (which could include the user's name).

Filed 1596514, my understanding 'listAttachedOAuthClients' returned name of Firefox Services (https://docs.telemetry.mozilla.org/datasets/fxa_metrics/attribution.html#service-attribution). I am open to changing implementation after guidance on what are the alternate attribute that can provide information on what firefox services does the user currently have attached to their Firefox Account

Comment 42

[Ryan Kelly [:rfkelly]]

Hrm...I wonder if this was the (undocumented?) reason that this code was previously filtering out records with a device_id - those are the ones that might have a custom name set by the user rather than a fixed name for a specific Mozilla service.

Comment 43

[Mark Hammond [:markh] [:mhammond]]

FTR, the old code checks more than just the device_id, and recall that those semantics also excluded the lockwise app.

Even though lockwise doesn't currently allow renaming of the entry, I think we'd be foolish to assume it will be that way forever - installing lockwise on 2 different devices will end up with 2 almost-identical entries for lockwise in this list, so I'd be surprised if we don't end up allowing/defaulting some differentiation at some point.

Comment 44

[Ryan Kelly [:rfkelly]]

Yes, I totally agree - to be clear, I'm not suggesting we change it back, just kind of wondering out loud if that was part of the motivation.

Comment 45

[Alex Gibson [:agibson]]

const MONITOR_OAUTH_ID = "802d56ef2a9af9fa"
let isMonitorEnabled = config.setup && config.accountClients[MONITOR_OAUTH_ID];

Do we have a canonical list of OAuth ID's that are available, so that we can implement a lookup in our logic for mozorg?

Comment 46

[Alex Gibson [:agibson]]

Cancelling needsinfo, I found them thanks

https://docs.telemetry.mozilla.org/datasets/fxa_metrics/attribution.html#service-attribution