[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Button, Localized Mixer Proximity Exits, etc
- To: or-talk@xxxxxxxxxxxxx, wilfredguerin@xxxxxxxxx
- Subject: Button, Localized Mixer Proximity Exits, etc
- From: "Wilfred L. Guerin" <wilfredguerin@xxxxxxxxx>
- Date: Sun, 14 Oct 2007 14:12:40 -0400
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Sun, 14 Oct 2007 14:12:49 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type; bh=lFJdWPLN0A9aw6qYAbt1KB4UtdesW6J/vMMJlNyJtNU=; b=R6dZ6WRAjAxwXPY1SosWt8C2ny/o8JWFTG/rYmB4GKUw0krWrlVD2/unII75B3OxCiMCjqjg3ZGbpzdGrVIaYkAHAKTfxoBnoN1YpDn4bhylRYRB5kTwMAkun7+WH8Df2PJOjEqvr9P01epItSjUB81J18AWoTED8cN+B2/Ig8U=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=TkOeH1aDUZmBVLb9fhFnaxBaXRYFhpmX02d/78TxqGv+j01yQMtgXGk6g80Z55xlgsInSbQN8oHQlibD8WX/GMWRUM2lFOJ6kT6S+/gQ5kQaNiDi8Xbi8MbpUfX0mzUCV8wEA43kyDkXoOavhWRlE3Zl2ATJvwN7P3uLvgSyjc4=
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
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@xxxxxxxxx
and see http://BlueNorway.Org about other topics (like Al Qaeda in Miami, SS Norway)