[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21742 [Applications/Tor Browser]: Investigate fingerprinting/linkability risk with File and Directory Entries API support

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs