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

[Melvin Carvalho]

On 22 July 2013 10:06, Klaus Schleisiek <address@hidden> wrote:

Dear Melvin,

thanks for your information. In this post-Snowden era many more people then ever
before have an open ear for security considerations (and cryptoparties).

I would like to make a number of remarks from a grassroots point to view. In
essence, Edward Snowden has raised the question of "trust". For a system that
serves as a trusted social web infrastructure more is needed than trusted
procedures and legal guarantees - the software itself and the platform it is
running on has to be trustworthy as well. The very possibilities to compromise
privacy have to be minimized by choosing an appropriate structure. This is
clearly to be preferred over a system that depends on the legal system to
"enforce" informational self determination.

Therefore, I believe that a social web for John Doe that can supersede
faceboogle needs to be not just open source, it needs to be crowd funded as
well.

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.

Decentralized payments could change things.  Currently facebooble make a 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.

 

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.

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. 

 

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.

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?

 

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.

 

2) Social graph obfuscation

+1

 

3) Self determined data storage

+1

Very much so, and important is that you can store your data in multiple places. 

 

4) Scalability

+1

This is absolutely key.  We need strategies to maximize this. 

 

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'

 

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

+1

 

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

+1
 

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

+1

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.

 

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.

 

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
 

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

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.

:)

Klaus Schleisiek

Wau-Holland-Stiftung                   W
Postfach 65 04 43              H O L L A N D
22364 Hamburg/Germany        S T I F T U N G
http://www.wauland.de

Am 19.07.2013 18:39, schrieb ☮ elf Pavlik ☮:
> --- Begin forwarded message from Melvin Carvalho ---
> From: Melvin Carvalho <address@hidden>
> To: "address@hidden" <address@hidden>, public-rww <address@hidden>
> Date: Fri, 19 Jul 2013 10:28:48 +0000
> Subject: FYI: Securing the Future of the Social Web with Open Standards
>
> http://www.w3.org/2013/socialweb/papers/w3c.html
>
> Harry Halpin, W3C/MIT and IRI
>
> 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
>
> The W3C has engaged the open social web since 2009, when it first hosted
> the "Future of Social Networking" workshop in Barcelona. While the workshop
> engaged a large number of stakeholders, it failed to garner enough industry
> interest and thus the Social Web Incubator Group was created to survey the
> open social web. The Incubator Group produced a high-level report of the
> standards landscape and a number of suggestions in their report @@, and
> included a number of suggestions for improving the W3C in order to make it
> more lightweight, suggested that led to the creation of W3C Community
> Groups. The W3C then started a number of community groups around relevant
> social standards (The Federated Social Web, OStatus, Pubsubhubbub) and
> hosted a developer-centric Federated Social Web 2011 conference in Berlin
> that brought companies such as Google together with grassroots activists
> (including activists from Egypt) and developers. While the conference
> concluded with a focus on adding secure group functionality to existing
> protocols, there was again not enough major industry interest to start a
> Working Groups. Then the W3C hosted, with the help of IBM, the Social
> Business Jam that led to the creation of the Social Business Community
> Group and this workshop. Thus, we hope that critical mass can now be
> achieved to start a Working Group in this area.
> Why Standards?
>
> The initial attempt to create an "open stack" for the social web happened
> outside of traditional standards bodies like the IETF and W3C. This in turn
> led to a very fragmented landscape of standards that have had mixed
> deployment with some success and some failures. However, there are a number
> of disadvantages of the approach of creating a "stack" of technologies
> outside of a standards body. In particular, there are:
>
>    - No unified IPR policy. While some specifications do specify their IPR
>    (OpenSocial), others had difficulty getting IPR signed over
>    (ActivityStreams), and some still have no clear IPR (Pubsubhubbub)
>    - No maintenance policy: Some specifications are in need of updating but
>    exist purely as informal specifications (PortableContacts) and fail to be
>    updated to take into account new developments (Salmon Protocol)
>    - Lack of guidance for developers: Developers need to make sense of a
>    bewildering number of specifications in order to build an open social
>    application. While the OStatus meta-architecture provided some guidance, it
>    needs to be maintained in lieu of current work.
>    - Lack of a test-suite. It is difficult to demonstrate interoperability
>    between code-bases without a single test-suite that can be easily deployed
>    via github. Thus, demonstrations of interoperability have been "one-off"
>    and have not been maintained.
>    - Lack of integration into the Web: HTML5 is providing a host of new
>    capabilities to HTML that will reliably work cross-platform across an
>    increasingly heterogeneous number of platforms, including mobile. Browser
>    plug-ins will be increasingly phased out of existence from all major
>    browsers. Any social work needs to take advantage of this.
>    - Lack of security considerations: A distributed social networking
>    architecture by nature needs strong authentication of parties and integrity
>    and even confidentiality of messages.
>
> 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) and
> chair with management structure 3) providing a primer and integration of
> examples into the Open Web Docs with the rest of HTML5 4) Adding client
> testing into the git maintained HTML test-suite and a clear server-side
> test-suite 5) re-factoring current specifications around HTML5 (in
> particular, Web Components and CORS) 6) Providing a broad test-suite and
> integration of the social web with security-oriented work such Content
> Security Policy, the Web Cryptography API, and wide security reviews with
> related work at the IETF. Future work should have a clear focus and work in
> a unified manner, ideally with a single group with a well-defined timeline
> and deliverables.
> A Secure Open Social Web?
>
> In particular, security considerations have received less attention that
> needed on the social web, with the paradigm of an unauthenticated public
> broadcast of messages failing to provide the elementary security
> considerations needed for closed groups and valuable information, which are
> requirements for many use-cases ranging from sensitive corporate
> information to human rights activism. Any open social web that fails to
> take on security considerations will be abused by spammers at the very
> least.
>
> Any new effort for the social web should clarify the threat model and
> propose mitigations so that the open social web can handle high-value
> information. For example, any attempt to broadcast messages needs to have
> the sender authenticated, and so by nature all messages should be digitally
> signed with integrity checks, lest a malicious party strip the signature
> and replace it with its own when substituting a false message. For
> sensitive information, the message should itself be encrypted and
> de-crypted only to those in the group. To allow messages in distributed
> systems to be re-integrated and ordered correctly (as originally tried with
> Salmon Protocol), time-stamping is necessary. Lastly, it may be incorrect
> that a distributed social system that isn't properly designed is actually
> more secure than a centralized silo: considerations should be made that the
> ability to post presence updates does not store more information than is
> necessary in a centralized location (as is currently done by XMPP servers
> for example) and for use-cases where high latency is allowed, constant rate
> background traffic and mixing can prevent traffic analysis threats.
> Next Steps
>
> The result of this workshop will determine the future of the open social
> web. Concretely, this will consist of a report released within one month
> and then possibly, if consensus is reached and there is enough industry
> interest, one or more charters for Working Groups. The W3C welcomes joining
> forces with the OpenSocial Foundation and numerous grassroots efforts both
> inside (Pubsubhubub, OStatus) and outside the W3C (ActivityStreams,
> IndieWeb) in making social should be a "first class" citizen on the Web.
> --- End forwarded message ---
>