Reviving The Discussion: Crowdsourcing some guidelines for what it means to make a web site "Tor-friendly"
Hello everyone,
Recently in a Tor UX meeting I brought up the idea of creating a Tor-Friendliness scanner, or a program that evaluates and ranks the "Tor-friendliness" of a web site and provides recommendations to improve. This idea seemed pretty well received by those attending the meeting, so I'd like to get stated on creating this. However, in order to do this I would need to precisely define "Tor-friendliness."
That's when this discussion (https://lists.torproject.org/pipermail/tor-project/2018-January/001606.html) was brought to my attention. It seems conversation about this has died down. I would like to revive this conversation and work towards creating an understanding of the definition of being "Tor-friendly."
Currently I am reading the Tor Browser Design Document to understand the Tor Browser more fully, and to understand how it works to thwart tracking and fingerprinting, etc. If there are other approaches I should consider to help me understand what "Tor-friendliness" is, please let me know! Otherwise, I would love to hear about what people think constitutes "Tor-friendliness" so I can build a tool that tests for these things.
Thanks,
Kevin Gallagher
Hi Kevin,
Thanks so much for reviving this thread and thinking.
Don't know if you got my reply from earlier this week, but I repopulated the etherpad from January,
https://pad.riseup.net/p/torfriendlysite
Some formatting was lost from my flat text backup, and as a result some reformatting is definitely needed (e.g. annotations are not currently differentiated from things being commented on)
I'm happy to connect and see if how what we were trying to then (more of a "before you build/before you go live" checklist) melds with your scanner vision, which I think is a *great idea.
thanks & peace, gunner
On 05/15/2018 02:10 PM, Kevin Gallagher wrote:
Hello everyone,
Recently in a Tor UX meeting I brought up the idea of creating a Tor-Friendliness scanner, or a program that evaluates and ranks the "Tor-friendliness" of a web site and provides recommendations to improve. This idea seemed pretty well received by those attending the meeting, so I'd like to get stated on creating this. However, in order to do this I would need to precisely define "Tor-friendliness."
That's when this discussion (https://lists.torproject.org/pipermail/tor-project/2018-January/001606.html) was brought to my attention. It seems conversation about this has died down. I would like to revive this conversation and work towards creating an understanding of the definition of being "Tor-friendly."
Currently I am reading the Tor Browser Design Document to understand the Tor Browser more fully, and to understand how it works to thwart tracking and fingerprinting, etc. If there are other approaches I should consider to help me understand what "Tor-friendliness" is, please let me know! Otherwise, I would love to hear about what people think constitutes "Tor-friendliness" so I can build a tool that tests for these things.
Thanks,
Kevin Gallagher
Hey Gunner,
I got the reply. Sorry, I thought I responded. This is going to be a great start for me!
Thanks,
Kevin
On 05/15/2018 07:59 PM, Allen Gunn wrote:
Hi Kevin,
Thanks so much for reviving this thread and thinking.
Don't know if you got my reply from earlier this week, but I repopulated the etherpad from January,
https://pad.riseup.net/p/torfriendlysite
Some formatting was lost from my flat text backup, and as a result some reformatting is definitely needed (e.g. annotations are not currently differentiated from things being commented on)
I'm happy to connect and see if how what we were trying to then (more of a "before you build/before you go live" checklist) melds with your scanner vision, which I think is a *great idea.
thanks & peace, gunner
On 05/15/2018 02:10 PM, Kevin Gallagher wrote:
Hello everyone,
Recently in a Tor UX meeting I brought up the idea of creating a Tor-Friendliness scanner, or a program that evaluates and ranks the "Tor-friendliness" of a web site and provides recommendations to improve. This idea seemed pretty well received by those attending the meeting, so I'd like to get stated on creating this. However, in order to do this I would need to precisely define "Tor-friendliness."
That's when this discussion (https://lists.torproject.org/pipermail/tor-project/2018-January/001606.html) was brought to my attention. It seems conversation about this has died down. I would like to revive this conversation and work towards creating an understanding of the definition of being "Tor-friendly."
Currently I am reading the Tor Browser Design Document to understand the Tor Browser more fully, and to understand how it works to thwart tracking and fingerprinting, etc. If there are other approaches I should consider to help me understand what "Tor-friendliness" is, please let me know! Otherwise, I would love to hear about what people think constitutes "Tor-friendliness" so I can build a tool that tests for these things.
Thanks,
Kevin Gallagher
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi all,
On 05/16/2018 05:18 PM, Kevin Gallagher wrote:
Hey Gunner,
I got the reply. Sorry, I thought I responded. This is going to be a great start for me!
Thanks Kevin and Gunner for going through this idea. I have been thinking about this lately and I have decided to share a few points.
On 05/15/2018 07:59 PM, Allen Gunn wrote:
Hi Kevin,
Thanks so much for reviving this thread and thinking.
Don't know if you got my reply from earlier this week, but I repopulated the etherpad from January,
When we started doing the Tor styleguide we thought a lot about how to design things in a way that could be Tor and privacy friendly over all. For example we tried to limit JavaScript and always test the no-JS version in order to guarantee an almost seamless experience between the two. But this is not the only thing that makes a website Privacy friendly, and noticing you have a few open questions in the pad, I will try to add a few more ideas.
Things that are bound to break the design are certainly the following: - Importing styles (CSS) and fonts from third parties (like google fonts and other cdn) - Embedding content from third parties (like media and videos, but also page previews) - Maybe content can be processed server-side first or linked statically. - PDFs (/me thinks) could be generally considered ok if can be opened within the Tor browser reader - Do not ask to share location - Canvas is ok if implemented properly (I have seen your points on the pad), but personally I would avoiding it. My take is that anything that should ask for consent is generally a bad practice.
I have seen you mention that vector images do not render (SVG), so the appropriate media queries and image qualities should be used instead - maybe this is actually something we could implement in our styleguide and could benefit other people directly.
Another thing that could be considered is that we (tor, tails, a few other orgs) do not log IPs nor User Agent infos. There have been a few projects started regarding privacy friendly logs. This could be something worth exploring again. Also some don't even understand the rationale behind this. A related project could be about privacy-friendly web analytics. Some install and use Matomo (https://matomo.org/) but it is worth mentioning that if you log anything you will end up with a lot of user data.
One more interesting point is that, because of the GDPR, some website have been offering a text only version and some people have been doing performance measurements of these lean pages. The results are amazing, some news site have been reduced from approx 5MB to 500KB or less. A follow up to this - a bit of a stretch maybe - could be trying to involve an audience that wouldn't even consider all these points when developing a website, by evaluating common JS libraries and framework to see how they perform.
I think this effort could also be a practical way for people to understand how Tor can protect them on the web. An example is this article about link shims and privacy badger (https://www.eff.org/deeplinks/2018/05/privacy-badger-rolls-out-new-ways-figh...). This is already blocked by Tor browser in high security mode.
Talk soon, -hiro
Hi,
On 29/05/18 22:29, silvia [hiro] wrote:
I have seen you mention that vector images do not render (SVG), so the appropriate media queries and image qualities should be used instead - maybe this is actually something we could implement in our styleguide and could benefit other people directly.
The "tor-icons" set contains PNGs for exactly this reason, and PNGs are used not webfonts in Relay Search. It would be great if someone could do the CSS that allowed us to use these PNGs as if they were webfonts when writing HTML (i.e. just adding the CSS classes).
Ideally you could choose one or the other CSS file and then it would give you either PNGs or the webfonts but not require any other changes.
Thanks, Iain.
Hello,
I opened an issue ( https://github.com/Fyrd/caniuse/issues/4287 ) on the caniuse ( https://caniuse.com ) source repository, asking if it would be possible to include the Tor Browser into the list of supported browsers.
I think that it would be a nice way to document what is working and what isn't, on the TB.
tor-project@lists.torproject.org
-
Allen Gunn -
Iain Learmonth -
jvoisin -
Kevin Gallagher -
silvia [hiro]