Skip to main content

Media without censorship (CensorFree) scenarios
draft-pouwelse-censorfree-scenarios-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Johan Pouwelse
Last updated 2012-07-16
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pouwelse-censorfree-scenarios-01
Internet Engineering Task Force                         J. Pouwelse, Ed.
Internet-Draft                            Delft University of Technology
Intended status: Standards Track                           July 16, 2012
Expires: January 17, 2013

            Media without censorship (CensorFree) scenarios
                 draft-pouwelse-censorfree-scenarios-01

Abstract

   This document describes some scenarios in which one can imagine that
   the ability of authoritarian regime to censor news dissemination is
   reduced.  It tries to draw some conclusions about what's desirable
   and what's not acceptable for users in those scenarios.

   The CensorFree objective is to standardize the protocols for
   microblogging on smartphones with a focus on security and censorship
   resistance.  Microblog entries are short text messages, possibly
   enriched with pictures or streaming video.  The goal is to devise
   protocols which guard against all known forms of censorship such as:
   cyberspace sabotage, digital eavesdropping, infiltration, fraud,
   Internet kill switches and lawyer-based attacks with the best known
   protective methods.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 17, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Pouwelse                Expires January 17, 2013                [Page 1]
Internet-Draft                 CensorFree                      July 2012

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Goal: microblogging  . . . . . . . . . . . . . . . . . . . . .  4
   4.  Four driving scenarios . . . . . . . . . . . . . . . . . . . .  4
     4.1.  20sec scenario . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Internet-Free scenario . . . . . . . . . . . . . . . . . .  6
     4.3.  Friends-only scenario  . . . . . . . . . . . . . . . . . .  7
     4.4.  Spammers and hoaxes  . . . . . . . . . . . . . . . . . . .  8
   5.  Design principles: simplicity and prior success  . . . . . . .  8
   6.  Background rant: lack of coordination and fragmentation  . . .  8
   7.  Current running code and related work  . . . . . . . . . . . .  9
   8.  What to include in a draft?  . . . . . . . . . . . . . . . . . 10
     8.1.  Gap between scenarios and existing work  . . . . . . . . . 10
     8.2.  Architecture and protocol messages . . . . . . . . . . . . 10
     8.3.  Text encoding and media containers . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
     11.3. URL References . . . . . . . . . . . . . . . . . . . . . . 11

Pouwelse                Expires January 17, 2013                [Page 2]
Internet-Draft                 CensorFree                      July 2012

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   Freedom to spread information is under active attack in various
   corners of The Internet.  Internet freedom has been losing and
   declining in many areas.  The Internet has been put under strict
   control using mechanisms of significant sophistication and
   complexity.  The age of cyber suppression is upon us and we need to
   act.  The forces favoring freedom need to avoid fragmentation of
   effort and re-group under a single initiative in order to impact the
   lives of millions.

   Democratic countries also face a dilemma.  Restrictions on the free
   information flow is the topics of several proposed laws by elected
   representatives.  The strength of copyright law impacts digital
   information flow.  Politicians must decide between weak copyright
   law, as championed by civil rights activists versus strong copyright
   enforcement, as promoted by numerous players in the creative
   industries.  Recent furor around SOPA, PIPA, etc. in the US plus the
   European Parliament vote on ACTA is highly relevant in this context.

   A glimmer of hope exists.  The Arab Spring shows that a new
   generation is claiming their right to express themselves.
   Microblogging, social media in general and traditional satellite news
   broadcast networks are perceived as critical catalysts for political
   change.  Generic computational fabric is soon getting in the hands of
   two billion people with the growth of smartphones and increasingly
   affordable communication.  These smartphones are increasingly used to
   record and spread disruptive audiovisual material, even in regions
   without media freedom.

   The uniqueness of The Internet lies in the IETF standards.  Moving
   certain bits to certain locations or offering a service requires no
   prior official approval.  However, Internet-deployed mechanisms now
   exist which filter news and media in general for both surveillance
   and censorship.  The Internet has ceased to provide reliable
   transport service for all users.  The IETF can repeat itA's
   historical inter-networking role again by setting the standard for
   reliable flow of packets of news.

Pouwelse                Expires January 17, 2013                [Page 3]
Internet-Draft                 CensorFree                      July 2012

3.  Goal: microblogging

   The goal of creating a microblogging standard and facilitating a
   reference implementation for portable devices which is capable of
   operating in a hostile environment.  Microblogging is an increasingly
   popular technology for lightweight interaction over the Internet.  It
   differs from traditional blogging in that [OPENMICRO]:

   o  Posts are short (typically less than 140 characters, which is the
      limit in SMS).

   o  Posts are in plain text.

   o  People can reply to your posts, but not directly comment on them.

   o  People learn about your posts only if they have permission to view
      them.

   o  Your microblogging feed is discovered based on your identity at a
      domain or with a service.

   This proposed draft standard SHALL provide: "information
   dissemination from a single smartphone to an audience of millions in
   the form of microblogging, enriched with pictures or streaming video
   which is guarded against all known forms of censorship such as:
   cyberspace sabotage, digital eavesdropping, infiltration, fraud,
   Internet kill switches and lawyer-based attacks with the best known
   protective methods".

4.  Four driving scenarios

   Recent events has shown the power of ubiquitous camera-phones, new
   media and microblogging.  This document proposes to uses smartphones,
   wifi and USB sticks for multimedia playback and transport.  The
   architecture, features and driving scenarios are specifically crafted
   to enable compliant implementations as a single smartphone app
   without any additional server infrastructure.

4.1.  20sec scenario

   First scenario, called "20sec", defines an open microblogging
   standard.  This first scenario duplicates existing microblogging
   practices with an open standard in a fully decentralized setting.
   Smartphone owner Alice with wifi-based Internet access records a
   video, attaches this video to a microblog entry and shares this story
   plus video automatically with friends Bob and Charlie which are
   subscribed to her news feed.  Alice does not need to trust any
   central server with her credentials or has to prove her identity to a

Pouwelse                Expires January 17, 2013                [Page 4]
Internet-Draft                 CensorFree                      July 2012

   central (web) server.  Bob and Charlie are both behind a NAT
   middlebox compliant to the BEHAVE recommendations [RFC4787].  No
   assistance of a coordinating server (e.g.  STUN or TURN) is required
   to traverse this NAT box using UDP messages.  This scenario assumes
   direct or NAT-based Internet access (the next scenario deals with
   packet forwarding).

   The scenario requirements are performance equal to central-server
   based approach (e.g. the ability to reach 20 million people in 20
   seconds), optional backwards compatibility and that there are no
   dependencies on any kind of central infrastructure (DNS, web servers,
   access portal, CDN cloud).  This first scenario duplicates existing
   microblogging practices with an open standard in a fully
   decentralized setting.  The 20sec scenario requires that solutions
   provide seamless backwards compatibility with existing leading
   solutions (e.g.  Twitter, Sina Weibo, chyrp, heello) by using content
   import tools.  Proposed open solutions MUST permit easy bulk trans-
   coding and ingest of existing news feeds into this open standard.

   An essential feature of the 20sec scenario is all potential central
   gatekeepers are removed.  Ownership of data is fundamental to
   autonomy.  To meet the anti-censorship goal, 20sec assumes an
   infrastructure which is not dependent and completely decoupled from
   potentially hostile servers such as DNS servers, web servers, swarm
   trackers, access portals. 20sec MUST be based on full self-
   organization.  The infrastructure consists purely of devices running
   compliant implementations.  No central server requires installation
   or maintenance, making this infrastructure independant on any type of
   funding or business model. 20sec requires an overlay which is highly
   resilient.  Smartphones, tablets and PCs are able to utilize this P2P
   overlay for microblogging.  Existing solutions such as [OPENMICRO]
   require a central webserver and OAuth-like authentication primitives.
   This prior work is not suitable for our 20sec scenario, as we aim to
   remove all server, ultrapeer or superpeer reliance and equality of
   all participants in the overlay.

   When Alice downloads her smartphone app and starts it for the first
   time it needs to bootstrap.  On this initial startup, the
   microblogging software must bootstrap and find at least one other
   peer in the overlay.  The most simple method of bootstrapping is
   using a list of currently online peers plus their port number.  See
   the example below.

   # file: Central-Bootstrap-Servers.txt
   # default bootstrap peers
   server1.always-online.org 6420
   host1.never-offline.ro 6420
   sealand.routed.org 6420

Pouwelse                Expires January 17, 2013                [Page 5]
Internet-Draft                 CensorFree                      July 2012

   168.0.0.13 6420

   A file sharing program needs a fresh list of peers to bootstrap.
   Thus a pre-defined list of peers is included in the software
   installer.  As peers can go offline it is important that at least one
   peer out of possibly thousands on the list is still online.  This
   pre-existing address list of possibly working peers must therefore
   remain valid for as long as possible.  Bootstrapping is done by
   contacting peers in the list, possibly in parallel.  If a single
   peers replies, the smartphone app of Alice is connected.  Once
   connected, a fresh list of working peer Internet addresses COULD be
   requested.  Several ideas have been proposed on bootstrapping systems
   without an "online booststrap server" list.  For instance, simply by
   smart brute force pinging, as described by the University of Denver
   [BOOTSTRAP].

   It is RECOMMENDED compliant implementations explore and implement
   efficient alternatives for decentralized initial boostrapping.

4.2.  Internet-Free scenario

   The Internet-free scenario describes a situation without direct
   Internet access.  It is focussed on ad-hoc packet forwarding between
   smartphones.

   Smartphone owner Alice records a video, attaches this video to a
   microblog entry and shares this story plus video automatically with
   This sharing at some point within range of the wifi,bluetooth or
   other wireless capability of Alice.  In an age where

   Smartphone owner Alice has no Internet access.  She records a video,
   attaches this video to a microblog entry in her phone app.  Friends
   Bob and Charlie are subscribed to her news feed.  Bob and Charlie are
   at some point within range of the wifi, bluetooth or other wireless
   capability of Alice.  This fresh microblog entry plus video is shared
   automatically.  Bob obtained the message from Alice using a
   smartphone app which is periodically scanning if other devices are
   around and if they possibly have fresh news.  This periodic
   synchronization SHOULD be energy-efficient.  Bob sees no noticeable
   decrease in battery lifetime after he obtained unconstrained news
   access.  Charlie later goes to a square where numerous people have
   gathered, most of which are highly interested in the latest videos.
   The fresh messages automatically spreads in this crowd.

   Note that this scenario differs from Delay-Tolerant Networking (DTN),
   as being investigated by a Working Group within the Internet Research
   Task Force [RFC4838].  The DTN focus is on finding routes to an
   explicitly given destination, usually by maintaining routing tables.

Pouwelse                Expires January 17, 2013                [Page 6]
Internet-Draft                 CensorFree                      July 2012

   Their system model and terminology cannot be applied in our context,
   for instance, "Endpoint Identifiers" which identify the original
   sender and final destination.  In our Internet-Free scenario sender
   Alice does NOT explicitly send a message with destination Bob.

4.3.  Friends-only scenario

   This third scenario uses friend-to-friend networking to remove the
   requirement for active networking and wifi sensing.  The smartphones
   of Alice and Bob need to be synced manually.  This scenario SHOULD
   deliver a privacy-by-design type of microblogging service.

   Encryption is not a sufficient requirement of the Friends-only
   scenario, everything MUST be hidden.  Possession of encrypted
   electronic messages is extremely harmfull in our scenario.

   Reports from repressive regions indicate that USB sticks are commonly
   used to transport sensitive information.  See for instance this
   extensive report on North-Korea [NKOREA].  In the Friends-only
   scenario a network of friends is trusted to transport news manually,
   by simply carrying it around.  Smartphones with NFC capability or
   manual USB transfer are used to duplicate and move messages.  Thus
   Alice delivers her fresh news message to Bob, which is later given
   manually to Charlie.

   As direct social connections are sparse and proximity of friends is
   not continuous, this scenario SHOULD facilitate usage of friends-of-
   friends or further removed social ties to relay news messages.  This
   requires the development of a decentralised social network, for
   instance, with digital signatures of friendship certificates.  In
   effect this would create a "decentralized social network", completely
   autonomous and owned by all participants.  We assume Alice only has
   Bob in her friendlist and Bob only has Charlie in his friendlist.  An
   OPTIONAL feature is that the smartphone apps running on the
   smartphone Alice and Charlie detect that they have friendship path
   through Bob. Fresh news is thus exchanged.

   The interception of a single smartphone MUST NOT expose the app
   itself, any friend list or worst: the entire social network.  We
   assume Alice is placing herself in danger with electronic tools for
   "subversive activities against the democratic republic".  Information
   hiding techniques are essential or even life-critical.  Possibly
   based on Zero-Knowledge Proof (ZKP) protocols [ZEROKNOW].  The
   smartphone app MUST pose as a harmless entertainment feature of a
   smartphone or use another mechanism to become a "stealth app".

   This scenario requires modification and enhancement based on real-
   world experience from human rights activits [EGYPTSTUDY].

Pouwelse                Expires January 17, 2013                [Page 7]
Internet-Draft                 CensorFree                      July 2012

4.4.  Spammers and hoaxes

   This final fourth scenario is focussed on spam.  All technology
   adressing one of the above three scenarios MUST also have the
   capability to deal with spam.  Unfortunately, this ability to deal
   with spam is in conflict with simplicity.

   Alice and Bob are exchanging the fresh messages from their social
   network (similar to Internet-free or Friends-only).  Eve is actively
   trying to disrupt the system by injecting news channels with a mix of
   genuine news, obviously fake messages (consuming valuable system
   resources and user attention) and hoaxes.  These falsehoods made to
   masquerade as truth result in erosion of overall trust in the system.

   Systems SHOULD offer capabilities to report spam, mechanisms for fact
   validation and reputations of (pseudo) identities.

5.  Design principles: simplicity and prior success

   Designing and crafting software which is completely self-organizing
   has clear limits [CAPLIMIT] and requires a certain level of expertise
   [LEVELS].  In order to avoid repeating mistakes from the past, this
   document aims to base itA's design principles on existing new media
   successes.  For microblogging this means following market leading
   solutions and enhance them with censorship resilience.  We recognize
   the following success factors: Simplicity, Real-time responsiveness,
   Near-effortless news creation, News items are bundled in channels,
   combine public broadcasting and person-to-person private messaging,
   following a channel is single direction, more followers yields more
   visibility, keyword search with push of updates and ability to deal
   with spam.

6.  Background rant: lack of coordination and fragmentation

   Computers communicating on equal footing has been part of the IETF
   standards for many decades.  Recently several loosely connected
   standard initiated around explicitly driven by the P2P paradigm for
   applications such as Internet telephony video streaming.  An
   essential problem in this domain is the lack of coordination and
   standard setting for P2P technology.  A large part of the innovation
   around P2P seems to happen in single-person Open Source projects and
   small groups which lack the engineering capacity to make generic, re-
   usable and documented components.  Given their running code-driven
   nature, money and time is not available for attending standards-
   setting meetings, writing formal specifications and defining quality
   control testing suites.  Profit-driven organisations should have the
   resources to overcome these resource shortage issues.  However, due
   to the dynamic, disruptive and litigious nature of P2P few examples

Pouwelse                Expires January 17, 2013                [Page 8]
Internet-Draft                 CensorFree                      July 2012

   exist of companies which are capable of supporting an IETF standard
   setting activity for several years.

   As presented during IETF 81 area directorate, there is "not a clear
   long-term architecture yet for you to build actual classes of P2P
   applications using IETF technologies".  Forming an overlay is hard
   and scalable privacy-preserving unstructured search solutions are
   only barely out of the scientific research community.

   From the above we conclude that a key obstacle to the success of this
   proposal is implementation and uptake.  A draft document, active
   community and reference implementation ideally evolve together over
   time.  To overcome this issue a continuous incremental improvement
   approach is advised.  The preferred way is incremental development of
   single a reference implementation, based on free software.

7.  Current running code and related work

   DISCLAIMER: this section needs significant expansion and listing of
   projects with running code and self-organisation.

   Several Open Source projects have running code and partially
   implemented the above four scenarios.  We will briefly list them
   here.

   [TOR] A free software implementation of second-generation onion
   routing, a system enabling its users to communicate anonymously on
   the Internet.  This flagship project has boosted online anonymity for
   over a decade and the key example for the cat and mouse dynamics.
   The Orbot project provides an Android implementation of Tor. Due to
   the usage of the client server/model, exit node principle plus lack
   of reputations this architecture is not compatible with our
   scenarios.

   [DIASPORA] A free personal web server that implements a distributed
   social networking service.  This partially operational system is
   based on the client/server model and not compatible with our ad-hoc
   scenarios.

   [BRIAR] Briar is a secure news and discussion system designed to be
   used by journalists, activists and civil society groups in
   authoritarian countries.  Briar differs from existing circumvention
   tools and mesh networks in three significant ways: needs no external
   infrastructure, can operate over any mixture of available media and
   builds on social relationships.  The aims of this project are similar
   to our scenarios, but this project lacks running code and has few
   active developers.

Pouwelse                Expires January 17, 2013                [Page 9]
Internet-Draft                 CensorFree                      July 2012

   [TRIBLER] DISCLAIMER2: this project is coordinated by the author.
   This project has created Open Source firmware for a Samsung Internet-
   connected television which gives it the ability to find, share and
   stream news videos within a fully self-organising overlay; operated
   only by remote control [REBELLIONTV].  It is also available as
   generic zero-server file sharing software for the PC which has been
   installed by 1.2 million users.  It uses the Dispersy elastic
   database for providing: keyword search, content discovery, content
   voting and spam prevention using crowd sourcing [DISPERSY].  For
   swarm-based streaming and generic message transport it uses the IETF
   protocol developed within the PPSP working group, called Libswift
   [LIBSWIFT].  All this code is created by a single team and
   specifically designed to facilitate evolution into the four described
   scenarios.  An Libswift demo streaming app is available on the
   Android market.

8.  What to include in a draft?

8.1.  Gap between scenarios and existing work

8.2.  Architecture and protocol messages

8.3.  Text encoding and media containers

9.  Security Considerations

   tbd.

10.  IANA Considerations

   tbd.

11.  References

11.1.  Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [RFC4787]      Audet, F. and C. Jennings, "Network Address
                  Translation (NAT) Behavioral Requirements for Unicast
                  UDP", BCP 127, RFC 4787, January 2007.

   [RFC4838]      Cerf, V., Burleigh, S., Hooke, A., Torgerson, L.,
                  Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-
                  Tolerant Networking Architecture", RFC 4838,

Pouwelse                Expires January 17, 2013               [Page 10]
Internet-Draft                 CensorFree                      July 2012

                  April 2007.

11.3.  URL References

   [NKOREA]       http://audiencescapes.org/sites/default/files/
                  Report_Summary_Quiet_Opening_North%
                  20Korea_InterMedia.pdf, "A QUIET OPENING: NORTH
                  KOREANS IN A CHANGING MEDIA ENVIRONMENT".

   [EGYPTSTUDY]   http://conferences.sigcomm.org/imc/2011/docs/p1.pdf,
                  "Analysis of country-wide internet outages caused by
                  censorship".

   [OPENMICRO]    http://xmpp.org/extensions/xep-0277.html, "XEP-0277:
                  Microblogging over XMPP".

   [BOOTSTRAP]    http://grothoff.org/christian/dasp2p.pdf,
                  "Bootstrapping Peer-to-Peer Networks".

   [ZEROKNOW]     http://www.cse.ust.hk/~liu/luli/PT_Trans_final.pdf,
                  "Pseudo trust: Zero-knowledge based authentication in
                  anonymous peer-to-peer protocols".

   [CAPLIMIT]     http://doi.ieeecomputersociety.org/10.1109/MC.2012.54,
                  "The CAP Theorem's Growing Impact".

   [LEVELS]       http://blog.incubaid.com/2012/03/28/
                  the-game-of-distributed-systems-programming-which-
                  level-are-you/, "The Game of Distributed Systems
                  Programming. Which Level Are You?".

   [TOR]          http://www.torproject.org, "Tor Project: Anonymity
                  Online".

   [DIASPORA]     http://diasporaproject.org/, "Diaspora is a fun and
                  creative community that puts you in control.".

   [BRIAR]        http://briar.sourceforge.net/protocol-spec.html,
                  "Briar: A Secure News and Discussion System".

   [TRIBLER]      http://dl.acm.org/citation.cfm?id=2206767, "Tribler:
                  P2P search, share and stream".

   [REBELLIONTV]  http://www.tribler.org/trac/wiki/SwiftTV, "RebellionTV
                  a.k.a. Libswift on a television project".

   [DISPERSY]     www.frayja.com/pub/
                  dispersypaper2012.pdf:donotdistribute, "Dispersy

Pouwelse                Expires January 17, 2013               [Page 11]
Internet-Draft                 CensorFree                      July 2012

                  elastic database".

   [LIBSWIFT]     http://www.libswift.org, "IETF PPSP streaming protocol
                  implementation".

Author's Address

   Johan Pouwelse (editor)
   Delft University of Technology
   Mekelweg 4
   Delft
   The Netherlands

   Phone: +31 15 278 2539
   EMail: J.A.pouwelse@tudelft.nl

Pouwelse                Expires January 17, 2013               [Page 12]