Thanks for the link to TBB's design document-- very useful. I haven't read it all, but I'm looking at section 2.2, "Privacy Requirements":
1) "Cross-Origin Identifier Unlinkability"-- so do sites with CORS or Content-Security-Policy: not work through Tor? CGIProxy supports CSP but not CORS yet; I could add a flag to disable those two technologies. 2) "Cross-Origin Fingerprinting Unlinkability"-- this led me to read section 3, "Adversary Model" and section 3.3, "Adversary Capabilities - Attacks", and to review section 4, "Implementation". CGIProxy handles some but not all issues, but I believe it could be extended to cover the rest (it can trap access to any JS or DOM property or method, for example). 3) "Long-Term Unlinkability"-- yeah, this has to be handled at the browser end; fortunately, most browsers offer "private browsing" options, though I imagine those would be disabled in a typical Internet cafe in China. --------- By "install" Tor, I mean even copying a file. This is relevant when e.g. it's easier to transmit a URL than a piece of software to the user (via radio/TV, via email when attachments are blocked, etc.). Also, some users may be wary of running Tor or another tool locally, if e.g. there's monitoring software running (though this could arguably detect browser accesses to sites with CGIProxy too). Finally, even the minor trouble of putting something on a USB stick might discourage some users. Consider that many (most?) in China don't care about being censored. So I still maintain that using CGIProxy is easier than installing and using anything that requires software on the client side. I'm also curious how Tor software gets into the hands of users in the first place. Hand-to-hand is best of course, but it seems like many users would need something like CGIProxy or another circumvention tool to initially obtain the Tor software. Absolutely, a user of CGIProxy has to trust the proxy operator! But the same is true with Tor exit nodes too (except for SSL traffic), and there the user has no chance to know the exit node operator. Note that I'm not trying to pit CGIProxy against Tor. I think they're very different tools, and each is better in certain situations. I see this as a useful case of them working together, though, if any risks are ironed out. Thanks again, James On Wed, Dec 4, 2013 at 1:05 PM, Moritz Bartl <[email protected]> wrote: > On 04.12.2013 18:57, James Marshall wrote: > > Is there any risk with another local application using Tor's SOCKS 5 > > interface? I heard a vague comment that it wasn't recommended, but I > > haven't heard exactly what the risks are, if any. > > Using a regular browser opens you to a lot of deanonymization attacks > that Tor Browser does not. Read > https://www.torproject.org/projects/torbrowser/design/ for more details. > > > This is for CGIProxy, which can use SOCKS 5 to provide a clientless > > front-end to the Tor network (clientless in the sense that it doesn't > > require an installation on the browsing machine). This could > significantly > > increase the potential user base of Tor, since many users can't or don't > > want to install anything on their browsing machine. > > You don't have to "install" Tor Browser, just extract to any directory > you have write permission for. This can be a USB stick, or the home > directory, or, if you can boot from a separate disk, Tails. So, everyone > "can" install Tor Browser. > > With CGIProxy, you have to trust the operator of the cgi proxy, because > it sees all traffic. > > -- > Moritz Bartl > https://www.torservers.net/ > -- > tor-talk mailing list - [email protected] > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
