Transparency Report

Last updated: May 11, 2026

Limits Built Into the System

Our service is designed so that certain things are impossible — not forbidden by policy, but prevented by architecture. No legal order, internal decision, or security breach can change these facts because they are consequences of how the software works:

Files are encrypted before they leave your device. We never receive plaintext private storage content. We couldn’t read it even if we wanted to.
Encryption keys never leave your device. We don’t generate, transmit, store, or have access to the keys that protect your private storage.
Encrypted shards go directly to Sia storage providers, not through Pinner’s indexer. The indexer only sees the sealed object: the object ID, encrypted fields, and slab layout. It never sees the actual shard content.
Private storage metadata is scrambled before it reaches us. The names, types, and structures of your private files are encrypted on your device. We store the resulting ciphertext, but cannot make sense of it.
Private storage metadata cannot be silently altered. Your client signs metadata using keys that live on your device. If anything changes in transit or at rest, the signature check fails and your client rejects it.
Shared Sia objects change the privacy equation. When a user generates a share URL, the URL includes the information needed to decrypt the object. Once shared, the content is effectively as public as an IPFS pin — anyone with the URL can download it, and we can verify what it contains. Share URLs are time-limited, but anyone who accessed one could have already pinned the object to their own account. There is no way to restrict sharing to specific users or revoke it once shared.
IPFS pins are public by design. IPFS content gets a content address (CID) that anyone can use to fetch it. We can see CIDs and we can see that you pinned them. Shared Sia objects have similar properties. If you need privacy for data, use private storage and do not generate share URLs.

What Our Infrastructure Actually Has

For full transparency, here is every category of user information our systems store or can access:

For all users:

Account details — email address, name, billing information (card details are handled by Stripe; we see only a token and last 4 digits)

For private Sia storage (not shared):

Object IDs — 32-byte content-derived hashes that identify sealed objects
Encrypted master keys — we store them, but cannot decrypt them without your app key
Slab layouts — which shards live on which storage providers (this is routing data, not content)
Encrypted metadata blobs — ciphertext we cannot interpret
Signatures — integrity checks over object IDs and encrypted fields
Timestamps — when objects were created or modified
Storage consumption numbers — how many bytes an account is using (needed for billing)

All of the above is ciphertext or hashes we cannot interpret. We have no way to recover plaintext data or metadata from it.

For shared Sia objects:

Everything listed under private Sia storage above
Share URLs — when a user generates a share URL, it contains the object ID plus the information needed to download and decrypt the content. If Pinner has the share URL, we can read and verify the content.
Once shared, the privacy properties are effectively equivalent to IPFS. Anyone with the URL can retrieve the content, and we can verify and take it down (unpin = remove from indexer state, shards orphaned).

For IPFS pins:

CIDs — content identifiers for pinned IPFS data. This is the correct IPFS term.
Pin timestamps — when a CID was pinned or unpinned

IPFS content is public by design. Anyone with the CID can retrieve it independently of Pinner. We can verify and unpin IPFS content.

We do not store: plaintext file contents from private storage, readable file names or types from private storage, encryption keys, or long-term API access logs.

Track Record

The following statements are accurate as of the date on this page. We update this section quarterly. If we remove a statement in a future update, assume it is no longer true. If this page goes more than 90 days without an update, treat it as potentially out of date.

As of May 11, 2026, Pinner has never:

Been served with a National Security Letter
Been served with a FISA order or directive
Received any government demand that came with a gag order
Been ordered or asked to add logging, data collection, or surveillance that isn’t already described in our Privacy Policy
Turned over user data to any government body
Received any request to monitor a user’s activity in real time
Been contacted by law enforcement about a user

Next scheduled update: August 2026. We commit to updating this report at least every 90 days.

Report abuse: abuse@pinner.xyz | Legal inquiries: legal@pinner.xyz