I’ve had a ticket open with Bitdefender about why Brave’s “New private window with Tor” doesn’t work when Bitdefender’s “Advanced Threat Defense” is enabled. Based on their explanation in the attached PDF file, it seems like maybe there’s something that Brave could be doing to alleviate the situation. Providing the info to Brave here for evaluation.
ATCSUP-8667 - ATD blocks Tor private window in Brave browser.
This is a short description of the specific interaction between Brave and Tor that can fail when small
delays are introduced in a file rename operation.
Relevant implementation details in Brave:
• chromium using ReadDirectoryChangesW in various FileWatcher/
DirectoryWatcherimplementations, which triggers a callback when a directory is changed
(including file rename)
• brave-core/components/tor/tor_file_watcher.cc at
e6c9ca8503d55da7c1cdc14c7c485b39f0171bcc · brave/brave-core
Brave monitors the C:\Users\test\AppData\Local\BraveSoftware\Brave-Browser\User Data\tor\watch
folder for changes. When its callback is called, brave tries to consume a control_auth_cookie file. If
this file is not found or opening fails, no retries are attempted, and the control_auth_cookie is never
read by brave.
Tor creates a control_auth_cookie.tmp file (with no file sharing allowed) in the monitored folder,
and then renames it to control_auth_cookie (using msvcrt rename). The handle to this file is closed
in rename. Until this handle is closed, brave cannot open control_auth_cookie with read access.
On success flows, tor closes its handle before Brave attempts to open control_auth_cookie.
When ATC introduces a small delay in the processing of the file rename operation, and Brave cannot
open control_auth_cookie anymore.
We also reproduced the issue without ATC, using a small driver that introduces a 1 ms delay in the file
rename operation.