There are two primary network stream origin node "latency injection" identification attacks, passive and active. Each attack begins with the attacker establishing one or more network streams through a target node to stalk, and attempting to manipulate its io streams. ## Passive latency injection attacks A passive attack involves stalking two nodes to ascertain whether they are the same node, or to ascertain whether one node is in the path of the other or otherwise effects the other. Our garlick/pipe/iqnets net attempts to mitigate such passive attacks with chaff file, packet switching with pre-agreed routes and pre-agreed b/w, and recording and booting nodes which fail to deliver (whilst we must also consider an innocent end user node who is under attack, and how to identify and correct for this). ## Active latency injection attacks An active latency injection attack is performed by having control of a physical node directly in the path of a stalked node - in practice the simplest version of this is the first physical hop for an end user node, which is typically one of their ISP's routers. Attacker simply suspends a stalked node's entire internet connection for a suitable number of milliseconds (say 57ms, or whatever is large enough given typical/ default iqnets config), and if attacker sees a stream somewhere else under the attacker's watch, display's a latency spike of around 57 ms, the attacker has with high probability identified the target they are stalking. If attacker's probability of ID of stalked node is only say 30% (due to network jitter or whatever), simply repeat the latency injection a couple more times, to increase to certainty. Such low magnitude latency injections (only 57ms, or even less), can be readily used over dozens or hundreds of targets, to bisect a large set of stalked nodes, to determine specific nodes of interest. The ONLY (caution, absolutism in operation here!) obvious mitigation to such active stalking (and still only for some cases) is: - create/use dark links, not just govnet links (you need at least one "first hop" link you can trust, which also means hardware you can trust) - "link" as in physical connection, i.e. "immediate/ first/ next hop from me" - maintain govenet (ISP) routes for others, not immediately for yourself - only use govnet for yourself as a fall back, and if you don't care about being actively stalked - monitor all first-hop/friend nodes, including dark links, for signs of latency injection attack/victim in operation ## Other mitigations: - stream splitting, possibly to a high degree ("many micro streams") and separate routes for each micro stream - widely and finely dispersed content addressed content distributiona and retrieval, thus: - eliminating fat streams - eliminating single points of failure - thereby reducing possible identification of that nodes which fail, and nodes that up/download - server-less web "applications" - content addressed DHT based forums, web sites etc - requires effective (incentivized) distributed cacheing models - for rare/old content, "cache of last resort" is an hopefully solvable problem - in the case of clear net content producers, presumably such content producers have an interest in making their content available, except when they don't or when they modify older content, mitigated with - content addressed content (git style ob stores) - distributed cacheing - end users who take an interest in archiveing old content and holding content producers/ reporters to account for what they did in fact say - for phone calls, which require real time / low latency, fixed rate streams, you're going to need dark links, or you are going to be exposed to active latency injection attacks (although, in the middle of a phone call, if the overall network params are right, latency injections should be audibly identifiable at least)