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