Re: [GNU/consensus] Fwd: FYI: Securing the Future of the Social Web with Open Standards

[Melvin Carvalho]

On 22 July 2013 21:28, hellekin <address@hidden> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/22/2013 06:01 AM, Melvin Carvalho wrote:
>
>> Klaus Schlesiek wrote: In essence, Edward Snowden has raised the
>> question of "trust".
>
*** Yes Klaus, you're right. I share most of your analysis. I posted
some of it yesterday and will correct the draft of the GNU/consensus
Whistle [0] to mention trust as well as privacy.

At least there's a shared agreement that we're living a momentum for
radical change.

>
> Crowd funding is a good idea.  Although it tends to be non
> optimally allocated.
>

*** That is the challenge we need to overcome! Two days ago I was
sitting in a library with a friend and I was proposing that we could
bring 10 developers from various projects and sequestrate them in a
cheap country to fix the inter-project communication for good. That
would not take a lot of investment to do it under nice weather
conditions, for 6 months to a year, and it certainly wouldn't take
that long to move from the actual mess to properly functioning
grassroots federation. We could do that with the Mocambos network in
Brazil (Vince?).

- From there, we could start worrying less about whose project is
mo'betta, and focus instead on figuring out a network of peers, a
scheme to mix global economies of scale for setting up infrastructure,
and local funding for sustaining local communities into cooperating
across state boundaries to build what we really want: a
privacy-preserving, censorship-resistant, local-community-operated
network of networks that will redefine democracy, or rather: res publica.

>
> Decentralized payments could change things.
>

*** Yes! But we're facing huge inertia: of nation states, of
capitalist banks. Can we get cooperative banks on our side? Can we
convince people that in order to escape from Prism, they need to
invest in their^Hpublic communications infrastructure, and in
their^Hcooperative financial infrastructure; and that this is not out
of reach!

We have crypto currencies now and off block IOUs.  You just need a web of trust.  I'm going to try and demo completely decentrlaized ads in the next year, it's a pity
"ad bard" is no longer going or I could have promoted lots of FLOSS software too...

 

>
> I agree although Linus was also an exceptional mind, coder and
> community leader.  He had a pure focus, ie to port the UNIX kernel
> to GNU as free software.
>
> In the social web we cant assume that we'll be blessed with someone
> as brilliant as Linus, and there is mixed focus, so working
> together becomes important, which is one area where standards can
> maybe help.  I say *maybe* because a standard that is restrictive
> may sometimes be counter productive.
>

*** Yes! We don't need a leader, we need leadership. And consensual
leadership. Based on ethical values, and clearly defined objectives.

The more I look at it, the more I think we should go for the simplest
possible thing, and leave convenience out of it, because convenience
is a vector for surveillance and control.

Ironically, Mozilla made a "Prism" project some time ago that would
allow to run a feature-stripped firefox to reduce risks, and make the
web app look more like a native OS app. A concept that Ubuntu recycled
pretty well, so much that it became itself a vector for
commodification of the user into a consumer.

I love most of what comes out of Mozilla, but underwhelmed with Persona, which is the identity solution that sits in the middle of most things.  They are in the church of "your email is your identity" -- let's be clear this is an unnecessary restriction with will not scale.  Other projects (not mentioning any names) *cough cough* are also in this religious sect. 

 

>
>> Before we can start to speak about standards, we need to have a
>> consensus of those interested in a post-faceboogle social web
>> about its structure and capabilities. You may call this worthy of
>> a standard in itself, but very basic properties have to be agreed
>> upon before serious efforts
should be
>> invested into realizing it.
>

*** Oh, I think we're on the path to reaching a GNU consensus on free
social software :)

>
> Together with Elijah of the LEAP project we came up with this list
> of priorities:
>
> 1) Client side encryption
>

*** +1, but only if it's end-to-end, otherwise, see (8).

>
> +1 Certainly should be an option, or a default, but key management
> is hard and a topic in itself, it takes time.  I would say a goal
> to build towards.
>

*** We tend to always repeat the same: public communication does not
need to be encrypted, so it's a use case that should easily be agreed
upon. Yet, everything that is not explicitly public is, in my opinion,
to be private: that means, in the current context, strongly encrypted.

Great point.  We've not even solved the public version yet.  When we do I suspect the encrypted version will be easy, just some shared keys and AES or another symmetric cypher, asymmetric PKI, or hybrid, or security by obscurity.  I'm not a huge believe in advertising which crypto algorithms are being used to the whole world, that all the relevant parties know should be enough.

 

>
> 2) Social graph obfuscation
>
*** +1

>
> 3) Self determined data storage
>

*** +1. I've been looking into OwnCloud 5 and Git-Annex lately.

>
> 4) Scalability
>
*** +1

>
> 5) Integration of old friends on legacy networks (which would
> compromise 1 and 2 for those, of course).
>
>
> +1  Some projects are underway to build this kind of 'driver'
>

*** Are you talking about Friendica (probably the largest surface of
contact with legacy networks), GNU Social (AKA StatusNet+Free Social),
others?

Freindica is one sure. 

 

>
> 6) High availability - you should be able to access your data when
> you want it.
>

*** Including OFFLINE! I'm not sure whether that is covered by the
more server-sideish "HA".

>
> 7) Device portability - you should be able to access your data
> from multiple devices at the same time
>

*** +1, and with various ACLs: I can't trust my phone as much as my
laptop for example. And certainly not a random computer in a random
cybercafe. [1]

>
> 8) Client choice - you should be able to use a mobile, desktop, or
> html5 app client (once webcrypto is deployed in browsers).
>

*** Honestly, I'm not sure that is a sane decision. Not until there
are some things fixed:

  - 1 TLS certification authorities (utterly broken and mostly
untrustable)
  - 2 TLS perfect forward secrecy implementation everywhere (servers,
browsers) including protection against TLS-downgrade attacks. That's
mostly a matter of proper configuration though.
  - 3 _javascript_ protection: Libre JS to ensure the code run on the
page is genuine and not malicious
  - 4 proper protection against XSS, CSRF, and other MITM

3 and 4 are way out of reach at the moment. HTML5 is bringing new
attack vectors, and the development of the Web is going towards more
usage of centralized resources (+1, Like, Login with X, analytics,
etc.) without mentioning _javascript_-less CSS-based or DOM-based XSS,
plugin-based infection, and mobile phone network insecurity as a whole.

I dont believe in trying to create perfect security, security should be "good enough" then you start the arms race between attackers and defenders.  Facebook didnt even start with https remember and go to 100 million users.  In any other project I'd be a security fundamentalist, but for a social project, users count, this often seems to be underestimated...

 

To me (8) is the convenience door open to keeping the spyware operate
as is. We should aim instead for much more ambitious things: secure
hardware, end-to-end encrypted connections (see (1)).

>
> 9) Multiple identity - you should be able to maintain multiple
> identities, and choose to link them or not.
>

*** +0 Again I see that as a convenience door open to spooks. True
unlinked identities are to remain... unlinked. Maintaining multiple
identities on a single device for example, is hard to protect in case
it is compromised...

The user should be in control of their identity.  They should be allowed to have their identity the way they want it, so long as it doesnt impinge on any other user.

 

>
> These are sometimes called 'nyms' (short for pseudonyms) ... yes
> it's important to think in terms of multiple identities, most
> systems restrict you to one, and even worse, one that is a subset
> of their particular world view.
>

*** +1. Identities are made to recognize people.

It is in the interest of bureaucracies and surveillance systems to
recognize people globally. That's why they want you to bear a "family
name" and well as a "given name", to get a passport and an identity
card (a recent invention that's supposed to prevent crime, but
everybody knows that criminals can forge identities), or in a too soon
future an implanted chip (now sold as "cool" for VIPs in hype clubs,
"life saving" for people with medical conditions or soldiers,
"protective" for inmates, or "efficient" for cattle).

But in social networks, people are used to share identity with their
own circles, and independently of their "Real Name (TM)". If you're
"Mister Smith" to your employee, you're "John" for your neighbor,
"daddy" for your children, "honey" for your wife, "spud" for your
former classmates, etc. Your identity only means that the people
susceptible to interact with you know who they are addressing
consistently, and you do as well know who is talking to you.

Identity is not about 1 person, but about a bi-directional
relationship. I have nothing to do with the NSA, nor any suspicious
government, nor any marketing entity that want to commodify me. So to
them my identity must be ephemeral.

>
> 10) Protocol agnostic - you should be able to cross-communicate
> with different protocols, be they XMPP, HTTP, or p2p based.
>

*** It depends. If I'm willing to use the Briar Transport Protocol,
obviously I don't want nor need that it interoperates with anything
else. Again, spooks might want that, but not me.

If I want to communicate using a protocol, with someone who is using
another, there should be a possibility for me to bridge that
communication to that protocol, but I would not put that as a requirement.

> Although I would love to see this happen, it's perhaps taking on
> too much for the first phase.
>

*** Yes.

>
> 11) Secure groups - groups with membership determined
> cryptographically. Groups function as a virtual user, with all
> users in the group able to receive and send as the group, because
> they share a private group-key.
>

*** +1. Private group communication is fundamental.

It's also a hard problem: sharing a private group key was discussed at
length last year during the hackathon in Berlin. Two main issues were
raised: 1) how do you bootstrap the key? 2) what to do when people
join or leave a group?

So maybe the notion of group must be revised as well to match
volatility of the concept. Transient groups might form and want
ephemeral communication; more stable groups will arise and want
perennial archives. Etc.

*

For me, most of the points you propose are conveyed by the
GNUnet/Secushare project, which you mention in your presentation, and
that is the explicit goal of the GNU/consensus project. For which I'm
being an opportunistic Bolchevik and wish for a (somehow short)
dictatorship of the Web people until we are ready to move to a true
p2p architecture. :)

==
hk

[0] The GNU/consensus Whistle is an upcoming monthly newsletter that
should start its life soon. A draft is available on the GNU/consensus
wiki at http://libreplanet.org/wiki/GNU/consensus/whistle/002013-07
and you're welcome to edit it.

[1] 3 years ago:
http://libreplanet.org/wiki/User:Hellekin/A_User_Perspective_Of_GNU_Social
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJR7YfuAAoJEEgGw2P8GJg9wBEP/Rdc/Akdiei2xEJ6t2aT6Qvn
WHbD72x9TdmP2Q5jj5iHJPnZO3xFCeRx73ZXeXbZKjVTOkP2pG+d5KXCVq7/wUwk
joy0hptBJVW6LSdv1hggf9s4emwfT0K8SyNxl2t5l1KC5EPVLcflZYWsQ2lmw61C
8JJPM2QtPVJbAQ+FiNZnK4DJebzfUPVvkQ19ImANrm/SPAtO0LqnO3UUXWbtRmLf
IXS43+PQn+Yq8Gm/hLVZxaZDR4RVF86eER2fV/993+DUZJczMogNapslQ19Z8VRo
mXXFhg2T9zP1A8w4ZGJJPB6ar5havCBlaS7xWp+zwTDuuwy3pt4VkLpGGG/oNRM5
NGDEed3pGJXloyZ2kapk8vowcVhT8ano/f+uJCbMavhU6f407CjpDAEo+Y1wWhbl
whWOI+oOOkitQfSbSwPP1I2x/JSCJMhI2lSzhC8o1/cMofbmZV8z3tEFAeizFtBa
1VHXYbVzNxhzgDVQqSe8ioj7Q2bd55hvPHaTHdxwTibENjyErij/M6bZJ1wIEYEi
WT+dlePfhfa2/LdVsi5i5BJ4/u+GWLhFKFE9lQevdECJkdS3wzuCBd6SRK3poPee
I5TmAiJZT3XfGZaAXKPjaP/zEK0JoXtiDnI5oki1t5B6BJERT9hSIPxxc4/G1rUZ
xH960Bxxi8w8gYe/KgJi
=LPX5
-----END PGP SIGNATURE-----