Please use this page to discuss potential threats to web 2.0 election monitoring in general and the Twitter Vote Report in particular -- as well as potential responses. For background, please read Tracy Viselli's Political Activism on Twitter: The Story of #dontgo (describing organized interference with a Twitter activism campaign); Sarah Lai Stirland's Ohio Secretary of State's Office Hacked (illustrating the lengths people are going to disrupt the 2008 election); and the Texas deceptive emails incident description on the Voter Suppression Wiki, where the comment describes a blended online/in-person attack.
Reporting false information
- with a goal of triggering false alarms about incidents
- with a goal of invalidating or discrediting overall results
- with a goal of flooding the channel and overwhelming people with data
Comment: we won't be building in any authentication mechanism so we should expect some of this. What are the processes for verifying alerts before sending them out? What caveats do we want to give to media who are covering the live feeds? Can we detect some patterns of abuse (e.g., "rogue SuperTwitterers"?)
Denial of service
- on Twitter
- messages
- overwhelming search/API functionality
- on the database server (bandwidth or CPU)
Comment: the first step is to estimate likely load as part of a capacity plan, and then look at opportunities for automated attacks. The best approach will be to have alternative mechnisms in place and identify up front what levels of load should trigger moving to backups.
Comments (1)
Billy Gray said
at 7:19 pm on Oct 21, 2008
I'd say that we'll have some kind of model/table for users, although not in the traditional sense. Maybe call it 'people'. But basically do just-in-time creation when we receive a message from someone that creates an identifying row. Maybe the identifier is a phone number in the case of SMS messages via Mozes, we can use the twitter_id & twitter_login for those folks. And each row has a boolean flag like needs_review or is_questionable.
If we receive a certain volume of messages from a user, or a certain rate, we keep bringing the messages in but flag the user row. Then when we run reports on data we can join against this user model and optionally exclude 'questionable' sources. Meanwhile, we can have a report of questionable sources, and someone can check them out, look at the submitted messages, review the time stamps, rate, location information, attempt to corroborate or even contact the user, and then un-flag the user, or mark the source as verified.
You don't have permission to comment on this page.