644769 - Disabling sharing during Private Browsing Mode

Status: RESOLVED WONTFIX

(Cloud Services :: Share: Firefox Client, defect)

Comment 1

[Philipp von Weitershausen [:philikon]]

Sid, it would be great if you guys could help us define the behaviour here, if we need any special behaviour at all.

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

For now, it's probably just wise to stop caching anything locally (nothing).  No localstorage, passwords, etc.

This is a helpful document:
https://developer.mozilla.org/En/Supporting_private_browsing_mode

Comment 3

[Philipp von Weitershausen [:philikon]]

We're moving away from localStorage anyway. The question really is, what shoudl happen in Private Browsing Mode?

a) Should we disable Sharing completely, on the grounds that if you're being private, you wouldn't want to share anyway. (That seems to be contradictory to the fact that we allow you to bookmark things.)

b) Enable Sharing but not allow new service sign up. That way we would never end up storing new account data and OAuth tokens.

c) Enable Sharing, allow new service sign up, but don't save the new account data and OAuth tokens to disk.

Seems like option c) would be the closest equivalent to what we do in Firefox in other areas (passwords, bookmarks, etc.) right now.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

It might be wise to do (a) since any sharing is potentially a leak of your "private mode" browsing history.

Comment 5

[Philipp von Weitershausen [:philikon]]

(In reply to comment #4)
> It might be wise to do (a) since any sharing is potentially a leak of your
> "private mode" browsing history.

But so would be bookmarking and yet we allow it in PBM. I personally don't care either way, we just need a decision. :)

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

Bug 566010 calls for the removal of the ability to create bookmarks in private browsing mode, and I think we should go in that direction with new features.

Comment 7

[Philipp von Weitershausen [:philikon]]

Thanks, that's a helpful datapoint. Let's do (a) then.

Comment 8

[(no longer active)]

Sorry that I saw this so late.

Firstly, I have absolutely no idea what sharing is all about, so I'm just using my imagination to fill in the gaps.  Reading comment 3, (c) seems to be most similar to how other things in the browser are handling the private browsing mode these days, but depending on the use cases for sharing, (a) might be a better option.  Can I know a bit more about what we're talking about here?

Comment 9

[Philipp von Weitershausen [:philikon]]

(In reply to comment #8)
> Firstly, I have absolutely no idea what sharing is all about,

It's essentially the F1 extension that we're integrating into Firefox 5. It lets you share the page you're on using Twitter, Facebook, etc. When you do so, it also bookmarks the page.

Comment 10

[Sid Stamm [:geekboy or :sstamm]]

I was advocating (a) since, as I see it, not storing history in private browsing mode runs counter to sharing your browsing history (even with Twitter, etc).

Comment 11

[Philipp von Weitershausen [:philikon]]

(In reply to comment #10)
> I was advocating (a) since, as I see it, not storing history in private
> browsing mode runs counter to sharing your browsing history (even with Twitter,
> etc).

Except sharing is much more explicit than just browsing. It's a lot like bookmarking which we do allow during PBM.

Comment 12

[Philipp von Weitershausen [:philikon]]

Whatever we do, we'll need input from UX on this, so I'm making this block bug 642684.

Comment 13

[(no longer active)]

For something like F1, I think we should just disable sharing completely inside the private browsing mode.

But there is also the question of people running with permanent private browsing mode enabled, too.  Should we just take this feature away from them?  Maybe not.  This feels like kind of a UX decision more than a technical one.  Let's hear the opinion of the UX folks -- I can still help with the technical side of things.

Comment 14

[Bryan Clark (DevTools PM) [:clarkbw]]

I'd like to talk to other Firefox UX people about this but I don't think we need to disable F1 during Private Browsing.  Sharing a page is an explicit act that people need to take on while browsing, there isn't any information leakage simply because F1 is enabled.  Though I think I would feel the same way about bookmarks.

I could see it might make sense to add a speed bump to these activities, to ensure there isn't accidental data loss during PB.  F1 doesn't have a "direct share" keyboard shortcut but I could see for bookmarks that there is some kind of dialog asking if people are sure they wanted to bookmark something after hitting cmd/ctrl+d.  In terms of F1 I could see us explicitly asking people if they wanted F1 to bookmark links that were shared instead of auto-bookmarking as it does currently.

Comment 15

[Philipp von Weitershausen [:philikon]]

I can take this one, once we have UX + sec input on the matter.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

we really need simultaneous browsing and private browsing in seperate windows asap. if creating a second temp profile is the only way to quickly do that, thrb we aren't just cutting access to f1 and bookmarks, but really everything.

not ideal (users may particuarly want extensions and password manager) but keeping their non-privatr window open is the higher priority until we can reach the perfect implementation.

Comment 17

[(no longer active)]

(In reply to comment #16)
> we really need simultaneous browsing and private browsing in seperate windows
> asap. if creating a second temp profile is the only way to quickly do that,
> thrb we aren't just cutting access to f1 and bookmarks, but really everything.

I do have some plans on making that possible without hacks such as a second temp profile.  You'll hear more about it from me very soon, and we plan to discuss this next week at the all-hands.

Comment 18

[Mike Connor [:mconnor]]

Let's not get into the "how should PB work in an ideal world?" debate in this bug. If we want to revisit that decision, it's a much broader discussion, and I don't think it is good design to make decisions piecemeal.

As implemented now, Private Browsing mode disables automatic tracking of personal information, but allows users to make explicit choices to remember things.  We generally avoid presenting "muscle memory" types of dialogs/prompts, but users can still explicitly bookmark/save pages/email links/etc.  The rationale behind this design was that users should be allowed to make that call themselves.

This all comes down to user intent.  If I intend to share a link, I am making a specific decision to share that link.  I don't see a compelling reason given in this bug to prevent a user from taking a specific action, so I really feel like we should WONTFIX this unless/until we build a different Private Browsing mode.

Comment 19

[Philipp von Weitershausen [:philikon]]

(In reply to comment #18)
> This all comes down to user intent.  If I intend to share a link, I am making a
> specific decision to share that link.  I don't see a compelling reason given in
> this bug to prevent a user from taking a specific action, so I really feel like
> we should WONTFIX this unless/until we build a different Private Browsing mode.

I agree, except instead of WONTFIXing I suggest implementing option (c).

Comment 20

[Bryan Clark (DevTools PM) [:clarkbw]]

Ok, I'm setting this to wontfix as the question should actually be framed in terms of Firefox 5 (aka 2 weeks from now).  We're currently very much inline with how bookmarks work in PB mode.  As long as sharing isn't automatically leaking any information about your private browsing out then I think we've satisfied the user expectation of privacy.

(c) sounds interesting but just as bookmarks are currently saved during PB accounts can currently be saved and we can revisit that decision on a longer timeline.

I think we also have some future direction and will continue to watch for changes in private browsing as it evolves and we need to adapt sharing with that.  I'll duplicate this bug into another bug that continues to follow Privacy Browser post Firefox 5 where we can start work on that.

Comment 21

[Philipp von Weitershausen [:philikon]]

(In reply to comment #20)
> (c) sounds interesting but just as bookmarks are currently saved during PB
> accounts can currently be saved and we can revisit that decision on a longer
> timeline.

The rationale for (c) was that we don't attempt to store your passwords in PBM, so our storage component shouldn't store oauth tokens, either. Bit of an edge case, I admit. Just sayin' that I think it's pretty analogous to passwords.

Comment 22

[Sid Stamm [:geekboy or :sstamm]]

I still think we should do (a).  As I mentioned in comment 6 and Ehsan said in comment 13, this is the direction private mode is going and we don't want to make it easy for people to shoot themselves in the foot by sharing sites they visit in private mode, publicly.

Perhaps it would be wise to add a partial exception for people who use permanent private browsing mode... no persistent storage, but you can sign in and use F1 during your session.  That use case makes sense, but allowing sharing and stuff in short PBM sessions doesn't seem as appropriate.

Comment 23

[(no longer active)]

This is not WONTFIX at all!  To recap what needs tobe done here:

If the UX folks think that sharing should act the same way as bookmarking in this context (which, after reading comment 18 seems more logical to me), (c) is what should be done here.

Otherwise, (a) is what needs to be done here.

It's simply impossible for us to leave sharing enabled *and* save auth tokens on the local disk as a result of sharing.  Furthermore, we cannot leave *any* local trace about sharing link X on website Y (or traces involving only X or only Y).

Supporting sharing without this bug being addressed breaks the private browsing functionality.

Also, the discussion about how private browsing _should_ work was just a side-chat, and does not affect what people said in this bug at all.

Comment 24

[Mike Connor [:mconnor]]

I actually think it should be WONTFIX, and that c) will also break user expectation.  That we store user tokens on the client side, instead of on the server, is purely an implementation detail.

Keep in mind that the setup flow takes place in a content tab, and the OAuth dance happens in a web-based browser popup.  As far as the setup flow appears to users, they're authorizing a web application to post to their social networks.  If I sign into Gmail in PB and change settings, I'd be pretty surprised if exiting PB causes my settings changes to be undone.

I'm going to repeat this again, since to me this is the key: user expectation and intent must be the primary consideration with this (and any other) design decision.  If the user intent is "configure Sharing to use Facebook" then we should respect that and not try to second-guess that user's decision.

If and when PB changes to be a separate window that is stripped of any way of persisting data, obviously we'll follow that overall design direction, but until that point, we should be consistent with how the rest of the app behaves.

Comment 25

[(no longer active)]

mconnor grabbed me today and convinced me that I'm wrong.  I now know a bit more about sharing as it's going to be implemented in Firefox, and with that new information, I concur that this bug in its current form is WONTFIX.

Comment 26

[Zandr Milewski [:zandr]]

I'm late to the party, but I think WONTFIX *also* breaks user expectations in PBM.

Here's the thing. I didn't know f1 bookmarked the shared link until I read this bug, linked from the Privacy Review.

I think f1>Gmail is a perfectly viable use case that the user would expect to be private, yet we write a bookmark, even in PBM.

(I'm ignoring what the server has access to in the process, that's a whole different conversation)

The context is here, but 'default bookmarking to off' just be a separate bug that addresses this.

Comment 27

[Mike Connor [:mconnor]]

Yes, definitely a separate bug, I agree that automatic persistence of data is different, as long as bookmarking is on by default.  Trickier argument if that was inverted!