Re: [tor-talk] How to make 100.000 bridge?

["Fabio Pietrosanti (naif)" <lists@xxxxxxxxxxxxxxx>]

On 1/14/12 2:51 AM, Andrew Lewman wrote:
> If you replace the word "stateless bridge" with "proxy server", then
> tor already supports that model. Bridges can also be proxy servers, as
> the goal is to get the tor client to connect to the tor network.
> Whether the tor client uses a tor bridge, or a proxy server, is mostly
> irrelevant from a connectivity standpoint. From an anonymity and
> security standpoint, what pros and cons exist for tor via proxy server
> is an open question.
> 
> See
> https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses
> and
> https://lists.torproject.org/pipermail/tor-dev/2011-December/003135.html
> about flashproxy plugin for blogs, websites, etc.
>

Very nice approaches!

I see the concept of 'proxy server' in point "Five".

However both solutions seems to me not being able to scale in numbers:
- Proxy server
- Flash plugin

Especially for the following reasons:
- For Flash plugin
  - the distribution of facilitators represent the same bottleneck issue
of bridge address in terms of numbers.
  - End-user workstation are typically behind NAT so not directly

- For Proxy server there are the same problem of Tor, as a volounteer:
  - Volounteer need an internet-exposed server
  - Volounteer need to run software in background
  - Volounteer need to eventually have system administration skills

I've been just thinking that as requirement/goals for proxy server we
would like to achieve:
 - a huge amount of IP address acting as entry point
 - a huge amount of hostname acting as entry point
 - an extremely easy way for installation of an entry point
 - an extremely low requirement for installation of entry point (no
background process running)
 - no issue in internet-exposing entry point (no NAT in the middle, like
for most home user's browsers)

All those requirements doesn't seem being satisfied by:
- a 'generic proxy server software' (being it socks or http)
- the flash plug-in approach (that provide the bottleneck of number of
facilitators)
but they seems satisfied by single web application approach.

-naif
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk