1323853 - How should Firefox Accounts behave in private browsing mode?

Status: RESOLVED FIXED

(Firefox :: Firefox Accounts, defect, P3)

Description

[Ryan Kelly [:rfkelly]]

The current behaviour can be demonstrated as follows:

1. Sign in to Sync in your browser
2. Open Preferences -> Sync, and click on "Manage Account"
3. Observe that you're taken to the FxA settings page on the web
4. Open a Private Browsing window
5. Open Preferences -> Sync in this private window, and click on "Manage Account"
6. Observe that you're prompted to sign in again, because the private browsing window "doesn't know" that you're signed in to the browser

My gut feeling is that this is weird, and the user would reasonably expect "Manage Account" to work regardless of whether they're in a private browsing window.

You can observe similar behaviour when logging in to an OAuth relier:

1. Sign in to Sync in your browser
2. Navigate to https://addons.mozilla.org and click on "log in"
3. Observe that you can login without re-entering your password, because we know you're already signed in in the browser
4. Open a Private Browsing window
5. Navigate to https://addons.mozilla.org in this private window and click on "log in"
6. Observe that you're prompted to sign in again, because the private browsing window "doesn't know" that you're signed in to the browser

The behaviour seems more appropriate in this case - you're in a private browsing window, you expect not to get automatic login to websites.


In both cases, the current behaviour is more-or-less accidental - it's due to the way we use localStorage to coordinate login state between the browser and web content.  We're working on tightening this up so it's a good opportunity to be more deliberate about the behaviour here, and add some tests to ensure we don't break it.


So, questions:

* If you're signed in to your browser, and you attempt to login to an FxA OAuth relier in a Private Browsing window, what is the desired behaviour?
* If you're signed in to your browser, and try to access the FxA settings page in a Private Browsing window, what is the desired behaviour?

ni? a few folks who I expect will have opinions here.

Comment 1

[(no longer active)]

(In reply to Ryan Kelly [:rfkelly] from comment #0)
> The current behaviour can be demonstrated as follows:
> 
> 1. Sign in to Sync in your browser
> 2. Open Preferences -> Sync, and click on "Manage Account"
> 3. Observe that you're taken to the FxA settings page on the web
> 4. Open a Private Browsing window
> 5. Open Preferences -> Sync in this private window, and click on "Manage
> Account"
> 6. Observe that you're prompted to sign in again, because the private
> browsing window "doesn't know" that you're signed in to the browser

Can we open the Manage Account page in a non-private window, always?  (For permanent PB mode, this behavior is fine since there's nothing better we can do, although arguably we should consider disabling the entire Sync UI in that case.)

> You can observe similar behaviour when logging in to an OAuth relier:
> 
> 1. Sign in to Sync in your browser
> 2. Navigate to https://addons.mozilla.org and click on "log in"
> 3. Observe that you can login without re-entering your password, because we
> know you're already signed in in the browser
> 4. Open a Private Browsing window
> 5. Navigate to https://addons.mozilla.org in this private window and click
> on "log in"
> 6. Observe that you're prompted to sign in again, because the private
> browsing window "doesn't know" that you're signed in to the browser

This looks fine to me.

Comment 2

[Ryan Kelly [:rfkelly]]

For additional context: one thing we're considering doing, is having the https://accounts.firefox.com do a WebChannel handshake with the browser to synchronize the current logged-in state.  So when web content on accounts.firefox.com loads up, it would send a probe WebChannel message to the browser asking "what's your current logged-in state?", and the browser could reply (or not) with the logged-in identity of the user.

If we want to keep the current behaviour with OAuth reliers, we'll have to add special handling and tests to preserve it.

Comment 3

[Alex Davis [:adavis]]

I am wondering about how the user will expect it to behave.

I think that by default, FxA and Sync shouldn't work in PB. If a user bookmarks something new and then has a non-PB window open, it should sync the bookmarked content if I am not mistaken.

> Can we open the Manage Account page in a non-private window, always?  (For permanent PB mode, this behavior is fine since 
> there's nothing better we can do, although arguably we should consider disabling the entire Sync UI in that case.)

Opening the Preferences window seems like it could work for a single PB window. 

Permanent PB brings up a different opinion though... If user is logged into the browser with bookmark sync enabled, user bookmarks but remains in permanent PB mode, I fail to see how this would be a good experience.

Can we make :rfkelly 's solution be a toggle in Preferences under Privacy? (e.g. Enable Firefox Accounts and Sync in Private Browsing. Note: History will not Sync since it is not saved in PB.)

Comment 4

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

(In reply to Alex Davis [:adavis] from comment #3)
> I think that by default, FxA and Sync shouldn't work in PB. If a user
> bookmarks something new and then has a non-PB window open, it should sync
> the bookmarked content if I am not mistaken.

Yes - and that's true even if they added the bookmark in a PB window.

> Permanent PB brings up a different opinion though... If user is logged into
> the browser with bookmark sync enabled, user bookmarks but remains in
> permanent PB mode, I fail to see how this would be a good experience.

TBH, I just think this is a UX issue to ensure the user has the correct expectations. The fact we "allow" the user to create bookmarks while in PB mode is a good indication (to me) that allowing sync in "always PB" mode is the right thing to do. Browser preferences and addons too.

> Can we make :rfkelly 's solution be a toggle in Preferences under Privacy?
> (e.g. Enable Firefox Accounts and Sync in Private Browsing. Note: History
> will not Sync since it is not saved in PB.)

I don't see how that offers any value for the user - we don't just automatically sign them in and even if they do sign in, we don't do anything bad (ie, it's not like we suddenly start syncing their history from the PB session.) I don't think a reasonable user would think that we *shouldn't* sync bookmarks created in a PB window given we make it clear they are saved.

I'd vote for something like:

(a) the "home" page for private browsing could mention sync, and/or:
(b) about:preferences could add some text which is shown only in PB windows, but otherwise doesn't change any functionality.

Comment 5

[Shane Tomlinson [:stomlinson]]

My personal opinion aligns closely with :markh's. Completely disabling Sync in PB mode seems like it'd require browser UI update to prevent breaking user expectations - "why isn't the bookmark I just added synced?" or "why isn't the add-on I just added synced?" The reverse also needs to be examined, if a user adds a bookmark or addon in a non-PB window, do they expect those items to be synced to their PB window? Perhaps these are questions that can be answered via a questionnaire of regular PB users.

If Sync stays enabled, ISTM that clicking on "Manage Account" from about:preferences should be treated as an extension to the browser and Should Just Work - I imagine very few users have an understanding that about:accounts loads an actual web page under the hood, why would they, we make an effort to hide that fact from them? From that P.O.V., Mark's suggestions seem reasonable, inform users of PB mode that the user's Sync creds will be shared from/with FxA if they click on any of the buttons/links.

Comment 6

[Shane Tomlinson [:stomlinson]]

(In reply to Shane Tomlinson [:stomlinson] from comment #5)

> If Sync stays enabled, ISTM that clicking on "Manage Account" from
> about:preferences should be treated as an extension to the browser and
> Should Just Work - I imagine very few users have an understanding that
> about:accounts loads an actual web page under the hood, why would they, we
> make an effort to hide that fact from them?

I have to modify this statement slightly after some playing with the UI - 
I realized clicking on "Sign in" or "Sign up" open about:accounts, 
clicking "Manage Account" opens "https://accounts.firefox.com/settings?lotsofstuffhere".

That's slightly different, but not enough to change my position. To me it 
still seems clicking "Manage account" should be treated as an extension
of the browser UI.

Comment 7

[Ryan Feeley [:rfeeley]]

I don't have any strong opinions because I think it's safe to assume very few users attempt to manage their account in a private window.

If we do feel that the account is an extension of the browser, we should consider (carefully) putting account management in an iframe in desktop preferences section (when user clicks manage).

Comment 8

[Alex Davis [:adavis]]

Your points are great. I'll align myself with them. Displaying a message mafes the most sense in about:preferences.

Comment 9

[(no longer active)]

(In reply to Ryan Feeley [:rfeeley] from comment #7)
> If we do feel that the account is an extension of the browser,

This seems sensible.

> we should
> consider (carefully) putting account management in an iframe in desktop
> preferences section (when user clicks manage).

If we end up going down this route, please make sure that the iframe is out of process so that we don't actually end up loading Web content in the parent process.  The good news is that we can make the iframe not be in PB mode, so things such as login cookies would just work.

Alternatively we can probably keep opening Manage Accounts in a normal tab, but we can make the tab part of Firefox by adding the "Firefox" indicator next to the globe icon (similar to our other chrome pages) and hide the address in the location bar.  If we end up going this route, we can open the link in a new non-private window if about:preferences is loaded in a PB window.

Note that in order to make either of these alternatives work well with permanent PB mode, we may need to change how the underlying code deals with opening windows and such.  I'd be happy to help if that becomes needed.

Comment 10

[Sean McArthur [:seanmonstar]]

> Completely disabling Sync in PB mode seems like it'd require browser UI update to prevent breaking user expectations - "why isn't the bookmark I just added synced?" or "why isn't the add-on I just added synced?"

As a user, I apparently have misunderstood Private Browsing, and am shocked (and almost upset) that Firefox remembers **any** action that I make when in Private Browsing. I wonder if my attitude is more unique, or if a large amount of people would also be surprised to learn that is how it currently works.

Comment 11

[Ryan Kelly [:rfkelly]]

> I think it's safe to assume very few users attempt to manage their account in a private window

Not deliberately, but we do know that some users set the "Never remember history" preference and then try to interact with sync.  IIUC this setting causes the browser to permanently be in private browsing mode.

Comment 12

[(no longer active)]

(In reply to Sean McArthur [:seanmonstar] from comment #10)
> > Completely disabling Sync in PB mode seems like it'd require browser UI update to prevent breaking user expectations - "why isn't the bookmark I just added synced?" or "why isn't the add-on I just added synced?"
> 
> As a user, I apparently have misunderstood Private Browsing, and am shocked
> (and almost upset) that Firefox remembers **any** action that I make when in
> Private Browsing. I wonder if my attitude is more unique, or if a large
> amount of people would also be surprised to learn that is how it currently
> works.

Even though we do a relatively good job of explaining this on every private browsing window, you're definitely not alone in getting confused about this.  We've received some similar feedback from users as well.  (I think most people just don't really read the text in the UI we show them...)

But the permanent PB mode is a special use case, since we don't alter the window's appearance, and don't show the user about:privatebrowsing...

For some use cases of this feature (for example, a browser for a public kiosk) it's totally possible to want some sync support (for example to sync preferences, or extensions, or bookmarks, etc.)

Comment 13

[Ryan Kelly [:rfkelly]]

Thanks for the input here everyone, I'm going to try to distill this down into some actionable outcomes.

> If we do feel that the account is an extension of the browser, we should consider (carefully) putting
> account management in an iframe in desktop preferences section (when user clicks manage)

I wonder if we can extend/re-purpose about:accounts for this, and have the "manage account" link open "about:accounts?action=manage" or similar, which then loads web content in an iframe with appropriate hand-holding to ensure localStorage etc works.

Here's what I propose based on everyone's comments in this bug:

1) Add verbiage to the private browsing landing page, to explain that sync will still sync stuff even when you're in PB mode.

2) Prevent private-browsing windows from learning the logged-in state of the browser.  In practice this means that when we implement the login status probe in Bug 1308038, we check whether the WebChannel message came from a private window, and reply in the negative if so.

3) Make a best-effort attempt to always open the "manage account" link in a non-private-browsing window.  We might not be able to do this in all cases, e.g. permanent-PB-mode.


The intended outcome is that "manage account" works reliably from anywhere, but that you don't get automagic login to FxA Oauth reliers when you're in private-browsing mode.  Does this seem reasonable to everyone?  If there are no objections I will file implementation bugs and close this one out.

:Ehsan, one final question: should everything said above about private-browsing mode, apply equally to container tabs, or other new isolation features?  Or perhaps more concretely: what's the right way to implement the "check whether it's a private private window" part of the above?

Comment 14

[(no longer active)]

(In reply to Ryan Kelly [:rfkelly] from comment #13)
> 3) Make a best-effort attempt to always open the "manage account" link in a
> non-private-browsing window.  We might not be able to do this in all cases,
> e.g. permanent-PB-mode.

Setting the private option to false when calling OpenBrowserWindow() may in fact give you a non-private window in that case, but please double check that before relying on it.

> The intended outcome is that "manage account" works reliably from anywhere,
> but that you don't get automagic login to FxA Oauth reliers when you're in
> private-browsing mode.  Does this seem reasonable to everyone?  If there are
> no objections I will file implementation bugs and close this one out.

This plan looks good to me!

> :Ehsan, one final question: should everything said above about
> private-browsing mode, apply equally to container tabs, or other new
> isolation features?  Or perhaps more concretely: what's the right way to
> implement the "check whether it's a private private window" part of the
> above?

I wouldn't conflate PB with those other features.  I'm actually not the best person to answer this, I suggest talking to baku about containers and Tom Ritter about first party isolation (but you may want to move those discussions to another bug, so I won't needinfo them here myself.)

Comment 15

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

Ryan said:
> If there are no objections I will file implementation bugs and close this one out.

Sold!

Comment 16

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

Ryan and I were just chatting about this and neither of us are completely clear on what consensus exists here.

I think a reasonable constraint for this discussion is that we continue to:
* Show the Sync status in about:preferences#sync, even in a private window.
* Save bookmarks created in PB mode and continue to sync them.

It could be argued that this isn't optimal (and indeed that some parts of PB, such as saving bookmarks, isn't optimal) for some users, but I don't think we are considering changing this as part of this bug.

Therefore, my opinion is:

* A user in a private-browsing window is able to see they are signed into account, including their username and profile avatar. Bookmarks they add are synced. I believe such users would be confused if they were either prevented from managing their account, or when they tried, we insisted they aren't logged in, when they can clearly see their email address and account information directly in front of them.

* Opening a non-private window just for this purpose would probably confuse the user - particularly for "permanent PB mode" - there's no UI indication that PB mode is active and thus there will be no UI hints that the new window is different in any way. If that new window remained open and did store history, I think there's an excellent chance we'd screw the user (ie, they'd accidentally use it without realizing it has different properties than they expect)

IOW, showing the user account info but not allowing them to perform certain actions (or throwing them out to a new window) just because they happen to be in PB mode is far more likely to confuse the user than to reassure them.

(In reply to Ryan Kelly [:rfkelly] from comment #13)
> The intended outcome is that "manage account" works reliably from anywhere,

Yep, I agree with that outcome, but I don't really see a benefit in opening new windows to achieve that, *especially* for permanent-PB mode, where the browser doesn't indicate you are in a PB mode.

> but that you don't get automagic login to FxA Oauth reliers when you're in
> private-browsing mode.

I agree with that too, but Ryan has some concerns about this from an implementation POV (ie, that it's safer for accounts.firefox.com to either fully work or not work, whereas trying to enforce a kind of degraded experience based on PB mode might be hard to get correct and to ensure stays correct).

If not for this last consideration, my opinion is that we should just "fix" this bug by making it work in PB mode via webchannels. But this last consideration leaves me in somewhat of a quandary.

Comment 17

[Ryan Kelly [:rfkelly]]

> A user in a private-browsing window is able to see they are signed into account,
> including their username and profile avatar.

To put this in concrete implementation terms: if you load https://accounts.firefox.com in a private-browsing window, it would send a WebChannel message to the browser to ask whether you're logged in, and the browser would reply with your logged-in state.  This is a special privilege afforded only to web content on accounts.firefox.com.

> but that you don't get automagic login to FxA Oauth reliers when you're in
> private-browsing mode.

Which would mean that, in order to implement this part, the browser would also have to tell https://accounts.firefox.com about whether or not you're in a private-browsing window.  We would then rely on the FxA web content to do the right thing w.r.t. OAuth logins.

This seems like strange and uncharted territory to me, and I would worry about us accidentally leaking that "the user is in private browsing mode" bit to other web content.

Perhaps we just need to prototype one of these so we can see how it feels, both from a user-experience perspective and from a user-privacy-management perspective.

Comment 18

[Shane Tomlinson [:stomlinson]]

(In reply to Ryan Kelly [:rfkelly] from comment #17)
> > A user in a private-browsing window is able to see they are signed into account,
> > including their username and profile avatar.
> 
> To put this in concrete implementation terms: if you load
> https://accounts.firefox.com in a private-browsing window, it would send a
> WebChannel message to the browser to ask whether you're logged in, and the
> browser would reply with your logged-in state.  This is a special privilege
> afforded only to web content on accounts.firefox.com.
> 
> > but that you don't get automagic login to FxA Oauth reliers when you're in
> > private-browsing mode.
> 
> Which would mean that, in order to implement this part, the browser would
> also have to tell https://accounts.firefox.com about whether or not you're
> in a private-browsing window.  We would then rely on the FxA web content to
> do the right thing w.r.t. OAuth logins.
> 
> This seems like strange and uncharted territory to me, and I would worry
> about us accidentally leaking that "the user is in private browsing mode"
> bit to other web content.
> 

I was thinking of a focused approach that should avoid the "is this private browsing mode
and an OAuth relier?" problems mentioned above. The original reported problem is that some
users must sign in to FxA when they click "Manage Account" about:preferences#sync because
their FxA state is gone. Fixing this case and this case only is relatively straight forward
because Firefox provides FxA with all the signals it needs to know whether a handshake
is appropriate. Firefox always opens FxA with a "service=sync" query parameter, FxA would 
look for this query parameter (and perhaps another signal), and perform the handshake. This
would fix "Manage Account" in both "normal" and PB mode and sandbox the behavior to only
Sync.

OAuth reliers do not provide those same signals, FxA would not do the handshake, no automatic
state synchronization would occur in PB mode, no surprises.

Comment 19

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

(In reply to Shane Tomlinson [:stomlinson] from comment #18)
> The original reported problem is that some
> users must sign in to FxA when they click "Manage Account"
> about:preferences#sync because
> their FxA state is gone. Fixing this case and this case only is relatively
> straight forward
> because Firefox provides FxA with all the signals it needs to know whether a
> handshake
> is appropriate.

Yep - your patch in bug 1308038 is moving to a state via webchannels model instead of via cookies/localstorage/etc. If we land that, IMO we are done here (from fx's POV)...

> FxA would not do the
> handshake, no automatic
> state synchronization would occur in PB mode, no surprises.

That makes sense to me - PB then works as rfkelly described. Have my hearty +1 :)

Comment 20

[Ryan Kelly [:rfkelly]]

Closing this out since we appear to have a clear path forward, and implementation bugs files.