Hi Kevin,
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 friendly sites".
Sounds like you have a robust way of going about this, so this is provided as food for thought.
peace gunner
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 feedback!
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 experience")
Site design
Test all site pages and functionality using Tor Browser [maybe add the security level to test against? the browser security level allows different experiences]
Working in Tor Browser with the "Low" security level would actually be a MUST. Working with the "Medium" and "High" could remain a SHOULD.
https://tb-manual.torproject.org/en-US/security-slider.html
Verify site works without javascript enabled
I don't think you *have* to make your site work without JavaScript, but you should at least inform the user in a friendly way that JavaScript is required and the site will not work properly without it.
Ack on the previous comment but the site should have basic functionalities available with no JavaScript. Plus explain how to enable it in Tor Browser. We did that on https://tails.boum.org/install/download/ with https://tails.boum.org/install/inc/screenshots/allow_js.png.
The same as above, except for SVG and WebRTC instead of JavaScript
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 user sessions
Don't expect a particular number of users per IP address
What else might break with new circuit or new identity based on site design assumptions?
Anything about "please don't fingerprint your users by network/device addresses or browser attributes" or "don't try to extract canvas details"?
Page design
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 possible JavaScript errors
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 them.
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 missing
Make sure pages work properly without being able to load fonts located remotely.
(Make sure pages work properly when the "Security Slider" is set to "High")
Server-side configuration
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 instructions)
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 experiences")
Make your site available via a corresponding .onion address [1]
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 other browsers.
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!
(1) Looking at the DOM tree reminds me of Micah's paper from a few years back: "Validating Web Content with Senser" https://security.cs.georgetown.edu/~msherr/pubs.php
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: https://www1.icsi.berkeley.edu/~sadia/
--Roger
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev