No description, website, or topics provided.
Java D
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
deadmanswitch
.gitignore
README.md

README.md

==================================================

Dead Man's Switch for Android

================================================== Work on this project has only just begun, and anyone who feels up for the challenge is more than welcome to help out.

The design concept thus far is to create a traditional Dead Man's Switch, for which the user will be capable of choosing the amount of time before the switch is activated and the preconfigured actions are executed automatically by the program. Implementation features for configurable executable actions should include tasks like deleting the Contact List on the user's phone, deleting emails (either on the phone or through ssh on a remote server), deleting all contents of a remote server (or shutting it down in the case of a remote server with full-disk encryption which has sensitive information). Features should be added depending on what activists will need from a Dead Man's Switch in the event of arrest or incapacitation.

It was discussed among the developers involved with March Hare Communications Collective that, in the United States, activists' phones are often imaged upon intake to jail or other "correctional" facilities, which requires the phone to be shut down. This creates problems for the design implementation in this application, because, in the event that the user's phone is turned off, the Dead Man's Switch would be unable to execute the specified tasks. The only way I can imagine getting around this is to set up a server somewhere, which stores a set of actions to be taken in the event that the user's phone does not contact the server to postpone events within the set ammount of time. A useful thing to do with this as well would be to have the application tell the phone to send out a zomg-my-phone-is-dying message when the battery reaches a critical level, so that the user's affinity group at least has some information that the Dead Man's Switch may have been triggered due to the user's phone being dead.

Software Requirement Specifications

Functionality

  • Timer function. Should deploy preconfigurable actions without user input, and require user input only to prevent actions from occurring. The amount of time before the switch goes off should be user configurable. Also, the user should be prompted for a passphrase to deactivate the switch, so that captors of, or antagonists to, the user cannot delay or disable the preconfigured actions.
  • Preconfigurable actions. Desired actions thus far include deleting contacts lists, SMSs, emails, and other phone data, sending emails or SMS, deleting contents of or shutting down a remote server, sending forth an army of robot minions to spring the user from jail. If you can think of a useful action, please [submit a feature request to the developer](mailto: isis@hackbloc.org).
  • Backend services for server. In the event that the phone is powered off, as is often the case when a phone is taken for forensics imaging, it would be convenient for the Dead Man's Switch application to actually store the timer function and preconfigurable actions on a remote server, if possible, in order that they are executed regardless of phone state. Obviously, in this situation, preconfigurable actions to modify data on the phone itself become unexecutable.
  • Low power emergency actions. The application should be able to read the phone's battery level to determine if the phone is dying. If the phone is dying, the application should perhaps execute a different set of preconfigured actions, such as sending SMSs to members of the affinity group to notify them that the user is still active but that their phone is dying.
  • Unexpected power off actions. If the phone is unexpectedly powered down while battery levels are still sufficient, and a backend server has been configured, we should determine if there is a method for the phone to send a last minute panic message to the server. This is probably not feasible, however.

External Interfaces

  • Visibility. The application should attempt to hide itself in the background, similarly to the OpenWatch app, i.e. there should not be any icons in the action bar showing that the app is running. The app should be visible only during configuration and when the timer has gone off.
  • Hardware Interfaces. 3/4G connection, wireless connection, access/modify SD Card contents.

Performance

  • Speed. The Dead Man's Switch application should avoid unnecessary drains on system resources.

Attributes

  • Portability. A sister app is being designed for iPhone devices. There are no current plans to offer the application on either Symbian or Blackberry. Only feds and CEOs use Blackberries anyway.
  • Correctness. We intend to be politically correct. That's what we're supposed to say at this part of the Software Requirement Specification, right, IEEE?
  • Maintainability. Classes should be designed in a modular fashion so that they may be easily updated. Strings, where possible, should be kept in a separate .xml file, so that the application is easily translatable to other languages. Document anything that looks wonky, which is really all of it, since it's Java for christsakes.
  • Security. Where possible, all stored data should be encrypted with passphrase protection. MD5 is not acceptable for hashes, only SHA-256 or SHA-512. Communication with networked services should never be plaintext. This application should not expose the user to any further attack surface than would already be available were it not installed.

Design Constraints

  • Language. Java. Yes, it sucks.
  • Platform. Android 2.3.3+
  • Feature Freeze. Starts on April 30th, 2012.