Opened 3 years ago

Closed 2 years ago

#21742 closed task (fixed)

Investigate fingerprinting/linkability risk with File and Directory Entries API support

Reported by: gk Owned by: arthuredelstein
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-7.0-must-alpha, tbb-fingerprinting, TorBrowserTeam201705R
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Mozilla convinced itself to implemented parts of Chrome's File and Directory Entries API for compatibility reasons ( and We should check whether that one adheres to our design guidelines.

Child Tickets

Change History (8)

comment:1 Changed 3 years ago by gk

Keywords: TorBrowserTeam201704 added; TorBrowserTeam201703 removed

Moving tickets over to April

comment:2 Changed 2 years ago by gk

Keywords: tbb-7.0-must-alpha added; tbb-7.0-must removed

Getting more tickets on our alpha radar.

comment:3 Changed 2 years ago by gk

Priority: MediumHigh

Moving the investigation tickets to higher priority.

comment:4 Changed 2 years ago by arthuredelstein

Keywords: tbb-fingerprinting added
Owner: changed from tbb-team to arthuredelstein
Status: newaccepted

comment:5 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201704R added; TorBrowserTeam201704 removed
Status: acceptedneeds_review

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

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.

comment:6 Changed 2 years ago by mcs

Cc: brade mcs added

comment:7 Changed 2 years ago by gk

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201704R removed

Moving review tickets to May.

comment:8 Changed 2 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good. The UUID seems to be not really session specific, although "session" might mean something else here than "browsing session": uploading the same file repeatedly leads to a different UUID every time (tested by modifying the first jsfiddle example).

Note: See TracTickets for help on using tickets.