This semester concludes with the development of SpideyApp: An Android-based cell tower comparator used for detecting Stingray devices.  Brought to you by a collaboration between the ACLU of Massachusetts, The Guardian Project, and MIT Media Lab students.

Project title: SpideyApp – Android-based Stingray detector.

SpideyApp user interface.

Description: An Android-based Stingray detector that uses scan differentials to detect anomalous cell towers.

SpideyApp final presentation: here.

SpideyApp case study: here (publish link).

We’re working on finishing our application (finishing the demo version for class, still a bit of work to do going forward).  Also working on incorporating the feedback into our case study: https://docs.google.com/document/d/12D8WoGjNb5OWloTB5gpyJrlhRWvSg6HutsOp3nG4CcM

For our final project demo we’ll be showing the Android application that we built.  I will bring a couple of phones so that people without Android devices can try it out.  I will email out the apk so those that want to install the current version will be able to do so.

I am not completely done the presentation but I have uploaded it here: https://drive.google.com/file/d/0Bz4rSu1GK9poX2JLeWk1bFNMc2c/edit?usp=sharing

This week I spent a lot of time working on the case study, coding pieces into the app, and getting things ready for launch (pre-launch page, social presence, etc).  I’m still waiting to hear back from our Neo partner on UI/UX wireframes and mockups.  Our team plans to have another work party this week to get our application demo-ready for next week!

The case study is here! Any comments would be greatly appreciated as I work toward the final submission.

We have a website up! Well, sort of. It will bring you to a signup page to get updates on the app. Right now we’re just collecting email addresses to spark interest.

Like us on facebook and follow us on twitter!

Last week we had a mini hackathon to get work done on our project — you can check out our code on Github at https://github.com/jtwarren/spidey.  As the last post mentioned, the hackathon was really successful and we got a lot of work done, all being in the same place at the same time.  Since then, we have been working to make the application more feature complete.  We have also connected with Alvaro from Neo and will be working with him to flesh out the UI/UX components of the application.  I am meeting with Alvaro today and will update based on what we discuss.  Finally, I will be working on the case study today and tonight.

Update on help from Neo:  Alvaro is working on UI wireframes and once we finalize these he will begin higher fidelity mockups and views.

We’re hacking away on the application, copy, and text right now!!

Case study: https://docs.google.com/document/d/12D8WoGjNb5OWloTB5gpyJrlhRWvSg6HutsOp3nG4CcM/edit#

Apologies for the brevity, will update later with more info but hacking away!!

== Update ==

Today we had a day-long, team hackathon with help from people outside the team too!  It was a lot of fun and very successful.  We were able to get a lot going with our application and have a basic version running for Android devices.  Seen below is the landing page for our application where the user can take actions to get more information (“ABOUT”), or scan the surrounding cell towers (“SCAN”).  The about action will take the user to another screen showing background information on the problem (“What is Spidey”, “What are IMSI-catchers”, “Why be concerned?”, etc.).  The scan action will actually scan and persist cell tower information.

Landing page for the Spidey application. Scan button in upper right will scan and persist cell towers. About button brings up additional information on the application and problem at hand (IMSI-catchers, Stingray devices).

With the initial version of our application running, we have a better idea on how to build out more features and are constantly coming up with new ideas.  We’re focusing on building out very clean scanning information for comparison and storage that will allow for us to do more with the data.  In addition to the application we’re working on copy for our promo website and the Google play store.

During the class review of our project we got a lot of useful feedback. The presentation outlined my project partners, the ACLU and the Guardian Project, and their missions — leaving some of the detailed information to Kade and Nathan who were in class to talk after presentations. I then gave a quick overview of the cellular topology and how cell phones connect to the network and trasnmit data back and forth — again leaving out specifics as Nathan was giving a talk specifically on this. I then talked about IMSI-catchers or Stingray devices, and how they can be used to intercept data. To put our project into context, I went over our team values and project goals and talked about the various user personae. Finally, I went over a few of the design candidates that we’re considering and talked about the one that we have started to implement.

The feedback from the class was really helpful. After the presentation a few questions led to the discussion of what would happen post-discovery of an IMSI-catcher or Stingray device. This is something that I hadn’t really thought of as an important aspect of the project/application. Initially I saw the main value of the application to be the alerting feature — purely a technological/engineering approach. It turned out that the audience didn’t know what they should do given the information that their signal is possibly intercepted. One member told us to consider suggesting to users where safe places are. Another asked specifically in what ways they should they react to finding out that they are being spied on. This is something to really think about and sort out going forward. A naive solution would be to present a set of steps that informs the user of things to do — such as turn off the phone, move to a safe location, and report the behavior.

Some of the feedback around sharing the information recorded was a little unexpected. We initially hypothesized that people would not want to necessarily share their data — the data pertaining to the possibility of an IMSI-catcher detection. It turns out that this seems to be an incredibly useful feature — and one that people would want. Specifically one member of the audience suggested, “Consider sharing publicly when an IMSI catcher is found via FB, twitter, with a hashtag”. This brings additional benefits such as alerting as many people about the issue as possible and increasing awareness of the subject, and letting law enforcement know that we know what they’re up to.

Finally, the biggest thing we learned is that there are a lot of people who don’t really know what the issue it or why it should matter to them. A suggestion was made to make it more friendly to people who aren’t aware or who don’t care about being under surveillance. A member of the audience suggested that we “make them somehow more aware of why it’s important”, and someone else agreed with this. This is something that we are addressing and will test in the next phase of our design process. It’s also something that we hope to address before people get their hands on our application. Hopefully we have a website or description of the app available and why people should care.

Last week Kade and Nathan, from the ACLU and The Guardian Project respectively, gave a great talk about the problem we’re tackling: IMSI-catcher detection. Before their presentations I gave a presentation on the status of our project and got some great feedback. Based on the feedback and questions it’s apparent that we really figure out how to make sure people realize the problem that exists and why it might be important to them — how to really capture attention and get people to use our application long term.

Nathan went over our project at a very technical level: how cell towers work, how cellphones work, and why the problem is very challenging. He talked about E911 and how stolen phones can be blocked or turned off so they no longer work. These technologies and features are useful but make cellular phones relatively insecure even though they’re being relied upon more and more everyday.

Kade gave a great presentation on the legality of the issues and why this is actually a problem. She really answered the question of, “why should I care if I’m tracked, I don’t have anything to hide”. Kade went through several case studies such as the Ukrainian Government and NAACP v Patterson. She talked about the companies making Stringray devices (IMSI-catcher related products for law-enforcement use) and how law-enforcement agencies use this technology.

Our project is really starting to take shape and we’re working in parallel on the design and the technology for an Android application. While we’ve discussed many possible design candidates, we’ve really set down with one and are beginning to implement it. We are planning a work-party which will basically be a hackathon in which we can all get together and combine our knowledge to be more efficient. This will leverage the group knowledge on the problem at hand and allow everyone to work at full speed.

Mockup of the Spidey user interface for Android cell phones. Spidey shows the current cell towers discovered and their relative danger levels.

I presented several versions and mockups of the application during last week’s project update presentations.  The above mockup shows the direction we’re heading and what we’ve currently been user testing with paper prototypes.  User testing has allowed us to gauge the level of knowledge of people in our various user groups and figure out how people might interact with the application.

This week we have come up with a name for our project, calling it Spidey.  This stems from Spiderman’s sixth sense that alerts him when danger is imminent.  Moreover, it highlights the telecomm network as a web of signals and routes that our phones and communication signals are caught up in.

We have completed and (mostly) signed our project proposal and working agreement.  Additionally, we’re meeting in person later this week to finalize everything before break and layout goals and deadlines for project work.

Finally, Nathan set up our project tracker on The Guardian Project’s project tracker.  They use it to build all of their apps, so it makes sense to use this workflow.  Once we are ready we will also put in milestones, features tickets, etc. and link in our source code repo, tie into our build server, etc so they are tracked as part of the open-source project.

This week we drafted our project proposal and MOU.

We will present this to our partner this week and finalize it for next week.