[tor-bugs] #12801 [Flashproxy]: documentation and guidelines for hosting flashproxy js

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Aug 5 22:50:08 UTC 2014


#12801: documentation and guidelines for hosting flashproxy js
------------------------+---------------------
 Reporter:  infinity0   |          Owner:  dcf
     Type:  defect      |         Status:  new
 Priority:  normal      |      Milestone:
Component:  Flashproxy  |        Version:
 Keywords:              |  Actual Points:
Parent ID:              |         Points:
------------------------+---------------------
 If we want more people to host flashproxy.js on their website, we should
 give clearer guidelines about informing their visitors what the
 consequences are. Here are some issues brought up by a reviewer:

 {{{
 <ansgar> <iframe src="//[http://crypto.stanford.edu/flashproxy/embed.html
 crypto.stanford.edu/flashproxy/embed.html]" width="80" height="15"
 frameborder="0" scrolling="no"></iframe>
 <ansgar> That's what upstream suggests to do. That will *not* be very
 informative.
 <ansgar> A 80x15 icon "Internet Freedom". Totally informative that users
 will not provide a proxy to the Tor network.
 [..]
 <infinity0> ansgar: is your problem that it doesn't specifically tell
 (people that host the javascript) to make it obvious to their visitors
 that they're running the javascript?
 <ansgar> infinity0: Yes. Also I believe such things should default to
 "No".
 <infinity0> ansgar: how do you define "such things"?
 <ansgar> infinity0: Things unrelated to the web service one is interested
 in.
 <ansgar> And things that allow third parties to track users (if you don't
 host the server-side part as well).
 <infinity0> ok i see. so on a web page about books, it would be surprising
 for users to default-on to flashproxy
 <infinity0> i think it's reasonable for the main flashproxy web page can
 be default=on though
 <infinity0> but i'll raise your point with upstream
 <ansgar> Well, even there I might just want to read what it does, not
 actually take part.
 }}}

 A few things we could do:

 a. tweak the badge so it's more obvious the user is being used as a proxy

 b. in the README (and maybe options.html) advise websites that embed the
 badge, to make it obvious what they are doing. perhaps also advise non-
 internet-freedom-related websites to default=no, or set this ourselves.

 c. explain the consequences of running a proxy in options.html (since the
 badge links to options.html).

 Potential user issues might include:

 - whether the facilitator can see which website the proxy last visited (I
 don't believe this is the case, but we should explicitly state this, given
 ansgar's confusion above.)
 - whether they are legally liable for users' traffic going through their
 browser (I believe not, since everything is encrypted by others' keys)

 I'm sure more extensive literature about this is already available, we
 just need to make it more obvious and accessible.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12801>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list