Re: <nettime> Unlike Us links on social media and their alternatives

[Geoffrey Goodell <goodell@oxonia.net>]

This is a bit of a tangent, but you mention the ability of infrastructure
operators to eavesdrop or interfere with communication.

I know that you are not explicitly saying this below, but to be clear I worry
that culturally, we may have somehow come to think that this situation is
acceptable, perhaps even a just reward to a platform operator for providing
community infrastructure.  I think that reasoning is flawed.  Specifically, I
am concerned that our governments and institutions are actively protecting
rent-seeking platform monopolists as if they were benign inventors who should
be rewarded for creating technologies for general use by persons and
businesses.

But platform operators are not benign inventors.  There is a critical,
functional difference between technology, which in a macroeconomic sense is a
choice available to business, and services, which are provided by specific
firms using whatever technology they happen to be using internally.

There are coherent arguments for protecting innovation that creates
technologies.  Patents are examples of such protection.  Protecting innovation
that creates platform monopolies is not defensible.

On Sun, Jun 16, 2019 at 07:18:09AM -0400, John Young wrote:
> Thought it was a given that communications are never secure against their
> inventors and operators.
> 
> The Internet never inaccessible to to its operators, coders, mechanics, its
> start and end packets never wholly invisible, log files essential for repair
> and admin.
> 
> Tor never intended to be beyond observation by its inventors and promoters.
> 
> Crypto never beyond access of its inventors and advocates.
> 
> End-to-end crypto, any must-use comsec protection, a signal of who to pursue
> by other means.
> 
> What is necessary, though, is promulgation of the the notion that somehow,
> some way, communicaions can be made secure and safe for those who just want
> to have fun. Wayback this faith was hawked as indulgences, evangelized
> lately as mail-lists, social media, free speech, archival tracking, open
> source.
> 
> 
> 
> At 02:34 AM 6/16/2019, you wrote:
> > I agree with all requirements, but I think one needs more refinement:
> > 
> > > in a manner that does not expose information about their conversations
> > to third parties.
> > 
> > I think that this should be further clarified as:
> > 
> > Stage 1: "in a manner that does not expose content of their
> > conversations to third parties" (ie. the conversations are private, but
> > metadata (who talks to whom and when) isn't.
> > 
> > Stage 2: "in a manner that does not expose neither content nor metadata
> > of their conversations to third parties".
> > 
> > Why this matters?
> > 
> > 1.1 Because any onion-like routing will raise red flags in many places.
> > Providing end-to-end privacy alone is a huge step by itself, and easier
> > to accomplish without irritating powers that be too much. Let them know
> > who talks to whom, and construct social graphs. They were able to do
> > that with paper letters as well, since ever. The amount of Tor use by
> > "freedom fighters" is infinitesimal compared by semi-criminal and
> > criminal use (as defined by legal domains.) This is a bar too high to
> > start with.
> > 
> > 1.2 It's asymmetric. Lesser governments (all except one) cannot
> > penetrate onion routing. Major government can, routinely, as it has
> > complete coverage, making correlation attacks trivial (unless we go back
> > to mixmaster with random delays up to many hours.) This would be
> > discriminatory towards lesser governments, and further empowering the
> > major one. Unfair.
> > 
> > 2. Once end-to-end privacy is routinely available, anonymity can be the
> > next step. But these should be two independently moving parts. Plus the
> > solutions for the two are not the same.
> > 
> > 
> > Which leaves open the legitimate question of shielding to prevent
> > censoring. Anonymity is not the only way to achieve this, there is
> > another one, easier to execute without insisting on anonymity: mimicry.
> > 
> > There are numerous channels in existence today that provide
> > point-to-point communication between two people. To name one, telephony,
> > or voice communications in general. Voice communications are real time
> > and involve usually two parties. No one in their right mind would think
> > of disturbing voice communications. In addition, there is wide spread
> > use of videoconferencing (Skype, Viber, Whatsapp) where voice is
> > accompanied by video. All that has to be done is piggyback over these
> > channels in a manner that makes data appear voice-like and/or
> > video-like, but unintelligible to third parties.
> > 
> > [This would not be the first time this strategy is deployed. The early
> > digital modems (30-40 years ago, up to 2400 baud) chirped the way they
> > did not because it was the most efficient way, but for entirely
> > different reason: telecoms were selling digital lines (all phone lines
> > are digital, 56 or 64 kbps) at huge markup (10-100X) over voice lines
> > (although their cost was the same.) The telecoms were not happy at all
> > with attempts to use voice lines for digital communications, so they
> > immediately started installing equipment to detect and block modems on
> > voice lines. The modem makers, on their side, started to modify the
> > carrier signal to make it hard to distinguish it from human voice with
> > technology then available (keep in mind we're talking 70s and 80s.) This
> > made telecoms have false positives, interrupting regular calls, which
> > caused backlash from customers, and modem makers eventually won.]
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On 6/15/19, 04:30, Geoffrey Goodell wrote:
> > > Following an earlier thread --
> > > 
> > > There are some infrastructures that directly address the points raised below.
> > > In particular, technology infrastructures that put control in the hands of
> > > users will generally involve users running free-software code on
> > > free-software
> > > platforms that they control and trust.  This might seem like an
> > > insurmountable
> > > challenge, but it is not; it can be done with sufficent support from
> > > institutions.  Whether this (infrastructure) support takes the form
> > > of project
> > > funding, regulation, educational initiatives, or some combination thereof,
> > > remains to be seen.
> > > 
> > > Addressing the challenges of metadata privacy and traversal of barriers
> > > established either for censorship or for price discrimination is a
> > > bit harder.
> > > However, efforts are underway, in the form of projects to build software and
> > > peer-to-peer overlay networks.  The most accessible examples involve onion
> > > routing.  (I believe strongly in Tor, as I have indicated earlier.  Objectors
> > > should note that there are alternative onion routing architectures
> > > such as I2P.
> > > As long as we are speaking theoretically, feel free to substitute the
> > > onion-routing architecture of your choice.)  My specific responses are below:
> > > 
> > > On Mon, Apr 29, 2019 at 03:14:19PM -0700, Morlock Elloi wrote:
> > > > This is a promising direction. It's impossible to guess/infer at the first
> > > > attempt what the platform should do, but it's almost obvious what it
> > > > shouldn't. What we need is a requirements document, the one not produced by
> > > > techies, as for one reason or another they tend to make bad choices. At this
> > > > point I wouldn't worry what's 'possible' or 'impossible'. Just imagine the
> > > > ideal system and then work back to MVP. It may take some time, so the
> > > > stamina is paramount.
> > > 
> > > > How can this be done? I would postpone this discussion at this point, as it
> > > > leads to multiple dead-ends due to diverse (in)competences of participants.
> > > > Instead, we should reach some kind of consensus how the ideal system should
> > > > behave. The rest is a technical problem.
> > > 
> > > Agreed.  Let's first specifically identify the key problems that
> > > need solving:
> > > 
> > > (1) We require a way for individuals to converse directly with each
> > > other, at a
> > > distance (which is to say electronically), in a manner that does not expose
> > > information about their conversations to third parties.  Three forms of
> > > communication are perhaps most essential:
> > > 
> > > (1a) long-form correspondence (mail).
> > > 
> > > (1b) real-time text messages (both bilateral and group chat).
> > > 
> > > (1c) real-time voice conversations (phone calls).
> > > 
> > > (2) We require a way for individuals to exchange digital content such as
> > > files and calendars, with the same requirements as (1) above.
> > > 
> > > (3) We require a way for individuals to coordinate their activities
> > > (projects,
> > > logistics, meetings, with the same requirements as (1) above.
> > > 
> > > > Nextcloud is promising, but there is an infrastructural anomaly that has to
> > > > be fixed first - direct addressability of every human (smartphone, home
> > > > computer, etc.) without intermediaries, directories, assistants. Without it,
> > > > only users with real IP numbers can freely participate (DynDNS is a
> > > > centralized service prone to corruption). It's explained in the paper I
> > > > peddled earlier ( https://cryptome.org/2019/02/elbar.pdf )
> > > 
> > > For exactly the reasons Morlock offered in a separate thread [1], network
> > > carriers will always have an interest to control the flow of
> > > information across
> > > a network.  Potential interests include censorship and extraction of surplus,
> > > for example via price discrimination or tax.  The problem of direct
> > > addressability of devices is just one manifestation of such control.
> > > 
> > > Strategically, users of a network that wish to avoid such control
> > > will need to
> > > shield knowledge about their use of the network from the
> > > intermediaries, hence
> > > the need for onion routing.  Tor onion services [2] can be used to create
> > > directly accessible services on any device that supports Tor.  So it is
> > > possible to run web servers, or indeed any other TCP-based Internet services,
> > > via a Tor onion service, not only on workstations in homes and
> > > businesses that
> > > have not paid for a static IP address, but indeed on laptops and
> > > smartphones as
> > > well.  Web servers available as Tor onion services can run Nextcloud too.
> > > 
> > > Suggest that because it is folly to assume that we will be able to trust
> > > Internet carriers not to block, monitor, or otherwise interfere with our
> > > traffic, we can expect to use onion routing for this in the first instance.
> > > This is not to say that those of us with static IP addresses should not feel
> > > free to run Nextcloud services directly on the Internet, at least as
> > > long as we
> > > are allowed to do so cheaply, which may come to an end before long.
> > > 
> > > I would like to suggest that using Nextcloud to solve challenges
> > > (1), (2), and
> > > (3) above will require essentially everyone to run a Nextcloud
> > > instance.  This
> > > is certainly possible, but there are no doubt more practical ways to achieve
> > > (1a) and (1b).
> > > 
> > > > Exactly. Let's do the effort and come up with white paper describing what
> > > > the hell we think would work. No one else will do it.
> > > 
> > > The 'Cwtch' Project as a means to achieve (1b):
> > > 
> > > It turns out that there is an interesting article to address (1b) already,
> > > written by Sarah Lewis of the Open Privacy Research Society in
> > > Canada [3].  An
> > > early prototype of Cwtch, based on the Richochet protocol [4],
> > > already exists,
> > > but it is not yet ready for general use.  Cwtch is a worthwhile effort worth
> > > supporting, both with time and with treasure, and I think that it is a fair
> > > response to Morlock's call for a whitepaper.  There are some aspects of the
> > > design that might be debatable, such as the distinction between Cwtch servers
> > > and Cwtch peers, although I think that the authors have made good choices.  I
> > > suspect that some of the software decisions are still crystallising.  (Let's
> > > hope that the software will allow individuals to manage many different
> > > identities at the same time.)
> > > 
> > > For (1a), I would like to suggest that we can do this with existing email
> > > clients and email servers, tweaked slightly to run as Tor onion services.
> > > There are aspects of this that would need elaboration, but I argue that the
> > > task of retrofitting email infrastructure to work this way would be
> > > better than
> > > starting from scratch.  There are too many useful features embedded
> > > in SMTP and
> > > IMAP implementations that we would not want to lose, and wiring them
> > > to work as
> > > Tor onion services should not be too difficult.
> > > 
> > > These are my recommendations for actionable next steps, and I would welcome
> > > views about alternative approaches that would be both at least as
> > > effective and
> > > at least as practical to implment.
> > > 
> > > Best wishes --
> > > 
> > > Geoff
> > > 
> > > [1] M. Elloi, "<nettime> infonuclear options are coming".  Fri, 03 May 2019
> > > 13:22:14 -0700, 5CCCA2F6.1030908@gmail.com.
> > > 
> > > [2] Tor: Onion Service Protocol.
> > > https://www.torproject.org/docs/onion-services.html.en
> > > 
> > > [3] S. Lewis, "Cwtch: Privacy Preserving Infrastructure for Asynchronous,
> > > Decentralized, Multi-Party and Metadata Resistant Applications".  2018-06-28,
> > > https://cwtch.im/
> > > 
> > > [4] J. Brooks, "Ricochet: Anonymous instant messaging for real privacy".
> > > https://ricochet.im/
> > 
> > #  distributed via <nettime>: no commercial use without permission
> > #  <nettime>  is a moderated mailing list for net criticism,
> > #  collaborative text filtering and cultural politics of the nets
> > #  more info: http://mx.kein.org/mailman/listinfo/nettime-l
> > #  archive: http://www.nettime.org contact: nettime@kein.org
> > #  @nettime_bot tweets mail w/ sender unless #ANON is in Subject:
> 
> 
> #  distributed via <nettime>: no commercial use without permission
> #  <nettime>  is a moderated mailing list for net criticism,
> #  collaborative text filtering and cultural politics of the nets
> #  more info: http://mx.kein.org/mailman/listinfo/nettime-l
> #  archive: http://www.nettime.org contact: nettime@kein.org
> #  @nettime_bot tweets mail w/ sender unless #ANON is in Subject:
#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mx.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime@kein.org
#  @nettime_bot tweets mail w/ sender unless #ANON is in Subject: