Unable to Retrieve Expected Results Using Performance API

[jurc3880]

Hello,

I am encountering an issue with automating webpage visits and data collection through the performance API in Tor Browser using **tor-browser-selenium** in headless mode. My operating system is Ubuntu 20.04, or alternatively, a Docker container based on the same system. The version of Tor Browser I am using is 13.0.8, with no modifications to the default browser preferences.

I have noticed that regardless of the webpage I visit, the following Python script always returns an empty list **[]** when executed:

driver.get(url)
resources = driver.execute_script(“return window.performance.getEntriesByType(‘resource’)”)
print(resources)

Attempting to modify the script by replacing **getEntriesByType** with **getEntries** , I used the following code:

driver.get(url)
resources = driver.execute_script(“return window.performance.getEntries().map(entry => ({url: entry.name, type: entry.initiatorType, size: entry.transferSize}));”)
print(resources)

This resulted in outputs like:

[
{‘size’: 56767, ‘type’: ‘navigation’, ‘url’: ‘https://www.google.com/’},
{‘size’: None, ‘type’: None, ‘url’: ‘first-contentful-paint’},
{‘size’: None, ‘type’: None, ‘url’: ‘O7jPNb’},
{‘size’: None, ‘type’: None, ‘url’: ‘kDcP9b’}
]

While the **resources** list is no longer empty, the format of the elements is not what I am aiming for. Ideally, I am looking to retrieve information in the format like:

[
{
“name”: “http://example.com/css/styles.css”,
“entryType”: “resource”,
“startTime”: 100,
“duration”: 200,
…
},
{
“name”: “http://example.com/js/script.js”,
“entryType”: “resource”,
“startTime”: 300,
“duration”: 150,
…
},
…
]

Theoretically, the script I am using should work in both Firefox and Chrome Browser. However, I am unable to replicate the expected results in Tor Browser. From this forum thread, I learned that the default RFP (Resist Fingerprinting) policy in Tor Browser might affect the performance API.

Following ChatGPT’s guidance, I was unable to locate the **prefs.js** file in [tor-browser/Browser/TorBrowser/Data/Browser/profile.default/] to add the line **user_pref("privacy.resistFingerprinting", false);**. Even after manually creating the file and restarting the Tor service, it didn’t resolve the issue.

Furthermore, I came across a thesis here (page 27), mentioning

Lennart also modified Firefox to enable the performance API that is disabled by default in Tor and implemented the deployment integration of that browser build.

Does this imply that in the worst-case scenario, I might need to modify the Tor Browser source code to achieve my objective?

Any insights or suggestions from the community would be greatly appreciated.

Thank you.

[thorin]

https://bugzilla.mozilla.org/show_bug.cgi?id=1692609 - this is the relevant bugzilla, look at the individual patches

RFP dropped timing precision protections of 100ms and instead linked everything to rAF (60 Hrtz), and this enabled allowing entries in performance.mark/measure etc - so this is not likely to be your issue

Tor Browser also locks RFP, so your chat-gpt needs whipping. It’s not locked in alpha

[PieroV]

As far as I remember we don’t have a specific patch for that, it might be some pref you can find in browser/app/profile/001-base-profile.js.

I’m not an expert of Selenium, but I’d try to check if it has an API to get what you need, instead of using content APIs.
This might be the easiest solution and also the most precise one.

[jurc3880]

Thank you very much! Your tip about “Tor Browser locking RFP settings but not in the alpha version” was very crucial.

Following your suggestion, I first manually tested the Tor Browser (version 11.5.8) on Windows. After entering the about:config page, I set the value of privacy.resistFingerprinting to false and restarted the browser. Unfortunately, when I visited some websites and ran those JavaScript commands in the console, the results were no different from the abnormal behavior I initially described.

However, the good news is that after installing version 13.5a3 of the Tor Browser in an Ubuntu Docker, running the original script yielded the output results I desired. I also installed Firefox version 115 in the Docker and, with slight modifications to the script, I was able to achieve the expected results as well.

There might be a discrepancy with your description regarding the RFP or other factors affecting the return values of APIs like performance.getEntries(). At least in the environments I tested, this seems to be the case.