Imagery © NASA, Terrametrics, Google Inc. - Last updated: 2012-06-29 - Hot spots not visible on this map (Database access required)

DEVELOP FOR GOOD CHALLENGE (Google ideas, I/O Extended 2012)

CONFLICT REPORTING FOR BLACKOUT
SITUATIONS IN REPRESSIVE REGIMES

The 'Develop for Good' challenges have been created by teams at Google that truly believe that technology can be used to address global challenges and drive real social impact.
The challenge for our team asks 'to change the way citizens are able to anonymously report violence in repressive regimes when phone and internet connections may be temporarily limited or intermittently severed.'

BACKGROUND

A substantial percentage of the world population lives under repressive governments: in 2011, Freedom House's 17 Worst of the Worst countries had 1.6 billion citizens living in them. The governments of these countries censor journalists, jail dissidents, and deny basic freedoms of speech to citizens. When the people in these countries rise up against their governments, these governments turn violent (most recently in Egypt and Syria). Information about incidents of violence in these situations is tremendously important: it can shame governments into reform, help the international community pressure regimes to cease violence, and increase citizens' own commitments to affecting change.

SILENT LENS (SL) SOFTWARE

• SUPPORTS CITIZENS IN HOSTILE ENVIRONMENTS (i.e. DISASTER, CIVIL UNREST, ETC),
• DOCUMENTS MATTERS OF CIVIL IMPORTANCE (i.e. DISASTERS, ATTACKS ON CIVILIANS),
• COMMUNICATES THIS EVIDENCE TO WITNESSES OUTSIDE OF THE HOSTILE ENVIRONMENT,
• EVEN IN THE FACE OF INTERFERENCE FROM HOSTILE FORCES AND/OR LIMITED INTERNET CONNECTIVITY.

IN A NUTSHELL

• The user installs the SL application on their Android device. It does not have a visible presence on the device.
• The user 'dials' their secret numeric passphrase to open the application and begin taking photographs. Meta data (IMEI, Latitude/Longitude, etc.) is added and then the evidence data encrypted.
• SL attempts to connect to other devices running SL and transfers evidence bi-directionally.
• A device has an encrypted 'payload' that can a) be submitted automatically to a 'mothership' whenever the device has a reliable Internet connection or b) downloaded from the device and couriered to the mothership via other means (simple desktop connection or shuttled out on physical media).
• Once a payload makes it out to the 'mothership,' the mothership provides a 'immunity' payload response that advises the mesh network to a) delete and stop caching/transmitting evidence that has been successfully retrieved, b) ban hostile devices from the mesh network, and c) prioritize communications from devices that have previously provided useful evidence.

KEY FEATURES

• Robust, multi-modal ad-hoc mesh network (Bluetooth, WiFi, direct cabled connection)
• Resilience against poisoning thanks to a robust 'immune system' that identifies trusted and untrusted sources of evidence.
• Considerable flexibility in how devices can deliver evidence payloads to the mothership.
• Provides useful evidence for international criminal courts by offering verifiably-authentic documentation without compromising the safety of citizens.

DOCUMENTATION

INSTALLING SILENT LENS

• The user downloads SILENT LENS from the Google Play store or obtains the APK from an alternative source.
• The user opens the application and specifies a numeric passphrase using a phone-style keypad. No further configuration is required.
• SL removes its icon from the phone's application list and runs as a run-at-startup background daemon.
• Rational: It should be extremely difficult for a attacker to determine whether or not a user has SL loaded on their device.

USING SILENT LENS TO TAKE PHOTOS

• The user opens the phone's dialer, enters the numeric passphrase as if it were a phone number, and presses 'Send.'
• SL intercepts the outgoing dialing attempt and opens the phone's camera library instead. The user can then begin taking photos using the standard camera library. Upon taking a photo, the user can 'Submit,' 'Retake,' or 'Cancel and Quit.'
• Discussion: Should the user be limited to several photos until some are successfully accepted by the 'mothership'?
• Discussion: Should this interface appear identical to the standard image capture libary (even with a loss of usability) to reduce the chances of an attacker realizing that the user is using SL?
• Once the user taps 'Submit', SL attaches meta data to the image (IMEI, phone number, latitude/longitude, phone model, Bluetooth ID, MAC address, time and date, etc) and encrypts the bundle with the mothership's public key.
• SL hashes the file to create a 128-bit item ID.
• SL signs the image so that its authenticity can be determined at a future date (see Image Authentication below for further commentary).
• SL resumes photo-taking mode.
• The user may tap the home screen button to return to the home screen at any time. SL should not be visible in the Task menu.
• Rational: The user should be able to exit the application quickly in the event that an attacker attempts to observe what the user is doing.
• The user may tap the menu button to edit settings (such as promiscuous mode durations, mothership address, etc), stop the daemon, or delete the application.

DISCOVERY PROCESS

• When Phone A (PA) discovers Phone B (PB) running SL, it examines either the MAC address or Bluetooth ID and compares it against its internal blacklist. If PB is on the blacklist, PA does not attempt a further connection and drops any connection established immediately (as if it simply dropped out of wireless range).
• If PB is not on PA's blacklist, they initiate a handshake. If either device has evidence (photos and other 'payload' items) or immunity signatures (IDs of known bad devices) that it has not sent to the other yet, it initiates the transfer process.
• Notes
  SL runs in a promiscuous mode in order to attempt to locate other devices running the application.
  Transport layers could include Bluetooth or WLAN (does not require an Internet connection; only a local LAN connection).

TRANSFER PROCESS (UPON SUCCESSFUL CONNECTION)

• PA sends PB any immunity signatures that it has not sent PB yet.
  Rational: Connection could drop at any moment and bandwidth is limited. Should focus on using first part of communication to share immunity data to help strengthen the network.
• PB reciprocates the transfer of immunity signatures.
• PA sends PB a list of files that the mothership has successfully retrieved. PB deletes all files that PA sent IDs for.
  Rational: Once an image is received by the mothership, we need to stop distributing it so that we can reserve the bandwidth for new images.
• PB reciprocates step 3.
• PA then sends PB a list of item IDs that it has not yet sent PB.
• PB responds with 'need' or 'don't need' for each item.
• PA updates its records for PB with the list of items it has sent PB to include items that PB says it doesn't need.
• PB sends PA a list of item IDs that it has not yet sent PA and the above repeats in reverse.
• PA begins a file transfer, prioritizing newer files originating from device IDs with the highest trust score (if available).
  Rational: There will be many untrusted actors on the mesh network. We should prioritize the opportunity to transfer images from someone whose images were previously validated by external observers.
• PB reciprocates with a file transfer, again prioritizing newer files originating from device IDs with the highest trust score.
  Steps 9 and 10 repeat until neither device has files left to send.
  
  Notes
  It seems rational to keep this entire process 'invisible' to limit the odds of an attacker observing whether or not a user has SL enabled on the phone.
  Extension: Use concepts from BitTorrent to improve peer-to-peer file transfer.

SECURITY

• MAC addresses and Bluetooth device IDs are sent in clear-text only during the device discovery process.
• All other personally identifiable information is encrypted using a public key.
• The private key is held by the mothership.

IMMUNITY

• Items sent to the mothership are reviewed by volunteers (or Mechanical Turk workers).
• Items that appear to be legitimate protest or conflict zone images are flagged as 'good.'
• Items that appear to be faked in an attempt to flood the network are flagged as 'bad.'
• Each time a device sends in a 'good' image, its trust score improves. (Probably need a fairly high number of 'good' images before a device is publicly promoted out of 'neutral' territory.)
• Any device that sends more than a reasonable quantity of 'bad' images (beyond what one would expect from poor luck) is considered a 'bad' device and is added to the blacklist.

FILE SCHEMAS

Mobile Payload from User (single XML file)

• Device ID
• Items (one or more)
  • Item ID
  • Meta-data, e.g.:
    • EXIF
    • GPS (lat/lon)
    • Origin device data
      • Device ID
      • IMEI or similar
      • Phone #
      • Carrier
    • Image authenticity data
    • Base64 encoded file data

Response Payload from Mothership (single XML file, signed with mothership's private key)

• Acknolwdgement
  • One or more Item IDs
• Immunity data
  • Device IDs to blacklist
  • Device IDs with promoted trust (gain higher priority for file transfers)
    
    Device ID = public-key encrypted (version of IMEI)
    Item ID = Salted MD5 hash of file data

IMAGE AUTHENTICATION

• This is a place where consultation would be useful; in theory devices should have a private key used to sign the file, but it would be next to impossible to keep the private key secure. Canon developed something similar for law enforcement purposes called "Original Decision Data" feature but it was successfully exploited. Refer to Forging_Canon_Original_Decision_Data [PDF].

OTHER CONSIDERATIONS

• Much of the functionality described above-particularly the ability for the application to network promiscuously and operate as a background process-may not be feasible due to Android application security policies. Therefore, we might need assistance circumventing these policies.
• We probably should not install SL by default on Android devices. Otherwise, the very possession of a Android device would be viewed with suspicion by attackers.
• Additional payloads
  Twitter 'tweets.' A user can specify their Twitter ID, password, and tweet content. Since SL encrypts the data, the user can rest assured that their credentials would not be tampered with. The mothership would then tweet the item on their behalf. Limitation: The user must enter their Twitter ID and password carefully as there would be no real-time verification of their credentials. Text captions for images. Disadvantage: Difficult to enter surreptitiously. Audio captions for images. Disadvantage: Increased bandwidth requirements. Video. Disadvantage: Increased bandwidth requirements.

ALTERNATIVE IMAGE TRANSFER/CAPTURE METHODS

• SL could download files from a memory card or camera.
• If the memory card fits in the phone, the hardware aspect is simple.
• Alternatively, a USB memory card reader could be attached to the Android device. All that the user would need is a commercially-available USB Type-A Female to Type-Micro-B Male cable.
• This type of cable has poorer availability than conventional USB Type-A Male to Type-Micro-B cables (what is typically used to connect Android devices to computers and chargers). However, a user with basic soldering supplies, one USB Type-A Male to Type-Micro-B cable (readily available), and one USB extension cable (Type-A Male to Type-A Female) can easily make the necessary cable.
• For higher throughputs, operation during radio jamming, or operation during and/or radio silence (to avoid remote detection), SL could transfer files between Android devices simply by connecting the two devices with a USB Type-Micro-B Male to Type-Micro-B Male cable. As with the USB Type-A Female to Type-Micro-B Male cable this item has poorer availability but can be easily made from two USB Type-A Male to Type-Micro-B cables.
• Could a user use the Android device as a modem with more traditional radios (Shortwave, Ham, etc) to transmit image data out of a country when all other communication has been cut off?
• Disadvantages
• Easy to detect (high power radio, often large antennas)
• Half-duplex
• Difficult to know if the mothership has received the data correctly

PROGRAM/IMPLEMENTATION

refer to apperfection.com/blue-box for the bluetooth sync (ryan quellet)
further development pending

TEAM

Perry Chow, San Jose, CA, U.S.A.
Chris Gagne, San Francisco, CA, U.S.A.
Ansgar Halbfas, San Francisco /Shanghai, Germany
Ryan Quellet, Wyoming, MI, U.S.A.
Andrew Song, San Francisco, CA, U.S.A.

THANKS

Google San Francisco, Anna de Paula Hanika & Kara Cooper for seamless organisation and great hospitality!