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

[Morlock Elloi <morlockelloi@gmail.com>]

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: