Privacy Policy

1. Information We Collect

When you interact with INFI-CLOUD, we collect certain categories of information that are necessary for us to provide you with a functioning, secure, and personalized cloud storage experience. We have carefully designed our data collection practices to gather only what is essential for operating the platform, and we do not engage in excessive or unnecessary data harvesting. The information we collect falls into several distinct categories, each of which is described in detail below.

1.1 Account and Identity Information

INFI-CLOUD relies exclusively on Google OAuth 2.0 for user authentication. This means that we never ask you to create a username and password combination, we never store passwords on our servers, and we never handle your Google account credentials directly. When you choose to sign in or create an account through Google Sign-In, Google's authentication service transmits a limited set of profile information to our servers on your behalf. Specifically, we receive and store your email address, your full display name as set in your Google account, and the URL that points to your Google profile picture.

Your email address serves as your unique identifier within the INFI-CLOUD system. It is the key that associates all of your uploaded files, folder structures, sharing activities, and account settings with your specific account. We do not use your email address for marketing purposes, we do not add it to mailing lists, and we do not share it with third-party advertisers. INFI-CLOUD does not send you any emails whatsoever — we have no SMTP integration, no transactional email system, and no newsletter functionality. Your email exists in our system purely for account identification and session management.

Your display name and profile picture URL are used solely to personalize your dashboard interface. When you log in, you see your name and picture in the navigation bar, making it clear which account you are using. If you change your name or profile picture in your Google account, these changes will be reflected in INFI-CLOUD the next time you sign in, because we retrieve this information fresh during each authentication event rather than caching it permanently.

When a new user signs in for the first time, our system automatically provisions a free-tier account with 2 terabytes of storage capacity. We record this registration event by sending a notification to our private administrative Telegram channel. This notification includes the new user's name, email address, and the timestamp of registration. This practice exists so that our development team can monitor the health of the registration flow and be aware of growth patterns, but the notification channel is a private, restricted Telegram channel that only the platform administrator has access to.

1.2 File and Folder Metadata

For every file you upload to INFI-CLOUD, we create and maintain a comprehensive metadata record that enables us to organize, display, and manage your files within the dashboard. This metadata includes the original filename as you uploaded it, the folder in which the file resides (including any nested subfolder path), the exact timestamp of when the upload was completed, and the file size measured in bytes. We also track the MIME type of the file to determine how it should be previewed in the browser.

Beyond basic attributes, we maintain several status flags for each file. These include whether you have starred the file as a favorite for quick access, whether the file has been moved to the trash bin, whether it is pinned to the top of your file listing (you can pin up to ten items at a time), and whether it has a PIN lock applied. If you have set a lock PIN on a file, the PIN itself is stored alongside the file metadata. Similarly, if you have configured a share PIN for generating protected public links, that PIN is also retained in the metadata record.

Each file is assigned a unique public hash — a short alphanumeric identifier that is used to construct shareable URLs. Even though this hash exists for every file, it does not mean the file is publicly accessible; the hash only becomes functional when you actively create and distribute a share link. We also store the file's owner identifier (your email address or the internal "admin" identity), the parent folder reference for nested folder navigation, any tags you have applied to the file, comments left by you or collaborators, the version history chain, and any self-destruct expiry timestamp you may have configured.

For folder-level data, we record the folder name, its position in the hierarchy (parent-child relationships for nested folders), the identity of the folder's owner, and any folder-level PIN locks you have set. We also maintain records of folder share links, tracking the hash identifier, creation time, the sharing user's identity, and the active/inactive status of each link.

1.3 File Content

The actual content of your uploaded files — the binary data itself — is processed through our upload engine and stored as chunked documents. When you upload a file, our system splits it into segments of up to 19 megabytes each, and each segment is transmitted to and stored within a private Telegram channel via the Telegram Bot API. We track the Telegram message identifiers for each chunk in our database, which allows us to reassemble the complete file when you request a download, preview, or stream. The file content is never analyzed, scanned, parsed for keywords, or processed in any way beyond what is necessary for storage and retrieval operations. We do not extract text from your documents, we do not perform optical character recognition on your images, and we do not generate thumbnails or derivative works from your media files for our own purposes.

1.4 Activity and Audit Information

INFI-CLOUD maintains a structured audit log that records meaningful actions taken within your account. This log exists primarily for your security benefit — it allows you (and, in the case of administrative accounts, the platform administrator) to review a chronological history of account activity and identify any suspicious or unauthorized actions. The audit log tracks a comprehensive set of forty-one distinct action types, covering file operations such as uploads, deletions, restores, renames, moves, and downloads; organizational actions like starring, pinning, locking, and unlocking files; collaboration events such as sharing, commenting, tagging, and version management; folder operations including creation, deletion, renaming, and sharing; account events like logins, logouts, and failed login attempts; administrative actions such as adding or removing administrators and upgrading storage tiers; and system-level events including API key management, webhook configuration changes, database exports, and settings modifications.

Each audit log entry captures several pieces of contextual information: the type of action performed, a human-readable label describing the action, the email address of the user who performed the action, the target of the action (for example, the filename that was uploaded or the folder that was created), additional details or notes about the action, a precise timestamp, the IP address from which the action originated, and a short unique identifier for the log entry itself. To keep this log manageable and prevent indefinite growth, we enforce a rolling cap of five thousand entries. Once this cap is reached, the oldest entries are automatically and permanently pruned as new ones are added, meaning that old audit data is not retained indefinitely.

1.5 Network and Technical Information

On every request made to the INFI-CLOUD platform, we capture two pieces of technical information. First, we extract your client IP address, which we determine by reading the X-Forwarded-For HTTP header (if present behind a reverse proxy or CDN) or by falling back to the direct remote address of the connection. Second, we generate a unique request identifier — a UUID — which is assigned to your request and included in response headers as X-Request-ID. This request identifier is used purely for internal debugging and tracing purposes. It allows our engineering team to correlate specific user reports with server-side log entries when diagnosing technical issues.

Your IP address is recorded in several places within the system. It appears in audit log entries, in API analytics logs (when you use the Developer API), in feedback submissions, and in help desk tickets. It is also used to enforce IP whitelisting rules on Developer API keys, should you choose to configure that security feature. We do not use your IP address for geolocation-based advertising, behavioral profiling, or any commercial purpose.

1.6 Feedback and Support Information

When you use the built-in feedback form within the INFI-CLOUD dashboard, we collect the text of your feedback message, your name and email address (from your active session), your current IP address, and your browser's User-Agent string. This information is packaged into a structured notification and delivered to our private Telegram support channel. The User-Agent string helps our team understand which browser and operating system you are using, which is often critical for diagnosing display issues, upload failures, or compatibility problems. We do not use this information for tracking purposes, and it is only retained within the Telegram channel where it was delivered.

1.7 Device and Browser Preferences

INFI-CLOUD stores a single user preference in your browser's Local Storage: your chosen visual theme. The platform supports multiple themes, including light, dark, midnight, forest, sunset, lavender, and AMOLED modes. Your theme preference is stored locally on your device and is never transmitted to our servers. This means that if you use INFI-CLOUD on a different device or browser, you will need to set your theme preference again, because it is not synced across sessions or devices.

2. How We Use Your Information

The overarching principle governing our use of your information is straightforward: we use your data only to provide, maintain, secure, and improve the INFI-CLOUD platform. We do not engage in secondary uses of your data such as advertising, behavioral analytics, user profiling, or machine learning model training. Every piece of information we collect has a specific, clearly defined operational purpose, and we do not repurpose data beyond those defined boundaries.

2.1 Providing Core Cloud Storage Services

Your email address is the foundational identifier that ties together your entire INFI-CLOUD experience. When you upload a file, the system tags it with your owner identifier so that it appears in your dashboard and no one else's. When you create a folder, it is associated with your account. When you search for files, the search engine filters results to show only items that belong to you. This per-user data isolation is not merely a feature — it is a fundamental architectural decision that ensures every database query, every API response, and every page render is scoped exclusively to the authenticated user's data.

File metadata is used to render the dashboard interface accurately. We use filenames and folder paths to display your file tree. We use upload timestamps to sort files chronologically and to populate the "Recent" view. We use file sizes to calculate your storage consumption and display a progress bar showing how much of your allocated quota you have used. We use starred, pinned, and trashed status flags to organize files into the appropriate views — Starred files appear in the Favorites section, pinned files appear at the top of directory listings, and trashed files appear in the Trash Bin with their remaining retention countdown.

Tags that you apply to files are used exclusively to power the tag-based filtering and browsing features within your dashboard. Comments you leave on files are stored and displayed in the file detail view, visible only to you and anyone you have shared the file with via a direct link. Version history entries are maintained so that you can review, restore, or delete previous iterations of a file. None of this data is used for purposes outside of serving you the features you have requested.

2.2 Authentication and Session Management

Your Google profile information is used during the sign-in process to establish a secure server-side session. When you authenticate through Google, we verify your email against our user accounts database, set the appropriate session flags (authentication status, user email, display name, profile picture URL, and a CSRF token), and redirect you to your dashboard. For subsequent page loads within the same session, the session cookie is used to identify you without requiring re-authentication through Google on every request.

2.3 Security and Abuse Prevention

The audit log, IP address tracking, and request ID system work together to form our security monitoring infrastructure. If your account experiences suspicious activity — such as a large number of failed login attempts, unexpected bulk deletions, or API calls from unfamiliar IP addresses — the audit log provides a forensic trail that can help identify and respond to the incident. IP addresses are also used to enforce the IP whitelisting feature on Developer API keys, which is an optional security measure that restricts API access to only the IP addresses you have explicitly approved.

Rate limiting on the Developer API is enforced using per-minute request counters keyed to your API key hash and the current minute. These counters exist as small files in the server's temporary directory and are automatically cleaned up after two minutes. This mechanism protects both you and the platform from accidental or malicious request floods.

2.4 Platform Improvement and Diagnostics

Feedback submissions, help desk tickets, and error logs are used by our development team to identify bugs, prioritize feature requests, and improve the overall reliability of the platform. When you report an issue, the technical details included in your submission (IP address, User-Agent string, and the context of the error) help us reproduce and resolve the problem more efficiently. We do not share this diagnostic information with external parties, and it is used solely for internal engineering purposes.

API analytics data — the rolling log of the last ten thousand API requests — is used to monitor API health, identify popular endpoints, detect error patterns, and plan capacity improvements. This data is aggregated and presented in the admin analytics dashboard as summary statistics such as total request counts, active key counts, and top endpoint rankings. Individual request records are retained only within the rolling log and are overwritten as new requests arrive.

2.5 Storage Quota Enforcement

We calculate your total storage usage by summing the sizes of all files associated with your account that are not currently in the trash. This calculation is performed on each page load to render the storage usage indicator in your dashboard. Your current storage tier — whether the default free tier of 2 terabytes or an upgraded tier of up to 5 terabytes — determines the maximum capacity shown in the progress bar and enforces upload limits. Storage upgrades are activated through passcodes and do not involve any financial transactions, payment processing, or collection of billing information.

3. Data Storage Architecture and Infrastructure

Understanding where and how your data is physically stored is critical to evaluating our privacy practices. INFI-CLOUD employs a distinctive storage architecture that differs significantly from traditional cloud storage providers, and we believe you should understand exactly how it works.

3.1 The Telegram-Backed Storage System

The foundational storage layer of INFI-CLOUD is built on top of the Telegram Bot API and private Telegram channels. When you upload a file to INFI-CLOUD, the file content is not stored on our own servers or in a traditional cloud storage service such as Amazon S3, Google Cloud Storage, or Microsoft Azure Blob Storage. Instead, the file is processed by our upload engine and transmitted to a private, restricted Telegram channel that is controlled exclusively by the INFI-CLOUD system. The file is stored as one or more document messages within this channel, and the Telegram message identifiers are recorded in our metadata database so that we can retrieve the file when you request it.

For files smaller than 19 megabytes, the entire file is sent as a single Telegram document message. For larger files — INFI-CLOUD supports uploads of up to 2 gigabytes — the file is automatically split into 19-megabyte chunks by our upload engine. Each chunk is sent as a separate Telegram document message, and the collection of message identifiers is stored as an ordered list in the metadata record, allowing seamless reconstruction of the complete file during downloads or previews.

This architecture means that the physical storage of your file data is subject to Telegram's own infrastructure and data handling policies. Telegram stores data across its distributed server network, which spans multiple data centers internationally. While we maintain full logical control over your data through our application layer — including who can access it, when it is deleted, and how it is organized — the underlying physical storage is managed by Telegram's infrastructure team. All communications between our servers and the Telegram API are conducted over encrypted HTTPS connections.

3.2 The Metadata Database

All metadata about your files, folders, share links, user accounts, tags, comments, versions, audit logs, and system settings is stored in a single JSON document that we refer to as the "database." This database document is itself stored as a pinned message within the same private Telegram channel used for file storage. Every time a change is made — such as uploading a new file, renaming a folder, or revoking a share link — the entire database document is updated, the new version is pinned in the Telegram channel, and the previous version is deleted.

To ensure fast page loads and responsive interactions, we maintain an in-process cache of this database with a thirty-second time-to-live (TTL). This means that when you load your dashboard, the system first checks whether it has a recent copy of the database in memory. If the cached copy is less than thirty seconds old, it is used directly without contacting the Telegram API. If it is older, the system fetches a fresh copy from Telegram. All database write operations immediately refresh this cache, so your own changes are always reflected instantly even if another user's changes might take up to thirty seconds to propagate.

Database write operations are serialized using a thread-level write lock. This prevents two simultaneous operations — for example, two concurrent file uploads — from creating a race condition that could corrupt the database. The write lock ensures that each modification is applied atomically and completely before the next one begins.

3.3 The Chunked Upload Engine

For handling large file uploads efficiently, INFI-CLOUD operates a separate chunked upload engine. On the client side, when you initiate an upload of a large file, your browser slices the file into 5-megabyte segments and sends them sequentially to the server via the upload_chunk endpoint. On the server side, these incoming segments are aggregated into 19-megabyte parts — the optimal size for Telegram document uploads — in the server's temporary directory. Once a part reaches the target size, it is dispatched to the Telegram API in a background thread, and the temporary file is deleted.

In addition to the standard Flask-based upload engine, INFI-CLOUD also operates a high-performance asynchronous upload server built on the Quart ASGI framework. This secondary engine, which listens on port 8001, uses a streaming approach that writes incoming request data directly into Telegram-sized parts without first buffering the entire upload to disk. This design keeps peak server memory usage bounded at approximately 19.5 megabytes regardless of the size of the file being uploaded, which is important for both performance and security — it prevents a single large upload from exhausting server resources.

During the upload process, temporary chunk files are created in the system's temporary directory with a distinctive prefix. These files are automatically cleaned up upon successful upload completion, upon upload failure, and during a startup sweep that runs every time the server boots. This sweep identifies and removes any orphaned temporary files that may have been left behind by a previous server crash or unexpected shutdown.

3.4 Video and Audio Streaming

When you preview a video or audio file in INFI-CLOUD's built-in media player, the file is not downloaded entirely before playback begins. Instead, our streaming engine implements HTTP Range requests as specified in RFC 7233. This means your browser can request specific byte ranges of the file, allowing you to skip to any point in a video or audio track without waiting for the entire file to buffer. The server responds with HTTP 206 Partial Content responses, delivering 512-kilobyte blocks on demand.

The streaming engine resolves the Telegram CDN download URL for each file part and caches these URLs in memory for approximately one hour (3,600 seconds), since Telegram CDN URLs are temporary and expire. No server-side transcoding, re-encoding, or format conversion is performed. The file is delivered to your browser in its original format, and all rendering is handled by your browser's built-in HTML5 media player capabilities.

3.5 Encryption Practices

All data transmitted between your browser and the INFI-CLOUD server, and between the INFI-CLOUD server and the Telegram API, is encrypted in transit using TLS (Transport Layer Security) over HTTPS. This protects your data from interception during transmission.

However, we want to be straightforward about the current state of at-rest encryption: files stored within the Telegram channel are stored in their original, unencrypted form as Telegram document messages. While the Telegram channel is private and accessible only through the INFI-CLOUD bot's credentials, we do not currently apply an additional layer of client-side or server-side encryption (such as AES-256 encryption) to file payloads before uploading them to Telegram. The practical implication is that the security of your stored files depends on the combination of our application-layer access controls (ownership checks, session authentication, PIN locks) and Telegram's own infrastructure security measures. We are transparent about this because we believe you deserve an honest assessment of how your data is protected, rather than vague claims of "military-grade encryption" that many services make without substantiation.

4. Security Measures and Protections

Protecting your data is not an afterthought at INFI-CLOUD — it is baked into the architecture, the codebase, and the operational decisions we make every day. While no system can guarantee absolute security, we employ a layered defense strategy that combines authentication controls, data isolation, access restrictions, and monitoring capabilities to minimize the risk of unauthorized access or data loss.

4.1 Authentication Security

By relying exclusively on Google OAuth 2.0 for authentication, we eliminate an entire class of security vulnerabilities related to password storage and management. We never store passwords, password hashes, or password hints on our servers. We never implement "forgot password" flows that could be exploited. We never send password reset emails that could be intercepted. Your Google credentials are handled entirely by Google's own authentication infrastructure, which benefits from Google's extensive investment in account security, including two-factor authentication, suspicious login detection, and device-level verification.

On our side, sessions are managed using Flask's cryptographically signed session cookies. The session cookie is signed with a server-side secret key that prevents tampering — if anyone were to modify the contents of the cookie, the signature verification would fail and the session would be rejected. The secret key is configured through an environment variable, and when properly deployed, it remains constant across server restarts so that user sessions persist. If the environment variable is not configured, a random key is generated at startup, which means sessions would not survive a server restart but would still be cryptographically secure during the server's uptime.

4.2 Data Isolation

Every file and folder record in the INFI-CLOUD database carries an "owner" field that identifies the user account to which it belongs. Every database query that retrieves, displays, or modifies user data includes an ownership check that compares the owner field against the currently authenticated user's identity. This means that even if two users upload files with identical names, each user sees only their own files. There is no scenario in which User A can see, access, download, or manipulate User B's files through normal platform usage.

The only exception to this strict isolation is the platform administrator account, which has visibility into all users' data for operational and support purposes. The administrator account is identified by a specific email address configured through an environment variable, and only a user authenticating with that exact Google account receives administrative privileges.

4.3 CSRF Protection

Cross-Site Request Forgery (CSRF) is a type of attack where a malicious website tricks your browser into making unwanted requests to a site where you are already authenticated. INFI-CLOUD defends against this by generating a unique, cryptographically random CSRF token for each user session. This token must be included with every state-changing request (POST, PUT, DELETE, PATCH) to administrative API endpoints. The token can be provided via the X-CSRF-Token HTTP header or as a field in the JSON request body. Requests that fail CSRF validation are rejected with a 403 Forbidden error. API requests authenticated with API keys (rather than session cookies) are exempt from CSRF checks because they use stateless authentication and are not susceptible to CSRF attacks.

4.4 Security Response Headers

Every response from the INFI-CLOUD server includes several security-oriented HTTP headers. The X-Content-Type-Options header is set to "nosniff" to prevent browsers from guessing the content type of a response, which defends against certain types of cross-site scripting attacks. The X-Frame-Options header is set to "SAMEORIGIN" to prevent the INFI-CLOUD interface from being embedded in iframes on other websites, which protects against clickjacking attacks. Each response also includes an X-Request-ID header containing the unique identifier assigned to that request, enabling end-to-end tracing for diagnostic purposes.

4.5 PIN-Based Protection

INFI-CLOUD offers multiple layers of PIN-based protection for users who want additional security on sensitive content. Folder-level PIN protection allows you to set a numeric PIN on any folder. When a PIN is set, the folder's contents cannot be viewed until the correct PIN is entered during the current session. The unlocked state is tracked in the session, meaning that if you log out or your session expires, you will need to re-enter the PIN on your next visit.

Individual file locking works similarly — you can set a PIN on any file, and the file cannot be previewed, downloaded, or modified until unlocked. To remove a lock, you must first verify the current PIN, preventing unauthorized lock removal. Share link PIN protection adds a password gate to publicly shared files, requiring anyone who visits the share link to enter the correct PIN before they can view or download the content.

4.6 API Key Security

Developer API keys are generated as long, cryptographically random tokens with a distinctive prefix format (INFI_live_ or INFI_unified_ followed by a 48-byte random token). Before storage, each key is hashed using the SHA-256 algorithm. This means that even if someone gained unauthorized access to the database, they would not be able to recover the original API keys — they would only see one-way hashes. The raw key is displayed exactly once at the time of creation and cannot be retrieved afterward. In the administrative dashboard, keys are displayed in a masked format that shows only the first and last few characters.

Each API key can be configured with a specific set of permissions (read, write, delete, admin), restricting what operations the key can perform. Keys can also be configured with IP whitelists, limiting usage to requests originating from specific IP addresses. An optional expiry date can be set on each key, after which the key is automatically rejected regardless of its permissions or IP configuration. Rate limiting is applied per key at a default rate of 120 requests per minute, enforced through filesystem-backed counters that work correctly even in multi-worker deployment configurations.

4.7 Request Size Controls

To prevent denial-of-service attacks through oversized requests, the Flask application is configured with a maximum content length of 2 gigabytes for the main upload route. The Developer API's direct upload endpoint enforces a more conservative limit of 50 megabytes, with a helpful error message directing users to the chunked upload endpoint for larger files. The chunked upload engine processes data in 5-megabyte segments from the client and 19-megabyte parts for Telegram upload, ensuring that server memory consumption remains bounded regardless of file size.

5. File Sharing, Public Links, and Collaboration

Sharing is one of the most privacy-sensitive operations in any cloud storage platform, and we have designed INFI-CLOUD's sharing system with that sensitivity in mind. You always maintain complete control over what is shared, who can access it, and for how long the access remains valid.

5.1 Individual File Share Links

When you generate a share link for a file, the system creates a unique, randomly generated hash identifier that serves as the public URL path. This link points to a dedicated public preview page where the recipient can view the file and, depending on the file type, preview it directly in their browser or download it. Creating a share link does not grant the recipient access to any other part of your INFI-CLOUD account — they can only interact with the specific file associated with that particular link.

You have extensive control over the behavior of share links. At the time of creation, you can specify an expiration period, which can range from a few hours to several days or be set to never expire. Once a link expires, any attempt to access it returns an error message, and the link is marked as inactive in your Shared Links dashboard. You can also protect share links with a PIN, requiring the recipient to enter a code before the file content is revealed. Furthermore, you can schedule a delayed block on a share link, which means the link will continue to work for a specified countdown period and then automatically deactivate itself — useful for time-sensitive document sharing. You can revoke or delete any share link at any time through your dashboard, and revocation takes effect immediately.

When a share link is created, the system records and stores the following data: the unique hash identifier, the name of the shared file, the creation timestamp, the expiration timestamp (if set), the owner's identity, and the active/inactive status of the link. If a PIN is configured, the PIN value is stored alongside the file metadata. These records are maintained as part of the "share_links" collection in our database and are subject to the same data retention policies as other metadata.

5.2 Folder Share Links

In addition to sharing individual files, you can generate share links for entire folders. A folder share link creates a public read-only directory listing that displays all active (non-trashed) files within the shared folder. Recipients can browse the folder contents and download individual files, but they cannot upload, modify, or delete anything within the folder. Folder share links are tracked in a separate "folder_share_links" collection in the database, with similar metadata to file share links: hash identifier, folder name, creation time, owner identity, and active status. You can revoke folder share links through your dashboard at any time.

5.3 Public Preview Pages

The public preview pages accessible via share links are standalone pages that do not require the recipient to have an INFI-CLOUD account. These pages display the file name, provide a download button, and — for supported file types — offer an in-browser preview powered by the same client-side rendering libraries used in the main dashboard (PDF.js for PDFs, SheetJS for spreadsheets, docx-preview for Word documents, and native HTML5 elements for images, videos, and audio). No authentication information from the recipient is collected or stored when they access a share link. We do not track who visits your share links, how many times a link is visited, or from which geographic location the link is accessed.

5.4 Sharing via the Telegram Bot

If you interact with INFI-CLOUD through the companion Telegram bot, you can generate share links using the /sharelink command, which outputs the public URL directly in the Telegram chat. You can also use the /give or /share commands to have the bot send the actual file directly into the Telegram conversation. In the latter case, the file is transmitted as a Telegram document message within your private chat with the bot, and anyone with access to that Telegram conversation could potentially see the shared file.

6. Core Platform Features and Their Privacy Implications

INFI-CLOUD offers a wide array of features designed to provide a comprehensive file management experience. Each feature interacts with your data in specific ways, and we want to be explicit about what those interactions look like.

6.1 File Upload and Processing

Uploads can be initiated through drag-and-drop, the upload button in the dashboard, the Developer API's upload endpoint, or the Telegram bot. INFI-CLOUD supports virtually every file type — documents, spreadsheets, presentations, images, photographs, videos, audio files, archives, code files, executables, and any other binary format. We do not restrict uploads based on file type, although the maximum file size is capped at 2 gigabytes.

During the upload process, temporary files are created on the server's filesystem. These temporary files exist only for the duration of the upload and processing pipeline and are deleted immediately upon successful completion or upon encountering an error. If the server restarts unexpectedly during an upload, a startup cleanup routine identifies and removes any orphaned temporary files. At no point during the upload process is the file content scanned for viruses, analyzed for metadata extraction, or processed beyond what is necessary for storage operations.

6.2 In-Browser File Preview

The file preview system supports over fifty file formats, rendering them directly in your browser without requiring a download. For PDF files, we use Mozilla's PDF.js library, which runs entirely in your browser and renders the document from the streamed file data. For Microsoft Excel, CSV, and spreadsheet files, we use the SheetJS library to parse the data and display it as an interactive HTML table. For Word documents, we use the docx-preview library for client-side rendering. For code files and plain text, we apply syntax highlighting using the Highlight.js library. For images, the file is loaded directly into an HTML image element. For videos and audio, the file is streamed using our HTTP Range request engine and played in the browser's native HTML5 media player.

All of these previews are generated client-side — the rendering happens in your browser, not on our server. Our server's role is limited to streaming the raw file bytes to your browser. We do not generate server-side thumbnails, we do not cache rendered previews, and we do not extract or index the text content of your documents for search purposes. The search functionality in INFI-CLOUD operates on file metadata (filenames, tags) rather than file content.

6.3 Trash and Deletion

When you delete a file or folder through the dashboard, it is not immediately and permanently destroyed. Instead, it is moved to the Trash Bin, which serves as a safety net against accidental deletion. Files in the Trash Bin are retained for a maximum of thirty days, during which time you can restore them to their original location with all metadata intact. After thirty days, trashed items are automatically and permanently purged — both the metadata records and the underlying file chunks stored in Telegram are deleted. You can also choose to empty your trash manually at any time, which triggers an immediate permanent deletion of all trashed items.

Permanent deletion is thorough. When a file is permanently deleted, its metadata record is removed from the database, and the Telegram message or messages containing the file chunks are deleted from the storage channel. Once permanently deleted, a file cannot be recovered by any means — we do not maintain backup copies or recycle bins beyond the 30-day trash retention period.

6.4 Self-Destruct Files

The Self-Destruct feature allows you to set a specific expiry timestamp on any file. When the configured expiry time arrives, the system automatically and permanently deletes the file, including both the metadata and the stored file chunks. This feature is useful for sharing time-sensitive documents or for ensuring that temporary files do not persist indefinitely in your storage. Self-destruct timers are checked during database maintenance operations, and expired files are removed during these routine checks.

6.5 Tags and Comments

The tagging system allows you to attach one or more text labels to any file. Tags are stored as a list within the file's metadata record and are used to power tag-based filtering and browsing. You can add tags individually or in bulk, and you can remove tags at any time. Tag data is visible only to the file owner and is not exposed through share links or public preview pages.

The comments system allows you to attach notes and observations to individual files. Each comment records the text content, the identity of the commenter (your email address or username), and the timestamp of the comment. Comments have a maximum length of two thousand characters, and each file can hold up to one hundred comments. You can edit or delete your own comments at any time. Comments are stored in a separate "_file_comments" collection in the database, keyed by filename. Like tags, comments are visible only to the file owner and are not publicly accessible through share links.

6.6 Version History

When you upload a new version of an existing file (a file with the same name in the same folder), the previous version is not overwritten. Instead, the previous version's file chunk references are preserved in the file's version history, allowing you to review, restore, or delete historical versions. Each file can retain up to twenty-five versions; when a twenty-sixth version is uploaded, the oldest version is automatically removed to stay within the limit. You can also manually clear the entire version history for a file if you want to remove all previous iterations. Version history entries include the Telegram file identifiers, the file size, and the timestamp of the version.

6.7 Folder Organization

INFI-CLOUD supports unlimited nested folders, allowing you to create deep hierarchical structures that mirror your preferred organizational scheme. You can create top-level folders and then add subfolders within them to any depth. Breadcrumb navigation in the dashboard allows you to quickly jump between levels of your folder hierarchy. Folders can be renamed, deleted, shared via folder share links, and protected with PINs. Every folder carries an owner field that ensures it is only visible and accessible to its creator.

6.8 Bulk Operations

The dashboard supports selecting multiple files for batch operations such as bulk deletion (moving multiple files to trash simultaneously) and bulk file movement (moving multiple files to a different folder in one operation). When you perform a bulk operation, each individual action within the batch is recorded as a separate entry in the audit log, maintaining a complete trail of activity even during large-scale reorganizations.

6.9 Storage Upgrades

INFI-CLOUD offers storage tiers ranging from the default 2 terabytes (free tier) up to 5 terabytes. Storage upgrades are activated by entering a valid passcode in the account settings panel. This upgrade mechanism is entirely free of charge — there are no financial transactions, no payment forms, no credit card fields, and no billing information collected. The storage upgrade simply updates the "tier" field in your user account record, which changes the capacity limit enforced by the storage quota system. The upgrade is logged in the audit trail as a "storage_upgrade" event.

6.10 Feedback and Help Desk

The feedback form accessible from the Settings panel allows you to send a free-text message to our development team. When submitted, the feedback text, your name, your email address, your IP address, and your browser's User-Agent string are packaged into a Telegram message and sent to our private feedback channel. This channel is monitored by the platform developer and is not accessible to other users or third parties. Similarly, the help desk feature allows you to submit structured support requests that are delivered to the same private channel. We use this information solely to understand your issue and respond appropriately.

7. The Telegram Bot Interface

In addition to the web-based dashboard, INFI-CLOUD operates a companion Telegram bot that allows you to manage your files directly from the Telegram messaging application. The bot supports a range of commands for listing files, searching for specific items, uploading files, downloading files, sharing file links, renaming and moving files, and managing your trash and starred items.

Access to the Telegram bot is restricted to users whose Telegram user IDs have been authorized in the system's admin list. When you first interact with the bot, it prompts you to verify your identity. Once verified, your Telegram user ID is stored in the "admins" list in the database, granting you access to the bot's commands. Authorized administrators can add or remove other Telegram user IDs using the /addadmin and /removeadmin commands.

When you upload a file via the Telegram bot — by simply sending a document, photo, video, or other file type to the bot in a private chat — the bot processes the file using the same storage pipeline as the web dashboard. The file is tagged with the appropriate metadata and stored in the Telegram storage channel. When you use the /give or /share commands to retrieve a file, the bot sends the file as a document message back to you in the Telegram chat.

Interactions with the Telegram bot are subject to Telegram's own privacy policy and data handling practices. Messages you send to the bot, including commands and uploaded files, pass through Telegram's messaging infrastructure. We do not have control over how Telegram processes, stores, or retains these messages on their platform.

8. Developer API and Programmatic Access

INFI-CLOUD provides a comprehensive RESTful Developer API accessible at the /api/v1/ path prefix. This API allows developers to integrate INFI-CLOUD functionality into their own applications, scripts, and workflows. The API is protected by key-based authentication and supports operations for listing files, retrieving file metadata, uploading files, creating folders, deleting files, and accessing a key-value database storage service.

8.1 API Authentication

All API endpoints require authentication via an API key, which can be provided through the Authorization header (as a Bearer token), the x-api-key custom header, or the api_key query parameter. Some endpoints also support session-based authentication through the "multi-auth" mechanism, which allows requests to be authenticated either by a valid session cookie (from the web dashboard) or by a valid API key.

API keys are generated through the admin dashboard and consist of a prefix indicating the key type (such as "INFI_live_" or "INFI_unified_") followed by a 48-byte cryptographically random token. Before storage, the key is hashed using the SHA-256 algorithm. The raw key is displayed exactly once at the moment of creation — it is the user's responsibility to store it securely, as it cannot be recovered. In the dashboard, keys are displayed in a masked format showing only the first few and last few characters.

8.2 API Permissions and Controls

Each API key can be configured with a specific set of permissions: read (for listing and retrieving files), write (for uploading files and creating folders), delete (for trashing and permanently deleting files), and admin (for managing API keys, viewing analytics, and configuring webhooks). Keys can also be restricted to specific IP addresses through an IP whitelist feature. When configured, requests from non-whitelisted IPs are rejected with a 403 Forbidden error, regardless of whether the key itself is valid.

API keys support optional expiry dates. When an expiry date is set and the current time surpasses it, the key is automatically rejected. Rate limiting is enforced at a default of 120 requests per minute per key, using filesystem-backed counters that work correctly across multiple server workers in a multi-process deployment. Exceeding the rate limit results in a 429 Too Many Requests response.

8.3 API Request Logging

Every API request is recorded in a rolling log file that is maintained separately from the main database. This separation is an intentional architectural decision to prevent the volume of API request logs from inflating the size of the main database file and impacting the performance of non-API operations. Each log entry records the timestamp, the SHA-256 hash of the API key used, the endpoint accessed, the HTTP method, the response status code, the response size in bytes, the bandwidth consumed, the originating IP address, and the request ID assigned by the server. This log is capped at ten thousand entries, with older entries being overwritten as new ones are added.

8.4 Key-Value Database API

The Developer API includes a simple key-value storage service that allows developers to store and retrieve arbitrary JSON data using the /api/v1/db/set and /api/v1/db/get endpoints. This data is stored in a dedicated "external_db" section of the main database, keyed by the API key hash and the user-specified key name. This feature is designed for lightweight application configuration storage and is subject to the same security controls (authentication, permissions, rate limiting) as all other API endpoints.

8.5 API Documentation

Interactive API documentation is available at the /apidocs endpoint, powered by the Flasgger/Swagger framework. This documentation is served locally by the INFI-CLOUD server and provides an interactive interface for exploring and testing API endpoints. No data is transmitted to external documentation hosting services.

9. Webhooks, Event Notifications, and Integrations

INFI-CLOUD supports a webhook system that allows you to receive real-time HTTP notifications when specific events occur within the platform. This feature is designed for developers and advanced users who want to integrate INFI-CLOUD with external tools, automation pipelines, or monitoring systems.

9.1 Webhook Configuration

Webhooks are configured through the admin dashboard or the Developer API. You specify a URL endpoint on your own server that will receive POST requests when events occur. You can configure webhooks to respond to any combination of eleven supported event types: file uploads, file deletions, file renames, file moves, file shares, folder creations, folder deletions, share link creations, share link revocations, storage upgrades, and user logins.

9.2 Webhook Payloads

When an event triggers a webhook, INFI-CLOUD constructs a JSON payload and sends it as an HTTP POST request to your configured URL. The payload includes the event type, a Unix timestamp indicating when the event occurred, the event-specific payload data (such as the filename, folder name, or share link hash involved in the event), and a source identifier set to "INFI-CLOUD." The webhook URLs you configure and the payloads we deliver to them are treated as confidential system data and are not shared with other users or exposed through any public interface.

9.3 Delivery Reliability

Webhook delivery is performed asynchronously in background threads, so event processing in the main application is not blocked by slow or unresponsive webhook endpoints. If the initial delivery attempt fails (due to a network timeout, server error, or HTTP error response), the system retries the delivery up to two additional times with increasing delays: five seconds after the first failure, thirty seconds after the second failure, and five minutes after the third failure. If all three attempts fail, the undelivered payload is written to a dead letter queue — a local file on the server that stores up to one hundred failed webhook deliveries. This dead letter queue can be inspected by the administrator to diagnose persistent delivery failures.

10. Cookies, Sessions, and Local Storage

Our approach to client-side data storage is minimal and strictly functional. We do not use cookies for advertising, cross-site tracking, behavioral analytics, or any purpose beyond maintaining your authenticated session.

10.1 Session Cookies

INFI-CLOUD uses a single Flask session cookie to maintain your authentication state as you navigate the platform. This cookie is cryptographically signed using a server-side secret key, which prevents unauthorized modification. The session cookie contains the following data: your authentication status (a boolean flag indicating whether you are logged in), your email address, your display name, the URL of your Google profile picture, a CSRF token for securing administrative requests, and lists of any folders or files you have unlocked during the current session using their respective PINs.

The session cookie is set when you log in and is cleared when you log out. If you close your browser without logging out, the session may persist depending on your browser's cookie retention settings, but it will eventually expire when the server-side session becomes invalid (for example, if the server restarts and uses a newly generated secret key).

10.2 What We Do Not Use

We want to be explicit about what you will not find in INFI-CLOUD's cookie and tracking behavior. We do not set any third-party cookies. We do not include Google Analytics, Google Tag Manager, Facebook Pixel, Mixpanel, Amplitude, Hotjar, Clarity, Segment, or any other third-party analytics or tracking script. We do not participate in real-time bidding networks, we do not contribute data to data management platforms, and we do not engage in any form of cross-site tracking. Your browsing behavior on INFI-CLOUD is not monitored, recorded, or analyzed for advertising or profiling purposes.

10.3 Browser Local Storage

The only data we store in your browser's Local Storage is your selected visual theme. This is a single key-value pair that records which of the available themes (light, dark, midnight, forest, sunset, lavender, or AMOLED) you have chosen. This preference is stored entirely on your device and is never transmitted to our servers. It exists purely so that your chosen theme is applied automatically when you return to the platform.

10.4 Service Worker

INFI-CLOUD registers a service worker at /sw.js for Progressive Web App (PWA) functionality. This service worker handles asset caching for offline reliability, allowing the application shell to load even when your internet connection is intermittent. The service worker does not implement push notifications, background sync, or any other capability beyond basic asset caching. It does not collect or transmit any data.

11. Data Retention, Deletion, and Lifecycle Management

We believe in giving you clear, predictable information about how long your data is kept and when it is deleted. Our retention policies are designed to balance your need for persistent storage with reasonable data minimization practices.

11.1 Active Files and Folders

Files and folders that are in active use (not trashed, not expired) are retained indefinitely for as long as your account exists. We do not automatically delete or archive files based on age, inactivity, or file type. Your files will remain accessible and intact until you choose to delete them, they reach a self-destruct expiry time, or your account is deleted.

11.2 Trash Retention

Files and folders moved to the Trash Bin are retained for a maximum of thirty days from the time they were trashed. The trashed_at timestamp is recorded when an item is moved to trash, and the thirty-day countdown begins from that moment. During this period, you can restore items to their original location with all metadata preserved. After thirty days, trashed items are automatically and permanently deleted during routine database maintenance. You can bypass the thirty-day waiting period by manually emptying the trash, which triggers immediate permanent deletion of all trashed items.

11.3 Self-Destruct Expiry

Files configured with the self-destruct feature are permanently deleted when their configured expiry timestamp is reached. The expiry check occurs during database maintenance operations, and once a file's expiry time has passed, the file metadata and stored chunks are permanently removed without any recovery option. Self-destruct timers are independent of the trash system — an expired file is deleted directly, not moved to trash first.

11.4 Share Link Expiry

Share links configured with an expiration period are automatically deactivated when the expiry time arrives. Deactivated share links return an error when accessed and are marked as inactive in your Shared Links dashboard. Share links can also be manually revoked or deleted at any time. The metadata records for share links (hash identifier, filename, creation time, owner, and status) are retained in the database even after the link is deactivated, allowing you to review your sharing history. These records are removed when the associated file is permanently deleted.

11.5 Audit Log Retention

The activity audit log is maintained as a rolling buffer with a maximum capacity of five thousand entries. When a new event is logged and the buffer is full, the oldest entry is permanently removed to make room. This means that for active accounts, the audit log typically contains a window of recent activity, with the exact time span depending on how frequently actions are performed. For accounts with low activity, the log may cover weeks or months of history. For highly active accounts or accounts with heavy API usage, the window may be shorter. The administrator can also clear the entire audit log manually through the admin dashboard.

11.6 API Log Retention

The Developer API request log is maintained as a separate rolling buffer with a capacity of ten thousand entries. Like the audit log, older entries are permanently overwritten as new requests arrive. This log is stored independently from the main database in a local file on the server's filesystem, which means it does not survive server redeployments or container restarts unless the filesystem is persistent.

11.7 Webhook Dead Letters

Failed webhook deliveries that exhaust all retry attempts are stored in a dead letter file with a maximum capacity of one hundred entries. Older dead letters are overwritten as new ones are added. Like the API log, this file is stored on the server's local filesystem.

11.8 Rate Limit Counters

Per-minute rate limit counter files are created in the server's temporary directory during active API usage. A cleanup routine automatically deletes counter files that are more than two minutes old, ensuring that these ephemeral tracking files do not accumulate over time.

11.9 Temporary Upload Files

Chunk files and assembly buffers created during the file upload process are stored temporarily in the server's temporary directory. These files are deleted immediately upon successful upload completion, upon upload failure, and during the startup cleanup sweep. They are never retained beyond the duration of the upload operation under normal circumstances.

11.10 Account Deletion

INFI-CLOUD does not currently offer an automated self-service account deletion feature within the user dashboard. If you wish to have your account and all associated data deleted, you should contact us through the feedback form within the platform or by reaching out to the administrator directly. Upon receiving a deletion request, we will systematically remove all files, folders, metadata, share links, comments, tags, version history entries, API keys, and audit log entries associated with your account from our database. Because the database is stored as a document in a Telegram channel and is overwritten on every update, deleted data does not persist in old versions of the database document — the previous document is deleted from the Telegram channel when the updated version is pinned.

12. Third-Party Services and External Dependencies

While INFI-CLOUD is built and maintained by Soham Soni as an independent product within the INFI-VERSE ecosystem, we rely on several trusted third-party services to provide essential functionality. We want to be transparent about each of these dependencies and how your data interacts with them.

12.1 Google LLC (Authentication and Fonts)

Google plays two roles in the INFI-CLOUD ecosystem. First, Google OAuth 2.0 is our exclusive authentication mechanism. When you click the "Sign in with Google" button, your browser communicates directly with Google's Identity Services platform (accounts.google.com/gsi/client). Google handles the authentication process, verifies your identity, and returns a signed token (JWT) containing your basic profile information. We decode this token on our server to extract your email, name, and profile picture URL. We do not receive your Google password, and we do not have access to any other Google account data beyond the three fields mentioned.

Second, we load typography assets from Google Fonts (fonts.googleapis.com and fonts.gstatic.com) to render the Inter typeface used throughout the platform's interface. When your browser requests these font files, Google may receive your IP address and the URL of the page you are visiting. Google's handling of this data is governed by their own privacy policy, and we have no control over it. We use Google Fonts because it provides fast, reliable delivery of web fonts without requiring us to host the font files ourselves.

12.2 Telegram FZ-LLC (Storage and Notifications)

Telegram is the most critical third-party dependency in the INFI-CLOUD architecture. Our entire storage layer — both file content and the metadata database — is built on top of the Telegram Bot API and private Telegram channels. Every file you upload passes through the Telegram API and is stored on Telegram's infrastructure. Every database update is written to the same private Telegram channel. Additionally, registration notifications, feedback submissions, and help desk tickets are delivered as messages to private Telegram channels via the Telegram Bot API.

The INFI-CLOUD Telegram bot provides an alternative interface for file management, and interactions with this bot pass through Telegram's messaging infrastructure. Telegram's privacy policy and data handling practices apply to all data that passes through or is stored on their platform. We encourage you to review Telegram's privacy policy to understand how they handle the data that resides on their servers.

12.3 Content Delivery Networks (CDNs)

INFI-CLOUD loads several client-side JavaScript libraries from public CDNs to power the in-browser file preview system and dashboard analytics. Specifically, we load PDF.js and Highlight.js from Cloudflare's CDN (cdnjs.cloudflare.com), SheetJS for spreadsheet rendering from Cloudflare's CDN, Chart.js for dashboard analytics charts from jsDelivr (cdn.jsdelivr.net), and docx-preview for Word document rendering from unpkg (unpkg.com). When your browser downloads these libraries, the respective CDN providers may receive your IP address and browser information. These CDN providers have their own privacy policies governing how they handle this data. We use CDNs because they provide faster load times and reduced latency compared to hosting these libraries on our own server.

12.4 ImgBB (Branding Assets)

The INFI-CLOUD logo and branding images are hosted on ImgBB (ibb.co), a free image hosting service. When your browser loads these images, ImgBB's servers may receive your IP address. We host branding assets on ImgBB because it provides reliable content delivery without adding to the storage or bandwidth demands on our primary server.

12.5 Services We Do Not Use

To be perfectly clear about the boundaries of our third-party integrations: INFI-CLOUD does not integrate with any advertising networks, data brokers, or behavioral analytics platforms. We do not use Google Analytics, Facebook Pixel, Mixpanel, Amplitude, Hotjar, Clarity, Segment, or any similar service. We do not integrate with any payment processors — there are no payments, subscriptions, or billing systems in INFI-CLOUD. We do not connect to any artificial intelligence or machine learning services (such as OpenAI, Anthropic, or Google Gemini) for processing your files or generating content. We do not use any email delivery services (such as SendGrid, Mailgun, or Amazon SES) — we never send emails to users.

13. Children's Privacy

INFI-CLOUD is designed as a general-purpose cloud storage platform for adults, professionals, students, and anyone who needs secure file storage. Our service is not specifically directed at children under the age of 13 (in the United States) or under the age of 16 (in the European Union and United Kingdom), and we do not knowingly collect personal information from children in those age groups.

Because INFI-CLOUD relies exclusively on Google OAuth 2.0 for account creation and authentication, the ability to create an INFI-CLOUD account is inherently gated by Google's own age restrictions. Google requires users to meet minimum age requirements to create a Google Account, and these requirements vary by country (typically 13 or 16 years of age). We rely on Google's age verification and parental consent mechanisms as our primary safeguard against underage registration.

We do not independently implement age verification questions, birthdate fields, or parental consent workflows within the INFI-CLOUD platform. If we become aware that a child under the applicable minimum age has somehow created an account or that we have inadvertently collected personal information from a minor without appropriate consent, we will take prompt action to delete the account and all associated data. Parents or guardians who believe their child may have registered for an INFI-CLOUD account without authorization should contact us immediately through the platform's feedback system or by reaching out directly to the administrator.

14. Your Rights, Choices, and Account Controls

We believe that privacy rights should be exercised through practical, accessible controls rather than through bureaucratic request processes. INFI-CLOUD provides a range of built-in features that give you direct control over your data without needing to submit formal requests or wait for manual processing.

14.1 Data Access and Portability

You have full access to all files, folders, and metadata in your account through the dashboard interface. You can download any individual file at any time by clicking the download button. For bulk data export, you can download the contents of any folder as a ZIP archive using the Download Folder feature, which packages all files in the selected folder into a single compressed archive and delivers it to your browser. While there is not currently a one-click "download everything" feature, you can systematically export all your data by downloading each folder.

14.2 Data Deletion

You have the right to delete any file, folder, version, comment, tag, or share link at any time. File and folder deletion follows the trash-and-purge model described earlier (30-day retention in trash, followed by permanent deletion). You can bypass the retention period by emptying the trash manually. Individual file versions can be deleted from the version history panel, and the entire version history for a file can be cleared in one operation. Comments can be individually deleted through the comments panel. Tags can be removed individually or in bulk. Share links can be revoked or deleted through the Shared Links dashboard.

14.3 Sharing Controls

You have complete control over how your files are shared. You can create, configure, and revoke share links at any time. You can set expiration periods, apply PIN protection, schedule delayed deactivation, and immediately revoke access. When you revoke a share link, the revocation takes effect immediately — any subsequent access attempts will fail. You can also view a complete list of all your active and inactive share links in the Shared Links dashboard.

14.4 API Key Management

If you use the Developer API, you have full control over your API keys. You can create new keys with specific permission sets and IP restrictions, you can view usage statistics for each key, and you can revoke keys at any time. Revoking an API key immediately invalidates it — any subsequent API requests using that key will be rejected.

14.5 Session Management

You can terminate your active session at any time by clicking the Logout button. Logging out clears your session cookie entirely, removing your authentication state, your display name, your profile picture URL, your CSRF token, and any folder or file unlock states from the session. After logging out, you must re-authenticate through Google to regain access to your account.

14.6 Audit Log Review

As an account holder, you can review the audit log to see a chronological record of all actions performed within your account. For administrative accounts, the audit log includes actions across all users and can be filtered by action type, user, time range, and target. The audit log can be exported in JSON format for offline analysis or archival.

14.7 Account Deletion Requests

If you wish to completely delete your account and all associated data, please contact us through the feedback form within the INFI-CLOUD dashboard. While we do not currently offer a self-service account deletion button, we are committed to processing deletion requests promptly. Upon receiving your request, we will permanently remove all files, folders, metadata, share links, comments, tags, versions, API keys, and audit log entries associated with your account.

15. Our No Data Mining and No Advertising Pledge

This section deserves its own dedicated space because it represents one of the core philosophical differences between INFI-CLOUD and many mainstream cloud storage services. We understand that in today's digital ecosystem, "free" services often come with hidden costs — your data being mined for advertising insights, your files being scanned for content moderation, or your usage patterns being sold to data brokers. INFI-CLOUD categorically rejects this model.

We will never scan, analyze, parse, index, or read the contents of your files for advertising purposes. Your documents, photographs, videos, code files, spreadsheets, presentations, and personal media are stored and delivered without any content-level processing beyond what is strictly necessary for storage and retrieval.

We will never serve you advertisements based on the content of your files or your usage patterns within the platform. There are no ad units, sponsored content, or promotional placements anywhere in the INFI-CLOUD interface.

We will never sell, license, rent, or otherwise provide your personal information or file data to third-party advertisers, data brokers, data aggregators, or marketing companies. Your data is not a product that we monetize.

We will never use your files, metadata, or usage data to train artificial intelligence models, machine learning systems, large language models, or any other automated learning technology. The content you store on INFI-CLOUD is not feeding any neural network, generative model, or predictive algorithm.

We will never deploy behavioral tracking technologies such as fingerprinting, supercookies, tracking pixels, or cross-site tracking mechanisms within the INFI-CLOUD platform.

These commitments are not aspirational statements or marketing language — they are hard constraints encoded into the architecture of the platform. Our codebase does not contain advertising SDKs, analytics trackers, or content scanning modules. We do not have partnerships with advertising networks or data brokers. The absence of these systems is verifiable and intentional.

INFI-CLOUD was built on the principle that cloud storage should be a utility — a secure, reliable, and private place for your digital life — not a data harvesting operation disguised as a convenience. When we say "your files, your privacy, your cloud," we mean it literally and technically.

16. International Data Considerations

INFI-CLOUD is available to users worldwide and does not restrict access based on geographic location. However, because our storage infrastructure relies on the Telegram Bot API and private Telegram channels, the physical location of your stored data is determined by Telegram's server deployment decisions. Telegram operates data centers in multiple countries and may store or transfer data across international borders as part of their normal operations.

If you are located in the European Economic Area (EEA), the United Kingdom, or other jurisdictions with data protection regulations that restrict international data transfers, you should be aware that your file data and account metadata may be processed and stored on servers located outside your jurisdiction. By using INFI-CLOUD, you acknowledge and consent to this cross-border data handling. We rely on the security measures described in this policy — including encrypted transfers, access controls, data isolation, and PIN protection — to provide appropriate safeguards for your data regardless of where it is physically stored.

Users in jurisdictions that grant specific data protection rights (such as the right to access, rectify, erase, restrict processing, or port personal data) may exercise those rights through the platform's built-in features described in Section 14, or by contacting us directly through the feedback system. We will respond to rights requests in accordance with applicable law and within a reasonable timeframe.

17. Changes to This Privacy Policy

As the INFI-CLOUD platform evolves and new features are added to the INFI-VERSE ecosystem, we may need to update this Privacy Policy to reflect changes in our data handling practices. When we make changes, we will update the "Effective Date" at the top of this document and, for material changes that significantly affect how we collect, use, or store your data, we will provide a prominent notice within the INFI-CLOUD web application.

Material changes that would trigger a prominent notice include, but are not limited to: introducing new third-party integrations that receive your data, changing our storage architecture in a way that affects data residency, modifying our data retention policies, adding new categories of data collection, or altering our no-advertising or no-data-mining commitments. Minor changes such as clarifications, corrections of typographical errors, or updates to reflect feature additions that do not change the fundamental privacy model may be made without a prominent notice.

We encourage you to review this Privacy Policy periodically to stay informed about how we are handling your data. Your continued use of INFI-CLOUD after changes to this Privacy Policy constitutes your acceptance of the revised terms. If you do not agree with any changes, you should discontinue your use of the platform and request deletion of your account and data.

Previous versions of this Privacy Policy are not publicly archived on the platform. If you require access to a previous version for legal or compliance purposes, please contact us and we will make reasonable efforts to accommodate your request.

18. Contact Information

INFI-CLOUD is developed, operated, and maintained by Soham Soni as part of the INFI-VERSE ecosystem. If you have any questions, concerns, or requests regarding this Privacy Policy, your personal data, or the security of your account, we encourage you to reach out through any of the following channels.

The most direct way to contact us is through the built-in Feedback System within the INFI-CLOUD dashboard. Navigate to Settings, select the Help & Feedback tab, and submit your inquiry. Your message will be delivered to our private support channel and will be reviewed promptly.

You can also reach us via email at [email protected]. When reaching out about a privacy concern, please include as much detail as possible about your inquiry, including the email address associated with your INFI-CLOUD account (if applicable) and a clear description of the issue or request. This helps us respond accurately and efficiently.

We are committed to acknowledging receipt of privacy-related inquiries within a reasonable timeframe and to resolving them as quickly as the complexity of the request allows. For straightforward requests such as account deletion or data export assistance, we aim to complete the process within a few business days. For more complex inquiries that require investigation or significant technical work, we will keep you informed of our progress.

Thank you for trusting INFI-CLOUD with your files. Your privacy is not just a feature we offer — it is a foundational value that shapes every decision we make about this platform. We built INFI-CLOUD because we believe everyone deserves access to generous, private, secure cloud storage without having to sacrifice their data to advertising engines or surveillance capitalism. That commitment will not change.