John Young on Sun, 16 Jun 2019 13:29:09 +0200 (CEST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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

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: