Closed Bug 1548404 Opened 1 year ago Closed 5 months ago

Update UITour to expose other FxA services used

Categories

(Firefox :: Tours, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 72
Tracking Status
firefox70 - wontfix
firefox71 --- wontfix
firefox72 --- fixed

People

(Reporter: hoosteeno, Assigned: markh)

References

Details

User Story

**As a web developer on www.mozilla.org**, I can already use client-side code to determine whether a Firefox browser requesting a page of the website is signed in to Firefox Sync[0].

We now cross-sell more services on our website to Firefox users. In order to give Firefox users more relevant promotions, I would like to use client-side code to determine whether the user of a Firefox browser requesting a page of the site...
* has used a Firefox Account to sign in to Monitor
* has used a Firefox Account to sign in to Lockwise
* has created a Firefox Account but is not signed in to sync
* has used a Firefox Account to sign in to Send

**As a Firefox user visiting www.mozilla.org**, I may wish to hear about Firefox products, services or features I don't already use. Paying attention to a promotion for a product I already use would be a waste of my time. If I have already established a relationship with Firefox by opting in to some services, tell me about something I don't already know.
* If I have opted in to Monitor, you could explain how Monitor and Lockwise work together to help keep me safe online.
* If I have an account and am not signed in, you could help me realize what I'm missing by not syncing.
* If I have enabled secure proxy, you could tell me more about a new VPN product.


[0] https://bedrock.readthedocs.io/en/latest/uitour.html#getconfiguration-type-callback

Attachments

(1 file)

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.

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?

Type: defect → enhancement
Flags: needinfo?(adavis)
Priority: -- → P2

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.

Flags: needinfo?(adavis)
Flags: needinfo?(hoosteeno)

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.

Flags: needinfo?(hoosteeno)

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?

Flags: needinfo?(adavis)

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

Summary: Update UITour to expose fxa-upgraded state → Update UITour to expose Trailhead opt-in state

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.

Flags: needinfo?(adavis)

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).

See Also: → 1547120

(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?)

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.

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.

Summary: Update UITour to expose Trailhead opt-in state → [Skyline] Update UITour to expose Trailhead opt-in state

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.

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.

Flags: needinfo?(hoosteeno)

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?

Flags: needinfo?(hoosteeno) → needinfo?(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.

Flags: needinfo?(ckarlof) → needinfo?(hoosteeno)
User Story: (updated)
Flags: needinfo?(hoosteeno)

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

: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.

Flags: needinfo?(jimthomas)

: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?

Flags: needinfo?(jimthomas)
User Story: (updated)
User Story: (updated)

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.

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

Flags: needinfo?(telin)

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.

Flags: needinfo?(pdolanjski)
Flags: needinfo?(jmoradi)

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.

Flags: needinfo?(MattN+bmo)

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.

Flags: needinfo?(MattN+bmo) → needinfo?(jimthomas)
Whiteboard: [skyline]

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.

Summary: [Skyline] Update UITour to expose Trailhead opt-in state → Update UITour to expose Trailhead opt-in state
Flags: needinfo?(jmoradi)
See Also: → 1593353

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.

Assignee: nobody → markh
Blocks: 593353
Status: NEW → ASSIGNED
See Also: 1593353

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

Flags: needinfo?(telin)
Flags: needinfo?(pdolanjski)
Flags: needinfo?(jimthomas)
Flags: needinfo?(hoosteeno)
Blocks: 1593353
No longer blocks: 593353

(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.

Group: mozilla-employee-confidential
Flags: needinfo?(hoosteeno)
Flags: needinfo?(giorgos)
Flags: needinfo?(agibson)

(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 :)

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

Summary: Update UITour to expose Trailhead opt-in state → Update UITour to expose other FxA services used

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.

Flags: needinfo?(agibson)

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];
Attachment #9106812 - Attachment description: Bug 1548404 - Update UITour to reflect the decoupling of FxA and Sync. r?MattN,ochameau → Bug 1548404 - Update UITour to reflect the decoupling of FxA and Sync. r?MattN,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.

(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

Flags: needinfo?(giorgos) → needinfo?(tasos)
Pushed by mhammond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c5c7e5fc0307
Update UITour to reflect the decoupling of FxA and Sync. r=MattN,andreio,rfkelly
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72

(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!

Flags: needinfo?(tasos)

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!

Flags: needinfo?(markh)
Regressions: 1550720

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

Regressions: 1591584

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).

Flags: needinfo?(markh)
No longer regressions: 1550720, 1591584
Regressions: 1596514

(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

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.

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.

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.

Depends on: 1601180

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?

Flags: needinfo?(markh)
Flags: needinfo?(markh)
Depends on: 1601662
You need to log in before you can comment on or make changes to this bug.