Closed Bug 1855513 Opened 1 year ago Closed 1 year ago

Move in-browser account verification to open the fxa sign in page instead of directly sending an email

Categories

(Firefox :: Sync, task, P3)

task

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox122 --- fixed

People

(Reporter: teshaq, Assigned: teshaq)

References

Details

(Whiteboard: [fxsync-])

Attachments

(1 file)

In an effort to move Firefox Desktop authentication to derive its sync keys using the oauth flow that Firefox mobile uses, we are aiming to limit the exposure of certain sensitive key material from Firefox Desktop.

Firefox Desktop currently temporarily persists two such materials, a keyFetchToken that is capable of requesting wrapped keys from the FxA server, and an unwrapKb value derived from the user's password that is able to convert the value returned from the server to the user's true encryption key (kb).

One reason Firefox currently keeps those values temporarily is that it expects to sync immediately after the account is verified, even if the account was verified outside of Firefox. Currently, the only way to verify the account outside of Firefox is if the account was not verified on sign-up (the user closed the tab before inputting the verification for example).

The existing behaviour nags the user to go to about:preferences#sync, and click a button that will send the user a verification link.

This ticket proposes that we move away from the above flow, and instead, when a user ends up in about:preferences#sync and clicks that button, the FxA sign in page pops up and the user re-enters their password, receives a code in their email and pastes that code in as if it was the very first time.

In an effort to measure how impactful the existing UX is, I created the following chart: https://sql.telemetry.mozilla.org/queries/94240/source#232910 (note that the drop off in the chart is most likely due to the GCP migration)

It shows that we have about 500 or so users a day that go through the flow, and about 300 or so that actually complete it. For comparison, we currently get about 10,000 users a day that sign up to FxA on desktop, so the 300 is about 3 percent.

Vesta, there is a product decision here, so I'm curious what you think. Here are some relevant details from above:

  • If we go forward with what this ticket is proposing it's quite possible we lose some portion of the 300 users a day that verify their account at a later time
    • It's hard to tell what the impact here will be, but we could certainly measure it, although, we won't have results until it hits release since the volume is really low in other channels.
  • If we go forward with what this ticket is proposing we dramatically simplify the work to move Firefox Desktop to oAuth, standardizing authentication flows across all three Firefox platforms, removing a decent amount of cryptography code and simplifying extending authentication-related features eg:
    • Storage of recovery keys that Ben Bangert proposed before
    • Using the Rust client in Desktop, which allows us to build cross-platform features one time in one core library

My naive position is that we should go through with this, measure it and evaluate strategies to improve our verification numbers afterwards, especially given the low volume and that it's not clear what the impact here will be (if any negative), thoughts?

Flags: needinfo?(vzare)

Tarik, thanks for the detailed explanation here and also answering my follow up questions on slack.

I agree that we should move forward with standardizing the flow across all platforms based on the benefits and risks below:

Benefits:

  • Standardization of user experience across platform
  • Sounds like the code-base will be cleaner and more scalable and allow for new features easier/faster.

Risks:

  • Adding 1 additional (entering password) for ~3% of Sync customers. This added step may introduce some friction but when it comes to Sync Customers, I think it's better to ask for password more often since forgetting password can carry a lot of friction/risk at the moment.

To make sure we are on the same page about the user experience:

  • When the customer clicks on the "needs authentication" warning in their toolbar menu, the FxA sign in page pops up.
  • When the customer clicks on the "needs authentication" warning in about:preferences#sync, the FxA sign in page pops up.

Can we also make sure that we have reliable events instrumented to measure the "Sync success" rate of those customers?

Flags: needinfo?(vzare)

Thanks a ton Vesta!

To make sure we are on the same page about the user experience:
When the customer clicks on the "needs authentication" warning in their toolbar menu, the FxA sign in page pops up.
When the customer clicks on the "needs authentication" warning in about:preferences#sync, the FxA sign in page pops up.

Yes exactly!

Can we also make sure that we have reliable events instrumented to measure the "Sync success" rate of those customers?

Yes, we can use a different entrypoint query parameter per flow, that will allow us to differentiate where the sign ups are coming from, so we'll do that!

Status: NEW → ASSIGNED
Duplicate of this bug: 1840414
Whiteboard: [fxsync-]
Pushed by teshaq@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a799320fe84d Move in-browser verification to open web content. r=markh,fluent-reviewers,settings-reviewers,Gijs,bolsson
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: