1005019 - Decide how loop should operate in private browsing mode

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect, P4)

Description

[Mark Banner (:standard8)]

We should make a decision and UX about how to operate in private browsing mode, and handle that accordingly.

Comment 1

[:shell escalante]

Assigned to Darrin for UX.  Could be more complex fix on how we keep calling cookies in private mode - or a message that says it doesn't work in Private Browsing.  Up to UX and PM.

Comment 2

[Romain Testard [:RT]]

What do we do on Loop that won't comply with private browsing mode policies?
Given we're not a 3rd party website but a browser feature I'm not sure we are subject to that and the only thing I can think of that a user would expect is not logging the calling history as a result of being in private browsing mode.

Darrin what are your views?

Comment 3

[Romain Testard [:RT]]

Alina, maybe you can help us understand what are the policies for us to comply with in private browsing mode for Loop?

Comment 4

[Rémy Hubscher (:natim)]

What about using Anonymous Mode only in private browsing mode with a specific SimplePush web socket and shutting down the web socket as soon as we leave the private mode?

Comment 5

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

Note that the ChatWindow, used by loop, doesn't work at all in PB mode due to how social works.  This can probably be fixed, but will require some thought.

Comment 6

[Romain Testard [:RT]]

I lowered the priority on this one.
I don't believe it is critical for MVP although nice to have what Remy suggests - only anonymous mode with a web socket which gets closed as the PB mode is left.
If we can't deliver it we should disable the Loop icon in PB mode.

I also notice that in PB mode I can't even bring down the panel (applies to both Talkilla and the Loop MLP).

Comment 7

[Darrin Henein [:darrin]]

Sounds like we're deferring the conversation on this one for now, and I think we need to understand and decide how we want this to work from a product/feature perspective before we move to designing the experience.

Comment 8

[:shell escalante]

Based on the work already in queue for Fx35 and the uplift of Fx34 work to Beta ([loop-uplift]) - moving this out at least until Fx36.

Comment 9

[Romain Testard [:RT]]

Clearing the needinfo as this will depend on the FF36 UX and features which are not final yet.

Comment 10

[Romain Testard [:RT]]

Now clearing...

Comment 11

[Matthew N. [:MattN]]

I think there should at least be a quick review of how we currently handle PB mode before release to ensure that we don't leak too much. We need to lead on privacy and punting this until later is a way to get burned. IMO this should be happening now as we have code on beta and leaking info from PB is normally high priority.

Comment 12

[:shell escalante]

Notes from meeting with Mika, Jaws, MattN, Standard8, Maire, and Shell (sent to Chad and RT for PM input).

Right now Loop/Hello doesn't do anything special to respect Private Browsing.  There are a few scenarios that have been identified where this breaks the Private Browsing concept and also potential work-arounds for Fx34 versus later versions.

We talked with Mika about Privacy, and she stated that this is a product issue for how Fx thinks Loop/Hello should respect Private Browsing, not a legal Privacy issue.

The scenarios we need to consider for Fx34:

**Click User A enters private browsing mode, creates a call URL and sends it to User B over a private channel. User B clicks the link to call User A and they have a conversation. User A closes the Private Browsing window and possibly all other Firefox windows. Later User C uses the same computer as User A and opens Firefox. User B clicks the link again to call User A, but User C answers (or sees the caller ID) and now information about User A's contact with User B is leaked to User C.
**User A enters private browsing mode on User B's (a friend's) computer, logs in with their Firefox Account, makes a call then quits Firefox. User B launches Firefox later and is logged into User A's account and has access to their contacts and call history. User B could also place audio calls an impersonate User A.


For Firefox 34 we don't have the options of adding user notifications - because they wouldn't get translated.  One suggestion was for Fx34 we disable Loop/Hello in Private Browsing mode and write a SUMO article explaining why.  This has precedence for being done for Social.

For future versions we could take some actions (TBD based on PM input) and then enable Loop/Hello in Private Browsing mode:

**request UX that notifies a user in Private Browsing mode when they create a Loop/Hello URL that it can be used outside of Private Browsing mode to call back that browser in regular use mode.
**design technical way to make a URL generated in Private Browsing mode only work in that mode and UX that tells the user that.
**add "remember my login information" UX check-box to show that remembering the Identity will persist outside of Private Browsing.
**decide that by the act of logging in the user has agreed to an action that creates an identity that persists - and they have the option to use Loop/Hello without logging in

Future features that will also cause Private Browsing mode decision points are anything that is stored or set in prefs:

    ex: calling history, most frequent contacts, etc.

Comment 13

[:shell escalante]

looking for PM input on if we should disable Loop in Fx34 for Private Browsing mode (see comment 12)

Comment 14

[Matthew N. [:MattN]]

One thing we can do without strings (at the cost of accessibility due to no tooltip) is to put a warning icon in the relevant place in PB mode and have clicking that open a SUMO article.

Comment 15

[:shell escalante]

I talked with Chad and Romain T via video chat.  
Chad had just spoken with Gavin as well (after Gavin's email).  Because other products (specifically Sync) allow authentication carry-over - we are going to release Hello as is for Fx34.  The rules for how authenticated services should behave in Private Browsing are being defined now.  
We should work on our plan to resolve for Fx36, add some notifications (of how link clickers still work for call back after PB session has ended) and options around remembering login and stored information (call history, top calls).  We couldn't add notifications for Fx34 because no strings this late can be added.

Working on SUMO article for explaining to users for what to expect and also that they should log out after PB if they don't want their logged in session to continue into regular browsing.

Comment 16

[:shell escalante]

send info on SUMO article about logging out after leaving browser.  pursue further talks with desktop.

Comment 17

[:shell escalante]

shell write SUMO with joni and revisit with chad

Comment 18

[Romain Testard [:RT]]

I think that for Fx36 we need at least to indicate to the user that:
* His generated rooms will persist outside of PB mode
* His signed-in status will persist outside of PB mode

Sevaan/Darrin, could you please think about a UX for this?

Comment 19

[Sevaan Franks [:sevaan]]

Hi all, just chiming in after reviewing the thread with Darrin, and we have some thoughts:

- Rooms generated within PB should be deleted once PB is closed.

- If a user signs in in PB, then they should ONLY be signed in to that account in the Private Window, and once that window is closed, they are signed out.

PB is a separate entity and we should not blur the lines between surfing in a Private Window and a regular window.

Comment 20

[Romain Testard [:RT]]

(In reply to Sevaan Franks [:sevaan] from comment #19)
> Hi all, just chiming in after reviewing the thread with Darrin, and we have
> some thoughts:
> 
> - Rooms generated within PB should be deleted once PB is closed.
Does this apply even if you are signed in you think? For instance if I add a favorite in PB mode, this favorite stays in normal mode so would a user not expect something similar with created rooms?
> 
> - If a user signs in in PB, then they should ONLY be signed in to that
> account in the Private Window, and once that window is closed, they are
> signed out.
It is not today the case for FxA. Are there reasopns why we would not apply this behavior to FxA in general?
> 
> PB is a separate entity and we should not blur the lines between surfing in
> a Private Window and a regular window.

Comment 21

[:shell escalante]

update from conversation with chad and emails on policy.

Comment 23

[:shell escalante]

Sevaan/RT - based on the behavior bug 1108187 introduced to handle private browsing - we should add UI and a message of some sort to let folks know why Hello isn't working in Private browsing. the private browsing concern is addressed - but it's a confusing experience that needs some notification. 

email conversation from 9/22 Gavin

> > I just chatted with Dolske and Matt about this; we agreed with Chad that
> > "doing nothing" is a viable option. But a better option, in our opinion,
> > is to disable the Loop UI in Private Windows, which should be a simple
> > fix. This addresses the concern that some users will have expectation that
> > their private window actions aren't persistent (at the expense of
> > introducing a bit of complication/potential confusion about the UI not
> > being present, but I don't think it's significant). Let's just do that.

Comment 24

[Sevaan Franks [:sevaan]]

How do people feel about hiding the Hello icon in a Private Browsing window all together?

Comment 25

[Romain Testard [:RT]]

This is in place today.
We discussed Mike's suggestion (show the button but disabled and show a helpful title="Firefox Hello is not available in Private Browsing mode" when you hover this disabled button. and everyone seems to agree this is a good way forward.
I am closing this bug  since implementation is underway on bug 1185485