Privacy Policy
Privacy-first: Minimal data, maximum protection
What We Don't Collect
- Raw IP Addresses - Only HMAC-SHA256 hashes stored temporarily in memory (keyed with a server secret — see note below)
- User Accounts - No accounts, no profiles, no login required
- Traditional Access Logs - No web server logs with IP/user-agent (we use a transparency log with hashes only - see below)
- Tracking Cookies - No analytics, no third-party trackers
About IP hashing: We use HMAC-SHA256 with a server-side secret key to hash IPs. Unlike plain SHA-256, HMAC prevents reverse-engineering via lookup tables — even with full access to the hashed values, the original IPs cannot be recovered without the secret key. The key is configurable via environment variable or auto-generated per instance.
What We Store (Minimal)
- Encrypted files (key in memory only)
- File metadata (name, size, expiration, view count)
- SHA-256 file hash (for blocklist/abuse prevention)
- Secret delete token (for file owner deletion)
- Optional note (if provided)
- Code snippets (content, language, title, expiration)
Code Snippets
Code snippets are stored in an in-memory database that is cleared on server restart. Snippet content is not encrypted server-side (unlike files) but can be password-protected with client-side encryption.
Snippets auto-delete after their chosen expiration time (1 hour to 30 days) or when download limits are reached.
Delete Link & Your Right to Erasure
Each upload generates a secret delete link containing a unique 32-character token. This link allows you to delete your file at any time before expiration.
Important: Keep your delete link private. Anyone with this link can delete your file. We cannot recover deleted files.
P2P Transfer
Zero server storage — strongest privacy mode. P2P transfers use WebRTC DataChannel to send files directly between browsers. The server acts exclusively as a signaling relay. No file data, file metadata, or transfer history is ever stored, logged, or cached.
What the server processes (ephemerally):
- SDP offers/answers — Session descriptions for WebRTC negotiation (codec info, connection parameters). Relayed in-memory, never stored.
- ICE candidates — IP addresses and port candidates for NAT traversal. Relayed to the peer and immediately discarded.
- Room metadata — Random 8-character ID, two WebSocket session references, creation timestamp. In-memory only, auto-deleted after 10 minutes.
What the server never sees:
- File content (transferred over encrypted DataChannel)
- File name, size, or type (exchanged only between browsers)
- DTLS encryption keys (negotiated directly between peers)
- Transfer progress or completion status
About ICE candidates and IP exposure: During signaling, ICE candidates containing the IP addresses of both peers are relayed through our server. This is a necessary part of WebRTC's NAT traversal mechanism. These addresses are held in memory only during the signaling phase and never written to disk or logs. After the room expires (10 minutes), all data is garbage-collected.
STUN servers: We use Google (stun.l.google.com) and Cloudflare (stun.cloudflare.com) public STUN servers for NAT discovery. STUN servers only see a lightweight binding request — never file data, room IDs, or signaling content.
TURN relay server: When configured, a TURN server provides relay fallback for users behind symmetric NATs or restrictive firewalls. The TURN server relays encrypted WebRTC traffic — it cannot decrypt the DTLS-encrypted DataChannel content. TURN credentials are delivered to the client via server-rendered HTML attributes. Self-hosted (e.g., coturn) or cloud providers (Cloudflare, Twilio, Xirsys) can be used.
QR Codes
QR codes are generated entirely in your browser using client-side JavaScript. No data is sent to external services.
Temporary Security Data
Brute Force Protection: We temporarily store HMAC-SHA256 hashed IP addresses in memory (not on disk) to prevent abuse. These keyed hashes cannot be reversed without the server's secret key and are automatically cleared after 1 hour.
Rate Limiting: Request counts are tracked temporarily in memory using HMAC-hashed IP addresses. No persistent storage, no raw IPs stored. API key holders receive higher rate limits.
Abuse Detection: A scoring system tracks suspicious patterns (failed auth, rapid uploads, scanning behavior). IPs exceeding the abuse threshold are temporarily blocked for 15 minutes. Scores decay automatically after 5 minutes of inactivity.
Third-Party Services & JavaScript Security
External Resources (CDNs & Fonts):
We load the following resources from external CDNs:
- Google Fonts (fonts.googleapis.com) - Inter typeface
- Cloudflare CDN (cdnjs.cloudflare.com) - Font Awesome icons
- jsDelivr CDN (cdn.jsdelivr.net) - Critical: Argon2 (encryption), JSZip, QR codes, Prism.js
- Tailwind CSS (cdn.tailwindcss.com) - Styling framework
When you load tmp0.cc, your browser makes requests to these CDNs. Standard HTTP request data (IP address, browser info, referrer) may be logged by these services according to their privacy policies.
Security Trust Model:
E2EE encryption depends on JavaScript from jsDelivr CDN. If jsDelivr were compromised, malicious code could theoretically intercept passwords before encryption. This is a fundamental limitation of browser-based E2EE.
Mitigations: We use Subresource Integrity (SRI) hashes to verify library integrity. For maximum security, advanced users can use our CLI tool (which doesn't depend on CDNs) or audit the source code.
Security Scanning
Virus Scanning: All uploads are scanned with ClamAV antivirus. Infected files are flagged.
Hash Blocklist: Known malicious or illegal content is automatically blocked based on SHA-256 hash.
Scanning Exceptions:
- Files larger than 2 GB skip virus scanning (ClamAV memory limit)
- E2EE files skip scanning (server cannot access plaintext content)
No Guarantee: Security scanning is provided on a best-effort basis. No antivirus can detect 100% of threats. Files marked as "clean" may still contain malware. Download at your own risk.
Encryption
Server-side (At-Rest): AES-256-GCM, key exists only in memory.
End-to-End Encrypted (E2EE — recommended default): Argon2id key derivation (6 iterations, 256MB memory, 4 threads) + AES-256-GCM. The UI recommends E2EE and provides a built-in password generator. A minimum entropy of 50 bits is enforced. Encryption/decryption happens entirely in your browser or CLI — the server never sees your password or plaintext.
True Zero-Knowledge mode: When enabled alongside E2EE, the server skips all plaintext processing (no metadata stripping, no virus scan, no hash blocklist). The upload is treated as an opaque blob. This provides the strongest privacy guarantee for stored files.
E2EE & ZK Files: Virus scanning is automatically skipped for E2EE and Zero-Knowledge files because the server cannot access the plaintext content. The download page shows "Scan disabled: End-to-end encrypted".
Automatic Metadata Stripping
For server-encrypted files, we automatically strip metadata from supported file types:
Supported formats:
- Images (JPEG, PNG, GIF, WebP, BMP, TIFF) - EXIF data removed (GPS, camera info, timestamps)
- PDF Documents - Author, title, subject, keywords, creator software removed
Limitations:
- • Other formats (Word, Excel, MP3, MP4, ZIP, etc.) are NOT stripped
- • E2EE files skip stripping (server cannot process encrypted content)
- • File size itself can be identifying (we do NOT pad file sizes)
- • File names are NOT anonymized (visible to server for all modes)
- • ZIP archives may contain files with unstripped metadata
For maximum privacy with sensitive files, use E2EE and consider stripping metadata yourself before upload.
Transparency Log (This IS a Log)
We maintain a Merkle tree-based audit log of file operations. This is different from traditional access logs:
- What IS logged: File hash (SHA-256), operation type (upload/download/delete), timestamp
- What is NOT logged: IP addresses, user agents, file content, file names, passwords
- Merkle tree structure - Cryptographic proof that log entries cannot be altered
- Publicly verifiable via API at /api/v1/transparency/*
Privacy note: If someone knows a file's SHA-256 hash, they can check the transparency log to see when it was uploaded/downloaded. This enables auditing but also means file hashes are semi-public information. For maximum privacy, use E2EE (the hash of encrypted ciphertext reveals nothing about the original file).
CLI Tool & API
A command-line interface (tmp0) is available with full E2EE support for automated workflows and power users.
All features are accessible via public API endpoints documented in the API section.
Data Retention & Deletion
Files auto-delete after their chosen expiration time (1 hour to 30 days).
- Deletion method: File content is overwritten with zeros before deletion
- No backups: We do not maintain backups of user files
- Database entries: Metadata is deleted from the database
Limitation: On modern SSDs with wear-leveling, "secure deletion" cannot be guaranteed at the hardware level. The SSD controller may retain old data in spare blocks. For highly sensitive data, use E2EE - even if old ciphertext is recovered, it cannot be decrypted without your password.
Jurisdiction & Legal Framework
Operating Jurisdiction: Iceland
tmp0.cc operates under Icelandic law. Iceland is a member of the European Economic Area (EEA), ensuring strong privacy protections equivalent to EU standards while benefiting from Iceland's robust legal framework for digital privacy and freedom of expression.
All legal matters, disputes, and data protection inquiries are governed exclusively by Icelandic law and subject to the jurisdiction of Icelandic courts.
GDPR & EEA Data Protection Compliance
As an EEA member state, Iceland has incorporated the General Data Protection Regulation (GDPR) into national law through the Icelandic Data Protection Act (Lög um persónuvernd og vinnslu persónuupplýsinga).
Data Processing Principles:
- Lawful Basis: Processing based on legitimate interest (service provision) and user consent (file upload action)
- Data Minimization: We collect only data strictly necessary for service operation (see "What We Store" above)
- Purpose Limitation: Data used exclusively for file hosting and security; never sold, shared, or used for profiling
- Storage Limitation: Automatic deletion after user-selected expiration period (1 hour to 30 days maximum)
- No Data Processor Agreements: We do not share personal data with third-party processors. All data processing occurs on our own infrastructure
Your GDPR Rights:
- • Right to Erasure: Use your delete link for immediate deletion, or contact us
- • Right to Access: Your file + metadata is accessible via your share link
- • Right to Portability: Download your file at any time before expiration
- • Supervisory Authority: Persónuvernd (Icelandic Data Protection Authority) - personuvernd.is
Government & Legal Request Policy
Our Commitment to User Privacy
We are committed to protecting user privacy to the fullest extent permitted by law. Any government or law enforcement request for user data will be subject to rigorous legal scrutiny.
Request Handling Procedure:
- 1. Validity Assessment: All requests are reviewed for legal validity under Icelandic law. Invalid or overly broad requests are rejected outright.
- 2. Jurisdictional Challenge: Requests from non-Icelandic authorities must comply with applicable mutual legal assistance treaties (MLATs) and Icelandic procedural requirements.
- 3. Legal Contest: We will challenge requests that we believe are unlawful, disproportionate, or infringe on fundamental rights. Legal challenges will be pursued through all available appellate channels.
- 4. Minimum Disclosure: If legally compelled to comply, we provide only the specific data explicitly required by a valid court order—nothing more.
Technical Limitation: For E2EE files, we cannot provide plaintext content even under legal compulsion—we do not possess decryption keys. Any disclosed data would be limited to encrypted ciphertext and minimal metadata.
Transparency Report
In the interest of transparency, we publish annual statistics on legal and takedown requests received. This report is updated annually.
| Year |
DMCA Requests |
Government/Legal Requests |
Data Disclosed |
| 2025 |
0 |
0 |
0 |
| 2026 |
0 |
0 |
0 |
Last updated: February 2026 • Next update: January 2027
Backup & Data Recovery Policy
Zero Backup Architecture
tmp0.cc intentionally operates without any backup systems. This is a deliberate architectural decision to maximize privacy—not a limitation.
Infrastructure Design:
- No Off-Site Backups: User files are not replicated to backup servers or cloud storage
- No RAID Redundancy: Servers do not use RAID configurations that would create data copies
- No Snapshot Systems: No VM snapshots, filesystem snapshots, or point-in-time recovery
- Ephemeral by Design: Server failure, crash, or decommissioning results in permanent, irrecoverable data loss
User Responsibility: If you need to retain a file beyond its expiration, download a copy. We cannot recover deleted or expired files under any circumstances—this is a feature, not a bug.
Verifiability: Our zero-backup policy is verifiable through our infrastructure: single-server deployment, no replication endpoints, no backup agent processes. This architecture ensures that when data is deleted, it is truly gone—with no hidden copies to potentially surface later.
Key Management & Hardware Security
HSM-Grade Key Protection
Encryption keys for server-side at-rest encryption are managed with hardware-level security protections.
Key Management Architecture:
- Hardware Security Module (HSM): Master encryption keys are stored in dedicated HSM hardware with tamper-resistant protection
- Memory-Only Operations: Working keys derived at runtime and held exclusively in volatile memory—never written to disk
- Key Rotation: Automatic key rotation policy with forward secrecy—compromise of current keys cannot decrypt historical data
- Secure Key Derivation: Per-file keys derived using HKDF-SHA256 from master key + unique file salt
Server Restart Behavior: On server restart, the HSM is queried to re-derive the master key. If the HSM is unavailable or tampered with, the service cannot start and existing encrypted data becomes permanently inaccessible.
E2EE Independence: For E2EE files, the above infrastructure is irrelevant—your password-derived key never touches our servers. E2EE security depends solely on your password strength and client-side cryptographic implementation.