Closed Bug 644769 Opened 13 years ago Closed 13 years ago
Disabling sharing during Private Browsing Mode
No description provided.
Sid, it would be great if you guys could help us define the behaviour here, if we need any special behaviour at all.
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
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.
It might be wise to do (a) since any sharing is potentially a leak of your "private mode" browsing history.
(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. :)
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.
Thanks, that's a helpful datapoint. Let's do (a) then.
Summary: Figure out how to integrate with Private Browsing Mode → Disabling sharing during Private Browsing Mode
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?
(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.
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).
(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.
Whatever we do, we'll need input from UX on this, so I'm making this block bug 642684.
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.
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.
I can take this one, once we have UX + sec input on the matter.
Assignee: nobody → philipp
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.
(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.
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.
(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).
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(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.
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.
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WONTFIX
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.
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.
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!
You need to log in before you can comment on or make changes to this bug.