EVdlc Bot Privacy Policy

EVdlc Bot is a Telegram-based download automation service. A user sends a supported link or picks a file, the service works out how to retrieve it, and the result is delivered back to the user.

EVdlc Bot is built on EVdlc, a separate local desktop download engine. They are different products with different behaviour, and this policy describes EVdlc Bot and this website only. Nothing here should be read as a description of how the desktop EVdlc engine stores data on a user’s own computer.

This policy explains what information is processed, why it is processed, how long it is kept, who it may be shared with, and what controls users have. Questions about it can be sent to karimimohammdd@gmail.com.

This policy covers two clearly separate surfaces. They behave differently, and it matters which one is being discussed.

A. The public website (evdlc.firstvanguardtech.com)

The website you are reading is intentionally minimal. It:

• is served by Cloudflare Workers;
• has no login, no user accounts and no application database;
• performs no Google OAuth and holds no Google credentials;
• accepts no links, no uploads and no files;
• sets no non-essential cookies;
• runs no analytics, advertising or tracking scripts.

Because the website sets no non-essential cookies, there is nothing to consent to and no cookie banner is shown. Cloudflare, acting as the infrastructure provider that delivers and protects the site, processes ordinary network and security metadata such as IP address, request time, user agent and security signals. That processing is a normal part of serving a website securely.

B. EVdlc Bot and its backend

The bot service is where user data is actually handled. It:

• receives commands and messages through Telegram;
• may receive links submitted by the user and files the user selects;
• performs Google OAuth when, and only when, the user chooses to use Google Drive;
• creates temporary working files while a job is being completed;
• keeps operational job records so jobs can be run and supported;
• implements the retention and deletion commitments published on this page.

Telegram itself, Google, and any other platform a user chooses to involve operate under their own terms and privacy policies. This policy cannot and does not change how those companies handle data on their own systems.

The categories below are the information that may be processed by EVdlc Bot, its backend, or the infrastructure that serves this website. Not every category applies to every user: a user who never connects Google Drive has no Google data processed at all.

• Telegram user ID.
• Telegram chat ID.
• Telegram username and display name, when Telegram makes them available.
• URLs submitted by the user.
• Job status and technical error information.
• Filenames, file size, MIME type and source metadata.
• The selected Google Drive file ID and its metadata.
• Selected file content, when needed to fulfil the request.
• OAuth access and refresh tokens, when persistent Google access is enabled.
• IP address and basic request metadata processed by infrastructure providers for website delivery and security.
• Support emails sent voluntarily by users.

Telegram is how EVdlc Bot is reached and how results are returned. When a user writes to the bot, Telegram passes that message to the service together with the identifiers Telegram attaches to it: the Telegram user ID, the chat ID, and the username and display name where Telegram makes them available.

These identifiers are used to:

• reply in the correct conversation;
• attach a job to the user who requested it;
• apply per-user limits and abuse prevention, so one user cannot exhaust the service for everyone;
• investigate a support request the user has raised.

Telegram controls what a bot receives. EVdlc Bot does not receive a user’s phone number, contact list, or messages in conversations the bot is not part of. Telegram’s own collection and handling of message data is governed by Telegram’s privacy policy, not by this one.

When a link is submitted, the URL is processed so the service can identify the source, choose a retrieval method, and fetch the content the user asked for. A URL can itself contain information — including a share key or an identifier that grants access — so it is treated as job data, not as casual text.

Each job produces a working record that may contain:

• the submitted URL and the detected source category;
• job status, such as queued, running, completed, cancelled or failed;
• technical error information, such as an error code or a failure reason returned by the source;
• filenames, file size, MIME type and source metadata for the file being handled;
• timestamps and the Telegram identifiers needed to deliver the result.

These records exist so a job can be run, retried, cancelled, delivered and supported, and so abuse can be detected. They are retained for the period set out in Data Retention.

Google Drive is optional. It is used only if a user chooses to connect a Google account. When that happens, EVdlc Bot requests exactly one Google scope:

https://www.googleapis.com/auth/drive.file

This is Google’s per-file scope. Under it, EVdlc Bot can access only the files the user explicitly selects, opens or shares with the app, plus the files the app itself creates or uploads at the user’s request. Selection happens through Google’s own file picker, with the user’s consent, using an authorisation code exchange with PKCE. There is no service account, and no other Google service is requested.

EVdlc Bot does not request broad access to a user’s entire Google Drive.

Google user data received through this scope is used only to:

• complete the file workflow the user requested;
• show the user the status of that workflow;
• troubleshoot errors reported by the user or by Google;
• prevent abuse and maintain the security of the service.

Google user data is not used for advertising, is not sold, is not used to build advertising profiles, and is not transferred to unrelated third parties. Transfers are limited to infrastructure and service providers acting on the service’s behalf where that is necessary to operate, secure, process or deliver the service the user asked for.

Connecting a Google account produces OAuth credentials. An access token allows short-lived calls to the Drive API; a refresh token allows the service to obtain a new access token so a connection can continue working without asking the user to sign in again.

• Access tokens and refresh tokens are confidential credentials and are treated as secrets.
• They are encrypted or otherwise securely protected at rest in the backend.
• They are never placed in browser storage by this website. This website performs no Google OAuth and holds no Google credentials of any kind.
• They must not appear in logs, error reports or support messages.
• A user can revoke access at any time from their Google Account permissions page.
• Tokens are deleted when access is revoked, when the Google account is disconnected, or when a valid deletion request is completed — subject to unavoidable short-lived backup copies that age out automatically.

Information is processed only for the following purposes:

• Delivering the requested service — retrieving the link or file the user asked for and returning the result.
• Job management — queueing, running, retrying, cancelling and reporting the status of a job.
• Support and troubleshooting — understanding a failure the user has reported and correcting it.
• Abuse prevention and security — enforcing limits, detecting misuse, protecting the service and its users, and investigating security incidents.
• Reliability and improvement — identifying error patterns and capacity problems so the service can be made more reliable.
• Legal compliance — meeting obligations that apply to the service.

Information is not used for advertising, behavioural profiling, or resale. There is no advertising business attached to this service.

Completing a job normally requires the backend to hold file bytes for a short time: content is downloaded or staged, prepared, and then delivered. This is temporary working storage for an in-flight request, not a personal file library, and there is no browsing interface over it.

Because the service processes file content on its own infrastructure, it is technically able to read the content it is handling in order to complete the request. EVdlc Bot therefore does not offer end-to-end encrypted storage, and it would be dishonest to claim otherwise. Data is protected in transit using HTTPS/TLS, and temporary working data is protected by the access controls described in Security.

Cleanup is asynchronous. A file becomes eligible for deletion when the job completes, is cancelled, fails, or expires, and it is then removed by a cleanup process within the retention window published below. This means deletion is prompt and bounded, but it is not instantaneous, and this policy does not promise that it is.

Data is kept only as long as it is needed for the purpose it was collected for. The commitments below are the retention rules published for EVdlc Bot.

A file that a user has copied into their own Google Drive belongs to that user and stays in their Drive. It is not covered by the retention windows above, and removing it is done from Google Drive itself.

To state it plainly:

• Personal data is not sold and is not rented.
• Data is not shared with ad networks.
• There is no cross-service behavioural advertising.

Data is disclosed to service providers only where that is necessary to run the service. Those providers act on the service’s behalf, for the purposes described in this policy, and the categories are limited to:

• hosting and compute;
• storage;
• network delivery, security and abuse protection;
• file processing needed to complete a requested job;
• message delivery, which for this service means Telegram as the channel the user chose to use.

Information may also be disclosed where it is required by law, or where it is reasonably necessary to investigate suspected abuse, to enforce the Terms of Service, or to protect the rights, safety and security of users, third parties and the service itself.

EVdlc Bot’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

In practice, and consistent with those requirements:

• Google user data is used only to provide and improve the user-facing features the user requested.
• Google user data is not transferred to others except as necessary to provide and improve those features, to comply with applicable law, or as part of a merger, acquisition or sale of assets with user notice and consent where required.
• Google user data is not used for advertising, and is never used to serve personalised, retargeted or interest-based advertising.
• Humans do not read Google user data unless the user has given explicit consent for specific items, it is necessary for security purposes such as investigating abuse, it is required to comply with applicable law, or the data is aggregated and anonymised for internal operations.

The only Google Drive scope requested is https://www.googleapis.com/auth/drive.file. Alongside it, EVdlc Bot requests the standard OpenID Connect sign-in scopes openid, userinfo.email and userinfo.profile, which identify the Google account a Drive connection belongs to — its email address and basic profile details — so a download reaches the correct account and the connection can be managed and disconnected. No other Google scope is requested. No trust badge, verification claim or endorsement by Google is asserted anywhere on this site.

Security controls are applied in proportion to the sensitivity of the data involved:

• data is transmitted over HTTPS/TLS;
• OAuth tokens are encrypted or otherwise securely protected at rest and are excluded from logs;
• the least-privilege Google scope https://www.googleapis.com/auth/drive.file is used instead of a broad Drive scope;
• access to backend systems and stored data is restricted to what is needed to operate and support the service;
• temporary working files are removed on the schedule published in Data Retention;
• rate limits and abuse detection protect the service from misuse and from denial-of-service workloads.

No online service can be guaranteed to be perfectly secure, and this one makes no such guarantee. EVdlc Bot is also in private testing, which means components are still changing. Suspected vulnerabilities or data-handling problems should be reported privately to karimimohammdd@gmail.com rather than published, so the issue can be fixed before it is exploited.

Use of the service is voluntary at every step. A user can:

• choose not to use EVdlc Bot, or stop sending it links at any time;
• choose never to connect Google Drive — the connection is optional and the rest of the service does not require it;
• select exactly which Drive files are shared, one at a time, through Google’s own picker;
• disconnect the Google account, or revoke access directly from Google, as described in Revoking Google Access;
• cancel a job, which triggers the cancellation cleanup path for its temporary files;
• request deletion of stored data as described in Data Deletion Requests;
• contact karimimohammdd@gmail.com with any question about this policy.

Browsing this website requires no account, no sign-in and no consent prompt, because the site sets no non-essential cookies and runs no analytics or tracking scripts.

Google access can be withdrawn at any time, directly from Google:

1. Open Google Account permissions.
2. Find EVdlc Bot in the list of apps with access to your account.
3. Select it and remove or revoke its access.

What revocation does, and what it does not do:

• It stops future Drive access immediately. Existing tokens stop working and cannot be refreshed.
• The stored tokens for that connection are deleted or invalidated, subject to short-lived backup copies that age out automatically.
• It does not delete files already saved into your own Google Drive. Those are yours, and you remove them from Drive itself.
• It does not by itself erase job records that are still inside their retention window. To request that, use Data Deletion Requests.

A deletion request can be made by email to karimimohammdd@gmail.com. Full step-by-step instructions are on the data deletion page.

Include enough information to identify the Telegram account or the connected Google account the request refers to — for example the Telegram user ID or username, or the Google account email address that was connected. Requests that cannot be matched to an account cannot be actioned.

Identity verification may be required before a request is carried out, so that one person cannot delete another person’s data. Some minimal records may be retained where they are required by law, or where they are needed for fraud prevention and security records; anything of that kind is kept to the minimum necessary and is not used for any other purpose. Data that has already been removed through automatic expiry cannot be deleted again, and short-lived backup copies age out on their own schedule.

EVdlc Bot relies on hosting, storage and network providers whose infrastructure is distributed across multiple countries. Telegram and Google, which a user chooses to involve, likewise operate globally. As a result, information described in this policy may be transferred to, stored in, or processed in a country other than the user’s own, including countries whose data protection rules differ from those where the user lives.

Where information is transferred, it is protected by the measures described in Security, and providers are expected to process it only on the service’s instructions and for the purposes set out in this policy. To the extent permitted by applicable law, using the service involves accepting that this cross-border processing takes place.

EVdlc Bot is not directed at children. The service is intended for users who meet Telegram’s own minimum age requirements and who are old enough, under the law that applies to them, to agree to the Terms of Service.

No information is knowingly collected from a child below the applicable age. If it becomes apparent that such information has been received, it will be deleted, and any associated connection will be removed. A parent or guardian who believes a child has used the service can write to karimimohammdd@gmail.com and ask for the data to be deleted.

This policy will change as EVdlc Bot develops. The service is in private testing, so features, providers and technical details are still evolving, and the policy is updated to keep pace with them rather than being left to drift out of date.

When it changes, the revised version is published at https://evdlc.firstvanguardtech.com/privacy and the last-updated date shown at the top of this page is revised. Where a change materially affects how user data is handled, reasonable steps will be taken to highlight it, including through the bot where that is practical. Continuing to use the service after a change takes effect means accepting the updated policy.

Questions, privacy requests, and reports about this policy or about EVdlc Bot can be sent to karimimohammdd@gmail.com.

Please describe what you need clearly, and include the identifiers needed to act on it — but never include passwords, verification codes, OAuth tokens, session files or private keys.

Related pages:

• Terms of Service — the rules that apply to using EVdlc Bot.
• Delete your data — step-by-step deletion and revocation instructions.