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

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

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.