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

Status: RESOLVED FIXED

(Core :: Widget, defect, P2)

Description

[Rob Wu [:robwu]]

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 )


Expected:
- Nothing to see.

Actual:
- 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:

https://searchfox.org/mozilla-central/rev/2aa0806c598ec433e431728f5ddd3a6847c1a417/widget/nsTransferable.cpp#65-67
(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:
https://searchfox.org/mozilla-central/search?q=nsiTransferable%3A%3Ainit&case=false&regexp=false&path=

Comment 2

[Rob Wu [:robwu]]

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.

Comment 4

[Rob Wu [:robwu]]

Attachment: Bug 1396224 - Avoid cache for private clipboard data

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
tests.

Comment 5

[Rob Wu [:robwu]]

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).

Expected:

• After step 5, the result should look like the first part of the bottom of https://bugzilla.mozilla.org/show_bug.cgi?id=1433030#c20
• After step 6, the result should look like the second part of the bottom of https://bugzilla.mozilla.org/show_bug.cgi?id=1433030#c20
• After step 9, the terminal should not show any file IO related to mozilla-temp- files.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e2e80a9540ff
Avoid cache for private clipboard data r=mstange

Comment 8

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/e2e80a9540ff