Privacy Tools Guide

How to Audit Your Cloud Storage Privacy

Most people pick a cloud storage provider based on price and storage size, then forget about it. The provider can read your files (unless zero-knowledge encrypted), scan them for content, share access logs with advertisers, and hand over data to law enforcement. An audit makes this concrete — what does your provider actually know?

This guide covers a systematic six-step audit process: reviewing privacy policies for specific red flags, requesting and analyzing your data export, auditing OAuth grants, verifying encryption claims, finding stale shared links, and reading transparency reports. For each problem found, concrete remediation options are listed.

What Cloud Providers Can Access

Provider type What they can see
Standard (Dropbox, Box, OneDrive) All your files, metadata, previews
E2EE optional (iCloud with Advanced) Files if E2EE enabled; metadata always visible
Zero-knowledge (Tresorit, ProtonDrive) Encrypted blobs only, no file content
Self-hosted (Nextcloud) Whatever your server admin has access to

Even zero-knowledge providers can see: file names (unless encrypted), timestamps, file sizes, IP address, and account data.

The difference between a standard provider and a zero-knowledge provider is not just a matter of trust — it is a technical architecture difference. Standard providers encrypt your data at rest using keys they control; they can decrypt any file at will. Zero-knowledge providers use client-side encryption before upload; the provider stores ciphertext only and provably cannot read the content. However, most providers claim “encryption” without specifying which model — this audit process makes that distinction concrete.

Step 1: Review the Privacy Policy

Key questions:

1. Do you scan file content?
   - For malware? (common)
   - For advertising?

2. Who do you share data with?
   - "Analytics partners" = advertising ecosystem
   - "Service providers" = subprocessors

3. Law enforcement response:
   - Warrant required?
   - Transparency report published?
   - Do they notify you of requests?

4. Retention policy:
   - How long after deletion?
   - Backup copies — how many, retained how long?

5. Encryption:
   - At rest? (standard, they hold keys)
   - Client-side / zero-knowledge?

Specific policy language to flag as concerning:

Compare this to privacy-forward policy language:

Step 2: Request Your Data Export

# Google Drive:
# takeout.google.com → Select Drive → Export
# Includes: files, metadata (created/modified dates, sharing settings)

# Dropbox:
# dropbox.com → Settings → Privacy → Download your data
# Includes: file list, sharing events, linked apps, location of accesses

# OneDrive:
# account.microsoft.com → Privacy → Download your data

# iCloud:
# privacy.apple.com → Request a copy of your data

Analyze the metadata:

#!/usr/bin/env python3
"""Analyze Google Takeout export for privacy-relevant metadata."""
import json
from pathlib import Path

def analyze_google_export(export_dir):
    metadata_files = list(Path(export_dir).rglob("*.json"))
    shared_files = []
    third_party_apps = set()

    for mf in metadata_files:
        try:
            data = json.loads(mf.read_text())
            if data.get('shared'):
                shared_files.append(mf.stem)
            for perm in data.get('permissions', []):
                if perm.get('role') == 'reader':
                    third_party_apps.add(perm.get('displayName', 'Unknown'))
        except (json.JSONDecodeError, KeyError):
            pass

    print(f"Shared files: {len(shared_files)}")
    print(f"Third-party access: {third_party_apps}")

analyze_google_export("/path/to/takeout")

What to look for in the export beyond file count:

Step 3: Audit Connected Apps and OAuth Grants

# Google Drive connected apps:
# myaccount.google.com → Security → Third-party apps with account access
# Revoke anything you don't recognize or no longer use

# Dropbox:
# dropbox.com → Settings → Connected apps
# Shows last used date — revoke stale access

# OneDrive:
# myapps.microsoft.com

OAuth grants are a common, overlooked exposure point. An app granted access to your cloud storage retains that access indefinitely unless you revoke it — even if you deleted the app, stopped using the service, or the developer sold it to a new owner. Review the scope of each grant:

For Dropbox, the “last used” timestamp in the Connected Apps panel is valuable. An app last used three years ago still has full access to your current files. Revoke anything not used in the last 90 days unless you have a specific reason to keep it active.

Step 4: Check Encryption Status

# Verify TLS on provider endpoints
openssl s_client -connect api.dropbox.com:443 -brief 2>/dev/null | head -5
# Look for: Protocol: TLSv1.3

# For providers claiming zero-knowledge:
# Inspect network traffic with mitmproxy
mitmproxy --mode transparent
# If files are readable as plaintext → NOT zero-knowledge

The TLS version check tells you whether data is encrypted in transit. TLSv1.3 is current; TLSv1.2 is acceptable; TLSv1.0 or TLSv1.1 is a red flag that the provider is not maintaining their infrastructure. Run this check against the API endpoint, not just the main web domain — some providers serve the web UI on TLS1.3 but use older configurations for their API backends.

The mitmproxy check is the definitive test for zero-knowledge claims. Configure your browser or desktop client to use an HTTP proxy (127.0.0.1:8080), install the mitmproxy CA certificate, then upload a file with known content. Inspect the traffic — if you can see the file content in the mitmproxy stream, the encryption is happening server-side, not client-side. True zero-knowledge clients encrypt before the data reaches the network layer.

Old shared links remain active indefinitely — a common exposure point:

import dropbox

dbx = dropbox.Dropbox('YOUR_API_TOKEN')
links = dbx.sharing_list_shared_links()
print(f"Active shared links: {len(links.links)}")

for link in links.links:
    print(f"  {link.path_lower}")
    print(f"  URL: {link.url}")

Beyond counting them, check whether your provider allows expiring shared links. Dropbox Business and Google Drive support expiration dates on shared links. If you are on a personal plan that does not support expiring links, the only option is to revoke them manually.

For files you shared publicly (no password, no expiry), check whether search engines have indexed the URL. A file shared via a predictable URL pattern may appear in search results. Search for site:dropbox.com/s/ "your-username" to find indexed links.

Step 6: Check Data Residency and Transparency Reports

# Find where your cloud provider's servers are located
host api.dropbox.com
whois $(dig +short api.dropbox.com | head -1)

# Check transparency reports:
# Dropbox: dropbox.com/transparency
# Google: transparencyreport.google.com
# Apple: apple.com/legal/transparency
# Proton: proton.me/legal/transparency

What to look at:

Transparency reports tell you how likely the provider is to hand over your data if requested. Google received tens of thousands of government requests per year and complied with the majority. Proton received a fraction of that number and publishes a canary statement that would disappear if they received a National Security Letter requiring silence.

Data residency matters if you are under specific regulatory obligations (GDPR, HIPAA, CCPA). Use the whois output to determine what jurisdiction governs the IP blocks hosting your data, and whether that matches your provider’s stated data residency policy.

Remediation If You Find Problems

# Option 1: Encrypt before upload (Cryptomator)
# Files encrypted locally, upload encrypted blobs to any provider

# Option 2: Migrate to zero-knowledge provider
# Proton Drive, Tresorit, Filen.io

# Option 3: Self-host (Nextcloud)

# Option 4: Rclone with client-side encryption
rclone config
# Set up encrypted remote:
# Type: crypt
# Remote: your existing remote (e.g., dropbox:/)
# Password: set strong password
rclone copy /local/files encrypteddropbox:backup/

Cryptomator is the easiest remediation if you want to keep your current provider. It creates an encrypted vault folder on your disk that syncs to the cloud — files are encrypted before the sync client sees them. The provider stores ciphertext. Cryptomator is open source and audited. Install it, create a vault in your cloud sync folder, and move sensitive files into it.

Rclone’s crypt remote wraps any other Rclone remote with client-side encryption. This is suitable for backup workflows where you are not syncing files across devices but pushing from a single machine. The configuration creates an encrypted remote that looks like a standard Rclone destination — rclone sync /local/path encryptedremote: works identically to syncing to an unencrypted remote.

Step 7: Analyze Access Patterns from Your Data Export

Once you have your data export, analyze patterns that reveal privacy implications:

#!/usr/bin/env python3
"""Analyze cloud storage export for privacy-revealing access patterns."""
import json
from datetime import datetime, timedelta
from collections import Counter

def analyze_access_patterns(export_dir):
    """Identify suspicious access patterns from timestamps."""

    # Parse event logs if available
    events = []
    for event_file in Path(export_dir).glob("**/activity.json"):
        try:
            with open(event_file) as f:
                events.extend(json.load(f))
        except (json.JSONDecodeError, FileNotFoundError):
            pass

    if not events:
        print("No activity logs found in export")
        return

    # Analyze access frequency
    access_times = [datetime.fromisoformat(e['timestamp'])
                   for e in events if 'timestamp' in e]

    # Access pattern analysis
    hours_accessed = Counter([t.hour for t in access_times])
    days_accessed = Counter([t.weekday() for t in access_times])

    print(f"Total access events: {len(access_times)}")
    print(f"Most active hours: {hours_accessed.most_common(5)}")
    print(f"Most active days: {days_accessed.most_common(3)}")

    # Identify unusual access gaps (potential storage access without your activity)
    access_times.sort()
    for i in range(len(access_times)-1):
        gap = access_times[i+1] - access_times[i]
        if gap > timedelta(days=7):
            print(f"⚠️  Unusual gap: {gap} between {access_times[i]} and {access_times[i+1]}")

from pathlib import Path
analyze_access_patterns("/path/to/export")

This reveals whether the cloud provider accessed your files outside of your actions—indicating scanning or backup operations.

Step 8: File Scanning and Content Analysis

Determine what scanning the provider does:

# Request provider's scanning policies
# Google Drive:
support.google.com → "How does Google scan files?"
# Usually scans for: malware, CSAM, copyright, policy violations

# Check if provider scans encrypted files
# Logic: If they can scan E2EE files, they must have access to keys
# If they say "encrypted files aren't scanned," confirm they don't make exceptions

# Test with a known signature
# Create file with known malware signature (EICAR test file)
EICAR='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
echo "$EICAR" > test-file.txt

# Upload to provider
# Provider's scanning system will flag this
# If flagged → they're scanning; if not → either no scanning or encrypted

Recommendations by Threat Model

Different cloud storage choices based on specific threats:

Threat: Government surveillance
→ Use zero-knowledge provider (Proton Drive) with Tor browser

Threat: Corporate espionage
→ Use end-to-end encrypted with audit logging (iCloud Advanced Data Protection)

Threat: Accidental data leakage
→ Use provider with strong access controls (Tresorit)

Threat: Long-term privacy (journalists, researchers)
→ Use decentralized storage (IPFS via Filecoin) or self-hosted (Nextcloud)

Threat: Compliance/regulatory
→ Use provider certified for HIPAA/FedRAMP (AWS with specific configs)

Implementation: Client-Side Encryption Layer

If you’re using an unencrypted provider but need encryption:

# Install Cryptomator
brew install cryptomator

# Create encrypted vault
# Choose "Dropbox" or "Google Drive" as backend
# Set password for vault

# All files placed in encrypted vault are:
# - Encrypted locally on your device
# - Uploaded as encrypted blobs
# - Cannot be decrypted by the cloud provider

# Workflow:
# 1. Unlock vault (mount virtual drive)
# 2. Copy files to vault drive
# 3. Files automatically encrypt and upload
# 4. Lock vault (unmount drive)

This adds encryption layer atop any unencrypted provider, but introduces complexity.

Audit Checklist

Before fully migrating to a cloud provider:

□ Reviewed privacy policy (20+ minutes reading)
□ Requested and analyzed data export
□ Checked transparency report and government requests
□ Verified encryption type (at-rest vs E2EE)
□ Tested file access logging
□ Understood retention policies for deleted files
□ Confirmed deletion actually removes from all backups
□ Checked if provider scans encrypted content
□ Reviewed TLS/transport security implementation
□ Understand data residency and jurisdiction
□ Verified no third-party data sharing
□ Confirmed 2FA available and enabled
□ Tested account recovery process
□ Reviewed company's track record for breaches
□ Compared to alternatives for your use case

Complete this before storing sensitive data.

Built by theluckystrike — More at zovo.one

Explore Our Developer Guides

© 2026 theluckystrike Developer Guides