Ostra: Leveraging trust to thwart unwanted communication

1. Ostra: Leveraging trust to thwart unwanted communication • A. Mislove, et al. • Offense - Marcel Flores

2. A noble goal • Seek to reduce unwanted messages • A good thing! • Minimize incorrect classification • Hey! They are aiming for the holy grail of spam filtering!

3. First, lets consider... • What does a user actually want? • Something invisible • Something that doesn’t ever prevent them from functioning • Simplicity

4. First, lets consider... • What can we expect from a user? • Nothing! • Systems already in place that require little to no regular input, users expect at least as good

5. The System • Trust network requirements • “Non-trivial cost of initiating and maintaining links in a network” • “Cannot acquire new relationships arbitrarily fast” • “Cannot maintain arbitrary number of relationships”

6. Many networks eliminated! • Many networks already do not meet these requirements • Hard to draw trust networks in an environment like Facebook or MySpace, where users are generally laid back in their acceptances of friend requests

7. Limitations... • “Thus, Ostra can be used only in conjunction with an ‘invitation-only’ social network” • Since it requires established trust links for anyone to begin sending and receiving • Not a feasible requirement for many services (email?)

8. Limitations... • “Users with few links in the trust network are more susceptible to credit exhaustion…” • Forces new users to “work” to be able to properly use the service! • Users also potentially have to deal with yet another layer of “approvals” and “invitations”

9. Experimental Network • Used a YouTube crawl • YouTube doesn’t meet the trust based requirements! • Do some analysis to patch this... • Also find users with degrees that are too high • This is not good data!

10. Workload Data • Again, cannot obtain necessary data, are forced to make assumptions about usage patterns • Provide reasonable explanation - still leaves me wondering if the data is particularly representative of any other networks

11. Results • Find Ostra to do a great job of bounding the amount of unwanted communication! • Users are still left with another layer of complexity • Can this work out in the “wild” • Issues of user participation

12. Generalization • Requires Ostra to be distributed • Built into every application that uses it? • Are users going to need to install and configure it? • Are either of these reasonable options?

13. Complexity • Ostra is very complex • Upper bounds, lower bounds, credit balances, reserved credits, penalty credits, etc. • How does it perform with mass failure? • Could it damage a network?

14. Conclusion • Ostra is powerful and effective • However... • It is complex • It is another layer that users or developers would have to wade through • Seems inapplicable to many situations (especially when there is nothing to readily adapt to a trust network)

15. Maybe another approach? • While effective, the previously mentioned problems make Ostra not-so-feasible • Perhaps this approach is not good • For it to be truly applicable to the most desired systems (email), must be able to function independent of other users