18 Oct
2019
18 Oct
'19
8:06 p.m.
Isn't that why networks like i2p exist? On Fri, Oct 18, 2019, 8:19 PM jim bell <jdb10987@yahoo.com> wrote: > On Friday, October 18, 2019, 09:56:12 AM PDT, Greg Newby < > gbnewby@pglaf.org> wrote: > > > On Fri, Oct 18, 2019 at 02:54:37AM +0000, jim bell wrote: > > > > > > > On Thursday, October 17, 2019, 05:43:04 PM PDT, Punk <punks@tfwno.gf> > wrote: > > > > On Thu, 17 Oct 2019 20:16:28 +0000 (UTC) > > jim bell <jdb10987@yahoo.com> wrote: > > > > >> The way I see it, there are at least two ways to promote TOR. > > >> 1. Openly promote TOR: "TOR is great". "TOR is secure enough". > "We don't need an improvement to TOR". > > >> and the second is: > > >> 2. Oppose potential improvements or augmented systems other than > TOR. List their potential problems. Ignore their possible benefits. > > >> I think there are clearly people who are choosing to do the second > kind of promotion of TOR. > > > > > > > I think a key aspect of the tor mafia is that getting a few million > dollars from the pentagon each year allows them to outcompete anybody who > could challenge them. They don't even have to 'oppose' anything. Just fail > to fund it. > > That sounds quite correct. Somebody needs to challenge them. > > > >It seems that TOR could be as a starting point, if it were possible to > validate the software before building upon it. I'm not sure it is, though. > > >Jim's proposal would seem to require a few important things: > 1. free software (of course) that is open to inspection > 2. verifiable functionality > 3. trustable deployment > > >#1 implies the full stack, from network, to hardware, to OS, to > libraries, to application. This is harder as you dig more deeply into what > needs to be validated. > > >#2 and #3 are also hard, whether using TOR or something completely new. > > >Are #2 and #3 easier if we start with the TOR base software or design? > With 600K+ lines of code, TOR is unwieldy to validate. The design could be > a starting point. > > >I'll make some obvious statements that I haven't seen in this thread yet > (apologies if I missed them): > > >Verifiable functionality means that the software, wherever it's deployed, > can be trusted (to whatever extent is needed). This is challenging for any > software, and more challenging when you need to worry about the entire > stack including the hardware. > > >Trustable deployment means that we can validate the nodes in the mesh, to > whatever extent is needed. This is a perpetual issue with TOR, because > players can do things antithetical to the design (such as collusion or > surveillance). > > > > I think it's important to put up and run SOMETHING, a network separate > from TOR, even if it must initially use pre-existing software that hasn't > been completely verified. (yet) There's an enormous difference between a > mere promise (it's coming "real soon now", as Jerry Pournelle used to say) > and an actual useable system. > > A currently-useable system would ignite far more interest, including > donations perhaps, than a mere promise, especially if the software was all > open-sourced and potentially verifiable, with the knowledge that it would > be verified or replaced in the future. > > Jim Bell > > > Interesting historical interest: > > In about 1979 when I was studying at MIT, I was logged onto a > computer system. (It might have been either network node "70" or "134". > Strange that I remember that!) I did a WHOIS command, listing the other > users of the system. Some other student, looking over my shoulder, said, > "Hey, that's Jerry Pournelle!", because one of those logged in was > "pourne". I, never having been a science fiction buff, didn't know who > "Jerry Pournelle" was. So, the fellow student explained it to me. > > Cut to about 1983, when my small company, SemiDisk Systems, was at the > West Coast Computer Faire in San Francisco, manning the booth. A man came > up to the booth, and he said "I'm Jerry Pournelle". I responded, "Hey, I > know who you are, but it's not the way you might think!". > > >