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

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

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

4. Limitations of the existing Reputation System 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

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

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

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

8. Design Space and Decision (II): Dynamics 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 John Bob Peter verify Yes, notify Bail: John notify OK

9. Why Social Structure? 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

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

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

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

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 & Outlook 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

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

16. Messages

17. Newcomers

18. 6-way Protocol Contract Action Receipt RequesterRequestee

19. Friends & Foes 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

20. Security & Transaction Protocol 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

21. IBR2 Benchmark

22. Security & Transaction Protocol 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

23. Security & Transaction Protocol 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

24. Security & Transaction Protocol 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

25. Security & Transaction Protocol 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