Note: The terms, policies, etc. outlined below are only applicable to the YeetFile service hosted on yeetfile.com, as well as the code as it exists in the repository (available on GitHub or SourceHut).

If you are not using yeetfile.com or hosting the service, these terms cannot be guaranteed.

Privacy Policy

Introduction

YeetFile is intentionally designed to protect user privacy as much as possible, while also retaining enough information to achieve its core functionality.

Here is a brief overview of how user privacy is treated:

  • Emails are optional -- you can use YeetFile using only an account ID, and add an email at a later date if desired
  • Cookies only store information related to session information
  • There are no advertisements
  • Data is not shared with any third party
  • No third party requests are made (third party JS, CSS, etc) aside from calls to Stripe or BTCPay when paying for account upgrades.
  • Payments always reference a user's payment ID rather than their account ID. The payment ID can be recycled to a new ID after a purchase.
    • Note that recycling your payment ID removes the ability for a YeetFile instance admin to debug any payment issues, so this should only be done after payment has been confirmed and your account has been updated.
  • Key management:
    • Every user has a unique "user key" that is never sent to the server
    • The user key is used to encrypt the user's private key before it is sent to the server
    • The only key that is ever stored in plaintext is your public key, which is used to encrypt files shared with you by another user
  • HTTPS is used everywhere
  • User account "passwords" (a unique login key derived using the user key as the payload and the first 16 bytes of a BLAKE2b-256 checksum of the user's password) are hashed with bcrypt before being stored in the database.
  • Files that are "sent" (not stored in the vault) are not associated with a user ID and are not tracked to a specific user aside from modifying monthly send limits with the sent file size.
  • Records of sent files are removed once the sent file expires.

Storage

All files stored in a user's vault are encrypted before upload. The key used for encryption depends on where in the vault the files are uploaded:

  • If the file or folder is in the root level of the vault (not under a subfolder), it is encrypted using a randomly generated key that is encrypted with the user's public key, and can only be decrypted with the user's private key
  • If the file or folder is in a subfolder, it is encrypted using the folder's key, which requires a "key sequence" to decrypt (the keys required to decrypt all parent folder keys before the current one).

Files uploaded to the vault are associated with user IDs, since that is the only way to retrieve files for a specific user.

Sending

Files uploaded through the YeetFile Send feature are not associated with user IDs, since they are meant to be completely ephemeral. The link to the resulting file is shown to the user who uploaded the file, but is otherwise inaccessible to that user at any point afterwards.

The file size is subtracted from a user's remaining "Send" meter, but is adjusted for encryption overhead and does not exactly match the size of the file on the backend.

Key Management

Every user has 3 keys associated with their account:

  1. The "User" key: This key is generated on signup using Argon2 with the password as the payload and SHA-256 hash of the identifier (email or account ID) as the salt. This is never sent to the server in any form.
  2. The Private key: This is the private half of the RSA asymmetric keypair generated on signup and is used to decrypt all content encrypted with the user's public key. This is encrypted using the user's "User" key before sending to the server.
  3. The Public key: This is the public half of the RSA asymmetric keypair generated on signup and is used to encrypt all content uploaded by the user, as well as encrypt content shared with the user by another user. This is sent to the server in plaintext, since it is required to be readable by other users for sharing content with the user.

The "User" key is generated every time the user logs in, but is not stored in any way on their client device. Once it is used to decrypt the user's private key, it is not used again during that session.

On the web, the asymmetric keypair is stored using IndexedDB, and the resulting CryptoKey objects created during the signup/login process are marked as non-exportable (meaning they cannot be dumped as raw bytes afterwards). These keys are removed on logout.

There's additionally a "login key" that is used for validating the user's credentials when logging in, which is generated using Argon2 with the user key as the payload and the first 16 bytes of a BLAKE2b-256 checksum of the user's password as the salt. Aside from login-related activities, this key/"password" is never used, and is bcrypt hashed before storing in the user database.

Sessions / Cookies

YeetFile uses cookies on the web and CLI to track valid sessions. This is a unique value that does not contain any data about the user.

If you have reason to believe your session has been compromised in any way, logging out will mark your session identifier as invalid.

Billing

Billing details (for any platform, Stripe, BTCPay, etc.) are not stored in YeetFile in any form. This includes credit card details, billing address, billing email, etc -- these are never stored in the YeetFile database. Transactions are entirely isolated to the platform they are performed on, and never seen or stored by YeetFile. Instead, every user is given a unique payment ID on signup that is used for transactions. This payment ID can be referenced when resolving billing issues and -- for most users -- can be ignored.

For users that seek an additional layer of privacy at the cost of some convenience, a user's payment ID can be recycled if your billing plan is non-recurring. To do this, a user may go to the account view and under "Advanced" select "Recycle Payment ID". This removes the user's old payment ID and generates a new one, which removes any way to reference their previous purchases. The one exception to this is if the user used the same email as their YeetFile account email during the checkout process, but this is not applicable for users with accounts that are ID-only.

Logging

YeetFile does not log successful user interactions with the service. Errors related to database queries, backend file retrieval, and other similar critical features that are required for general operation, are logged. These error logs typically contain information related to the specific action. For example, if a file lookup by ID to B2 fails, a log entry such as the following would appear:

Error: Failed to locate file in B2 with ID: 'abcdefg1234567'

Error logs such as these are needed for debugging any issues that users may encounter while using YeetFile.