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
47 bytes, text/x-phabricator-request
|Details | Review|
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®exp=false&path=
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: nobody → rob
Status: REOPENED → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e2e80a9540ff Avoid cache for private clipboard data r=mstange
You need to log in before you can comment on or make changes to this bug.