Last updated: March 16, 2026

Organizing peaceful assemblies requires communication infrastructure that protects participant identities from surveillance, device seizure, and network interception. A properly configured burner device, a secondary phone or tablet used only for sensitive activities, forms the foundation of operational security for protest coordination. This guide covers the technical implementation from hardware selection through secure disposal, with code examples for automation where applicable.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Select Hardware and Initial Acquisition

The goal is hardware with no personal data linkage. Purchase devices with cash from physical retail locations rather than online. Avoid devices tied to your identity through carrier accounts. Recommended options include:

Do not use your primary device for protest-related communication. The security of your entire operation depends on maintaining strict separation between personal and operational identities.

Step 2 - Harden the Operating System

After acquiring the device, perform a factory reset before first use. Install a privacy-focused custom ROM or use the stock OS with extensive hardening. GrapheneOS and CalyxOS are the leading choices for Android devices, both remove Google dependencies and implement aggressive security defaults.

Initial Device Setup

When setting up the device:

  1. Skip all account creation prompts
  2. Disable WiFi and Bluetooth during setup
  3. Use a local-only account (no Google, no cloud sync)
  4. Disable location services at the system level

Network Isolation

Burner devices should never connect to networks associated with your primary identity. Use a dedicated mobile hotspot or public WiFi with a VPN. Configure firewall rules to block non-essential network traffic:

Android iptables rules (requires root)
Block all incoming connections
iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Allow only necessary outgoing traffic
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

For automated VPN connection management, create a script that activates on boot:

#!/system/bin/sh
/system/bin/vpn-autoconnect.sh
while true; do
    if ! ifconfig tun0 &>/dev/null; then
        am start -n com.windscribe.vpn/.ui.SplashScreenActivity
        sleep 10
    fi
    sleep 30
done

Step 3 - Communication Stack Selection

Choose communication tools based on threat model. For protest coordination, prioritize:

Recommended Tools

Signal remains the gold standard for encrypted communication. Configure it with a burner phone number and enable all privacy settings:

Signal registration via command line (requires signal-cli)
Install - brew install asukiaaa/tap/signal-cli

signal-cli -u +1555EXAMPLE register
signal-cli -u +1555EXAMPLE verify VERIFICATION_CODE

Send encrypted message
signal-cli -u +1555EXAMPLE send -m "Meeting at 5pm, bring supplies" +1555TARGET

Briar offers mesh networking capability, devices can communicate directly via Bluetooth or WiFi without internet connectivity. This is valuable when internet access is unreliable or blocked.

Session provides no-phone-number messaging using a decentralized onion-routing network. Useful when phone number acquisition itself creates risk.

Configuration Checklist

Before deployment, verify these settings in Signal:

Step 4 - Application and Permission Audit

Every installed app is a potential attack vector. Install only what is strictly necessary. Audit permissions aggressively:

List all permissions for installed packages
adb shell pm list permissions -d -g

Revoke specific dangerous permissions
adb shell pm revoke com.signal.android android.permission.CAMERA
adb shell pm revoke com.signal.android android.permission.RECORD_AUDIO

Create an app audit script to run weekly:

#!/bin/bash
permission-audit.sh

echo "=== Permission Audit ==="
echo "Apps with camera access:"
adb shell dumpsys package | grep -A 5 "android.permission.CAMERA" | grep "pkg="

echo ""
echo "Apps with location access:"
adb shell dumpsys package | grep -A 5 "android.permission.ACCESS_FINE_LOCATION" | grep "pkg="

Remove any app that requests unnecessary permissions. A messaging app should need: network access, storage (for attachments), and notifications. Nothing else.

Step 5 - Data Hygiene and Operational Security

During active operations, maintain strict data hygiene:

Separate SIM cards - Use a dedicated SIM for the burner, purchased with cash. Remove it when not in active use. Store it separately from the device.

Minimal storage - Store no contact lists locally, memorize critical numbers or keep them on paper in a secure location. Never store meeting locations in message history.

Regular wipes - Configure automatic data expiration. Signal’s disappearing messages handle this for communications. For local files:

Secure file deletion script
secure_wipe() {
    local file="$1"
    # Overwrite with random data 3 times
    for i in 1 2 3; do
        dd if=/dev/urandom of="$file" bs=1024 count=$(($(stat -f%z "$file") / 1024))
    done
    rm -f "$file"
}

Step 6 - Device Seizure Response

Prepare for the possibility of device seizure. The goal is to maximize time before device unlock and minimize exposed data.

Screen lock - Use a strong PIN (6+ digits) rather than biometric unlock. Biometric authentication can be compelled; PINs have protection against self-incrimination in some jurisdictions.

Secondary PIN - Many Android devices support a separate PIN for “guest mode” or work profile. Set this up with a different PIN that unlocks a limited shell with decoy data:

Create limited user profile (Android 5.0+)
adb shell pm create-user --profileOf 0 --managed DecoyProfile

Auto-wipe - Configure your device to wipe after failed unlock attempts. On stock Android - Settings → Security → Strong → Auto-wipe after 15 failed attempts.

Faraday cage - Store the device in a Faraday pouch when not in use. This blocks all cellular, WiFi, and Bluetooth signals, preventing remote wipe or data extraction.

Threat Model Documentation

Before deployment, document your threat model explicitly:

THREAT MODEL FOR PROTEST COORDINATION

Assets at risk:
- Participant identities (highest priority)
- Meeting locations and times
- Organizational strategy
- Financial information (if applicable)
- Communication patterns

Adversaries:
- Law enforcement surveillance
- Institutional surveillance
- Infiltrators/undercover agents
- Network-level monitoring (ISP, cellular provider)

Attack vectors:
1. Device seizure → need full encryption + panic wipe
2. Network interception → need VPN + encrypted messaging
3. Location tracking → need GPS disabled + Faraday pouches
4. Social engineering → need training, discipline

Mitigations implemented:
- GrapheneOS/CalyxOS (reduces attack surface)
- Signal E2EE (protects communication)
- Disappearing messages (limits data persistence)
- VPN (masks IP/location from ISP)
- Faraday pouches (prevents remote tracking)

Step 7 - Secure Disposal

When a burner device’s operational life ends:

  1. Remove and destroy the SIM card physically
  2. Perform factory reset with “secure erase” (writes over all storage)
  3. For devices with encrypted storage, the encryption key should be destroyed, making data unrecoverable
  4. Physical destruction: drill through the storage chip or crush the device
Verify full storage encryption is enabled before disposal
Check encryption status
adb shell dumpsys diskstats | grep "Encrypted"

Secure wipe internal storage before physical destruction
This ensures encrypted storage keys are unrecoverable
adb shell pm clear com.android.systemui
adb shell wipe data all

Step 8 - Chain of Custody for Burner Devices

Maintain strict control over device ownership:

Device tracking and chain of custody
class BurnerDeviceLog:
    def __init__(self):
        self.devices = {}

    def register_device(self, device_id, purchaser):
        """Record device purchase"""
        self.devices[device_id] = {
            'purchased_by': purchaser,
            'purchase_date': datetime.now(),
            'purchase_location': 'retail_cash',
            'condition': 'new',
            'handlers': [purchaser]
        }

    def transfer_device(self, device_id, from_person, to_person):
        """Record device transfer"""
        self.devices[device_id]['handlers'].append(to_person)

    def destroy_device(self, device_id, proof_of_destruction):
        """Record device destruction"""
        self.devices[device_id].update({
            'destroyed_date': datetime.now(),
            'proof': proof_of_destruction
        })

    def print_audit_trail(self, device_id):
        """Print chain of custody"""
        device = self.devices[device_id]
        print(f"Device {device_id}:")
        print(f"Purchased: {device['purchased_date']} by {device['purchased_by']}")
        print(f"Handlers: {device['handlers']}")
        if 'destroyed_date' in device:
            print(f"Destroyed: {device['destroyed_date']}")

Step 9 - Post-Action Device Handling

After protest activities conclude:

  1. Power down immediately: Turn off device completely, remove from area
  2. Store isolated: Keep in Faraday pouch until safe house reached
  3. SIM removal: Remove SIM card, store separately
  4. Battery removal (if possible): Prevents remote wipe commands
  5. No data review: Don’t connect to networks or check messages until safe
  6. Disposal: Follow secure disposal procedures within 48 hours

Troubleshooting

Configuration changes not taking effect

Restart the relevant service or application after making changes. Some settings require a full system reboot. Verify the configuration file path is correct and the syntax is valid.

Permission denied errors

Run the command with sudo for system-level operations, or check that your user account has the necessary permissions. On macOS, you may need to grant terminal access in System Settings > Privacy & Security.

Connection or network-related failures

Check your internet connection and firewall settings. If using a VPN, try disconnecting temporarily to isolate the issue. Verify that the target server or service is accessible from your network.

Frequently Asked Questions

How long does it take to set up burner devices for protest organization?

For a straightforward setup, expect 30 minutes to 2 hours depending on your familiarity with the tools involved. Complex configurations with custom requirements may take longer. Having your credentials and environment ready before starting saves significant time.

What are the most common mistakes to avoid?

The most frequent issues are skipping prerequisite steps, using outdated package versions, and not reading error messages carefully. Follow the steps in order, verify each one works before moving on, and check the official documentation if something behaves unexpectedly.

Do I need prior experience to follow this guide?

Basic familiarity with the relevant tools and command line is helpful but not strictly required. Each step is explained with context. If you get stuck, the official documentation for each tool covers fundamentals that may fill in knowledge gaps.

Is this approach secure enough for production?

The patterns shown here follow standard practices, but production deployments need additional hardening. Add rate limiting, input validation, proper secret management, and monitoring before going live. Consider a security review if your application handles sensitive user data.

Where can I get help if I run into issues?

Start with the official documentation for each tool mentioned. Stack Overflow and GitHub Issues are good next steps for specific error messages. Community forums and Discord servers for the relevant tools often have active members who can help with setup problems.

Related Articles