Button, Localized Mixer Proximity Exits, etc

[Wilfred L. Guerin]

There are a number of concerns over flow management that are easily
accomodated with the existing protocols and configuration capabilities,
specificly localized mixing and exit nodes for targets such as google and
other single entry point targets, and some significant issues with the very
effective TorButton:

First, the Button should have configurability for both targets as well as
sources... Too many times the idiot firefox extensions and plugins have
attempted to connect out via the tor proxy (which is a waste of system
capability) along with other automatia like the alexa and google browser
sync which are quite useful if you want the CIA and jews to know exactly
what you are doing with said machine all the time, but obviously maintaining
the links for something like gmail (high load +js) should not attempt to
portal through TOR unless you want it to (the proxy reconfig is automatic).
Auto disabling all other comms except the actual target would be favourable,
then later selecting which route to use. Proximity mixers and routing should
be handled as well to make this effective. Most humans understand routing
graphs like visio and UML flow charts now.....

There is a statistical problem when dealing with high volume flow to single
target points, especially something like the ballancers of CIA's Google, or
Yahoo's aka, for example... Even disregarding the latency and distinction
between any exit point and the target, the issues (tracking) of transport
latency become highly problematic when dealing with session based targets.
The word-confirm systems are known to have a centralized tracking and
auditing capability, commonly used by criminal gang informants to
communicate through the "help desk" facilities, but this type of tracking,
along with session tracking, makes the need for greater ambiguity in
proximity to the target system.

It would be most effective to make use of localized clusters when
communicating to server farms, especially ones with significant traffic and
high demand. There are counter problems that could be addressed when the
flow does not pass through intermediate nodes as much for primary traffic,
but the reduction of load on smaller pipes could be beneficial.

The most obvious method of implementation is a favourability weighting and
exit GROUP routing for target ranges, serverfarm nodes at serverfarm,
heavily peered targets via peering points, etc. This would be a 4th hop exit
routing value and would double for internal mixing for sites with large
infrastructure and multiple AS routes.

The internal side would allow clusters to be more effectively managed at the
boundaries of universities (internal client) and around the perimiter of
server farms (localized) as the target, while still using diverse mixing
through the other nodes.

When specifying a local cluster as a fast mixer and a distant cluster around
the target for additional loading, an enhanced routing method would still
make use of 3+ in route and have significantly higher probability of leaving
any single political jurisdiction. (must-exit-usa-cluster at all perimeters,
etc)

The difference in performance is great, the additional avilability of
intermediate nodes, and the reduction in wasted flow for idiot content off
the dominant targets would make convolusion far more effective between
mixers.

Of course, internally routed networks have obvious mix potential, and cable
is faster to cable locally (dsl, isp, etc)... Any meta cluster should
attempt to mix within itself and make good use of its potential exit points
to intermediate nodes prior to entering a target cluster for exit. (nodes
with multiple upstream providers should be encouraged, wireless, etc)


This is mostly possible with the existing systems, however self-peering is
needed for the internal mixer and fairly complex variables for the exit and
mixing requirements...

I hope someone can produce a tutorial for this purpose, or hack up a privoxy
style binary that would easily automate the process with graphicals.

The more clients there are, the more functional the system is. Machines work
only when humans comprehend with minimal mousing.

-Wilfred
WilfredGuerin at Gmail.com

and see http://BlueNorway.Org about other topics (like Al Qaeda in Miami, SS
Norway)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20071014/334b066d/attachment.htm>