Closed Bug 1396224 Opened 3 years ago Closed 1 year ago

>500kb clipboard data (and text selection on Linux) is written to the filesystem, even in private mode


(Core :: Widget, defect, P2)

55 Branch



Tracking Status
firefox69 --- fixed


(Reporter: robwu, Assigned: robwu)


(Blocks 1 open bug)


(Keywords: privacy)


(1 file)

Steps to reproduce:

1. Create a file with 500K of data:
python -c 'print("x"*500000)' > file.htm

2. Open the file.htm in a private window.

3. Press Ctrl + A (or Cmd+A) to select everything.

4. If the platform does not have a selection clipboard (e.g. Windows or Mac), press Ctrl+C / Cmd+C to copy it.

5. Look at the temporary directory (TmpD).
/tmp/clipboardcache-xxx (Linux)
$HOME/Library/Caches/TemporaryItems (macOS)
%TMP%\ (Windows)
( the exact locations may differ, get the actual location using Services.dirsvc.get('TmpD', Components.interfaces.nsIFile).path )

- Nothing to see.

- A bunch of "clipboarcache-" files.

There are already a bunch of bugs about unwanted "clipboardcache" files (bug 1254094 and bug 335545). However, this bug is different, since starting from bug 1123480, it should not be possible for clipboard data to leak:
(this code is ultimately called when nsITransferable::SetTransferData is used)

The many calls to nsITransferable::Init with parameter null are very suspicious. In particular, IPC-related code does this:
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 335545
Is this really a duplicate?

In bug 335545 I fixed the lingering files by referencing the files via a file descriptor instead of file name, which allows us to delete a file as soon as it is created. Until the file descriptor is removed, the file handle can still be used for file I/O.

I thought that in Private browsing mode, all IO is in-memory and not persisted to avoid privacy issues.
Deleting the file descriptor makes it more complicated to recover the clipboard content, but not impossible, as the data is still written to the disk (and can be recovered by treating the disk as a block device).

Do you really consider this issue to be solved? The issues in the code that I pointed out in the report are still open, so I think that this bug should be re-opened.
Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Resolution: DUPLICATE → ---
Priority: -- → P2
Blocks: 1433030
Duplicate of this bug: 1433030

To avoid populating the clipboard cache,
nsContentUtils::IPCTransferableToTransferable should set the
IsPrivateData flag on the output transferable BEFORE assigning data to
it, not therafter.

This patch includes a new regression test for this specific scenario.

The patch also includes fixes for incorrect IsPrivateData flags in some
other locations with transferable->Init(nullptr), but without unit

I've added a patch with basic unit test. To verify (on Linux):

  1. Create a big file: python -c 'print("x x "*500000)' > /tmp/big.txt
  2. Open the big file in Firefox.
  3. Open the terminal, and start the following program to watch file behavior: inotifywait -m /tmp/
  4. Select the contents of the tab from step 2 and copy it: Ctrl-A, Ctrl-C
  5. Look at the terminal.
  6. Clear the clipboard (e.g. by selecting a small part of the page and pressing Ctrl-C).
  7. Open the big file in Firefox, in a private window.
  8. Copy its content by repeating step 4.
  9. Look at the terminal.
  10. Clear the clipboard (e.g. by selecting a small part of the page and pressing Ctrl-C).


Assignee: nobody → rob
Duplicate of this bug: 1562487
Pushed by
Avoid cache for private clipboard data r=mstange
Closed: 3 years ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.