Awesome! Thank you for this clarity.
I had not grokked the below. On Mon, Oct 28, 2019 at 01:33:29AM -0400, grarpamp wrote: > > GPA was monitoring the upload, thus why GPA attacked X (and others in > > their target set), and due to the [temp|full] link dropout (latency > > trough), GPA IDs node X as the uploader. > > But, same problem even if link not dropped, and just a latency trough > > - target X, is now IDed by GPA. > > In both cases a) X's uplink dropped, or b) not dropped, > > there destination of X's upload, sees the [temp|permanent] dropout. > > No. First principles... under a proper enforced and regulated background > of fill traffic network, there is no such observables for GPA to monitor, > so nothing to attack (which a GPA doesn't do), no ID to be made. > > Now if a GAA is an agent running the central server receiving the > upload, and they're fast enough to recognize the content on > their filesystem as such before it completes, they can try to > DoS back their own overlay hops toward the uploader in realtime. > > At first that would seem hard to defend against. > > Then you realize that again, a proper fill contract aware network > will auto detect and depeer any link that gets DoS, thus the > upload stops well before it can ever be tracked back. > And GAA has to literally sweep through the entire overlay spiking > at tens of thousands to millions of nodes (because every node is > a relay, linear search odds) trying to find the point source that causes > the server upload to stall. And if the user has selected a higher hopcount > for their side, odds are that much higher that GAA will spike one of > those first again depeering the path and ending the upload before discovery. > > The upload might continue a bit slower in a multipath > or scatter mixnet, or if either the depeered node renegotiates > back in, or the source repaths another circuit around. > Whichever way the GAA has discovered nothing and is back > to step one at that point... the depeering problem. > > Nodes might publish a number of depeering tolerance parameters, > or network metrics seen of peers, such that clients could use them > when constructing paths on continuum from more reliable to more > secure as desired. The particulars of what observables drive > depeering thresholds should be, and whether an overlay can perform > whatever self management tasks well... all need tested out. > > > Regardless, sensitive users should not upload to > any plausibly owned / suspect / scene central servers, > and instead should insert into any distributed encrypted > file storage overlays, IPFS, generic surface websites or > hosts, upload encrypted blobs and release the keys > elsewhere, use wifi, vpn, etc. > > Any candidate network for any nextgen award in > the subject line should raise the bar significantly > such that only the highest sensitive and smallest > number of users would have reason to argue. > > That is simply not the case with today's networks. > > > > incentivize > > Incentive is that secure network platforms provide generic > transport for cool apps and services that people want to use. > Most users are not going to hack their nodes to disable giveback, > and or the network will detect that, or have natural consumption limits. > Again ventures into generic transport network built for mass utility > vs network built for some specific app or class of app... the > former has probably not yet received its fair share of development > consideration over the last decades. > > As before, have fun creating and deploying new stuff.
