Golden Drop security boundaries
Golden Drop is intentionally small: temporary file delivery, short retention and a narrow recipient surface. This page describes what the production service actually protects, what it records and what it does not claim.
What is the Golden Drop security model?
Golden Drop creates a high-entropy temporary access URL for an uploaded file, stores only hashes of the access and management secrets, serves the file as a download attachment, checks expiry on every request and removes expired copies through durable cleanup.
The recipient does not authenticate. The share URL itself therefore acts as the temporary access capability: protect it like any other private bearer-style link and send it only to the intended recipient.
Download access and deletion are separate capabilities
Every uploaded object gets a random download secret and a different management secret for early deletion. Only SHA-256 hashes of those values are stored in SQLite. Knowing the ordinary download link does not grant deletion rights, and the recipient page does not expose management controls.
There is no API that lists uploaded files. A recipient must know the private URL.
Access is short-lived by design
Canonical Golden-integrated deliveries use a server-selected lifetime of 1 hour. Clients do not extend that lifetime. Each request checks the persisted expiry before returning bytes, so an expired link stops working even if the background cleaner has not run yet.
The backend also supports early revocation with the separate management credential. Expiry and revocation remove the server-side copy and its metadata from active delivery.
Golden Drop is not permanent cloud storage. Do not use it as the only copy of something you need to retain.
The original filename is metadata, not a storage path
Files are stored under random server-generated object names. The original filename is retained as metadata for the recipient-facing download name but is never trusted as a server filesystem path.
Golden Drop stores durable metadata in SQLite and the temporary object bytes on the service filesystem. On startup and during periodic cleanup, the service also removes stale partial uploads and crash-orphaned objects that are no longer referenced by active metadata.
Files are delivered, not executed
User HTML is not rendered as a Golden Drop web page. User-supplied files are served as attachments using application/octet-stream, with the original filename presented only as a download name.
Golden Drop does not run an LLM over uploaded content, summarize files or classify their meaning. It is a delivery service.
Golden Drop is not an antivirus or malware scanner
The current product does not claim antivirus scanning, content disarm/reconstruction or semantic safety classification. Recipients should download files only from senders and workflows they trust. General file-upload threat modeling guidance is available in the OWASP File Upload Cheat Sheet.
Temporary pages are designed not to become public content
- Production delivery uses HTTPS and HSTS.
- Temporary pages and file responses use
X-Robots-Tag: noindex, nofollow, noarchive. - Private responses use
Cache-Control: no-storeandReferrer-Policy: no-referrer. - Browser responses use CSP, frame denial, MIME sniffing protection and a restrictive Permissions Policy.
- User files are forced to attachment download rather than browser execution as a Drop page.
noindex is an indexing hint, not access control. Privacy comes from the high-entropy URL, short lifetime and the absence of public listing — not from search-engine directives.
Private URL tokens are intentionally kept out of ordinary access logs
The production nginx vhost has ordinary access logging disabled, and Uvicorn runs without an access log. The application does not intentionally log request bodies, headers, access tokens, management tokens or the internal Golden client key.
This reduces the chance that a temporary access token appears in routine service logs. It is not a promise that every network, host, browser, proxy or recipient environment outside Golden Drop has no logs of its own.
Production Golden delivery limits
These are current product limits, not promises of permanent plan limits. If the implementation changes, this page should change with it.
Do not use Golden Drop as a secret vault
Do not send raw passwords, private keys, API tokens, recovery codes, seed phrases or other credentials through Golden Drop. Short expiry reduces exposure time; it does not turn an ordinary file-delivery link into a dedicated secret-management system.
What Golden Drop does not promise today
- No customer-managed encryption-at-rest key model is claimed.
- No specific data-residency jurisdiction is promised on this page.
- No malware scanning or file-content safety certification is claimed.
- No permanent deletion guarantee outside the verified expiry/revocation and service-storage boundary is claimed.
- No permanent audit archive or long-term version history is provided.
What Golden Drop protects against — and what it cannot
| Guessing public file IDs | Mitigated with high-entropy access secrets and no public file listing. |
|---|---|
| Old links staying active forever | Mitigated by persisted expiry checks and cleanup. |
| Filename path traversal | Mitigated by random server-side object names; the original filename is metadata only. |
| Browser execution as a Drop page | Mitigated by attachment delivery and restrictive response headers. |
| Recipient forwarding the active URL | Not prevented. Anyone with the active URL can use it before expiry. |
| Malicious file contents | Not detected by Golden Drop today; there is no antivirus/content-safety claim. |
HTTPS protects transport; it does not change the bearer-link model
Production Golden Drop is served over HTTPS, so the ordinary network transport to and from the public service is encrypted in transit. The service then stores the temporary server-side object until expiry or earlier deletion.
Golden Drop does not claim end-to-end encryption in which the service is cryptographically unable to read the file. Do not describe the current product that way unless the implementation changes and is separately verified.
Expiry cannot revoke a copy the recipient already downloaded
Expiration controls access to Golden Drop's server-side copy and URL. Once a recipient successfully downloads the file, Golden cannot remotely delete that recipient's local copy, email attachment, browser download or downstream backup.
Use temporary links to limit the delivery window, not as a substitute for recipient trust, data-loss prevention or rights management.
Some files need identity, policy or long-term audit instead of a Bearer [REDACTED]
Choose another delivery or storage system when the workflow requires named-user authorization, passwords, organization policy enforcement, durable access logs, legal retention, customer-managed encryption keys or collaborative permissions over time.
A shorter lifetime reduces the opportunity for re-use, but the right expiry depends on how quickly the intended recipient can realistically download the file. AWS security guidance for pre-signed download URLs makes the same trade-off explicit: shorter expiry narrows reuse time but requires faster recipient action.
External guidance behind the boundary
- OWASP File Upload Cheat Sheet — threat modeling for untrusted file uploads and content handling.
- AWS Security Blog: secure file transfer with pre-signed URLs — expiry-window, URL-distribution and monitoring considerations for temporary URL access.
Before you send a file
- Name the exact artifact.Share the finished file or reviewed archive, not an entire workspace “just in case.”
- Remove raw secrets.Inspect generated configs, logs and exports before delivery.
- Send the URL privately.Anyone with the active link can download the file.
- Use permanent storage when retention matters.Golden Drop is intentionally temporary.