Anonymity Networks and Developer Determination

Zenaan Harkness zen at freedbms.net
Sat Sep 5 15:12:40 PDT 2020


On Sat, Sep 05, 2020 at 01:07:08PM -0400, Karl wrote:
> This email is shared from a place of forthrightness (and hope).
> 
> https://github.com/ipfs/notes/issues/37
> 
> Just to add, I suspect the reason that the state of public anonymity tools
> is not stronger is that the existing international powerholders, whose
> power could be reduced by widespread accessible anonymity, take diverse
> action to slow the release and hinder the effective use of the research.
> 
> The way to make things change would be for people like us to agree to work
> together on forging one right thing in a development community, and use
> tools of both interpersonal mediation and software development to bring the
> result to happen by force of collective determination. It might help if


As Marxos correctly points out, the important ground is usually broken by a single individual - who must have sufficient time and resources, as well as ability.

Once the cathedral has served its purpose, the bazaar can take over.

In both Linus' hits, he created first alone, by himself, in his "personal cathedral" we can say (Linux and Git).

As you know a collection of the basic ideas has been made.

I am presently writing submissions in reply for a case in which the right to be heard (in a court case) is being demanded (by the team I am on, against the state), and it looks particularly challenging (read, low probability of success) due to the entrenched statute law which is quite explicit in this case.  Nonetheless, in this case, the question must be asked (something like "when there is both a law and a regulation, each allowing the self represented person to appeal on an issue of "was due process afforded", and he chooses the law but did not know the regulation, but the law denies an appeal whereas the regulation allows it, should that self represented person be denied his right to rehearing just because he did not know the regulation, but the law section he chose by default says 'if you use this section, you don't get a rehearing'?").


> everyone kept themselves more anonymous, collaborated in private as well as
> in public, and supported people who ran into personal issues so as to
> resist disruption and keep the work moving forward.


These are good points, it's just that they assume that "a free for all communicty project" works - and in some cases (simpler things) it can work, and in other cases (maintenance of something already created) it can also work, but in certain cases (somewhat complex from a design perspective), the bazaar tends to not work so well, or not work at all - Marxos is correct about this.

Also, "more privacy during development" is probably not particularly relevant in this instance, except that whoever finds the space to do the initial 'heavy lifting' might find "being less public" to be less distracting to his work than the alternative.



> On Fri, Sep 4, 2020, 5:49 PM David Stainton <notifications at github.com>
> wrote:
> 
> > It's too late for this discussion. IPFS has failed to embrace the concept
> > of free Tor integration from volunteer developers.
> >
> > That having been said, anonymity is a synonym for traffic analysis
> > resistance; that is to say, even encrypted traffic can be analyzed for the
> > metadata it leaks. Tor is the very weakest of the existing designs for
> > anonymous communication networks however it is the most widely used whereas
> > the other designs from academia have not had much field testing; such as:
> > mix networks, dcnets, verified shuffles and other things can be used to
> > form anonymous communication networks such as private information
> > retrieval, oblivious ram, multi party computation etc.
> >
> > Tor is trivially broken by any sufficient global adversary by means of
> > timing correlation whereas mixnets are not. There are many other ways to
> > break Tor.
> >
> > Anonymity aka traffic analysis resistance is not yet a popular security
> > feature because these designs are in some respects ahead of their time...
> > just like not every software project embraces deterministic builds. Just
> > because your white middle class platitude doesn't allow you to understand
> > why people in high risk situations might need these things doesn't mean
> > they are not needed. In fact, in dealing with such folks I find the easiest
> > way to impart the importance to them is to describe military scenarios,
> > e.g. if you were in the military, overseas, you might actually be
> > interested in traffic analysis resistance.
> >
> > Think about a future brighter than Tor! Think about mixnets, hybrid
> > networks, dcnets and so on. Monoculture is death. Why is Tor the only
> > successful anonymity network? And to a lesser degree I2p? Although the I2p
> > observation is less valid because it's design is so similar to Tor in that
> > it can easily be broken by timing correlation from a sufficiently global
> > adversary.
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <https://github.com/ipfs/notes/issues/37#issuecomment-687407153>, or
> > unsubscribe
> > <https://github.com/notifications/unsubscribe-auth/AACEIIKJAJVQXDV267SEBU3SEFOGDANCNFSM4BOOQVOA>
> > .
> >


More information about the cypherpunks mailing list