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

[Geoffrey Goodell <goodell@oxonia.net>]

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: