P2P Widgets

Goal is to generalise the notion of a plugin, widget, and mashup within a zero-server P2P architecture.

Status: initial design and [source:abc/branches/boudewijn/widget/Tribler 1st lines] of code

Key to !P2PWidgets is the zero-server requirement for the whole software directory listing and software distribution plus update process. !P2PWidgets have access to four types of information: social network information, web 2.0 information, other running P2PWidget instances, and Bittorrent content. Our leading examples are Facebook for their directory listing and rating of widgets, Sourceforge which facilitates an active developers community, and Greasemonkey which provides a generic mashup solution.

In short, evolutionary biology is applied to a software ecosystem.

Support for P2P widgets or modules/plug-ins

  • Define P2P widgets API
  • Create several P2P widgets as examples
  • Include a repository of P2P widgets
  • Open Source only

Combining Web 2.0 with P2P:

Expanding the plug-in model towards greasemonkey, pipies, widgets... User-programmable!

P2PWidget architecture:

  • Storage of MP3/AVI/JPG using Bittorrent/Tribler
  • Communicate across an overlay with equal P2PWidgets
  • Access to social network
  • Website integration with Greasemonkey
  • HTTP/RSS/FTP

​http://azureus.sourceforge.net/plugin_list.php ​http://www.facebook.com/apps/ 15000+ apps ​http://en.wikipedia.org/wiki/Greasemonkey ​http://www.lifehack.org/articles/productivity/top-10-greasemonkey-scripts-to-improve-your-productivity.html 10.000+ scripts: ​http://userscripts.org/scripts/show/22639 ​http://pipes.yahoo.com/pipes/pipe.info?_id=7hu75gzd2xGcqdSolfXiAA ​http://www.google.com/ig/directory ​disruptive

Screenshot of prototype

Thesis

Planning

Subject Deadline
First prototype of built-infrontpage stats widgets Mid januari
First prototype of WidgetCast for widget swarm creation/code distribution --
Creation of widgets using WidgetCast to communicate --

prototype Runtime Design

Widgets extend the TriblerWidget class, which is basically a wx.Panel. They can do whatever they want on the panel.

WidgetRegistry has a Panel where Widgets can be added, moved and resized. It wraps widgets in a WidgetWrapper which creates the titlebar e.d. The registry keeps track of the widget instances.

Widget examples

Widget Functional requirement Comments
Fronpage Stat widgets
Top X most popular torrents Read access to TorrentDB
Top X contributors Read access to BarterCastDB
Top X similar friends Read access to FriendDB, PeerDB
Top X moderators Read access ModeratorCastDB
X newest torrents Read access to TorrentDB
Filter widgets
Subscription TorrentDB, storage for subscribes peers subscribe to another peer to be alerted when he publishes new content
Filter widget TorrentDB, storage for filter strings Display content that conforms to a filter
Social widgets
ShoutCast Intra-Gossip functionality+local storage Show messages other users left
FriendChat Direct Peer-to-Peer communication, storage for messages, storage for friends Select a friend (or peer) and start chatting
Mashup widgets
Mashup WidgetCast, access to WEB, storage for content Subscribe to RSS feed/website-scrape either from website or generated by a peer. Peers cooperate to disseminate messages

Notulen 5 maart

Long term:

  • Discovery: deep integration
  • install
  • display
  • 2-4 examples
  • API documentation: Widget skeleton, GUI, Tribler API (notifications)
  • BuddyCast: # unique installs seen, installed

Security measures

  • Torrent Collecting policy:
  • auto download next widget download: max ( median ( # unique installs seen))
  • whitelisting

Whitelisting

There are multiple methods of whitelisting. Proposal:

  • Several peers are trusted "initially"
  • They create whitelist certificates, saying that "trusted peer x" whitelists "peer y" (with a signature)
  • format: whitelist{signer: PERM_ID, subject: PERMID, signature: SIGNATURE}
  • Everybody gossips the certificates and either whitelists the subject (if signer is trusted and signature is verified) or does not

Methods of gossiping:

  • (easy) include field in buddycast which adds 1-3 random whitelist certificates
  • (more difficult) include field in "random peers" and "taste buddies" saying whether we have a certificate for them. Other peer then selects a certificate it wants.

Simulation A simulation would be handy to verify several things:

  • Check whether the distribution of widgets is robust and secure. (Are the real popular widgets downloaded first, even when some peers lie about the 'tribler_sources_seen'. Check various fucntions of ppopularity calculation
  • Check whether the easy whitelisting method works well..

Papers

Name Link
Ipoque internet study 2007 ​http://www.ipoque.com/userfiles/file/internet_study_2007.pdf

Research assignment

status: finished research assignment by Delft msc student Alain van den Berg

report: Research Assignment P2PWidgets

Draft list of topics to find 20+ scientific publications on P2PWidgets

  • User-generated code
  • security and sandboxing
  • Deployed widget systems and algorithms (still client/server)
  • Zero-server Repository of widgets and discovery algorithms
  • DDoS, Malware and Spyware prevention
  • ​Existing Python frameworks

Research

Deployed widget systems

  • Eclipse (Plugin engine + plugins, Extensions & Extension points)
  • Google Desktop Gadgets
  • Youserve (P2P!)
  • Spamato (List required plugin permissions explicitly)
  • Facebook apps
  • Greasemonkey scripts

interesting points:

  • central site to find widgets.
  • category based
  • reputation per widget author (Google Desktop Gadgets)
  • comments (with rating) on widgets
  • Top Rated, Newest, Most Active widgets...
  • Documentation about the Widget API! (P2PWiki ?)

Zero-server Repository

The main goal of a zero-server repository is be able to store widgets without one single server and to be able to find them. For a zero-server widget repository, other aspects play a role, like the ones in a centralized widget repository (Metadata):

  • Security measures (Reputation system)
  • reputation system: ratings and comments
  • categorize widgets (tags) (metadata)
  • Thus, metadata management
  • Find updates for widgets
  • Pollution prevention

Update management:

  • ​uuids to identify a widget (hash wouldnt work!)
  • epidemic protocol

Storage of comments:

  • Most current P2P systems use a DHT to store and retrieve comments on torrents/files.

Distributed storage:

  • Project Cassandra (P2P Bigtable)
  • DHT (e.g. Khashmir) Drawback: only exact matches. Prefix Hash Trees.
  • Chord
  • Pastry
  • Gossiping/epidemic protocols

Security and sandboxing

Without prevention, P2P widgets give easy access to creation of malicious widgets. Normal widget systems have a centralized repository where the widgets are stored for downloading. With moderators checking submitted plugins, the plugins which can be downloaded are already checked.

In a P2P Widget repository without security measures, everyone would be able to submit their (malicious) widget and everybody could directly download and use it.

Threats

Prevention:

  • Code signing
  • List permissions required and block everything else
  • Security policies
  • warn user that it is running 3rd party
  • Social Sandbox: Reputation system for widgets or authors.
  • Restrict the scripting language

Restricted execution of widget code

Running widget code in a restricted mode would require things like editing the source code to make sure it doesn't execute malicious things (compile time, like RestrictedPython) or interpret the language (Python or another scripting language) and make sure the interpreter doesn't execute malicious code (runtime).

Current restricted execution environments are mostly restricting access to for example the file system, sockets, IO components. Another form of restricting the widget is Resource Limitation, which would prevent the widget from taking all CPU, internet access (to be used by a DDoS attack for example)

Restrict python:

Other scripting languages

Other scripting languages would require an interpreter which restricts the language to some sort.

  • Javascript
  • Lua

Related work

Deployed widget systems papers

P2P Sharing of Web Applications R. Bayardo et al IBM Research Report RJ10268
Eclipse Technical Overview Object Institution Inc. --
Spamato Plugin Report Remo Meier Semester Project report

Zero Server Repository Papers

Directory service

A survey of peer-to-peer content distribution technologies Stephanos Androutsellis-Theotokis et al ACM Comput. Surv.
Survey of Research towards Robust Peer-to-Peer Networks: Search Methods John Risson et al Tech Report
Dl meets p2p - distributed document retrieval based on classification and content Wolf-tilo Balke et al In ECDL
PlanetP: using gossiping to build content addressable peer-to-peer information sharing communities Cuenca-Acuna et al Proc. 12th IEEE International Symposium on High Performance Distributed Computing
Peersearch: Efficient information retrieval in peer-to-peer networks Chunqiang Tang et al In Proceedings of HotNets-I, ACM SIGCOMM
Distributed object location in a dynamic network Kirsten Hildrum et al SPAA '02: Proceedings of the fourteenth annual ACM symposium on Parallel algorithms and architectures

Reputation systems

Trust and Reputation Model in P2P Networks Wang et al Proc. Third International Conference on Peer-to-Peer Computing (P2P 2003)
Reputation in p2p anonymity systems Roger Dingledine In Workshop on Economics of Peer-to-Peer Systems
The Eigentrust algorithm for reputation management in P2P networks Kamvar et al 12th WWW conference
A social mechanism of reputation management in electronic communities Bin Yu et al In Proceedings of Fourth International Workshop on Cooperative Information Agents
On Distributed Rating Systems for Peer-to-Peer Networks YE TIAN et al COMPUTER JOURNAL 2008, VOL 51
PeerTrust: supporting reputation-based trust for peer-to-peer electronic communities Li Xiong et al IEEE Transactions on Knowledge and Data Engineering, 2004, 16
The Design of A Distributed Rating Scheme for Peer-to-peer Systems Debojyoti Dutta et al In Workshop on Economics of Peer-to-Peer Systems

Security Papers

DDoS

Exploiting P2P systems for DDoS attacks Naoum Naoumov et al InfoScale '06: Proceedings of the 1st international conference on Scalable information systems
DDoS Attacks using P2P Networks Kohli et al --

Pollution

Content Availibility, Pollution and Poisoning Christin et al ACM E-Commerce Conference
Pollution in P2P File Sharing Systems J. Liang et al IEEE Infocom

Malicious Code

Attacking malicious code: a report to the Infosec Research Council McGraw, G. et al IEEE Software
Mobile code security Rubin et al IEEE Internet Computing
Project transprose: Reconciling mobile-code security with execution efficiency Wolfram Amme et al In DARPA Information Survivability Conference and Exposition

Proof Carrying code

Trust Management and ProofCarrying Code in Secure Mobile-Code Applications Joan Feigenbaum et al In DARPA Workshop on Foundations for Secure Mobile Code Workshop. DARPA
Proof-carrying code George Necula POPL '97: Proceedings of the 24th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Research on Proof-Carrying Code on Mobile-Code Security Peter Lee and George Necula Proceedings of the Workshop on Foundations of Mobile Code Security

Sandbox model/Security Policies

Specifying runtime environments and functionalities of downloadable components under the sandbox model Kaiya, H. and Kaijiri, K. Proc. International Symposium on Principles of Software Evolution
Usable Security Policies for Runtime Environments Almut Herzog et al Thesis

Attachments