Team Sports Problem Statement

Submitted To:

Dr. Tracy Wuster

Prepared By:

Cassidy Burden

Leelabrindavanan Karunakaran

Robert Ly

Ross McNulty

Sneha Shrotriya

EE333T Team Project

Electrical and Computer Engineering Department

The University of Texas at Austin

Spring 2015

ii

TABLE OF CONTENTS

FIGURES .......................................................................................................................... iii

1.0 INTRODUCTION........................................................................................................1

2.0 PROBLEM DEFINITION ..........................................................................................2

2.1 Problem Background and Technical Premise ...............................................2

2.2 Client and User Needs Analysis ......................................................................2

2.3 Ethical Considerations.....................................................................................4

2.4 Product Deliverables ........................................................................................5

3.0 DESIGN SPECIFICATIONS .....................................................................................5

3.1 Input and Output Specifications.....................................................................6

3.2 User Interface Specifications ..........................................................................7

3.3 Key Environment Specifications ....................................................................8

3.4 Key Performance Specifications and Test Criteria ......................................8

4.0 PROPOSED DESIGN SOLUTION ...........................................................................8

5.0 CONCLUSION ..........................................................................................................12

REFERENCES .................................................................................................................14

APPENDIX A ................................................................................................................ A-1

iii

FIGURES

Figure 1: Objective Tree ................................................................................................. A-1

Figure 2: Input Output Diagram ..........................................................................................6

Figure 3: Google Landing Page ...................................................................................... A-2

Figure 4: Yahoo! Landing Page ...................................................................................... A-2

Figure 5: Functional Block Diagram .............................................................................. A-3

Figure 6: User Interface Module ........................................................................................10

Figure 7: Basic UI Mock Up ........................................................................................... A-5

Figure 8: Filtering Screen Mock Up ............................................................................... A-6

Figure 9: Confirmation Screen Mock Up ....................................................................... A-7

Figure 10: Data Acquisition Module .................................................................................11

Figure 11: Deletion Module ...............................................................................................12

Figure 12: Platform Interface Module ...............................................................................13

1

1.0 INTRODUCTION

This report describes the planned functionality and consumer need for Team Sports’ browser

extension, Social Shredder, to automate and streamline deletion of user data across social media

platforms. Social media platforms make deleting a large number of posts difficult and time

consuming. We have targeted teens and young adults as our main audience because they have

substantial amounts of data online they wish to remove for privacy, popularity, and professional

reasons. Social Shredder will be a browser extension that allows users to delete content from our

target platforms: Facebook, Google+, Instagram, Reddit, and Twitter. We will improve upon

existing data removal solutions by creating a single hub for data deletion across multiple social

media platforms, letting users customize which posts are deleted through filtering features, and

allowing users to set automatic recurring deletions.

We begin this report by defining our problem through the background and technical premise,

client and user needs analysis, ethical considerations, and product deliverables. The background

and technical premise section identifies slowness and lack of precision as shortcomings of

current data removal applications. The client and user needs analysis section selects teens, who

will use our application to delete unpopular posts, and young adults, who will use Social

Shredder to create a professional social media presence, as our main users, and describes the

application from a non-technical perspective. The ethical considerations section identifies ethical

constraints as adhering to rate-limiting rules, abiding by terms of use for our targeted platforms,

and ensuring automation is in line with human intent. Finally, in the project deliverables section

we describe our deliverables as a browser extension, documentation, and final presentations and

papers for Senior Design.

The team specifies design requirements and constraints by defining inputs and outputs, user

interface, environment, and performance and test criteria for Social Shredder. For this

application, we describe the inputs as user authentication, data filtering, deletion confirmation,

and the outputs as platform limitations and warnings, deletion status, deletion confirmation, and

deletion of data. In the user interface section, we outline the importance of our defined inputs and

outputs interacting in a clean user interface. To ensure our application works in performance and

2

test criteria, we describe automated tests that post and delete data in bulk, use filters for post

deletion, and test periodic deletion across various social media sites on multiple browsers.

We establish the functionality of our proposed design’s User Interface, Data Acquisition,

Deletion, and Platform Interface modules in a functional block diagram. The User Interface

module facilitates all communication between the user and all other modules by collecting

platform login information, filters for post deletion, and deletion approval and by displaying

deletion progress. The Data Acquisition module aggregates posts to delete based on filters

provided in the User Interface module, which the Deletion module deletes. The Platform

Interface module processes all Application Programming Interface (API) calls necessary for

interaction with social media platforms. These modules adhere to rate-limiting rules, meet the

Terms of Service of all target platforms, and allow users to tailor and customize the deletion

process to enhance user control over privacy.

2.0 PROBLEM DEFINITION

In this section, we define the motivation, the technical premise, client and user needs, objectives,

deliverables, design functionality, and ethical considerations for this project. Our project

motivation is to provide an effective solution for our main target audience, teens and young

adults, to easily manage their online content across multiple social media platforms. Existing

solutions, such as Absterge for Facebook and TwitWipe for Twitter, have drawbacks such as

slow run times, a lack of keyword and time filters, and no cross-site integration which prevent

these applications from fully addressing our target users’ needs [1, 2]. From the user’s

perspective, the application will be easy to install, simple to use, and customizable. In order to

meet legal and ethical standards with our design, our application must use APIs and confirm with

users before deleting posts. Our deliverables will consist of a browser extension, application

documentation, an oral report, and a final paper. We have identified ease of use, adherence to

legal and ethical standards, and inclusion of features for our target audience as the most

important criteria for project success as shown in our objective tree in Figure 1 of Appendix A.

3

2.1 Problem Background and Technical Premise

Teens and young adults are our main audience because they frequently use social media and

scatter their information across multiple platforms [3], which makes managing their privacy

difficult and time consuming. Users often delete content from their social media accounts to

protect their privacy [4], and some users can spend up to 12 hours deleting content by hand [5].

Manual removal of online personal data is tedious and does not provide a method for filtering

posts easily. Some platforms have official methods for deleting entire user accounts, but these

methods can lead to deletion of crucial information and can hinder personal and professional

communication. Additionally, users expect deletion to leave no trace of their data, but the

“delete” button usually serves to hide data than to remove it. For instance, Reddit stores

comments on their servers even after deletion, but they do not store histories of comment edits

[6]. We will inform users of deletion limitations when our application is unable to remove data

completely.

Our data deletion application will improve upon the scope and functionality of existing data

removal processes by targeting multiple platforms, supporting additional filtering criteria, and

addressing rate-limiting constraints. Currently, solutions to automate data removal are tethered to

one platform, while our solution will consolidate deletion protocols across multiple platforms.

Absterge for Facebook, the solution with the most search functionality, filters data by status,

comments, likes, or photos [1]. Social Shredder will also filter data by type but will improve

upon this design by supporting keyword and time-based filters. Rate limiting is the process in

which social media platforms restrict access to automated applications by limiting the frequency

of API interaction [7]. Absterge adheres to Facebook’s rate limiting and achieves a running time

of 2-3 hours, but TwitWipe can have a running time that spans several days [2]. We must

consider rate-limiting rules across all target platforms before our team can determine the running

time of Social Shredder, as our application will target multiple platforms.

2.2 Client and User Needs Analysis

To define our design functionality requirements, we have identified maintaining popularity and

professionalism as the main needs of our target users. According to the Pew Research Center,

4

teens delete posts with fewer likes and retweets, and adults delete posts that show lack of

judgement [3]. College students, job holders, and job hunters would use Social Shredder to tailor

their profiles for employment opportunities by removing disparaging posts about potential

employers and embarrassing posts from their past. Job holders that are conscious of their social

media presence will want to remove data frequently, but not all people will want to delete the

same types of posts [8]. Therefore, college students, job holders, and job hunters would use our

data removal application to manage and tailor their profiles.

A favorable user interaction would require supporting multiple social media platforms, filtering

posts for deletion, and periodic deletions as seen in the objective tree. Our project will allow

users to delete personal data across multiple social media platforms by installing a browser

extension, linking social media accounts, and setting up data filters. The detailed walkthrough of

our design functionality below indicates that an easy-to-use application must have a clean user

interface, provide easily modifiable settings, and be easy to install as stated in the objective tree.

Users will install our browser extension on Chrome, Firefox, or Safari

Users will link their social media accounts to the browser extension

Users will filter posts to be deleted for each platforms by using individual platform APIs

Users will confirm deletion of data

Application will display progress of deletion per platform

Application will continue to run in background if the browser is closed

Application will pause if the computer is shut down, and resume when restarted

Application will notify users of successful data deletion

Application will prompt users to close the application or run the deletion again

2.3 Ethical Considerations

Our project must adhere to legal and industry standards by following rate-limiting rules, abiding

by terms of use for social media websites, and ensuring actions taken by Social Shredder

resemble the user’s intention as closely as possible. In considering rate-limiting rules, we must

balance adherence to legal standards with reasonable deletion speeds. Based on Twitter’s API

5

documentation, the strictest of the social media sites we intend to target, we will require the

program to delete at least 180 posts per hour per user [7]. From the 2000 court case Ebay, Inc. v.

Bidder’s Edge, Inc., law and industry view bots pretending to be site users unfavorably [9]. To

abide by platform terms of use, we will only use supported APIs. Because our project increases

the computer’s role in deleting online content, we must ensure the computer's execution mirrors

user intent [10]. To address this issue, the application will prompt users to confirm deletion and

warn them that they could permanently lose content. Current solutions to privacy, legislation,

technical standards, and industry codes of conduct, do not provide users direct control over their

online presence [11]. Social Shredder provides users autonomy over their privacy by enhancing

online content management.

2.4 Product Deliverables

Next semester our team will present at Senior Design Open House, give an oral presentation,

submit a final project paper, and prototype a browser extension for Chrome, Firefox, and Safari

to delete content on Facebook, Instagram, Reddit, Tumblr, and Twitter. The browser extension

will include a short documentation manual on how to install the application, use the application,

and report or fix bugs. We will also provide commented source code for the extension, basic

documentation on how we use each API for deletion, and a guide for other developers to support

additional platforms. Finally, we will provide a small program that will allow users to run Social

Shredder without an active browser.

3.0 DESIGN SPECIFICATIONS

This section describes our project’s general, high-level design specifications by defining Social

Shredder’s inputs and outputs, user experience and interface, functioning environment, and

performance constraints. Input and output specifications define the data Social Shredder will

require from users, including login credentials, deletion filters, platforms for deletion, and

deletion confirmation. User interface specifications provide guidelines for user interaction with

the browser extension. Key environmental specifications are reliable internet connection and

installation of a supported browser. Specifically, Social Shredder will support Chrome, Firefox,

and Safari. Key performance specifications are deleting data in bulk, supporting post filters,

6

allowing recurring deletion, and supporting multiple browsers. We have defined a test process

for our application to meet these specifications.

3.1 Input and Output Specifications

Social Shredder requires users to provide social media login authentication, filters for data

acquisition, and approval of deletion in order to carry out data deletion. Upon acquisition of all

inputs, Social Shredder will warn users of deletion consequences, start the data deletion process,

and display deletion progress. Our input/output scheme is shown in Figure 2 below.

Figure 2: Input Output Diagram

Social Shredder’s inputs will authenticate users for selected platforms, allow users to filter posts

by keywords, time periods, or post types, and prompt users to confirm the deletion of their data.

The necessary user inputs are outlined in following list:

1. User Authentication

Description: Obtains user credentials so our program can remove account data.

Type: Text input or Access prompt (e.g. Facebook Login Button)

2. Data Filtering

Description: Filters by post keywords, timestamps, and types.

Type: Text input, checkboxes

3. Deletion Confirmation

Description: Confirms the user wants to delete data found by submitted filters.

Type: Yes/no input

7

The outputs of Social Shredder will ensure users understand deletion limits of each platform,

notify users of deletion progress, confirm deletion requests, and carry out deletion of data. The

necessary outputs are outlined in following list:

1. Platform Limitations and Warnings

Description: Informs user of platform limits, estimated removal time, and max

number of deletions allowed.

Type: Text output

2. Deletion Status

Description: Tells user the current status of deletion, including estimated time before

deletion completes.

Type: Icon in browser

3. Deletion Confirmation

Description: Prompts user to approve posts selected for deletion.

Type: Text output

4. Deletion of Data

Description: Actual deletion of data as requested by users.

Type: Result of application

3.2 User Interface Specifications

For Social Shredder to best meet user needs, the application must have simple traversal steps,

intuitive interaction options, and clear user interface elements. Users will install our extension,

link supported social media platforms, select platform posts for deletion, and track the deletion

process. Social Shredder’s purpose is to delete user data, so our extension should emphasize

interaction options for selecting and filtering posts to delete. Because deletion times vary widely

across platforms, the user interface will provide a progress bar to inform users of deletion status.

Figures 3 and 4 in Appendix A show the juxtaposition between good and bad interface design:

Google’s landing page displays only elements absolutely necessary to a web search, while

Yahoo’s landing page obscures the search bar within a jumble of unrelated design elements and

content [12]. When designing our user interface, we must pursue a simple Google design as

opposed to a cluttered Yahoo design. To design an effective user interface for Social Shredder,

8

we will make our application’s functionality straightforward, interaction options intuitive, and

design elements clear.

3.3 Key Environmental Specifications

Social Shredder will run in a common software environment on both low-end and high-end

consumer computers with an internet connection. Since we are targeting browser extensions, a

user must have one of the supported browsers installed: Chrome, Firefox, or Safari. All of these

browsers are free to use and supported on most operating systems, meaning the majority of users

with internet access will be able to use our application. To connect to social media platforms,

Social Shredder will require a constant network connection but will need no more bandwidth

than what is necessary for everyday web browsing.

3.4 Key Performance Specifications and Test Criteria

Social Shredder will delete data in bulk, provide filters for post deletion, allow periodic deletion,

and support multiple browsers. We will create automated tests that post on and delete from social

media platforms to verify Social Shredder meets these performance specifications. We will time

the deletions of both small and large data sets to ensure our application meets our goal of

deleting 180 posts per hour. To test whether Social Shredder accurately filters data and only

deletes content that fits the filters selected by users, we will test the application on a predefined

set of posts. Finally, we will thoroughly test each browser implementation to confirm uniform

functionality across Chrome, Firefox, and Safari. An automated test suite will ensure the

application is free of bugs and works as the user expects.

4.0 PROPOSED DESIGN SOLUTION

To meet the above design specifications for Social Shredder, our team has divided major

functionality into User Interface, Data Acquisition, Deletion, and Platform Interface modules.

The User Interface module collects all information necessary to begin deleting data and displays

deletion progress to the user. The Data Acquisition module uses search filters to aggregate social

media posts for deletion. The Deletion module deletes posts collected by the Data Acquisition

module. The Platform Interface module connects all other modules to supported social media

9

platforms by processing API calls for login, data filtering, and data deletion. An overview of

these modules and the data flow between them is shown in Social Shredder’s functional block

diagram in Figure 5 of Appendix A.

The User Interface module facilitates Social Shredder’s user experience by prompting users for

social media login information, deletion filters, and approval to delete filtered posts and

displaying platform deletion progress. An expanded view of the User Interface module is shown

in Figure 6 below, which includes an Input Validation sub-module that re-prompts users for

information if incorrect. After installing our browser extension, users can select Social

Shredder’s icon in their browser toolbar to view a grid of supported platforms and green bars

behind platform icons indicating deletion progress, as shown in Figure 7 of Appendix A. If a user

wishes to start a deletion task or view detailed deletion progress for a platform, they can select

the platform icon to open the window shown in Figure 8 of Appendix A. After submitting filters,

the user must confirm deletion of aggregated posts, as shown in Figure 9 of Appendix A.

Figure 6: User Interface Module

The Data Acquisition module, as seen in Figure 10 below, gathers all data to be deleted from

user-defined filters and ensures that Social Shredder only removes data users want deleted. The

User Interface module will provide filtering criteria, allowing users to filter by date, keywords,

10

and post types. After getting all selected posts from the Platform Interface module, the User

Interface module will prompt users to approve collected posts. This step ensures that our

application's automation matches with user intent and avoids deleting important or sensitive data.

The Data Acquisition module will send approved posts to the Deletion module.

Figure 10: Data Acquisition Module

The Deletion module, shown in Figure 11 below, will start a background process for deleting the

data found by our Data Acquisition module, report the status of deletion to the User Interface

module, and ensure that Social Shredder adheres to rate-limiting policies for target platforms.

The Background Process sub-module will ensure that users do not need to keep their browser

open through the potential multi-day deletion process. As the deletion process occurs, the

Deletion module will pass current deletion status to the User Interface module. Finally, the Rate

Limit Handler will ensure our application does not exceed the rate-limiting policies of each

target platform.

11

Figure 11: Deletion Module

The Platform Interface module, presented in Figure 12 below, connects all modules of our

application to backend APIs of supported social media websites. The User Interface module

passes login information to the Platform Interface module, which the OAuth sub-module will

format and pass to the OAuth API. The Data Acquisition module passes filtering criteria to the

Platform Interface module, where the Platform Specs sub-module will format the filters

according to which social media platform is being accessed. The formatted filters are passed to

the API handler, which makes appropriate API calls and returns filtered posts. The Deletion

module passes a list of posts to be deleted to the Platform Interface module. The Platform Specs

sub-module passes this information to the API handler, which calls the appropriate APIs to

delete the data.

12

Figure 12: Platform Interface Module

To reiterate, the User Interface, Data Acquisition, Deletion, and Platform Interface modules

detail the major functionality of Social Shredder. The User Interface module provides a simple

UI for the user to enter login credentials, select filtering criteria, and confirm deletion requests.

The Data Acquisition module filters posts using prompts the User Interface module to confirm

deletion. The Deletion module deletes all specified posts while adhering to our limit of 180 posts

deleted per hour per user and tracks the progress of deletion for the User Interface module.

Finally, the Platform Interface module connects other modules to social media APIs by handling

API calls and returning the necessary data back to the other modules. An overview of the four

modules and the data flow between them is outlined in our functional block diagram.

5.0 CONCLUSION

To review, this Problem Statement outlines the need for an application to delete social media

content and the functionality of Social Shredder, Team Sports’ browser extension to automate

removal of user data across social media platforms. Social Shredder’s filtering features aid user

control over personal privacy. We will improve upon existing solutions, such as Absterge for

Facebook and TwitWipe for Twitter, by supporting multiple social media platforms and tailoring

design functionalities, such as filtering based on time periods, to the needs of our target audience,

teens and young adults. To focus our efforts on this project, we have prioritized ethical standards

13

and reliability and will design robust software that abides by industry guidelines. To verify our

design with concrete criteria, we have cataloged user inputs, user outputs, and system outputs.

User inputs will include user authentication for accessing user accounts, customized filters for

sorting posts, and deletion confirmation for ensuring automation matches user intent. User

outputs will include notifications of platform limitations, status and progress of the deletion, and

deletion confirmation, while the main system output is deletion of data. We will test our design

to ensure deletion times are reasonable for users and agreeable with rate-limiting rules. To meet

these design specifications, we will make a browser extension consisting of a clean User

Interface module that obtains and validates user input, a Data Acquisition module that retrieves

filtered posts, a Deletion module that requires user confirmation before carrying out deletion, and

a Platform Interface module that handles API calls to different platforms. Team Sports’ next step

is to start developing Social Shredder. By the end of next semester, Fall 2015, we will develop a

prototype of our browser extension along with documentation to present at Open House, deliver

an oral presentation, and submit a final report.

14

REFERENCES

[1] A. Stojanov. (2013, September 14). Absterge [online]. Available:

http://userscripts-mirror.org/scripts/show/122073.

[2] TwitWipe [online]. Available: http://twitwipe.com/.

[3] M. Duggan et al., “Social Media Update 2014,” PewResearchCenter, Washington, D.C.,

Rep. Jan. 9, 2015.

[4] J. T. Child et al., “Blogging privacy rule orientations, privacy management, and content

deletion practices: The variability of online privacy management activity at different

stages of social media use.” COMPUT HUM BEHAV, vol. 28, no. 5, pp. 1859-1872, Sep.

2012.

[5] J. Golbeck. “I Decided to Delete All My Facebook Activity,” Slate, Jan. 1, 2014.

[Online]. Available:

http://www.slate.com/articles/technology/future_tense/2014/01/facebook_cleansing_how

_to_delete_all_of_your_account_activity.html.

[6] (2014, April 14). Reddit Privacy Policy [online]. Available:

https://www.reddit.com/help/privacypolicy#section_post.2C_comment_and_messaging_

data.

[7] (2015). API Rate Limits [online]. Available:

https://dev.twitter.com/rest/public/rate-limiting.

[8] E. Teitel. “Hire that Facebook party animal,” Maclean's, vol. 126, no. 29. July 2013.

[9] L. Graham, "Keep your bots to yourself [software law]," Software, IEEE , vol.17, no.6,

pp.106,107, Nov/Dec 2000.

[10] S. Vihavainen, et.al, "The Clash between Privacy and Automation in Social Media,"

Pervasive Computing, IEEE , vol.13, no.1, pp.56,63, Jan.-Mar. 2014.

[11] M. Michael and K. Michael, "Privacy - The times they are a-changin' [Introduction],"

Technology and Society Magazine, IEEE , vol.31, no.4, pp.20,21, winter 2012.

[12] L. Wroblewski, “Google vs. Yahoo! Interface Design,” LukeW, June 5, 2005. [Online].

Avaliable: http://www.lukew.com/ff/entry.asp?189.

A-1

APPENDIX A – Additional Figures

A-2

Figure 1:Objective Tree

A-3

Figure 3: Google Landing Page

Figure 4: Yahoo! Landing Page

A-4

Figure 5: Functional Block Diagram

A-5

Figure 7: Basic UI Mock Up

A-6

Figure 8: Filtering Screen Mock Up

A-7

Figure 9: Confirmation Screen Mock Up