1578632 - Allow the Monitor card in about:protections to sign the user in to the browser

Status: NEW

(Firefox :: Firefox Accounts, enhancement)

Description

[Ryan Kelly [:rfkelly]]

If you visit about:protections in a browser that is signed in to Sync, you can see a "Firefox Monitor" report card informing you whether you've been in a data breach.

If you visit about:protections in a browser is is not signed in to Sync, you will see an option to "Sign Up for Breach Alerts" which, when clicked, will direct you to https://monitor.firefox.com in a new tab. You can sign in with your Firefox Account in this new tab and view your breach alerts on the web. But if you return to about:protections you will still see the "Sign Up for Breach Alerts" button, because about:protections uses the signed-in state of the Browser, and you only signed in on the Web.

Bug 1570565 tracks the work to decouple "signing in to Firefox" and "enabling Firefox Sync", which will put us in a better position to offer other account-based services the browser. The Monitor card in about:protections is a great candidate for taking advantage of this.

So...let's make it so that clicking "Sign up for Breach Alerts" in about:protections will sign you in to the Browser and result in your Monitor report being displayed inline.

I put together a strawman UX proposal for how this could operate, without diving in to any of the technical details. Betsy, Ryan, I'd like to get your initial impressions:

https://docs.google.com/presentation/d/1BdGjT3U74ZwwFUy5z-UjBAKQJYQsb9zHDe7TJ80-gnQ/

Shane, could you please also take a look when you have a moment? There are some technical details implied even at this early stage that I'd like to discuss with you.

Comment 1

[Ryan Kelly [:rfkelly]]

But if you return to about:protections you will still see the "Sign Up for Breach Alerts" button, because about:protections
uses the signed-in state of the Browser, and you only signed in on the Web.

While digging into the details here, I remembered that there was another possible solution that I don't recall being discussed. I'm not personally a fan of it but I think we should discuss it for completeness.

If you take a look at the way Pocket is integrated into Firefox, it's similar to the Monitor report card in a lot of ways - there are some native browser UI hooks that provide a basic view into the service, but for more details you get redirected out to the web, and you sign in by doing on OAuth flow on the web.

Unlike about:protections, the Pocket integration does not use the signed-in state of FxA in the Browser. Instead, it crawls through the local cookie store to extract the session cookie for getpocket.com and it uses that to make authenticated requests to the Pocket backend API:

https://dxr.mozilla.org/mozilla-central/rev/5f26741abcac98035b471c50b9ef8db0250857b3/browser/components/pocket/content/pktApi.jsm#188

Something about this approach sits wrong with me, it seems to violate the separation between "Browser" and "Content" in a way that's similar to the Chrome auto-signin kerfuffle. But it does have some advantages, such as making it easier to understand whether and how you're signed in to Pocket (it's the same everywhere) and making it simpler to sign out of Pocket (signing out on the web signs you out everywhere).

Did we consider a similar approach when implementing the Monitor protection report? I'd be curious to know whether we explicitly ruled it out. Not really sure who to ask about that, so I'm starting with :johannh but please redirect as appropriate.

Comment 2

[Johann Hofmann [:johannh]]

Did we consider a similar approach when implementing the Monitor protection report? I'd be curious to know whether we explicitly ruled it out. Not really sure who to ask about that, so I'm starting with :johannh but please redirect as appropriate.

I think we briefly talked about this in Whistler but I could be wrong. In any case, I would be extremely hesitant to do this for the reason you mentioned and also because I really don't like when the fate of a browser application feature hinges on external website behavior in such a way, for stability and security reasons. If we set this precedent then things are going to get messy fast. I.e. what do you do when the user is clearing site data? And other edge cases like this.

Not a big fan of Pocket doing this IMO.

Comment 3

[Ryan Kelly [:rfkelly]]

Great, thanks! Sounds like we are pretty strongly on the same page then, which gives me more confidence that pushing ahead with a full signin to the browser is the right path forward here.

Comment 4

[Shane Tomlinson [:stomlinson]]

Shane, could you please also take a look when you have a moment? There are some technical details implied even at this early stage that I'd like to discuss with you.

Read. Let's talk implied technical details.

Comment 5

[Ryan Kelly [:rfkelly]]

Just to capture context back here in the bug for visibility - I've had some good conversations on the technical front and there seems to be consensus that the best technical approach is what's called "Back-to-Back Signin Flows" in the proposal linked above. Basically, clicking "Sign up for Breach Alerts" in about:protections causes you to sign in to Firefox, then at the end of that flow Firefox uses its new-found account credentials to sign you in to Monitor and enable the Monitor service.

We'll start moving some code pieces in this direction, e.g. via the smaller signin refactor proposed over in Bug 1577690.

We can't yet move this bug forward without input from UX on how the flow should look from the user's perspective.

Comment 6

[Johann Hofmann [:johannh]]

Yup, sorry for not following up on your question in the doc, but I think that makes the most sense and feels like the safest way to do it both from a security as well as a "felt" privacy standpoint for users.

Thanks!

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

For more information, please visit auto_nag documentation.