[tor-dev] Tor Friendliness Scanner

Mon Mar 4 21:42:44 UTC 2019

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-- 

Allen Gunn
Executive Director, Aspiration
www.aspirationtech.org

Aspiration: "Better Tools for a Better World"

Read our Manifesto: https://aspirationtech.org/publications/manifesto

Twitter:  www.twitter.com/aspirationtech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190304/b2a04e0f/attachment.sig>