Hello all!
After a year away from my Tor related research, I'm finally back at it. As I've introduced in the past [1] I wanted to build a Tor Browser Friendliness scanner that would scan the web and rate the Tor Browser friendliness of web pages. Unfortunately time got away from me for personal reasons, but I finally got the chance to work on the scanner and I feel it's close to being ready to run.
To re-introduce the concept: the scanner checks a web page for evidence of some activity that would likely cause the site to not render or run properly on the Tor Browser. This includes the tests listed below, which are motivated by the Tor Browser Design Document [2] and our own experiences analyzing what broke on the Tor Browser during analysis of some randomly selected websites.
_*Tests*_
1. Checks to see if the site supports HTTPS. If not, there's a problem. 2. Checks to see if the site serves JavaScript over HTTP. If not, there could be a problem on the Safer setting of the Tor Browser Security Slider, 3. Checks to see if there is auto-played media or hidden media. This could cause issues on the Safer setting of the Tor Browser Security Slider. 4. Checks to see if there is any evidence of usage of the following JavaScript libraries/functionalities. These were taken from the draft of the Tor Browser Design Document. 01. asm 02. battery status 03. game pad 04. graphite 05. media devices 06. navigator online 07. sensor 08. network connection 09. touch 10. web audio 11. webgl 12. webrtc 13. web speech 14. HTML canvas 5. Checks to see if the page contains JAR files or Flash files. 6. Checks to see if the page contains chrome:// or resource:// links.
Given this information, I have a few questions.
1. What other tests should I add, if any? 2. Is there any other feedback on this idea that you'd like to provide?
Please keep in mind that I intend on releasing the source code soon. At the moment it's in an "academic code" state, and I want to clean it up before release.
Thanks,
Kevin
References:
[1] https://lists.torproject.org/pipermail/tor-dev/2019-March/013731.html
[2] https://2019.www.torproject.org/projects/torbrowser/design/
On 4/9/21 12:19 PM, Kevun wrote:
Hello all!
After a year away from my Tor related research, I'm finally back at it. As I've introduced in the past [1] I wanted to build a Tor Browser Friendliness scanner that would scan the web and rate the Tor Browser friendliness of web pages. Unfortunately time got away from me for personal reasons, but I finally got the chance to work on the scanner and I feel it's close to being ready to run.
To re-introduce the concept: the scanner checks a web page for evidence of some activity that would likely cause the site to not render or run properly on the Tor Browser. This includes the tests listed below, which are motivated by the Tor Browser Design Document [2] and our own experiences analyzing what broke on the Tor Browser during analysis of some randomly selected websites.
_*Tests*_
- Checks to see if the site supports HTTPS. If not, there's a problem.
- Checks to see if the site serves JavaScript over HTTP. If not, there
could be a problem on the Safer setting of the Tor Browser Security Slider, 3. Checks to see if there is auto-played media or hidden media. This could cause issues on the Safer setting of the Tor Browser Security Slider. 4. Checks to see if there is any evidence of usage of the following JavaScript libraries/functionalities. These were taken from the draft of the Tor Browser Design Document. 01. asm 02. battery status 03. game pad 04. graphite 05. media devices 06. navigator online 07. sensor 08. network connection 09. touch 10. web audio 11. webgl 12. webrtc 13. web speech 14. HTML canvas 5. Checks to see if the page contains JAR files or Flash files. 6. Checks to see if the page contains chrome:// or resource:// links.
Given this information, I have a few questions.
- What other tests should I add, if any?
- Is there any other feedback on this idea that you'd like to provide?
Please keep in mind that I intend on releasing the source code soon. At the moment it's in an "academic code" state, and I want to clean it up before release.
Sounds great!
It would be great to add if they have an onion service or not.
Look at this project for news: https://securethe.news/
Thanks,
Kevin
References:
[1] https://lists.torproject.org/pipermail/tor-dev/2019-March/013731.html
[2] https://2019.www.torproject.org/projects/torbrowser/design/
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Hi Kevin,
This is a great idea!
I have a few optional nitpicks:
1. Rather than check if the website supports HTTPS or if it loads JS over HTTPS, it might be worth considering just checking if it works in HTTPS-only mode (in other words, if there was *any* non-HTTPS content.) This seems more timely with Firefox and other browsers slowing rolling out HTTPS-only modes. 2. I am not sure if auto-play is necessarily a bad thing. IRCC even non-tbb browsers like brave stop auto-play and make certain media click-to-play. 3. It may not be the case that the APIs blocked or fuzzed by Tor Browser are necessarily bad, for instance, people may use the canvas for good (like cropping images or converting formats) so it may be worth emphasizing that in the wording (compared to say the HTTPS test where you could be more forceful). 4. Also, as usual, this list is subject to change, so it might be valuable to have an update mechanism in place from the start.
Thanks again for sharing your idea here. Best, Sanketh
From: tbb-dev tbb-dev-bounces@lists.torproject.org On Behalf Of Kevun Sent: Friday, April 09, 2021 11:19 AM To: tbb-dev@lists.torproject.org; ux@lists.torproject.org Subject: [tbb-dev] Tor Browser Friendliness Scanner: Seeking Feedback
Hello all!
After a year away from my Tor related research, I'm finally back at it. As I've introduced in the past [1] I wanted to build a Tor Browser Friendliness scanner that would scan the web and rate the Tor Browser friendliness of web pages. Unfortunately time got away from me for personal reasons, but I finally got the chance to work on the scanner and I feel it's close to being ready to run.
To re-introduce the concept: the scanner checks a web page for evidence of some activity that would likely cause the site to not render or run properly on the Tor Browser. This includes the tests listed below, which are motivated by the Tor Browser Design Document [2] and our own experiences analyzing what broke on the Tor Browser during analysis of some randomly selected websites.
Tests
1. Checks to see if the site supports HTTPS. If not, there's a problem. 2. Checks to see if the site serves JavaScript over HTTP. If not, there could be a problem on the Safer setting of the Tor Browser Security Slider, 3. Checks to see if there is auto-played media or hidden media. This could cause issues on the Safer setting of the Tor Browser Security Slider. 4. Checks to see if there is any evidence of usage of the following JavaScript libraries/functionalities. These were taken from the draft of the Tor Browser Design Document. 01. asm 02. battery status 03. game pad 04. graphite 05. media devices 06. navigator online 07. sensor 08. network connection 09. touch 10. web audio 11. webgl 12. webrtc 13. web speech 14. HTML canvas 5. Checks to see if the page contains JAR files or Flash files. 6. Checks to see if the page contains chrome:// or resource:// links.
Given this information, I have a few questions.
1. What other tests should I add, if any? 2. Is there any other feedback on this idea that you'd like to provide?
Please keep in mind that I intend on releasing the source code soon. At the moment it's in an "academic code" state, and I want to clean it up before release.
Thanks,
Kevin
References:
[1] https://lists.torproject.org/pipermail/tor-dev/2019-March/013731.html
[2] https://2019.www.torproject.org/projects/torbrowser/design/
On 4/9/21 8:19 AM, Kevun wrote:
- What other tests should I add, if any?
In our experience working with news orgs, a common problem is that some exit nodes trigger some geographically targeted site behavior changes. The most common are GDPR notices, which are often heavy interstitials that don't load properly if JS is disabled.
All of which is to say, it may be worth testing with multiple circuits to see if a site loads differently (though that may also be indicative of other differences, such an exit node being impacted by nation state level censorship).
Warmly,
Erik
-
Erik Moeller -
Gaba -
Kevun -
Sanketh Menda