On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote:
>
>> On 24 Jan 2016, at 09:28, s7r <
s7r@sky-ip.org>> <
mailto:s7r@sky-ip.org>> wrote:
>>
>>> * This will break some Tor2Web installations, which
>>> deliberately choose rendezvous points on the same server or
>>> network for latency reasons. (Forcing Tor2Web installations to
>>> choose multiple RPs may be a worthwhile security tradeoff.)
>>>
>> Yes, but there is a HiddenServiceRendFilter 0 in the proposal for
>> this purpose and for RSOS services as well.
>
...
>
> HiddenServiceRendFilter 0 only modifies the behaviour of one
> hidden service with Tor2Web. But because Tor2Web is a client which
> is configured to use the same rendezvous point(s) for every hidden
> service connection, it will get banned if it connects to the same
> hidden service too many times.
>
Negative.
A Tor2Web instance runs as a normal Tor client and are configured as
reverse proxies.
This means that Tor2Web runs as _normal_ and _genuine_ client, and
picks rendezvous points randomly as per Tor's path selection. They do
not request a hidden service server to connect 100 times to a middle
relay (rendezvous point) with consensus weight of 0.01%, which is what
we are trying to mitigate. So a super popular Tor2Web service might
initiate 10000 rendezvous circuits in few hours, but they will all be
at multiple rendezvous points, according to their weight and middle
fraction probability, which is OK in our model and will not be affected.