[tor-dev] Tor Friendliness Scanner
gunner at aspirationtech.org
Mon Mar 4 21:42:44 UTC 2019
It may or may not be of any use, but here is a content from an etherpad
that a number of Tor folks worked on a while back regarding 'tor
Sounds like you have a robust way of going about this, so this is
provided as food for thought.
Designing a web site to be "Tor-friendly"
The following represent an initial set of guidelines to help web site
publishers to design and maintain sites that work well with the Tor Browser.
This is an incomplete set, and we welcome contributions, suggestions and
NOTE: Italicized comments are requests for additional input/responses...
Must do (as in "otherwise you undermine the core design goals of Tor and
put user anonymity and privacy at risk")
Avoid using plugins like Adobe Flash, or any proprietary plugins
that can not be audited, in any way, shape, or form
Avoid relying on users downloading and opening files such as pdfs or
Microsoft Word Documents
What else can enable or cause leaking actual IP address info?
What else about site design/implementation could de-anonymize users?
The verb "avoid" here sounds like a MUST. Maybe here we should
instead say "Do not use plugins..." and "Do no rely on users".
Should Do (as in "help to maximize the security and quality of Tor user
Test all site pages and functionality using Tor Browser [maybe add
the security level to test against? the browser security level allows
Working in Tor Browser with the "Low" security level would actually
be a MUST. Working with the "Medium" and "High" could remain a SHOULD.
but you should at least inform the user in a friendly way that
Ack on the previous comment but the site should have basic
it in Tor Browser. We did that on
Serve all content over HTTPS
Use a trustworthy certificate authority such as LetsEncrypt.org
What is the purpose here? One CA is effectively the same as any
other CA, so long as the CA isn't distrusted by Mozilla.
Don't depend on IP address for locale determination (allow users to
set their own language)
Don't depend on or assume IP address will remain constant during
Don't expect a particular number of users per IP address
What else might break with new circuit or new identity based on site
Anything about "please don't fingerprint your users by
network/device addresses or browser attributes" or "don't try to extract
If you actually have a feature (such as user avatar/image editing)
that relies on canvas image extraction, allow a user to trigger the
image extraction multiple times and confirm the resulting extracted
image is what the user intends. This will allow friendly support of the
Canvas Permission Prompt.
Do not rely on high resolution timestamps from any date properties,
such as performance.now() or Date().getMilliseconds()
If you have a feature that relies on automatically detecting the
user's timezone, allow the user to override the automatic selection with
a manually chosen one
Before making use of DOM features (WebSpeech API, gamepad API, etc)
perform feature detection to ensure the methods are present to avoid
Minimize page "weight"/bandwidth needs
Make sure pages work properly with image loading turned off (that's
not a "Should Do" item but "Please Do", if at all)
This is not a supported configuraiton of Tor Browser, so I don't
think it should make the list.
Don't auto-start videos or multimedia content
And do not rely on the media statistic API to scale media
performance. Alternately, detect the spoofed media statistics and ignore
Don't assume low latency or constant latency
Make sure pages work properly without SVG support enabled.
And/or display a note that SVG images are in use and what users are
Make sure pages work properly without being able to load fonts
(Make sure pages work properly when the "Security Slider" is set to
Anything? Technologies to be avoided?
If you use CloudFlare or another provider that treats Tor
differently, enable uninterrupted access for Tor users (link to CF
Verify site works "without" cookies
(need correct/clarifying language to convey that actual session
cookies after login make sense) (you could specify "third-party" cookies
or more broadly "tracking cookies" if you want; right now I'd argue the
third-party cookie item is actually a "Should Do" item as we currently
have third-party cookies disabled; Hm. I wonder if that is not even a
"Must Do" at the moment because if a website really relied on
third-party cookies then it would be broken currently)
Please Do (as in "these things further enrich and protect Tor user
Make your site available via a corresponding .onion address 
Make your site available over IPv6 as well as IPv4 (provide both
addresses in DNS)
Once Tor Browser supports it, using HTTP2 with Push will decrease
the load time of your site.
In general, any tech that decreases load time (image spriting,
minifying JS, etc) will get a magnified improvement in Tor Browser over
On 3/4/19 1:15 PM, Roger Dingledine wrote:
> On Mon, Mar 04, 2019 at 03:58:58PM -0500, Kevin Gallagher wrote:
>> To generate a method of determining ground-truth, we decided to modify* the
>> Firefox (FF) browser to log all of the steps of the creation of the Content
>> Tree (also called the DOM tree)
>> We have moved ahead with development (though have not yet finished it) and
>> are (hopefully) very close to a working prototype. I was wondering if there
>> was feedback on this method
> Neat stuff!
> Looking at the DOM tree reminds me of Micah's paper from a few years back:
> "Validating Web Content with Senser"
> and (2)
> Be sure to check out the recent papers by the Berkeley group on this
> area, e.g. the "do you see what I see" paper and more recent ones:
> tor-dev mailing list
> tor-dev at lists.torproject.org
Executive Director, Aspiration
Aspiration: "Better Tools for a Better World"
Read our Manifesto: https://aspirationtech.org/publications/manifesto
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the tor-dev