Security, Privacy, and Trust Boundaries

Pastey is a privacy-first secure sharing and control platform for sensitive text and files. This page is the short public summary of how the service handles data today. It is intentionally conservative: when there is a tradeoff, limit, or open question, Pastey should say so plainly.

Pastey is designed for deliberate sharing, controlled retention, and honest trust boundaries. It is not trying to become a general-purpose cloud drive, a source-control platform, or a broad collaboration suite.

• Pastey keeps baseline privacy features outside the billing gate.
• Credits expand storage, delivery, retention, and automation headroom rather than access to safer defaults.
• Public marketing and trust copy should reflect the same boundary-conscious product stance.

• Anonymous text Pasteys are possible today and default to unlisted sharing.
• Private Pasteys and file attachments currently require a signed-in owner.
• Pastey now offers a sealed-link mode for text-only unlisted shares. In that mode, the browser encrypts the text before upload and the decryption key stays in the URL fragment.
• Pastey now supports custom expiration timestamps and optional view limits.
• Baseline privacy features stay free. Credits expand storage, delivery, retention, and automation headroom.
• Matching Apple, Google, or Microsoft email addresses do not automatically link to an existing Pastey account.
• Linking providers, unlinking providers, adding a first password to a provider-only account, and deleting the account now require recent verification.
• Signed-in users can now delete their account, optionally export owned Pasteys first, and receive a minimal deletion receipt email when an email address is available.
• Narrow recent-activity viewing stays simple, but larger audit exports or richer filters now require recent account verification.
• Signed-in accounts can create scoped automation tokens, and Pastey stores only hashed token secrets plus minimal metadata for them.
• Pastey now runs a narrow BTCPay-hosted credit top-up experiment for signed-in accounts. That flow stores purchase and fulfillment metadata, not raw payment instruments.
• Pastey does not support direct account-password API login for long-lived bearer credentials.
• Standard Pasteys use encryption at rest. Sealed-link Pasteys use client-side encryption, but Pastey does not claim that every Pastey is end-to-end encrypted.
• Raw routes, server-side password unlock, in-place editing, view limits, and attachments are intentionally unavailable for sealed-link Pasteys in v1.
• Anonymous create and abuse-report routes are rate-limited with short-lived HMAC-derived connection fingerprints instead of raw IP storage in Pastey's database.
• Shared Pasteys can be reported in-product without creating an account, but Pastey cannot proactively scan the plaintext of sealed-link content it cannot decrypt.
• Infrastructure and third-party providers may still receive operational metadata needed to run the service.

If you create an account, Pastey stores the account information needed to run that account, such as your email address, optional display name, authentication records, and session data.

If you create a Pastey, Pastey stores the metadata needed to deliver it, such as its title, timestamps, language setting, privacy settings, expiration settings, and view state. If you attach files while signed in, Pastey also stores file metadata and the backing storage key.

If you create a sealed-link Pastey, Pastey stores the ciphertext payload and non-secret metadata only. The fragment key used to decrypt that Pastey is not sent to the server and is not stored by Pastey.

If you sign in with Apple, Google, or Microsoft, Pastey also stores the linked-account records required to support that sign-in method. Password reset requests store an email address, a reset token, and an expiration time until that recovery flow completes or expires.

If you create an automation token while signed in, Pastey stores a public identifier, a hash of the secret part of that token, a label, its scopes, creation and expiration timestamps, and a coarse last-used timestamp. Pastey does not store the raw automation token after creation.

If you use the BTCPay top-up flow while signed in, Pastey stores the minimum purchase metadata needed to reconcile and fulfill the credits, such as an internal purchase id, the BTCPay invoice id, the selected credit pack, status timestamps, and the resulting credit-ledger entry.

Pastey uses stored information to authenticate accounts, protect access to private or password-protected Pasteys, deliver expiring, limited-view, or burn-after-reading behavior, store attachments, and operate password reset and support flows.

• Unlisted Pasteys are accessible by direct link and are not published in a public browse page.
• Private Pasteys are restricted to the owning signed-in user.
• Password-protected Pasteys require the correct password before content or locked files are returned to non-owners.
• Expiring, limited-view, and burn-after-reading controls limit how long or how often a Pastey remains available.
• Attached files inherit the same access rules as the parent Pastey.
• Sealed-link Pasteys keep plaintext decryption in the browser only when the viewer has the full link, including the fragment key after #key=.

By default, Pastey encrypts stored content at rest before saving a Pastey. Account passwords and Pastey passwords are stored as hashes, not plaintext.

Sealed-link mode is different. In that mode, the browser encrypts the text before upload and the decryption key stays in the URL fragment, so the normal server read path only stores and returns ciphertext plus metadata.

That is helpful, but it is not the same as saying every Pastey is end-to-end encrypted. Standard Pasteys are still decryptable by the running application during authorized reads, and even sealed-link Pasteys still expose operational metadata such as title, timestamps, and access patterns needed to run the service.

Anonymous creation is available for text Pasteys. If you want owner-only private access, file attachments, or account-based management, you currently need to sign in.

Pastey's first payment experiment is also account-bound today, but the product direction still favors lower-disclosure options like vouchers where those paths can be offered safely and honestly.

If you use Apple, Google, or Microsoft sign-in, Pastey does not auto-link providers by matching email address alone. A provider is only linked to an existing account when the already-signed-in user starts that link from Account Settings.

Pastey uses cookies for signed-in sessions and, when needed, to remember that a viewer has successfully unlocked a password-protected Pastey for a short period. Disabling cookies may affect some account and access-control features.

Pastey treats sign-in method changes as sensitive actions. Linking a new provider, removing a linked provider, adding a first local password to a provider-only account, and deleting the account all require a recent verification window.

Password-backed accounts can unlock that window by confirming the current password. Provider-only accounts must sign out and back in with a linked provider first. Pastey also blocks removal of the last remaining sign-in method so users do not accidentally lock themselves out.

Pastey applies the same recent-verification guard to larger recent-activity exports and richer audit-history filters. Small in-product recent-activity viewing stays available without turning audit export into a silent high-retention side channel.

Pastey now supports a separate opt-in list for launch announcements, product updates, security and privacy notes, and optional workflow guides. That list is distinct from transactional account email such as password resets or account-deletion receipts.

New account creation may also trigger a one-time onboarding message with practical first-use guidance. That message is account guidance, not enrollment in the updates list.

If you subscribe, Pastey stores your email address, selected update categories, a hashed manage-link token, and the timestamps needed to track subscription, preference changes, and unsubscribe events.

If you unsubscribe, Pastey keeps a bounded record of that leave request so the app can honor it and avoid accidental re-adds. Update emails should always include an easy path back to the preferences page instead of hiding unsubscribe behind account-only flows.

Non-expiring Pasteys remain available until they are deleted. Expiring Pasteys are removed by access paths and cleanup jobs. View-limited and burn-after-reading Pasteys are deleted immediately after the final allowed successful read flow.

Account deletion now removes the account and every owned Pastey tied to it. Users can optionally export owned Pasteys and attachments before deletion. If an email address exists on the account, Pastey also sends a minimal deletion receipt after completion.

If an account export includes sealed-link Pasteys, the export contains the stored ciphertext payload files and metadata that Pastey has on hand. Pastey cannot recover the fragment key or reconstruct plaintext from the server side.

• Signed-in sessions currently use a 30-day max age.
• Automation tokens remain active until they expire or are revoked, and expired tokens are now cleaned up automatically.
• Password-reset records are deleted automatically after their 1-hour expiration window.
• Pastey unlock cookies for password-protected content are limited to 1 hour.
• Anonymous abuse-prevention buckets and automation-token rate-limit buckets expire when their short rate-limit windows end.
• Abuse reports currently target a 30-day retention window unless an active safety or legal incident requires a shorter or longer hold.
• Application error and background-job logs should be kept to the shortest practical window, with a current target of 30 days max.

The application does not intentionally persist raw viewer IP addresses in its own database. For a small number of anonymous abuse controls, Pastey derives short-lived HMAC fingerprints from network metadata instead of storing those raw identifiers directly. Infrastructure and third-party providers may still receive request and service metadata that is necessary to operate the service.

Today, Pastey relies on third-party services for storage, key management, email delivery, and optional OAuth sign-in. Those systems may have their own operational logs or retention behavior outside the application database.

Account deletion receipts are also delivered through the email provider when an account email address exists. Those receipts are intentionally minimal and should not become a reason for Pastey to keep a separate local archive of deleted account content.

The current BTCPay experiment uses a hosted checkout provider boundary. BTCPay may observe payment settlement metadata for that flow, while Pastey keeps only the narrow purchase and fulfillment records needed to apply credits and support disputes or refunds.

Pastey is moving toward a logging posture that avoids full email addresses, reset tokens, API tokens, raw automation-token values, and raw storage keys in first-party application logs.

• Pastey does not claim that every Pastey is end-to-end encrypted. Sealed-link mode is a narrow client-side encrypted mode, not the default for the whole product.
• Pastey does not currently provide full anonymity from infrastructure providers.
• Sealed-link mode does not hide titles, timestamps, or other operational metadata from the service or its providers.
• Pastey cannot prevent an authorized recipient from copying or forwarding content after access is granted.
• No internet-connected service can promise perfect secrecy or absolute security.

Pastey may disclose information if required by law or if doing so is necessary to protect the service, its users, or others from abuse or harm. Shared Pasteys now include an in-product abuse report path, and confirmed phishing, malware, exploit delivery, or similarly dangerous content may be disabled or deleted without waiting for a full account-style appeal workflow.

Abuse controls are being expanded carefully so they do not become an unnecessary surveillance layer. The goal is to keep anonymous sharing possible while still limiting obvious spam and giving people a direct safety valve when something harmful is sent through the service.

Sealed-link mode creates a narrower trust-and-safety posture. Pastey can still rate-limit abusive traffic, act on metadata-level reports, and disable stored ciphertext, but it cannot proactively scan the plaintext of sealed-link content it cannot decrypt.

We do not knowingly collect personal information from children under the age of 13.

We may update this page as Pastey changes. As the product matures, we intend to make this explainer and the underlying trust documentation more specific rather than less.

If you have any questions or concerns about Pastey's security or privacy posture, please contact us at support@pastey.io.