<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Geoffrey Goodell <<a href="mailto:goodell@oxonia.net" class="">goodell@oxonia.net</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: <nettime> Unlike Us links on social media and their alternatives</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">15 June 2019 1:30:50 pm GMT+2<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Morlock Elloi <<a href="mailto:morlockelloi@gmail.com" class="">morlockelloi@gmail.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><a href="mailto:nettime-l@mail.kein.org" class="">nettime-l@mail.kein.org</a><br class=""></span></div><br class=""><div class="">Following an earlier thread --<br class=""><br class="">There are some infrastructures that directly address the points raised below.<br class="">In particular, technology infrastructures that put control in the hands of<br class="">users will generally involve users running free-software code on free-software<br class="">platforms that they control and trust. This might seem like an insurmountable<br class="">challenge, but it is not; it can be done with sufficent support from<br class="">institutions. Whether this (infrastructure) support takes the form of project<br class="">funding, regulation, educational initiatives, or some combination thereof,<br class="">remains to be seen.<br class=""><br class="">Addressing the challenges of metadata privacy and traversal of barriers<br class="">established either for censorship or for price discrimination is a bit harder.<br class="">However, efforts are underway, in the form of projects to build software and<br class="">peer-to-peer overlay networks. The most accessible examples involve onion<br class="">routing. (I believe strongly in Tor, as I have indicated earlier. Objectors<br class="">should note that there are alternative onion routing architectures such as I2P.<br class="">As long as we are speaking theoretically, feel free to substitute the<br class="">onion-routing architecture of your choice.) My specific responses are below:<br class=""><br class="">On Mon, Apr 29, 2019 at 03:14:19PM -0700, Morlock Elloi wrote:<br class=""><blockquote type="cite" class="">This is a promising direction. It's impossible to guess/infer at the first<br class="">attempt what the platform should do, but it's almost obvious what it<br class="">shouldn't. What we need is a requirements document, the one not produced by<br class="">techies, as for one reason or another they tend to make bad choices. At this<br class="">point I wouldn't worry what's 'possible' or 'impossible'. Just imagine the<br class="">ideal system and then work back to MVP. It may take some time, so the<br class="">stamina is paramount.<br class=""></blockquote><br class=""><blockquote type="cite" class="">How can this be done? I would postpone this discussion at this point, as it<br class="">leads to multiple dead-ends due to diverse (in)competences of participants.<br class="">Instead, we should reach some kind of consensus how the ideal system should<br class="">behave. The rest is a technical problem.<br class=""></blockquote><br class="">Agreed. Let's first specifically identify the key problems that need solving:<br class=""><br class="">(1) We require a way for individuals to converse directly with each other, at a<br class="">distance (which is to say electronically), in a manner that does not expose<br class="">information about their conversations to third parties. Three forms of<br class="">communication are perhaps most essential:<br class=""><br class="">(1a) long-form correspondence (mail).<br class=""><br class="">(1b) real-time text messages (both bilateral and group chat).<br class=""><br class="">(1c) real-time voice conversations (phone calls).<br class=""><br class="">(2) We require a way for individuals to exchange digital content such as<br class="">files and calendars, with the same requirements as (1) above.<br class=""><br class="">(3) We require a way for individuals to coordinate their activities (projects,<br class="">logistics, meetings, with the same requirements as (1) above.<br class=""><br class=""><blockquote type="cite" class="">Nextcloud is promising, but there is an infrastructural anomaly that has to<br class="">be fixed first - direct addressability of every human (smartphone, home<br class="">computer, etc.) without intermediaries, directories, assistants. Without it,<br class="">only users with real IP numbers can freely participate (DynDNS is a<br class="">centralized service prone to corruption). It's explained in the paper I<br class="">peddled earlier ( <a href="https://cryptome.org/2019/02/elbar.pdf" class="">https://cryptome.org/2019/02/elbar.pdf</a> )<br class=""></blockquote><br class="">For exactly the reasons Morlock offered in a separate thread [1], network<br class="">carriers will always have an interest to control the flow of information across<br class="">a network. Potential interests include censorship and extraction of surplus,<br class="">for example via price discrimination or tax. The problem of direct<br class="">addressability of devices is just one manifestation of such control.<br class=""><br class="">Strategically, users of a network that wish to avoid such control will need to<br class="">shield knowledge about their use of the network from the intermediaries, hence<br class="">the need for onion routing. Tor onion services [2] can be used to create<br class="">directly accessible services on any device that supports Tor. So it is<br class="">possible to run web servers, or indeed any other TCP-based Internet services,<br class="">via a Tor onion service, not only on workstations in homes and businesses that<br class="">have not paid for a static IP address, but indeed on laptops and smartphones as<br class="">well. Web servers available as Tor onion services can run Nextcloud too.<br class=""><br class="">Suggest that because it is folly to assume that we will be able to trust<br class="">Internet carriers not to block, monitor, or otherwise interfere with our<br class="">traffic, we can expect to use onion routing for this in the first instance.<br class="">This is not to say that those of us with static IP addresses should not feel<br class="">free to run Nextcloud services directly on the Internet, at least as long as we<br class="">are allowed to do so cheaply, which may come to an end before long.<br class=""><br class="">I would like to suggest that using Nextcloud to solve challenges (1), (2), and<br class="">(3) above will require essentially everyone to run a Nextcloud instance. This<br class="">is certainly possible, but there are no doubt more practical ways to achieve<br class="">(1a) and (1b).<br class=""><br class=""><blockquote type="cite" class="">Exactly. Let's do the effort and come up with white paper describing what<br class="">the hell we think would work. No one else will do it.<br class=""></blockquote><br class="">The 'Cwtch' Project as a means to achieve (1b):<br class=""><br class="">It turns out that there is an interesting article to address (1b) already,<br class="">written by Sarah Lewis of the Open Privacy Research Society in Canada [3]. An<br class="">early prototype of Cwtch, based on the Richochet protocol [4], already exists,<br class="">but it is not yet ready for general use. Cwtch is a worthwhile effort worth<br class="">supporting, both with time and with treasure, and I think that it is a fair<br class="">response to Morlock's call for a whitepaper. There are some aspects of the<br class="">design that might be debatable, such as the distinction between Cwtch servers<br class="">and Cwtch peers, although I think that the authors have made good choices. I<br class="">suspect that some of the software decisions are still crystallising. (Let's<br class="">hope that the software will allow individuals to manage many different<br class="">identities at the same time.)<br class=""><br class="">For (1a), I would like to suggest that we can do this with existing email<br class="">clients and email servers, tweaked slightly to run as Tor onion services.<br class="">There are aspects of this that would need elaboration, but I argue that the<br class="">task of retrofitting email infrastructure to work this way would be better than<br class="">starting from scratch. There are too many useful features embedded in SMTP and<br class="">IMAP implementations that we would not want to lose, and wiring them to work as<br class="">Tor onion services should not be too difficult.<br class=""><br class="">These are my recommendations for actionable next steps, and I would welcome<br class="">views about alternative approaches that would be both at least as effective and<br class="">at least as practical to implment.<br class=""><br class="">Best wishes --<br class=""><br class="">Geoff<br class=""><br class="">[1] M. Elloi, "<nettime> infonuclear options are coming". Fri, 03 May 2019<br class="">13:22:14 -0700, <a href="mailto:5CCCA2F6.1030908@gmail.com" class="">5CCCA2F6.1030908@gmail.com</a>.<br class=""><br class="">[2] Tor: Onion Service Protocol.<br class=""><a href="https://www.torproject.org/docs/onion-services.html.en" class="">https://www.torproject.org/docs/onion-services.html.en</a><br class=""><br class="">[3] S. Lewis, "Cwtch: Privacy Preserving Infrastructure for Asynchronous,<br class="">Decentralized, Multi-Party and Metadata Resistant Applications". 2018-06-28,<br class="">https://cwtch.im/<br class=""><br class="">[4] J. Brooks, "Ricochet: Anonymous instant messaging for real privacy".<br class="">https://ricochet.im/<br class=""># distributed via <nettime>: no commercial use without permission<br class=""># <nettime> is a moderated mailing list for net criticism,<br class=""># collaborative text filtering and cultural politics of the nets<br class=""># more info: http://mx.kein.org/mailman/listinfo/nettime-l<br class=""># archive: http://www.nettime.org contact: nettime@kein.org<br class=""># @nettime_bot tweets mail w/ sender unless #ANON is in Subject:<br class=""></div></blockquote></div><br class=""></body></html>