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 11:01:25AM +0200, Melvin Carvalho wrote:
> Crowd funding is a good idea.  Although it tends to be non optimally
> allocated.  ie most of the crowd funding went to Diaspora partly because
> they evangelized well, and got good coverage on web 2.0 blogs and hacker
> news.  There are projects that didnt get 1% as much as diaspora that were
> not 99% worse.

Crowd funding suffers from effects of P.R. - We need procedures like we
have in our liquid feedback driven pirate parties (austria, italy) to
establish a decent degree of technical competence and correctness before
leading people to decide where to put the money.

> Decentralized payments could change things.  Currently facebooble make a

No, it's the lack of expertise and patience to get to it. Exactly the
problem liquid feedback was designed to solve (and does a lot better
than not doing anything at all).

> lot of money by putting ads on content.  Content they did not create.  The
> content creators often get no remuneration, or sometimes just a fraction.
> This makes no sense to me in a world of decentralized micropayments.  We
> should have a multi faceted funding strategy.  However, project selection
> is quite hard either for the lay person or even the expert.  But perhaps we
> can try and make it slightly more democratic, at least that, if no more.

^From my point of view the way to go is to have a liquid feedback
driven software foundation.

> On 22 July 2013 10:06, Klaus Schleisiek <address@hidden> wrote:
> > This makes the lack of interest of the industry sector less of a problem -
> > privacy conscious people will welcome a system that is free from corporate
> > interests. That does not mean that the corporate world is not welcome to
> > use the
> > standards and structures, which are going to be developed in the public
> > domain,
> > but the public domain needs to take the lead. As I see it, the situation is
> > similar to what happened with Linux: There has been an open system, which
> > then
> > got used by industry that threw development efforts on it, which
> > benefitted the
> > open community in return - a healthy win-win situation.

Exactly the idea behind http://secushare.org/business - the infrastructure
is by the people for the people and secure, but you can do business over it.

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

Glad to hear standards are no longer the cure to all problems as it has
hardly ever been so. Some popular mantras in the blogosphere really need
to be kicked in the butt.

> > 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. See my brief presentation from this years Eastehegg at
> >
> > https://frab.eh13.c3pb.de/system/attachments/6/original/13-03-29_19Uhr_social_networks.ppt?1364649557
> > ,
> > which proposes a basic set of requirements needed to supersede faceboogle.
> > It
> > turned out to be quite agreeable.

We need at least one implementation that actually works and scales, before
considering to call anything similar to it a "standard."

> Nice presentation.  What happened to the dooble / intefrace social browser
> that was based on libretroshare ... that was really nice, is it still part
> of this group's focus?

No idea about that, but I recently looked at retroshare again and had the
superficial impression that it has made huge improvement. Retroshare is
really a small Internet replacement in a single application - similar to
what I had in mind for secushare. Certainly a lot easier to deploy at
crypto parties than the old PGP+email and XMPP+OTR tirades which provide
zero meta data protection and yet require far too many gestures that
people should not have to care about, like choosing jabber and mail
servers to entrust. wtf.

> > Together with Elijah of the LEAP project we came up with this list of
> > priorities:
> >
> > 1) Client side encryption
> 
> +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.

Key management is a solved problem. We have shared secret approaches
(socialist millionaire) and hardware approaches (gnunet's pubkey in a
QR code on your business card). Just implement it where it's missing.
Now is the time to make key exchange a healthy habit for humanity -
and there is no alternative. TLS? make me laugh.

> > 2) Social graph obfuscation
> 
> +1

On http://secushare.org/comparison this aspect is split into
several points at "Use Case: Social Networking" - but it isn't
up to date. Funny how I granted "Secret Friends" to Skype...
even I was considering the PRISM case a fringe paranoia and
expected the social links between people to be private for
most. Wrong! "Unobservability" is a relevant point, and I
don't know if retroshare has improved on that recently.

By looking at
    
https://retroshareteam.wordpress.com/2012/11/03/retroshares-anonymous-routing-model/
I presume they have focused on trust, not unobservability -
thus retroshare exposes the social graph proactively.
This is very different from gnunet/secushare - and it puts
servers back on the menu - because if for any reason a server
is indeed trustworthy (lorea use case), a star topology over
that server (no federation!!) with some obfuscation by delay
and packet size normation can provide better social graph
security than other approaches. Deadly though, if the attacker
later gets access to the servers. Also, no such protocol exists,
so retroshare is to be considered the least bad option.

Maybe something over TOR or I2P is superior to retroshare.
What's out there? torchat?

> > 3) Self determined data storage
> 
> +1
> 
> Very much so, and important is that you can store your data in multiple
> places.

Solved in several P2P approaches including retroshare.
Not solved if you're trying to use some service that
is only available on the web.

> > 4) Scalability
> 
> +1
> 
> This is absolutely key.  We need strategies to maximize this.

We have bittorrent as an established multicast file sharing
technology. according to
    http://retroshare.sourceforge.net/wiki/index.php/File_transfer_protocol
retroshare has some strategy about that, too.

gnunet is working on a generic multicast mesh networking
currently - beyond just file transfer. It's what we need for
massive social usage.

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

I consider this totally irrelevant. Facebook never needed to provide for
an integration of myspace to drive it out of business. If people
seriously start using a free social network only the dumb will
stick to Facebook.

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

secushare keeps it on your hard disk, so you don't need the
Internet to use it. I presume retroshare is similar.

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

Planned for secushare. Not sure if retroshare can have multiple
instances with the same identity and if it provides syncing
capability. I doubt it.

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

Only if your communications node is running on the same device
and the browser is not enabled to do HTTP connections to normal
web servers... or it only executes very carefully peer reviewed
Javascript. Otherwise it's like asking to have privacy while
you're using Microsoft Windoze or MacOS. It's impossible by design.

I'm terrified people could even fall for "easy" promised
solutions like heml.is or cryptocat. Everyone wants to get
security without sweat. Terrible. The browser can only be
used as a dumb terminal. Web crypto is broken by design.
See http://secushare.org/end2end - The only time web crypto
could potentially be okay is when there is a daemon on the
same computer - which obviously means that it is safer to
do in that daemon.

> > 9) Multiple identity - you should be able to maintain multiple identities,
> > and
> > choose to link them or not.
> 
> +1
> 
> 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.  For example, one church believes your email *is* your identity, and
> one church believes your homepage *is*.  Neither are correct (tho of course
> email favours google/yahoo/microsoft) and the two will never get on.  We
> need permissive identity solutions and multiple identity solutions.  If we
> solve this one thing alone, we will have advanced more than in the last few
> years, because it will mean that different projects can talk to each other.

It's planned for secushare, don't know about other apps.

> > 10) Protocol agnostic - you should be able to cross-communicate with
> > different
> > protocols, be they XMPP, HTTP, or p2p based.
> 
> +0
> 
> Although I would love to see this happen, it's perhaps taking on too much
> for the first phase.  Everyone goes away and programs something the does
> not inerop with anything else.  Most critical is that we prioritize solving
> the HTTP case first, at least to a good level.  The reason is that almost
> everything is able to talk HTTP.  If we can get that working quickly, the
> same patterns can be extended to other transport layers.

If you mean tunneling, then I'm with you. gnunet tunnels over HTTP,
P2P DHT and even over raw WLAN - that is without requiring nodes to
log into it. Other than that, gatewaying to old protocols only
means enabling a downgrade attack on your privacy - and nobody needs
to be XMPP compatible for anything. Simply run your new privacy
friendly communications tool and slowly migrate away from XMPP crap.
Start doing it today.. with retroshare and torchat and dunno what else.

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

Retroshare already has that. We will, too.

One thing I'm wondering about with retroshare is forward secrecy.
I'm not sure it does DHE on link level and I'm not sure if that's
enough. Probably yes: if an attacker wants to log all encrypted
traffic, then get at the private key and decrypt it, she needs to
be one of the person's friends the person routes his packets over.
That means NSA needs to undertake a Stasi-like effort to infiltrate
the social network in order to get at the communications. That is
acceptable IMHO.

> > After Snowden, I am quite certain that we will have broad attendance for a
> > workshop on these topics at the upcoming 30C3, the annual get together of
> > the
> > Chaos Computer Club. See the CFP at
> > http://events.ccc.de/2013/07/18/30c3-call-for-participation-en/.

You may want to have me around so I can ring the easy-but-broken-solution
alarm bell... or maybe there are other folks who are as knee-deep on the
subject as me.

> > On the weekend of August 24/25 there will a preparatory meeting for this
> > 30C3
> > workshop sponsored by Wau Holland Foundation. This meeting will sort out
> > the
> > following questions:
> >
> > - which grass-roots projects should to represented
> > - whom would we like to see there
> > - what preparatory material needs to be produced for the workshop
> >
> > Whoever would like to participate, please drop me a note.

Note.

Oh no.. Harry Halpin, W3C/MIT and IRI wrote:
> > > The social web increasingly defines the Web itself. The Web is more than
> > > hyperlinks between documents, as the web ultimately consists of the links
> > > between people. Integrating the ability to co-operate socially on the Web
> > > via open standards has the possibility of unleashing a new round of
> > > innovation that would benefit everyone on the Web.
> > > W3C's engagement with the Social Web

Yes, but it isn't safe. Privacy is not possible on the web. Thus,
the W3C is no trustworthy standards organization for privacy issues.
But it keeps marketing the idea that "social" has something to
do with the "web." Approach broken by design.

> > >    - No unified IPR policy. While some specifications do specify their

Intellectual Property Rights? We are talking about cutting secret
services out of our most basic human needs and you are talking about
respecting some illegally conferred IPR!? I am sure that supreme
courts will rule in favour of basic human rights, so the IPR topic
is totally ridiculous and driven by commercial interests.

> > > In combination with the OpenSocial Foundation, the W3C can help address
> > > each of the above concerns by 1) providing a single unified royalty-free
> > > IPR policy 2) a Working Group with clear responsibilities for editor(s)

This whole approach is just a grand way to keep the idealistic
developers busy investing energy in something that will hopelessly
never scale, never provide privacy and thus never fulfil its scope.
This has been explained in detail to Harry before, but Harry seems
resistant against scientific explanations.


-- 
»»» psyc://psyced.org/~lynx »»» irc://psyced.org/welcome
 »»» xmpp:address@hidden »»» https://psyced.org/PSYC/
network chat technology since 1988 » http://www.psyced.org
_______________________________________________
SocialSwarm-DISCUSSION mailing list
address@hidden
https://mail.foebud.org/cgi-bin/mailman/listinfo/socialswarm-discussion

Website        : http://socialswarm.net/
Wiki           : https://wiki.socialswarm.net
Liquid Feedback: https://socialswarm.tracciabi.li

All mailing lists for SocialSwarm:

SocialSwarm-ANNOUNCE (Announcements only; no discussion)
SocialSwarm-DISCUSSION (discussion list)
SocialSwarm-TECH (discussion list for technik and coders)

https://mail.foebud.org/cgi-bin/mailman/listinfo/socialswarm-announce
https://mail.foebud.org/cgi-bin/mailman/listinfo/socialswarm-tech
https://mail.foebud.org/cgi-bin/mailman/listinfo/socialswarm-discussion


FoeBuD e.V. | Marktstrasse 18 | 33602 Bielefeld | Germany | address@hidden