[GNU/consensus] Consensus on the aims of this group

[carlo von lynX]

It is no longer clear if people in here are Social Swarm, GNU consensus
or something else currently using the name #youbroketheinternet. The
latter just seemed to be the most appropriate name since we can't get
social off the ground without fixing the Internet first.

In the past we worked out http://libreplanet.org/wiki/GNU/consensus/berlin-2013
and reached a consensus on at least these points:

        - End-to-end encryption
        - Perfect Forward Secrecy 
        - Social graph and transmission pattern obfuscation 
        - Self determined data storage 

These four requirements make it such that any discussion of "improvements" of
the general situation that does not fulfil them should be seen as out of
scope for this group of people.

Feel free to put some band aids around SMTP, XMPP and other established apps,
but don't discuss it here - especially not as a solution to our list of basic
requirements. Let us work on solutions that fulfil OUR basic requirements for 
privacy.
This is the only thing that differentiates us from dozens of other similar 
groups.

And sorry for not having been patient enough to say this every couple
of months, using the best possible wording. As always with mailing lists,
memory fades quickly and people won't read documents before they start 
contributing.


On Sat, Nov 16, 2013 at 11:01:08PM +0100, Guido Witmond wrote:
> > Exactly, you are providing a neat alternative to X.509 but it doesn't
> > change anything about the entire rest of the architecture. I think that's
> > okay for banking or for Tor hidden services apps, but I don't like it for
> > a communications and messaging system as I won't accept that my naked
> > teenager pics are on your server's hard disk.
> 
> The strong point is that it's easy to implement and get quite a lot of
> communication encrypted. A weak point is that it is still vulnerable to
> traffic analysis. It needs Tor for that. Another weak point is that if
> you lose a private key, you're out of that account forever. Unless you
> can prove identity to the site some other way.
> 
> It also has a very simplistic repudiation model: delete the private key
> of an account securely and never mention that it was you.
> 
> Eccentric has either unsigned or signed public messages, or encrypted
> private messages. To get your naked teenager pics in clear-view on my
> server, you need to publish it. If you send it to a specific person,
> whose public key you've learned somehow, it is encrypted and my site
> can't decrypt it. All private messaging is end-to-end. Guaranteed. I
> don't know if Snapchat can offer that guarantee. :-)
> 
> I expect sites make it clear when you are publishing to the world or
> sending a private message. Anyway, the user agent should always show
> which of the two actions it is doing, signing a public message or
> encrypting a private message.
> 
> You may still not like it but it is quite an improvement over the
> current http-internet. Or Dropbox, or Google drive or ... I hope that
> once people get used to this model they can search for other systems
> that offer even more privacy. We crypto-designers have to lead them. The
> hardest part is not designing, it is selling.

Currently many aspects are hard.

> > So the server has the complete social graph. The tools I am recommending
> > as best current practice try to protect the social graph.
> 
> That is one other weakness but it is not so bad as you imagine. The
> server sees all traffic (not contents) between its users. As soon as two
> people have verified that there is no mitm, they can send this message:
>       Hi User2@@guido's-site,
>       Please connect to <protocol://my-ip:port/url>
>       Use your certificate to authenticate, I use mine.
>       Regards: User1@@guido-s-site
> User 1 opens the port on his computer and awaits if user2 connects.

And you can even do that with WebRTC's DTLS.

> Here we bootstrap a new channel based upon an existing channel. The
> protocol can be anything, xmpp, zrtp, maybe even psyc. My site acts as
> an introducer to people, like a mutual friend that arranges a blind
> date, only with cryptography.
> 
> As the message is encrypted, my server doesn't learn of this new
> channel. All the server learns is that after a few message, the
> communication ceased. There is nothing that I can do to prevent this new
> channel from opening. And once established, my server that has signed
> the certificate is not needed anymore. It can be nuked from orbit.
> 
> When User2 has previously established a private channel with User3,
> User2 can introduce User3 to User1 over their private channel. Again,
> the server cannot learn of this. The new channel between User1 and User3
> is invisible to the site. The site learns only about a partial social
> graph, not the full graph. The users, of course will learn the whole graph.
> 
> That message from User1 to User2 can even be published as wide as
> possible by User1. The whole world will learn that 1 is trying to
> contact 2 but only they have the matching private keys to validate each
> others' public key. It can be used in case my server is gone. Success
> depends on User2 learning of the contact request and willingness to
> connect. If either uses Tor, the world won't learn if they ever get
> connected.
> 
> That's the power of pseudonymous authenticated connections.

So to put it into the frame of our consensus, it doesn't preclude
installing something like Tor or GNUnet. It could be a tool for
dealing with web apps better - without them having to cooperate in
a the way they have to with unhosted.org. But it's a discussion aside
to figure out if we should politically require apps to work in an
unhosted style rather than eccentric. If we take requirement 4 of our
list for real, then eccentric must not substitute unhosted.

In any case this needs a patch of the browser and, what is the thing
that I criticize about browser extension approaches (and I did some
myself, so I know) is

1. that you only achieve the first two requirements, E2E and PFS, if
   you have DHE implemented in such a browser extension AND
2. the user interface for encrypting and decrypting messages is kept
   safely out of the regular HTML rendering so the user cannot be
   fooled by some website recreating exactly that GUI
3. you still put your communications at risk because of the many potential
   security leaks in web browser technology

That's the point when it is so distant from "the web" - if we can't even
trivially and safely use the rendering engine of the browser - that I
don't see a point to still use web technology and bring in all the risks
related to javascript backdoorability etc etc....

We don't need and we should not have javascript in THE tool that we intend
to use for the majority of our social interactions. It's unreasonable
and totally unnecessary since we require a software installation ANYWAY.
If people are installing some Tor/* bundle, let them have a fully viable
communications stack outside the browser.

I think, in future releases of a GNU internet OS, the web browser has
to run in a separated virtual machine from the actual communication apps,
anyway. Then it needs both an 0day for the browser AND the virtual machine
to cause harm. And you can easily make a two-physical-computers set-up as
recommended by Whonix if a VM isn't good enough for you.

These days we can even separate certificate control from the web browser
as we have developed a C version of Certificate Patrol that could be
integrated into the Tor socks proxy - thus it checks the validity of
certificates (beyond just the broken X.509) before the connection with
the sandboxed/isolated browser is even permitted.

Real security is feasible, why lose time on things that won't cut it?