How To Document Privacy Violations For Potential Class

Documenting privacy violations requires preserving timestamped screenshots, browser inspector captures showing data transmission, network logs (using Charles or Fiddler), and metadata proving your access date and conditions, with parallel documentation of privacy policy text and company statements contemporaneous to the violation. Hash file timestamps, save browser consoles showing data being transmitted to unexpected third parties, and preserve ToS or privacy policy versions via archive.org before they’re updated—this layer of authentication evidence transforms anecdotal complaints into admissible documentation. Class action lawyers specifically need evidence showing: (1) what data was actually collected, (2) violation of stated privacy policy or law, (3) company knowledge (security researcher disclosures, regulatory complaints), and (4) affected population scale—technical documentation you can provide demonstrating large-scale unencrypted data transmission, hardcoded API keys in client code, or retention beyond stated periods becomes crucial evidence distinguishing frivolous from meritorious class actions.

Understanding Evidence Requirements

For privacy violations to support a class action, evidence must be authentic, reliable, and preserved in forensically sound ways. Courts look for documentation that shows:

What data was collected
How it was transmitted or stored
Who had access to it
When the violations occurred

Screen captures alone rarely suffice. You need reproducible, timestamped evidence that can be independently verified.

Capture Network Traffic

One of the most compelling forms of evidence comes from observing actual data transmissions. Developers can use tools like Wireshark or mitmproxy to capture and analyze network traffic.

Using mitmproxy for HTTPS Inspection

# Install mitmproxy
pip install mitmproxy

# Run mitmproxy in regular mode
mitmproxy -p 8080

# Configure your system or browser to route traffic through 127.0.0.1:8080
# Examine the traffic for unexpected data exfiltration

After capturing traffic, export the data:

mitmproxy -n -r capture_file.mitm --set flow_detail=3 > network_analysis.txt

This creates a permanent record showing exactly what data leaves your device and where it goes.

Document API Calls and Data Leaks

For web applications, browser developer tools provide immediate evidence of privacy issues. Documenting API calls reveals what information gets sent to external servers.

Capturing Console Logs

Open Chrome DevTools (F12), navigate to the Network tab, and record XHR/Fetch requests. Export these as HAR files:

Right-click in the Network tab
Select “Save all as HAR with content”
Save the .har file with a descriptive name

HAR files contain complete request/response cycles including headers and payloads.

Automated API Monitoring Script

#!/usr/bin/env python3
"""
Monitor outgoing HTTP requests and log them with timestamps.
"""
import json
import subprocess
from datetime import datetime
from pathlib import Path

def log_request(method, url, headers, body):
    entry = {
        "timestamp": datetime.utcnow().isoformat(),
        "method": method,
        "url": url,
        "headers": dict(headers),
        "body": body
    }

    log_file = Path("privacy_log.jsonl")
    with open(log_file, "a") as f:
        f.write(json.dumps(entry) + "\n")

    print(f"[{entry['timestamp']}] {method} {url}")

# Example using mitmproxy's API
# from mitmproxy import http
# def request(flow: http.HTTPFlow):
#     log_request(flow.request.method, str(flow.request.pretty_url),
#                 flow.request.headers, flow.request.get_text(strict=False))

Screenshot Documentation with Metadata

Screenshots provide visual evidence but require careful handling. Always capture full-page screenshots that include URL bars and timestamps.

# Using Chrome headless for automated captures
chrome --headless --screenshot=evidence_$(date +%Y%m%d_%H%M%S).png \
  --virtual-time-budget=5000 \
  "https://example.com"

For timestamp verification, use services that embed metadata or capture browser console output alongside screenshots.

Preserving Web Archives

Internet Archive’s Wayback Machine provides immutable snapshots. Submit suspicious pages before they change:

# Use the Wayback Machine save API
curl -I "https://web.archive.org/web/$(date +%Y%m%d%H%M%S)/https://example.com/suspicious-page"

Create personal backups using wget:

wget --mirror --convert-links --adjust-extension \
  --page-requisites --no-parent \
  -e robots=off --timestamping \
  "https://example.com" \
  2>&1 | tee wget_$(date +%Y%m%d).log

The log file becomes part of your evidence chain, showing exactly when content was retrieved.

Privacy violations often involve unauthorized tracking. Document cookies and local storage:

Extracting Browser Cookies

// Run in browser console to export all cookies
const cookies = document.cookie;
const blob = new Blob([cookies], { type: 'text/plain' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = 'cookies_' + new Date().toISOString() + '.txt';
a.click();

For Firefox, use the sqlite3 command-line tool:

sqlite3 cookies.sqlite "SELECT host, name, value, expiry FROM moz_cookies" \
  > cookies_export.txt

Hashing and Chain of Custody

Raw evidence files are only as credible as your ability to prove they have not been modified since collection. Generate cryptographic hashes immediately after saving any evidence file:

# Generate SHA-256 checksums for all evidence files
find ./evidence -type f | sort | xargs sha256sum > evidence_manifest.sha256

# Verify integrity later
sha256sum -c evidence_manifest.sha256

Store the manifest file separately from the evidence directory — ideally signed with a GPG key or uploaded to a public blockchain timestamp service. RFC 3161 timestamp tokens from services like FreeTSA.org provide cryptographically verifiable proof that a file existed at a specific moment in time without relying on any single party.

# Create an RFC 3161 timestamp token
openssl ts -query -data evidence_manifest.sha256 -sha256 -cert -out request.tsq
curl -H "Content-Type: application/timestamp-query" \
     --data-binary @request.tsq \
     https://freetsa.org/tsr -o timestamp.tsr

The .tsr file cryptographically binds your evidence manifest to the timestamp authority’s signed assertion of the date and time, providing court-admissible proof of when your evidence was collected.

Mobile App Traffic Analysis

Many privacy violations originate in mobile applications that transmit data without visible browser tooling. Analyze mobile app traffic using a rooted Android device or iOS with SSL Kill Switch:

For Android analysis without root, use an Android emulator with a user-installed certificate authority:

# Set up Android emulator with mitmproxy CA
adb push ~/.mitmproxy/mitmproxy-ca-cert.cer /sdcard/
# Install via Settings > Security > Install Certificate

For iOS, use the iOS Simulator with mitmproxy or Charles Proxy configured as the system proxy. Capture the traffic while interacting with the app normally, then examine request payloads for personal information transmitted to unexpected domains.

Document any transmission of device identifiers (IDFA, IDFV, Android Advertising ID), location data, contact lists, or health information that the app’s privacy policy does not disclose. Cross-reference against the app’s stated data practices in the App Store or Play Store listing as of the date you captured the traffic — archive those listing pages before examining traffic so you have evidence of what was claimed at the relevant time.

Building an Evidence Package

Organize collected evidence systematically:

evidence/
├── network_captures/
│   └── mitmproxy_dump.jsonl
├── screenshots/
│   └── evidence_*.png
├── web_archives/
│   └── example.com/
├── api_logs/
│   └── privacy_log.jsonl
└── metadata.json

Create a manifest file documenting each piece:

{
  "case_id": "privacy_001",
  "collected": "2026-03-16T10:30:00Z",
  "collector": "theluckystrike",
  "evidence": [
    {
      "file": "network_captures/mitmproxy_dump.jsonl",
      "description": "HTTPS traffic capture showing data exfiltration",
      "tool": "mitmproxy 10.0.0"
    },
    {
      "file": "screenshots/evidence_20260316.png",
      "description": "Screenshot of suspicious API call",
      "tool": "Chrome headless"
    }
  ]
}

Static Analysis of Application Code

When a violation stems from an application rather than a website, static analysis can reveal behaviors that traffic capture might miss — especially for obfuscated or certificate-pinned apps.

For Android APKs, use apktool and jadx to decompile the application:

# Decompile APK
apktool d suspicious-app.apk -o decompiled/

# Convert to Java source with jadx
jadx -d jadx-output/ suspicious-app.apk

Search the decompiled source for common privacy-relevant patterns:

# Look for hardcoded API keys or tracking IDs
grep -r "api_key\|tracking_id\|analytics_token\|MIXPANEL\|AMPLITUDE" decompiled/

# Find network endpoints
grep -r "http\|https" decompiled/ | grep -v "schema\|xmlns" | head -50

# Identify data retention calls
grep -r "SharedPreferences\|SQLiteDatabase\|ContentProvider" decompiled/

Evidence from static analysis can demonstrate that the application was designed to collect specific data categories, reinforcing network capture evidence showing that data being transmitted. When an app’s privacy policy claims no location data is collected but the decompiled source contains explicit GPS coordinate serialization to a third-party domain, that contradiction is compelling evidence of a knowing misrepresentation.

Class actions involving advertising ecosystems require documenting the chain of data sharing, not just collection from the user. Identify which third-party SDKs are embedded in an application:

# List all packages in decompiled APK
find decompiled/smali -name "*.smali" | sed 's|decompiled/smali/||' | \
  cut -d/ -f1-3 | sort -u | grep -v "^com/yourapp"

Common advertising and analytics SDK packages to document include com/facebook/ads, com/google/firebase, com/amplitude, com/mixpanel, com/braze, and com/appsflyer. Cross-reference detected SDKs against the privacy policy’s disclosure of third-party data processors. Any SDK present in the binary but absent from the privacy policy disclosures is a potential violation of transparency requirements under CCPA and similar laws.

Legal Considerations

Preserve evidence properly from the start. Chain of custody matters:

Use write-once storage when possible
Hash all files and record checksums
Document who collected what and when
Avoid modifying original files

When engaging with attorneys, prepare a technical summary that translates your findings for non-technical readers. Courts and juries do not read HAR files or JSONL logs. Describe in plain language what data was collected, what the privacy policy said about that data, and why the technical evidence proves a discrepancy. Attorneys experienced in data privacy litigation — particularly those familiar with CCPA, GDPR, or BIPA class actions — will guide you on jurisdiction-specific admissibility requirements.

Consult with an attorney before initiating any formal action. This guide provides technical documentation methods, not legal advice.

Built by theluckystrike — More at zovo.one