#21742: Investigate fingerprinting/linkability risk with File and Directory Entries API support -------------------------------------------------+------------------------- Reporter: gk | Owner: | arthuredelstein Type: task | Status: | needs_review Priority: High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: ff52-esr, TorBrowserTeam201704R, | Actual Points: tbb-7.0-must-alpha, tbb-fingerprinting | Parent ID: | Points: Reviewer: | Sponsor: -------------------------------------------------+------------------------- Changes (by arthuredelstein):
* keywords: ff52-esr, TorBrowserTeam201704, tbb-7.0-must-alpha, tbb- fingerprinting => ff52-esr, TorBrowserTeam201704R, tbb-7.0-must-alpha, tbb- fingerprinting * status: accepted => needs_review Comment: A subset of the File and Directory Entries asynchronous APIs were introduced in Firefox 50. These APIs can be disabled by the "dom.webkitBlink.filesystem.enabled" pref. The interfaces [https://developer.mozilla.org/en- US/docs/Web/API/File_and_Directory_Entries_API#Asynchronous_API are]: * FileSystem * FileSystemEntry * FileSystemFileEntry * FileSystemDirectoryEntry * FileSystemDirectoryReader * FileError Unlike Chrome, Firefox does not allow writing to the files; only reading them. The two access points in the Firefox JS API that expose these interfaces [https://developer.mozilla.org/en- US/docs/Web/API/File_and_Directory_Entries_API/Firefox_support#Limitations_in_Firefox are]: * `HTMLInputElement.webkitEntries` * `DataTransferItem.webkitGetAsEntry()` In Firefox, if the user drags and drops a directory or multiple files onto an <input> element or a "HTML Drag And Drop" target, then these APIs return a list of FileSystemFileEntry or FileSystemDirectoryEntry objects. In the case of the Drag And Drop API, the full hierarchy within the dragged directory can be retrieved (see an example from Mozilla at https://jsfiddle.net/syq3hdm9/). In the `<input>` element case, multiple files can be retrieved, but nested directories don't appear to be working correctly. In Firefox, the available data for each file or directory consists of: * a relative path from the "root" (dragged directory) * the file name * booleans `isDirectory` and `isFile` * a corresponding File object * a nonce UUID specific to the file and session As far as I can tell, the provision of this information (apart from the nonce) by these APIs is redundant -- it's already available using File objects returned by `HTMLInputElement.files`, where the user has dragged a directory onto an `<input type="file" webkitdirectory multiple />` element. In that case as well, it's possible to get the relative path, file name, and infer directory names from File objects. (See Mozilla's demo at https://jsfiddle.net/8ugLLdhs/) So it looks to me that, if we want to block reading of multiple files in a hierarchy, we need to disable not just the File and Directory Entries API but HTMLInputElement.files as well. There might be an argument to be made for disabling all of these things, given that dragging and dropping a directory onto a web page could potentially reveal large amounts of private information. The user could accidentally drag on the root directory of their entire user directory for example, thus revealing the names and contents of all files inside. Or, the user might drag and drop a directory without realizing that it contains hidden files that contain private data. On the other hand, being able to upload a directory of files seems rather useful, and the danger is mitigated by the requirement that the user actively provide the directory via drag and drop. One privacy enhancement I could imagine we could introduce would be a confirmation dialog (providing an option to cancel) before a file list with that includes many files or hidden files is handed to the content script. So my current thinking is that it is not necessary to block the File and Directory Entries API. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21742#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs