815952 - Remove the "clear clipboard on exit" during Private Browsing

Status: VERIFIED FIXED

(Firefox :: Private Browsing, enhancement)

Description

[yakmandango]

What did you do:
Set to "Private Browsing" indirectly, by selecting:  Tools --> Options --> Privacy --> History --> "Never remember history"
Accessed a URL.
Copied text from within the content at the URL.
Closed FireFox.
Attempted to paste the text into another application.

What happened:
No data was pasted from the clipboard.

What should have happened:
Data pasted from clipboard.

Reference:
This feature was implemented as with Bug 462106 (https://bugzilla.mozilla.org/show_bug.cgi?id=462106).  One comment issued recently on that bug, requests a way to disable the function via "about:config".

Request:
Please provide a way to disable this function of Private Browsing.  Please also consider making the clearing behavior optional, rather than default.

Rationale:
Below I explore an improvement, which I believe takes the motivation for clearing the clipboard to a further extreme.  The intention of this exaggeration is to make clear two simple reasons why the new clipboard-clearing behavior feels uncomfortable to a user.

It looks like the idea is a special "Private" clipboard that breaks with the standard Operating System clipboard behavior, to improve data privacy control.  To achieve this, a custom clipboard should be implemented as a feature of Private Browsing, leaving the OS clipboard as a separate entity.  Or, possibly, making only clearly-defined interactions with the OS clipboard.  With the clipboard is cleared only on exit, it feels incomplete and intrusive.

Incomplete:  The overall goal seems to be isolation of data related to a Private Browsing [PB] session.  Looking at the possible dataflows, the clipboard is one.  From this point of view, just clearing on exit only provides situational isolation.  Data could also be imported from outside a PB session by pasting data from outside sources.  Data from a PB source could be exported before the browser closes, and before the PB session ends.  Inside the perimeter, data can also flow from one tab to another, and one domain to another (see JavaScript's "Single Origin Policy").  It's possible that PB doesn't clear other areas, because they are left to the user/OS, e.g.: on the file system (slack space from temporary files or swap files), in RAM (previously-used stack or heap memory).

Intrusive:  A "clear on exit" feature [or any "clear on event" feature] breaks the typical use contract between users and their operating system.  A common assumption by users is that the OS provides the clipboard, and all applications do is get and put data upon the direct command of the user.  Applications aren't to touch the clipboard for other reasons.  An exception might be when their purpose clearly involves some operating system function (e.g. A/V may scans many things, including the clipboard, for malicious activity or content), or specifically the clipboard (e.g. a utility that converts all clipboard contents to plain text).  Personally, I don't know of any apps that touch it.  To attentive users, deleting contents of the clipboard feels like an intrusion.

Comment 1

[(no longer active)]

This change was implemented because we wanted to err on the cautious side and make sure that we're not leaking data about the things that users did in their private browsing session.  I don't think that the annoyance that this has caused you is large enough for us to add an option for overriding it, as these types of options are hard to maintain and increase the overall code complexity over time.  I think this is something that an add-on can be written to do, and I'd like to wontfix this bug for now, until we have evidence that this is affecting a large number of our users.

Comment 2

[yakmandango]

Life is easier without resorting to annoyance :)  I hope users who are simply dissatisfied with the feature would suffice.

It'd be easier to accept the request for evidence, if the same bar had been applied to implement the feature in the first place.  A compelling argument was sufficient at that point; why not now?

If we don't know whether the user wants their clipboard cleared or not, shouldn't we ask?  PB sessions are a good place to access sensitive data.  It's fair to assume that someone may copy some sensitive data to the clipboard.  Since the clipboard is a feature of the OS, and not of Firefox, they might also assume that it will still be there after Firefox closes.

If a user really has left something sensitive on the clipboard, they either wanted it there or they didn't.  Always clearing it addresses the latter case, when they didn't want it.  In the former case, when they do want it, we destroy a copy of some sensitive data.  In some cases, it might be the only copy.  We may judge that as a bad decision by the user.  But forgoing that judgment, we may err on the side of caution, by preserving the user's clipboard data from such an unexpected loss.

Is the level of caution appropriate?  Unchecked caution can become unhelpful.  Mozilla support sets the tone for Private Browsing here (http://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-saving-info): it protects against people who use your computer, but not malware and the such.  From that point of view, closing the browser is a significant event.  It's someone's way of saying "okay I'm done, FireFox, clean it up proper".  Someone who wants this feature would probably want to be certain that it's happening.  Right now the only way to tell that the clipboard is clear is a functional test: try pasting.  It'd be a better assurance to make the feature evident, so someone can know with confidence when, how, and why the clearing happens.  Otherwise, a user might guess "maybe it was a fluke last time, and maybe it won't get cleared this time".

Two other arguments were been presented related to intrusion and incompleteness.  These seem to be disqualified as minor annoyance.  While I'd concede that both are minor, I don't entirely agree that they're simply equivalent to annoyance.  Intrusion breaks a common user assumption.  In an immediate sense, that may lead to annoyance, but overall it can also degrade confidence in the product.  Incompleteness of solution more directly affects product confidence.

Comment 3

[(no longer active)]

We can't really ask the user before making every decision, most of the time we just use judgement to come up with the most appropriate decision and make that on behalf of the user.

Something which was a factor in accepting the original patch is that the clipboard data is transient by default, and for example copying something else in another application will overwrite the contents of the clipboard without asking the user, so most of the time you only use it for pasting shortly after you've copied something, and probably before you've closed your window...

Note that this is specifically designed to prevent someone else sitting at your computer after you've left private browsing mode to see something that you had copied from a page before.

Comment 4

[yakmandango]

Clipboard data is generally transient by nature, but the clipboard also has to be reliable enough to use.  Events that normally clear the clipboard: copying new data, logout, restart, or shutdown.  Are there others?

The suggestion is not to ask the user upon every decision, but only in this instance of breaking a normal OS user experience pattern, to avoid unexpected loss of user data.  For example, prompt upon exit, including a "remember this decision" checkbox.  Following this established user experience pattern, the question would only be asked once.  This would also serve the purpose of making evident how the clearing function works, so that users have a basis to rely on it.

Someone who wants a their data cleared would see the prompt, or remember having seen it before, or could check in the configuration to verify.  This user would  therefore have confidence that the clipboard data was gone, whatever they might've copied there at some point.

With the prompt, somebody who copied data to the clipboard with the intention to use it after closing the browser would not find their data mysteriously missing.  Or, if they did lose it, it would be a pure case of user error.

As an outside example, Microsoft Office applications also prompt the user upon exit, if a large amount of clipboard data has been copied.  I still haven't come up with any examples of an application that clears the clipboard without asking the user, aside from FireFox.

Is this a wontfix for level of effort, because it is not an appropriate feature regardless of effort, some combo of those, or...?  If it's just effort, I'm inclined to submit a patch.  If it's because of appropriateness, then I'd like to resolve before spending effort on a patch.

Comment 5

[(no longer active)]

I think it's a terrible UI to prompt the user about the clipboard contents when they leave the private browsing mode.  The user has no visibility on what's on the clipboard, and the fact is that clipboard data is in fact transient, and is intended to be used as a quick place to save something for a very short period of time.  The reason that I wontfixed this was the above, not the amount of effort that writing the patch is going to take (we don't wontfix bugs if they're hard!).  I think this is best done in an add-on, since I don't believe this belongs in the core product.

Comment 6

[f.ck you mozilla team]

I think whoever decided to change this behavior without letting advanced users to decide for themselves is an idiot.
No warning about it and no about:config option => I can only switch to other browser.
Thank God we're not in 1990's when I had no other choice (Yes, I'm that old) so I have a couple of decent alternatives rather than being forced back to IE!

Comment 7

[f.ck you mozilla team]

OH and by the way, NSA's got everything about you and you care about the corner case of the pervert guy sitting next to you in the internet cafe stealing your data from clipboard! how stupid can you be to make such a big change for this 0,00001%-probability case? IDIOTS...!!!

Comment 8

[(no longer active)]

Comment 6 and comment 7 are way out of line for this discussion forum, please consult <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before posting any further comments, and please refrain from insulting people because you don't agree with their decisions.  Thanks!

Comment 9

[f.ck you mozilla team]

when these decisions FORCE ME INTO BREAKING A HABIT - particularly not a BAD one - and FORCE ME CREATE NEW HABITS (open a text editor, paste, exit fx) THAT ALSO MAKE ME DO MORE WORK THAN BEFORE then these people deserve all insults in the world!
technology should not be about making things more complicated, but easier.
technology should not make people adapt to it but rather adapt to HUMAN BEHAVIOUR.

Comment 10

[(no longer active)]

(In reply to comment #9)
> when these decisions FORCE ME INTO BREAKING A HABIT - particularly not a BAD
> one - and FORCE ME CREATE NEW HABITS (open a text editor, paste, exit fx) THAT
> ALSO MAKE ME DO MORE WORK THAN BEFORE then these people deserve all insults in
> the world!
> technology should not be about making things more complicated, but easier.
> technology should not make people adapt to it but rather adapt to HUMAN
> BEHAVIOUR.

If you insist on insulting people, I would be more than happy to ignore you.  This is not a good way to have a productive conversation, sorry.  I won't respond on future comments from you.

Comment 11

[Rabbi Bull]

This is a "bug" that has bothered me for a long period of time, and one that I've had to learn to work around.  It's something I "put up with", but it's not the behavior I would expect.

I don't want my browser keeping track of my browsing history, for a variety of reasons.  However, I do not consider the clipboard as part of my browsing history, nor do I consider Firefox to be the owner of the clipboard.

I think it's a good option to have--some people may appreciate the extra security this provides.  However, I think it's equally as important to have the option to disable this behavior.

I would appreciate this bug ticket being re-opened, because there are certainly action items that need to be given attention.  These action items are as follows:

1. Define the clipboard as something that will be cleared when the browser closes.  This is not clearly listed within the privacy options, which is why it comes as a surprise to people when their clipboard is mysteriously missing after closing Firefox.

2. Provide users the granularity to disable this arguably erroneous behavior, even if it's only in the about:config.

As far as whether or not this negatively impacts a large number of users, it's difficult to tell.  I didn't realize it was Firefox clearing out my clipboard for quite a long time.  It took me years of frustration before finally getting to the point where I figured out what was happening.  After that, it took another year or so before it finally annoyed me to the point where I determined it was time to let someone know there's room for improvement when it comes to my Firefox experience.

Thank you for your consideration.

Comment 12

[(no longer active)]

Hmm, I think I have received enough complaints about this over the years to make me want to reconsider.  I'm still very uncomfortable with changing the defaults here, but I might consider adding a pref to disable this for people who really care.

But before we proceed, Madhava, do you agree with me about the desired default behavior here?

Comment 13

[jaramat]

Clearing the clipboard after leaving the private browsing mode has bugged me for quite some time now. I use private browsing mode for visitting websites that I don't want to appear in my browsing history, often sites I want to just take a peek at, copy some text from them, close the window and paste it somewhere else. Current configuration makes me switch to my destination window, paste the desired text and then close the private window, which is a process way slower than I like.
I hereby plead you to create a boolean switch to enable/disable the automated clipboard cleanup behaivor, or make the cleanup happed after some time passes, like one or two minutes after closing the private window.

Comment 15

[Iain Elder]

Thank you for considering this, Ehsan.

As a fellow software developer, I sympathize when you say "these types of options are hard to maintain and increase the overall code complexity over time".

Meeting the user requirements should still be the top priority. In this thread there are several commenters representing the users who want Firefox to leave clipboard data up to the user.

I use private sessions to keep the browser history and cache clean. Clearing these on exit makes sense to me. Firefox can do what it likes with its own resources as long as the behavior is consistent and controllable (it is).

The system clipboard does not belong to Firefox, so I expect different behavior here. Without an "explicit action" on my part, I don't expect the clipboard to change.
https://bugzilla.mozilla.org/show_bug.cgi?id=816998

I'd have voted against this feature if I was a Firefox user when it was proposed.

Do you have a record of the original proposal? I'd be interested to see why people wanted to implement this.

Comment 16

[Iain Elder]

I found the original proposal (It's right at the top of this bug, but I missed it):
https://bugzilla.mozilla.org/show_bug.cgi?id=462106

It starts: "We may need to clear the contents of the clipboard [...] This bug is filed to discuss this."

The discussion is mostly "how do we implement this" rather than "why would a user want us to do this".

No-one replied to Igor Velkov's request that it be made optional.

"""
As compromise, there have to be a non-modal warning about non-empty clipboard exiting private mode, and chooser: 
clear clipboard(default), keep clipboard, stay in private mode, and checkbox "remember decision" for exit buttons.
"""

What do we think of his proposal now?

I think it's a better solution than fiddling with about:config.

Comment 17

[jaramat]

Attachment: "Clear clipboard at Private mode exit" new option

(In reply to Iain Elder from comment #16)

If this feature is ever going to get fixed, an about:config entry will be necessary. Ideally, the user shouldn't be prompted at all. This should be a new option to set up under Options -> Privacy, as you can see in the attached image (that I GIMPed).

Comment 18

[(no longer active)]

Here are a few points to consider:

1. I'm definitely not interested in showing any kind of prompt when the user closes their last private window.  We should in general be trying to show fewer prompts and not more, especially ones that disrupt interactions such as closing a window.

2. I'm not very interested in adding a pref for this because it increases the complexity of the code and increases the number of configurations which we need to maintain.  But based on the number of complaints that I've seen about this over the years, I'm now open to consider the idea as I mentioned in comment 12.

3. What ultimately really matters here is going to be the default behavior.  The pref is not going to be very discoverable to most of our users, and we should try to make a sensible judgement on what the default behavior should be.  While I think that the current default behavior is not perfect, and I do agree that it can lead to surprises, it is designed to protect the majority of our users who don't necessarily have the mental model of something they copy to the clipboard to survive the lifetime of their tabs/windows.  During the design of the private browsing mode, we made a lot of effort to make sure that we're making the right choices on behalf of the majority of our users.

That all being said, this is really a UX decision, so I'm not ultimately the person to make the final decision.  If Madhava gets back to us saying that the existing default is fine, I will be open to adding a pref to turn this off for those who are annoyed by it.  If he says that we should change the current behavior, then that's what we will do here.

We're currently blocked on making a decision here.  Whatever the decision ends up being, implementing it is relatively simple.  I hope this clears up the current state of affairs here.

Comment 19

[Iain Elder]

jaramat:

I don't know Firefox internals, so thanks for confirming that about:config is a prerequisite.

Thanks for the mockup. I'd be happy to use something like that.

Options that exist only in about:config annoy me because they are harder to find than options in the GUI. I resort to Google every time I want to enable MRU tabbing or disable backspace as a back button. (I'm not against the global config table in principle, but improving it is another issue.)

Ehsan:

I agree, there are too many prompts already. jaramat's proposed check on the privacy tab would be less disruptive.

Security is a balancing act. I believe it works best when it meets informed user or administrator preference.

For users unconscious of their mental model, isn't the best thing we can do to be consistent? Firefox is the only app I know that does this.

Looking forward to Madhava's perspective.

Comment 20

[(no longer active)]

(In reply to comment #19)
> I agree, there are too many prompts already. jaramat's proposed check on the
> privacy tab would be less disruptive.

I don't think that the use case here is important enough to warrant adding a new checkbox to that dialog.

> For users unconscious of their mental model, isn't the best thing we can do to
> be consistent? Firefox is the only app I know that does this.

The goal of the private browsing mode is to protect the users' privacy, not necessarily be consistent with other applications.

Comment 21

[Iain Elder]

What do other popular browsers do, and how do the users feel about it?

Chromium implemented the feature in April this year, and reverted it in June.
"we tried it out and didn't like it"
https://code.google.com/p/chromium/issues/detail?id=171974#c20
https://code.google.com/p/chromium/issues/detail?id=242767

In that thread, Chromium users were annoyed and frustrated.

Opera implemented the feature in 2010 (DSK-273009)
http://my.opera.com/desktopteam/blog/2010/04/16/fixing-bugs

Opera users are quiet about the feature.

Internet Explorer preserved the clipboard contents after I closed InPrivate browsing today. Can't find a public reference for it.

Can't find a public reference for Safari. Too much effort for me to test it and avoid installing iTunes at the same time.

Browserland is divided on the issue, and poorly documented.

Comment 22

[(no longer active)]

(In reply to Iain Elder from comment #21)
> What do other popular browsers do, and how do the users feel about it?
> 
> Chromium implemented the feature in April this year, and reverted it in June.
> "we tried it out and didn't like it"
> https://code.google.com/p/chromium/issues/detail?id=171974#c20
> https://code.google.com/p/chromium/issues/detail?id=242767
> 
> In that thread, Chromium users were annoyed and frustrated.
> 
> Opera implemented the feature in 2010 (DSK-273009)
> http://my.opera.com/desktopteam/blog/2010/04/16/fixing-bugs
> 
> Opera users are quiet about the feature.
> 
> Internet Explorer preserved the clipboard contents after I closed InPrivate
> browsing today. Can't find a public reference for it.
> 
> Can't find a public reference for Safari. Too much effort for me to test it
> and avoid installing iTunes at the same time.
> 
> Browserland is divided on the issue, and poorly documented.

Thanks Iain, this is *extremely* helpful!  I actually did not know that Chrome has tried this and reverted their decision.  Let me see if I can reach out to Madhava and ask him to get back to us sooner on this.

Comment 23

[Tom S [:evilpie]]

Did anything happen here in the meantime?

Comment 24

[(no longer active)]

(In reply to Tom Schuster [:evilpie] from comment #23)
> Did anything happen here in the meantime?

No, I contacted Madhava in December and have not heard back yet.

Comment 25

[Matt]

The "feature" so infuriated me that I went through the trouble of creating a account.  I have never before encountered an application that makes uncommanded changes to the operating system clipboard as Firefox does when closing a private browsing window.

And, to play devil's advocate, Firefox *fails* to clear the clipboard of screenshots taken via PrtSc of the private browsing window.  If the current clipboard clearing is considered a feature, this failure must certainly be considered a bug.

Comment 26

[jaramat]

Matt, it needs to be noted that Firefox clears the contents of clipboard only if the contents in question were created by Firefox's private window in the first place. Firefox has no control over screen capturing software, so it's only logical that the screenshot of the screen stays in the clipboard after closing the private window.

Just try it yourself: copy something from, say, notepad, open Firefox in Private mode, and close it again. The clipboard stays untouched. Now, open Firefox in Private mode, copy something from the window, close the window, and check the clipboard - it's cleared.

So, it works as intended. Needles to say, "works as intended" does not always equal to "works as the user expects it", and this bug is still valid.

Comment 27

[Matt]

A common use case which this behavior interferes with is using private mode to browse sites that limit access based on cookies, such as major newspapers.  When the site's view limit is reached, the user may want to copy the URL, close and reopen the private window to clear cookies, paste back the URL, and continue browsing.

I was only half serious about the failure to remove screenshots being a bug, although one could make that argument in light of Ehsan's statements in comment 1 that "we wanted to err on the cautious side and make sure that we're not leaking data about the things that users did in their private browsing session" and in comment 20 that "The goal of the private browsing mode is to protect the users' privacy, not necessarily be consistent with other applications."

Comment 28

[(no longer active)]

(In reply to Matt from comment #27)
> A common use case which this behavior interferes with is using private mode
> to browse sites that limit access based on cookies, such as major
> newspapers.

Without meaning to get into a more detailed discussion about this, this is actually not a use case for private browsing, and there are newspaper sites with more sophisticated cookie techniques which already defeat this (but I understand your point).

> When the site's view limit is reached, the user may want to
> copy the URL, close and reopen the private window to clear cookies, paste
> back the URL, and continue browsing.
> 
> I was only half serious about the failure to remove screenshots being a bug,
> although one could make that argument in light of Ehsan's statements in
> comment 1 that "we wanted to err on the cautious side and make sure that
> we're not leaking data about the things that users did in their private
> browsing session" and in comment 20 that "The goal of the private browsing
> mode is to protect the users' privacy, not necessarily be consistent with
> other applications."

We have never attempted to prevent other application running on the system (such as a screenshot capture utility) from capturing traces of the users' browsing in private browsing mode.  In fact, that would be impossible from a technical standpoint on the OSes that our users use.

Comment 29

[M8R-igrcf5]

This feature has given me enough unpleasant surprises to make me create an account and kindly ask for an option to disable it. 

Sometimes i like having FF running with 30+ tabs opened for hours, but sometimes i only open FF whenever i want to find information about something and then i immediately close it to get back to where i was working before. If i had copied something important to my OS's clipboard, i am sad to realize that it is not there anymore! Furthermore, it may even take a little while to find that information again since the browser's history is cleared. 

Therefore, i believe that having an option to disable that behaviour would greatly save me from lots of frustration whenever i have the above workflow.

Comment 30

[(no longer active)]

CCing some other folks who might be able to help us the UX input requested here.

Comment 32

[(no longer active)]

OK, I'm done waiting on this bug and I'm going to make the call here as the module owner.

My decision is to remove this behavior completely from the product.  I'd be happy to mentor someone to do this, but this is not a great first bug.  Mike, how do we mark those types of bugs again?

Comment 33

[Mike Hoye [:mhoye]]

Marking it [good next bug] and [diamond], I'll shop it around in the morning.

Comment 34

[Biru [:poiru]]

Attachment: Stop clearing clipboard data originating from a private window after closing private windows

Comment 35

[Biru [:poiru]]

Attachment: Stop clearing clipboard data originating from a private window after closing private windows

Try push: https://tbpl.mozilla.org/?tree=Try&rev=c2655a4697d8

Comment 36

[(no longer active)]

Comment on attachment 8455122 [details] [diff] [review]
Stop clearing clipboard data originating from a private window after closing private windows

Review of attachment 8455122 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks so much!

::: widget/tests/test_bug462106_perwindow.xul
@@ -1,5 @@
> -<?xml version="1.0"?>
> -<?xml-stylesheet type="text/css" href="chrome://global/skin"?>
> -<?xml-stylesheet type="text/css" href="chrome://mochikit/content/tests/SimpleTest/test.css"?>
> -<!--
> -https://bugzilla.mozilla.org/show_bug.cgi?id=462106

Broken splinter!

Comment 37

[Biru [:poiru]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5a1427a43a8f

Comment 38

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5a1427a43a8f

Comment 39

[Catalin Varga [QA][:VarCat]]

Verified as fixed using the following environment:

Firefox Nightly
Build Id:20140718030202
OS: Win 7 x64, Ubuntu 13.04 x64, Mac Os X 10.7.5

The clipboard data originating from a private Firefox window is not cleared after closing Firefox.

Comment 40

[ssnobody]

I see that a fix for this has made it into nightly and will presumably reach the stable product.

I just wanted to thank you for the patch. This "bug" got me again today and I appreciate that it will stop "bugging" me in the near future.

Comment 41

[b552824]

I just stumbled upon this default behavior being changed in FF 33.  Not a fan given that one using a private browsing window is done deliberately so user history is automatically deleted upon close but I gather this change is permanent.

My question, how does one go about changing the default behavior in about: config for this?  I haven't been able to find out myself or via a search yet.  It is possible for one to choose to have clipboard contents created when in a private window automatically deleted upon close like it was before isn't it?

Thanks.

Comment 42

[Biru [:poiru]]

(In reply to b552824 from comment #41)
> My question, how does one go about changing the default behavior in about:
> config for this?  I haven't been able to find out myself or via a search
> yet.

Unfortunately you can't as this feature was removed entirely.

Comment 43

[Techni Myoko]

It has not been removed, as I still have it happen. Only now it's when Firefox crashes. Which is really annoying because it makes it harder to recover from the crash, which was usually from pasting from the clipboard in the first place.