Law Enforcement Guide
Last updated: May 11, 2026
This page explains what Pinner can and cannot provide in response to lawful legal process. We recommend reading this in full before submitting a request.
What Pinner Is
Pinner is a cloud storage service that offers three distinct products:
- IPFS Pinning — We keep public, content-addressed files available on the InterPlanetary File System. IPFS content is public: anyone with a CID (content identifier) can retrieve it independently of Pinner.
- Private Sia Storage — We provide encrypted, S3-compatible file storage built on the Sia decentralized network. Files are encrypted on the user’s own device before upload. The keys needed to decrypt those files are never on our infrastructure. Our indexer (indexd) stores sealed objects — object IDs, encrypted master keys, slab layouts, encrypted metadata, and signatures — but cannot read any of it.
- Shared Sia Objects — Users can generate share URLs for their Sia storage objects. A share URL is a time-limited link that includes the object ID and the information needed to download and decrypt the content. Once a share URL exists, the content is effectively as public as an IPFS pin — anyone with the URL can retrieve it, and Pinner can verify the content using the share URL. Share URLs cannot be restricted to specific users or revoked once shared.
What Data We Have
Pinner’s systems hold the following categories of user information:
| Category | What It Includes | Where It Lives |
|---|---|---|
| Account info | Name, email address, billing records | Pinner’s database; payment details processed by Stripe |
| IPFS pin records | Which CIDs an account has pinned, timestamps | Pinner’s database |
| Private Sia storage records (sealed objects) | Object IDs, encrypted master keys, slab layouts, encrypted metadata blobs, signatures, timestamps | Pinner’s indexer (indexd) — all metadata is ciphertext we cannot decode |
| Shared Sia object records | Same as private, plus share URLs which include the ability to decrypt | Pinner’s indexer (indexd) |
| Storage sizes | Byte counts per account (derived from slab layouts) | Pinner’s indexer — needed for billing |
| IP addresses | Device addresses recorded with account activity, uploads, downloads, and storage changes | Retained for security, abuse prevention, and download attribution |
What Data We Do Not Have
Because of how our service is built, the following information never passes through or is stored on our infrastructure:
- File contents from private Sia storage that has NOT been shared — encrypted files travel directly between the user’s device and Sia network hosts; Pinner is not in the data path. For shared Sia objects, we CAN decrypt and verify content using the share URL.
- Readable file names, types, or directory structures from private Sia storage — these are encrypted on the user’s device before reaching our indexer. Shared objects can be verified via share URL.
- Encryption keys — generated and stored only on the user’s device; we never have access
- Long-term IP address logs — we retain IP addresses for security, abuse prevention, and download attribution
What We Can and Cannot Produce
We Can Produce (with Valid Legal Process)
| What | Details |
|---|---|
| Account registration details | Name, email address, account creation date |
| Billing records | Transaction history, payment amounts, payment method type (card via Stripe or crypto) |
| Shared Sia object contents | If we have the share URL, we can download and verify the plaintext content of a shared Sia object |
| Sia storage object records | Object IDs, encrypted metadata blobs, slab layouts, timestamps associated with an account — but we cannot interpret encrypted metadata or content without a share URL |
| IPFS pin associations | Which CIDs a specific account has pinned or unpinned, and when |
| Storage consumption | How much storage an account is using |
| Encrypted metadata blobs | The raw ciphertext stored by our indexer (we cannot interpret it) |
| IP address logs | IP addresses associated with account activity, uploads, downloads, and storage operations |
We Cannot Produce — Not Withheld, Literally Unavailable
| What | Why |
|---|---|
| Decrypted file contents from private Sia storage that has not been shared | Files are encrypted on the user’s device. The keys are on the user’s device. We do not have the keys and cannot decrypt the data. A court order compelling production of plaintext private storage files would fail because the plaintext does not exist on our systems. We CAN decrypt shared Sia objects if we have the share URL. |
| Encryption keys | Never stored on our infrastructure. They exist only on the user’s device. |
| Readable private storage file names, types, or structures | Encrypted on the user’s device before reaching our indexer. We store the resulting ciphertext but cannot reverse it. |
| Real-time monitoring of user activity | Our architecture does not support it. Encrypted data does not flow through our servers. We have no visibility into what users are uploading, downloading, or transferring in private storage. |
| Altered or fabricated metadata | Private storage metadata is signed on the user’s device. If anyone modifies it in transit or at rest, the signature fails and the client rejects it. We cannot forge valid metadata. |
Public and Shared Content and Law Enforcement
IPFS pins are public content. If you have a CID, you can independently retrieve the content from the IPFS network without Pinner’s involvement.
Shared Sia objects are effectively public once a share URL has been generated. If you have a share URL, you can download and decrypt the object. Unlike IPFS CIDs, share URLs are time-limited, but anyone who accessed the URL could have copied or pinned the content.
For both IPFS pins and shared Sia objects, Pinner CAN verify the content AND can remove it from our infrastructure (unpin/delete from our indexer). For shared Sia objects, this means the object is removed from the indexer state and the underlying encrypted shards on storage providers are orphaned.
How to Submit a Request
- Send requests to: legal@pinner.xyz from an official government or law enforcement email address
** Note:** abuse@pinner.xyz is for public abuse reports (CSAM, malware, copyright). Law enforcement requests must go to legal@pinner.xyz. 2. Include: requesting agency name, contact information, nature of the investigation, and the specific data requested 3. Attach: any legal process that has been issued (subpoena, warrant, court order) 4. Identify the account: provide the email address or account ID you are asking about
We review every request for legal validity before responding. We will challenge or reject requests that lack proper legal process, are overbroad, or are not permitted under applicable law.
Pinner only responds to legal process issued by US governmental entities or courts, or through applicable international cooperation mechanisms (MLAT requests, letters rogatory, etc.).
User Notification
We notify users of legal requests when we are legally permitted to do so. If a gag order or other legal restriction prohibits notification, we comply with that restriction.
Reimbursement
We may seek reimbursement for costs incurred in responding to legal process, as permitted by applicable law.
Questions
Contact legal@pinner.xyz with any questions about this guide or our legal compliance processes.