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).

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

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!

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

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.

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.

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.

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.

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