Hiya, I just had a v. quick look at the draft. It looks like the changes are mostly minor enough detailed additions. Can you summarise what's changed/new since Vancouver?
Thanks, Stephen. On 10/25/2012 06:31 PM, Johan Pouwelse wrote: > Dear All, > Anyone interested in attending a side meeting, to be organised in > Atlanta (IETF 85)? > > Topic: privacy enhancing technology, focused on smartphones and > microblogging > Title: "Media without censorship" > Date: 19:30 Thursday, November 8, 2012 (tentative, pending room > availability etc) > Goal: seek feedback, measure level of interest and see if a future > BoF is realistic > > The IETF Journal has just published a 2-page description of this > initiative: > http://www.internetsociety.org/articles/moving-toward-censorship-free-internet > > 18-page writeup of motivation, overview&scenarios: > https://datatracker.ietf.org/doc/draft-pouwelse-censorfree-scenarios/?include_text=1 > > There was a prior Bar BoF on this topic held last August in Vancouver. > We had some press attention, like: > http://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FIETF-diskutiert-Netz-Standards-gegen-Zensur-1660244.html > Martin Stiemerling was even quotes there as saying this was "Very > interesting" and very "constructive" :-) > > Numerous groups work on this topic, little interaction exists, > documentation and common terminology is lacking. > If people are interested I would like to briefly demo the work of > others and our own running code in this proposed gathering. > > Given the luxurious staffing of my university research team we now > have running code of several building blocks for privacy enhancement. > This allows discussion about desired architecture and approaches based > on real-world prototyping experience. On Android market for IETF 85: > - Transfer a video file between two Android phones, *without* the > receiver having any special app installed. > Uses NFC initiation of data transfer and Bluetooth handover > (enabled by default on V4.1 Android). > (scenario 3 building block: > http://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios-02#section-4.3) > - Live streaming with an Android app, stream phone camera feed to > other phones using IETF PPSP WG draft peer protocol, uses no central > server, pure P2P > (scenario 1 building block: > http://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios-02#section-4.1) > - Record a video on a smartphone and includes one-click playable URL > in a Twitter.com message, without requirement of any central server > Record a video from app, create hash check, seed content from > phone (PPSP compliant on-demand streaming) > (scenario 1 building block) > - Plus we now have M2Crypto experience on Android > > Below are the meeting notes from the Last Aug Vancouver meet. > > Looking forward to any feedback you might have on this or even > attending this suggested meeting. > > Greetings from Holland, Johan. > > ######## side meeting notes by Johan Pouwelse ######## > Participants present at bar BoF: 25+ > People indicating willingness to participate, but had agenda conflicts: 5+ > > Overall there was a lively discussion going on for over an hour. The > diverse audience represented a wide range of backgrounds and > expertise. From security to networking, students to professors and > area director to decades-long IETF participants. > > Numerous attendants had read the initial discussion I-D document. > Numerous questions and lack of clarity was ventilated. First, > essential need for improvement is making the implied threat models > explicit. It was unclear what the capability are of the adversaries. > The context and model of information transport was not clear. > A discussion emerged about the security of the physical layer. Nothing > can be accomplished if trust is absent even in the physical layer. A > common understanding was that news is created in a region without > freedom and then needs to travel to the outside world. No term was > defined during the discussion, for clarity, we will refer to this > simplistically as the freedom/non-freedom border. Different transport > protocols, dynamics and different solutions are needed on the two > sides of this border. > > A second item was that the use cases (scenarios) need to be more > clearly defined. Specifying exactly what problem is to be solved. > Third, it was unclear why existing technology was not sufficient to > meet the described demands. The example proposed was the tor onion > network in combination with XMPP or the orbot smartphone app. After > much discussion the conclusion was that existing technologies, such as > tor facilitate protected point-to-point communication. However, > possible desired use cases focus more on current Twitter-like social > media practices, best typified as a "global conversation". > Furthermore, current social media revolves around video-rich, > real-time interaction with groups, hashtag-based discovery and social > networking. All of these aspects are not offered or are incompatible > with current-generation of privacy enhancing technology. A discussion > emerged on reputation models in news reporting and information flows. > In the current microblogging age, does the number of real-person > followers be seen as your reputation. The question publicly posed was > roughly: do several news sources of moderate reputation which report > the same news story yield together a different reputation score > > At this point in the discussion, a summary was given (Lucy?) > introducing the "transmorf" principle. The identities used in Twitter > are highly identifiable labels, with a certain trust level. This hard > identity with millions of followers is a stark contrasts with > anonymity. It was concluded that lacking in current anti-censorship > technology is the ability to first have stealth encrypted transport of > news, cross the freedom/non-freedom border and then transmorf this > news into a public accessible form with a highly identifiable label. > This relates closely to 2nd stage verification of news. > Discussion arose around the lack of motivation for the smartphone app > focus in the scenario I-D. The requirements and solution space need to > be separated. > It was noted that the strong point of the IETF lies in describing > architectures and protocols. > Finally, a first stab needs to be done at defining various components. > What are the major chunks of functionality that need to be addressed. > Supporting area director Martin Stiemerling asked who would be willing > to help write documents. Several people responded. Next step was > forming a mailinglist. Given the nature of this problem, it was > discussed if either EITF or IRTF where appropriate for this activity. > > Four documents to move forward: > Use cases and threat model > System components, definitions and system architecture > Current technology and gap > Detailed system design and protocol specification > > Scenario: no control points, everything is capture proof. > > ########Notes by Ronald In 't Velt####### > > Q: why isn't TOR + XMPP sufficient for what you want? > > Q (R. Bush): What is the threat model? > > Martin: ultimately, personal judgement > > Kevin Fall: intermixing problems and solutions > > use cases > > Kevin Fall: responded because DTN was mentioned > > ?: multiple distribution modalities > > separate into 2 problems: 1. transport 2. content > > send out anonymously, identified as highly reliable and redistributed > > KF: dynamic provenance > > distributed reputation systems > > multiple not-that-reliable sources adding up > > Martin: too big for IETF? IRTF group? > > scenarios, threat model, architecture, gap analysis > > Lucy: related work going on in W3C > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy > > _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
