<unlike-us> Unlike Us links on social media and their alternatives

[Geert Lovink]

> From: Geoffrey Goodell <goodell at oxonia.net>
> Subject: Re: <nettime> Unlike Us links on social media and their alternatives
> Date: 15 June 2019 1:30:50 pm GMT+2
> To: Morlock Elloi <morlockelloi at gmail.com>
> Cc: nettime-l at mail.kein.org
> 
> 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 at 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 at kein.org
> #  @nettime_bot tweets mail w/ sender unless #ANON is in Subject:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listcultures.org/pipermail/unlike-us_listcultures.org/attachments/20190620/9fde5824/attachment.html>