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

[carlo von lynX]

On Mon, Jul 22, 2013 at 10:13:04PM +0200, Melvin Carvalho wrote:
> 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.

email needs to be discontinued in the long run. it doesn't serve any of
the purposes it was constructed for. it gives the attacker a full view
of the social network, a view into the content by default and it also
fails at delivering to many recipients promptly and to handle spam.

a proper messaging system protects both content and meta data of
communications, multicasts whenever something wants to be received by
multiple recipients and sorts out spam because it is the only use 
case for massive unicasting. also, key management is ridiculously
easy if it doesn't try to get along with email addresses. the key
is the identity. works great in modern systems such as tor hidden
services, retroshare etc.

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

haven't looked into it, but if there is a client i presume there is
a server so there is a server that gets to see meta data of who is
talking to whom. that means it doesn't fulfil today's requirements
for privacy. correct?

> > *** 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.

once there is a system that can deliver public info without exposing who
is actually receiving it, there will be no need for public info to
actually be unencrypted. in other words, i am afraid you are putting
effort into something nobody will want as soon as something better is
available. there is no such thing as "public communication." even if i
subscribe to the public pirate party announcements channel, i am
exposing my political interest - thus, even the most popular twitter
content needs to be subscribeable in privacy, the delivery tree must
be invisible to outside viewers thus the content must be encrypted or
otherwise you would see how the distribution tree is architected.

conclusion: the use case for a "public version" does not exist - at
least not from the point of view of somebody who is not going to tolerate
any further data mining on the general population - even if it is
just subscribing to sports news. this whole 1984 approach has to be
stopped without exceptions.

> > > 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 agree and i also doubt that 1 and 2 can be fixed in a way that cuts
out big brother. too many bugs on all levels. X.509 is a failure.
the only way to use web technology is to forbid it from connecting
to anywhere else but the locally running social network daemon.

> 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...

the user count is irrelevant if the load is fully distributed among those
who are using it. it doesn't matter if a hundred or a billion people
participate. each time we do something "good enough" we are only behind
the attacker and not achieving our goals - because each time we find
out it wasn't good enough. we have a realistic chance to do much better
so let's not invest in anything half-baked. after all Tor just needed
to be coded, too, and it has changed the landscape of the internet.