Skip to main content
Back to BucketSpace
Privacy Policy

BucketSpace Privacy Policy

Effective Date: September 3, 2026

1. Overview

BucketSpace is an open-source personal cloud storage software project designed to let individuals store files using Telegram's MTProto infrastructure as a storage layer. The software consists of:

  • A browser-based client application providing a personal vault drive interface and client-side encryption.
  • A Node.js backend service acting as a relay for Telegram MTProto connections.
  • Optional public link sharing functionality.
  • Client-side encryption of file payloads before transmission to the backend.

This Privacy Policy explains what technical information and data BucketSpace processes, where that information is handled, and the technical mechanisms implemented in the current software.

2. Information BucketSpace May Process

BucketSpace processes only the information necessary to provide authentication, client-side encryption, file uploads, file downloads, and optional link sharing.

Telegram Account Information

To authenticate with Telegram, the software processes:

  • Phone Number: Entered into the onboarding modal and transmitted over HTTPS to the backend (POST /api/v1/telegram/auth/send-code). It is held ephemerally in server memory for the duration of the login handshake (up to 10 minutes) and is not saved to any database or disk.
  • Telegram Verification Code: Sent by Telegram to your device, entered in your browser, and transmitted over HTTPS to the backend (POST /api/v1/telegram/auth/verify-code) to complete sign-in. It is discarded from server memory once authentication succeeds or fails.
  • Two-Factor Authentication (2FA) Password: If your Telegram account has cloud password protection enabled, the password is transmitted over HTTPS to the backend (POST /api/v1/telegram/auth/verify-2fa) to complete the MTProto SRP challenge. It is not saved to disk, database, or server logs.
  • Telegram Session Credentials: Upon successful authentication, Telegram issues a serialized session string (sessionString). The backend returns this credential to your browser, where it is stored in browser localStorage. During subsequent upload, download, and vault operations, your browser transmits this session credential to the backend within the x-telegram-session HTTP header. The backend maintains an in-memory connection pool for active MTProto clients (automatically evicted after 30 minutes of inactivity).

File Information

  • File Payloads: Files are divided into logical chunks in your browser and encrypted client-side using AES-256-GCM before transmission. The backend receives only encrypted binary ciphertext.
  • Filenames and Types: Filenames, MIME types, and file sizes are handled in browser memory and stored in browser localStorage.
  • Chunk Metadata & Integrity Hashes: For each chunk, the browser computes a SHA-256 checksum and cryptographic initialization vector (IV) to verify bit-exact integrity during subsequent downloads. This metadata is maintained in browser localStorage.

Browser Storage

BucketSpace uses browser localStorage on your local device. It persists the following keys:

  • bucketspace_master_encryption_key: 256-bit AES-GCM master key (never sent to the server or Telegram).
  • bucketspace_active_provider: Active provider ID and session credentials.
  • bucketspace_file_metadata: Local file list and chunk manifests.
  • bucketspace_resumable_*: Multipart upload progress markers.
  • bucketspace_shares: Locally saved public share tokens.

Public Sharing

When you create a public share link, the share token, optional passcode, shared file metadata, and chunk IDs are registered in the backend service's in-memory cache to allow authorized recipients to fetch the encrypted file parts.

3. How File Encryption Works

Browser File Chunk → AES-256-GCM Encryption → Encrypted Binary Data → Backend Relay → Telegram Cloud

The current application encrypts file chunks in the browser before they are sent to the storage backend:

  1. A 256-bit AES key is generated in your browser using the standard Web Crypto API (window.crypto.subtle).
  2. Files are sliced into bounded chunks (configurable, default 16 MB) in browser memory.
  3. Each chunk is encrypted using AES-256-GCM with a unique, cryptographically random 12-byte Initialization Vector (IV). A 128-bit authentication tag is appended to guarantee tamper detection.
  4. The encrypted binary payload is transmitted over HTTPS to the backend.
  5. When downloading, encrypted chunks are retrieved from Telegram via the backend, verified for SHA-256 integrity, and decrypted inside your browser using your locally held master key.

4. What BucketSpace Can and Cannot See

Backend Can Process

  • Incoming HTTP requests, paths, and headers.
  • The x-telegram-session authentication header.
  • Ephemeral login parameters during sign-in.
  • Encrypted chunk ciphertext and byte sizes.
  • Public share tokens and optional passcodes.
  • IP addresses available to hosting infrastructure.

Backend Does Not Intentionally Receive

  • Plaintext file contents (encrypted in browser prior to transmission).
  • Your 256-bit AES-GCM master encryption key.
  • Master passphrases used to derive encryption keys.

5. Telegram

BucketSpace uses Telegram as a third-party storage provider via MTProto. Users should understand:

  • Telegram is an independent third-party service; Telegram's own terms and privacy policies govern your account and stored data.
  • BucketSpace does not operate, own, or control Telegram's servers, data centers, or network policies.
  • Encrypted chunks are stored as documents within your account's Telegram cloud storage (in your dedicated vault channel).
  • You can review Telegram's Privacy Policy at: telegram.org/privacy

6. Hosting Providers: Vercel and Render

BucketSpace is designed to run across two cloud hosting environments:

  • Vercel: Hosts frontend web assets and user interface pages.
  • Render: Hosts the long-running Node.js backend relay for MTProto uploads and downloads.

These infrastructure providers process technical connection data according to their own privacy policies:

7. Cookies and Local Storage

BucketSpace does not use browser HTTP cookies or sessionStorage. BucketSpace relies exclusively on browser localStorage on your local device to store your encryption key, active provider session string, and file metadata catalog across visits.

8. Analytics and Tracking

Based on the current application implementation, BucketSpace does not intentionally integrate a third-party analytics or advertising tracker.

9. Logs and Technical Data

The backend service prints operational diagnostics, error traces, and Telegram MTProto status messages to standard output for server monitoring. Hosting layers (Vercel and Render) log technical connection data including IP addresses, timestamps, request URLs, and user agents. BucketSpace does not maintain a database of user request logs or browsing history.

10. Data Retention

  • Browser Storage: Stored locally until you clear browser data or click “Disconnect”.
  • Server In-Memory State: Login sessions expire in 10 minutes; MTProto clients evict after 30 minutes of inactivity; share records in memory clear upon backend server restart.
  • Telegram Cloud Data: Files remain on Telegram until deleted. Deleting files inside BucketSpace purges local metadata; permanent removal from Telegram requires deleting the corresponding message in your Telegram vault channel.

11. User Controls

You have direct control over your local data:

  • Disconnect Account: Clears session credentials from your browser.
  • Delete Files: Move files to Trash or permanently purge local metadata.
  • Revoke Shares: Remove generated public share tokens from your vault.
  • Clear Storage: Clearing your browser data removes all local keys and metadata.

12. Security Architecture

BucketSpace implements client-side AES-256-GCM cryptography, HTTPS transport encryption, server-side secret management via environment variables, origin-based CORS validation, and SHA-256 integrity verification.

Notice: No security architecture can guarantee absolute protection or 100% security against all potential threats, software defects, or compromised client devices.

13. Children's Privacy

BucketSpace is not directed to children under 13 years of age (or the applicable minimum legal age in your jurisdiction), and we do not knowingly collect personal information from children.

14. International Data Transfers

BucketSpace relies on third-party infrastructure (including Vercel, Render, and Telegram) operating globally. Data may be transferred, processed, and stored internationally subject to the terms and privacy policies of those services.

15. Changes to This Policy

This Privacy Policy may be updated as software features or infrastructure configurations evolve. Any updates will be published with a revised effective date.

16. Contact

For questions or inquiries regarding this Privacy Policy or BucketSpace, please contact:

Vanraj Solanki
Email: vanrajsolanki2875@gmail.com

17. Legal DisclaimerThis privacy policy is a product disclosure document and is not legal advice. It should be reviewed by qualified legal counsel before commercial/public launch.