The Buddy System : A Distributed Reputation System Based on Social Structure

1. The Buddy System : A Distributed Reputation System Based on Social Structure Universität Karlsruhe Workshop “Get Connected to the Mobile World - Data Management in Mobile Environments” September 21, 2004 – Ulm, Germany Stefan Fähnrich1, Philipp Obreiter1, Birgitta König-Ries2 1Universität Karlsruhe Institute for Program Structures and Data Organization 2Technische Universität München Faculty of Computer Science http://www.ipd.uni-karlsruhe.de/DIANE

2. Need: 2b Offer: 1a 2b Need: 2a Offer: 1a 1a Need: 2a Offer: 1a Need: 2a Offer: 1a 2a x Motivation: Students preparing their exercises Amy solved: 1a Bob solved: 2b John: Nothing solved Peter solved: 2a,b

3. Warning x Distributed Reputation System What if Amy doesn‘t know Peter??? Amy Bob Need: 2a Offer: 1a 2a John Peter

4. 1) Assement - many informations needed - trust calculation depends on trust towards recommender 2) Self-recommendation - not possible 3) Dissemination of information - no control over dissemination - could lead to bias Limitations of the existing Reputation System

5. Verification Warning Bails:X,Y,Z Distributed Reputation System with Social Structure Amy Bob Need: 2a Offer: 1a 2a Peter John

6. Design Space and Design Decisions for the Buddy System Evaluation Summary & Outlook Overview

7. Design Space Relationships (I) N-ary bilateral multilateral Direction directed mutual Type trust, distrust, bail,… Design Decision (I) bilateral mutual bail (buddy) Design Space and Decision (I): Relationships

8. Design Space (II) Establishment Criterion: various group rules Procedure: majority, 100% agreement Cancellation group agreement with notification timeout bilateral immediate, lazy, third party mediation Design Decision (II) Establishment Criterion: same world views Procedure: simple agreement Cancellation lazy cancellation third party mediation Bob Bail: John verify notify Yes, notify OK John Peter Design Space and Decision (II): Dynamics

9. 1) Assessment of recommendation - Bails higher trusted - Number bails as a clue for trust 2) Self-Recommendation - possible by stating number of bails 3) Dissemination improved - more effective (through self-recommendation) - controllable Why Social Structure?

10. Evaluation Goals improvement through social structure can social structure itself be exploited? Simulation Setting: DIANEmu IBR2 Benchmark Evaluation

11. Thesis: Colluders are discovered effectively I) Evaluation • Conclusion: Colluders have least gain - Robustness granted

12. Thesis: Performance increased independent from setting II) Evaluation 25% regular • Conclusion:Thesis verified - still too many vicious entities destroy usabilitiy

13. Newcomers and Messages • Thesis: Improved performance for newcomers • Defection rate decreased from 70% to 40% • Conclusion: Thesis verified • Thesis: Increase of messages through maintenance is lower than total messages saved. • Total number of messages decreased by 20% • 50% less recommendation messages • maintenance overhead low • Conclusion: Thesis verified

14. Summary A distributed reputation system is necessary to uphold usability of the whole system conventional distributed reputation system have inherent limitations with a social structure those limitations can be overcome Buddy System introduced as a distributed reputation system with mutual, pair-based social structure. Evaluation of the Buddy System Future Work Evidences (certificates for buddies) Noise Summary & Outlook

15. Any Questions ??? ... http://www.ipd.uni-karlsruhe.de/DIANE

16. Messages

17. Newcomers

18. Contract Contract Action Requester Requestee Action Receipt Receipt 6-way Protocol

19. Each Entity has a personal list of friends and foes (and suspected foes) Friends and foes lists are exchanged, but only used as simple recommendations Directed relationships No Self Recommendations possible No explicit social structure formed Friends & Foes

20. Certificates are possible with public key exchange gradual exchange not always possible still „last step“ problem The problem of defection alone can not be solved by a transaction protocol Security & Transaction Protocol

21. IBR2 Benchmark

22. Certificates are possible with public key exchange gradual exchange not always possible still „last step“ problem The problem of defection alone can not be solved by a transaction protocol Security & Transaction Protocol

23. Certificates are possible with public key exchange gradual exchange not always possible still „last step“ problem The problem of defection alone can not be solved by a transaction protocol Security & Transaction Protocol

24. Certificates are possible with public key exchange gradual exchange not always possible still „last step“ problem The problem of defection alone can not be solved by a transaction protocol Security & Transaction Protocol

25. Certificates are possible with public key exchange gradual exchange not always possible still „last step“ problem The problem of defection alone can not be solved by a transaction protocol Security & Transaction Protocol