Re: FYI: Securing the Future of the Social Web with Open Standards

On 19 July 2013 12:28, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 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.
>
>
The full agenda: http://www.w3.org/2013/socialweb/agenda.html