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 where a Google Drive connection is offered, and then only when the user chooses to use it;
• creates temporary working files while a job is being completed;
• copies a completed file that came from a publicly retrievable source into private Telegram archive channels it operates, and keeps those copies;
• re-delivers a copy it already holds — including to a different user who later submits the same link — instead of downloading it again;
• keeps operational job records so jobs can be run and supported;
• keeps subscription records and payment references for paid access, but never card details;
• 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, where a Google Drive connection is offered and the user enables persistent access.
• IP address and basic request metadata processed by infrastructure providers for website delivery and security.
• Support emails sent voluntarily by users.
• Subscription status, plan, expiry date, and the payment reference returned by the payment provider.
• Telegram file identifiers and archive channel message references for a file the service has already retrieved.
• Canonical source identifiers and content hashes, used to recognise a file that has already been downloaded.

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.

Connecting Google Drive is optional. It applies only where a Drive connection is offered, and then only if a user chooses to connect a Google account. Where it is offered, EVdlc Bot requests 4 Google scopes — one Drive scope, and the standard OpenID Connect sign-in scopes that identify the account being connected:

• https://www.googleapis.com/auth/drive.file — Google’s per-file Drive scope, for the files the user picks.
• openid — the sign-in itself, which is how the Google account is identified at all.
• userinfo.email — the email address of the account being connected.
• userinfo.profile — basic profile details of that account, such as the display name.

Under the Drive scope, 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. Where the connection is offered, selection is made through Google’s own file picker, with the user’s consent, and access is authorised by an authorisation-code exchange with PKCE rather than by a service account. The sign-in scopes exist so a transfer reaches the account the user actually connected, and so that connection can be shown, managed and disconnected. No other Google scope, 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.

Where a Drive connection is offered, 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. The rules below govern those credentials wherever the connection is offered.

• Access tokens and refresh tokens are confidential credentials and are treated as secrets.
• Where they are stored, they must be 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.

EVdlc Bot is a paid service. Access to the download features is checked against a subscription record, so the service holds a small amount of billing-related information about each subscriber.

What is stored about a subscription:

• the Telegram user ID the subscription belongs to;
• the plan, the subscription state — for example active, expired or cancelled — and the expiry date;
• the payment reference returned by the payment provider, such as a transaction, invoice or order identifier;
• the date and amount of a payment, for reconciliation, support and accounting;
• the state of a payment link issued through the bot — how many uses it was issued with, how many have been spent, when it expires, and the user it is bound to where it is bound to one — so a link cannot be used beyond the uses it carries.

A payment link is a Telegram deep link carrying an opaque token. Each link is issued with a set number of uses, normally one, and may optionally be bound to a specific user, in which case only that user can redeem it; a link issued without that binding can be redeemed by whoever presents it, for as many uses as it was issued with. The token is stored only as a SHA-256 hash, so the stored record cannot be turned back into a working link if it is ever exposed.

What comes back from the provider is the outcome of a payment and the reference needed to reconcile it — not the payment instrument. Subscription data is used to decide whether a request is allowed, to tell the user when their access expires, to answer billing questions, and to meet accounting and tax obligations. It is not used for advertising or profiling. Its retention is set out in Data Retention.

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.
• Archiving and de-duplication — keeping a copy of a completed file from a publicly retrievable source in the service’s own archive channels so it survives the loss of any one channel, and recognising a file that has already been downloaded so it is re-sent instead of fetched again.
• Subscription management — checking whether access is active, issuing and validating payment links, and keeping the billing records that go with a paid service.
• 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 requires the download server to hold file bytes while content is fetched, staged and prepared for delivery. This section is about those working files on the download server, and about them only. What happens to a file after it has been delivered successfully is different, and is described in Archive Copies and Cross-User Reuse.

Temporary working files means:

• a partially downloaded file while a transfer is still running;
• staging, container and conversion files produced while the result is being prepared;
• residue left behind by a job that was cancelled, failed, or expired before it finished.

The commitment is that these are removed from the download server within 24 hours — no later than 24 hours after successful delivery, cancellation, failed-job cleanup, or expiry. It is a commitment about the download server’s working storage, not a claim that a delivered file has ceased to exist, because the service keeps a copy of what it downloads.

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 stored data is protected by the access controls described in Security.

Cleanup is asynchronous. A working 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 window above. This means deletion is prompt and bounded, but it is not instantaneous, and this policy does not promise that it is.

This is the most consequential thing about how EVdlc Bot handles files, so it is stated plainly here rather than left to be inferred from the retention table.

A downloaded file is kept, not discarded

When a download finishes, the file is retained by the service, and where it came from a publicly retrievable source it is also copied into one or more private Telegram archive channels operated by the service. A file that needed the user’s own credentials, or a share secret, to obtain is not placed in those channels at all.

The archive copy is made while the result is being prepared for delivery — before the file is sent to the user, not after. It therefore exists even if delivery to that user is delayed, retried, or never succeeds at all.

Those copies are retained indefinitely. They are not removed after 24 hours, they are not removed when the user deletes the message, and they are not removed when the user stops using the service. They are removed when the operator removes them, or when a deletion request is actioned.

Archive copies exist for two reasons, and only these two:

• Redundancy. The same file is mirrored into several channels at once, so that if one channel is blocked or removed the file is not lost with it.
• Not downloading the same file twice. A file already held can be re-sent from the archive instead of being fetched again, which is faster for the user and much lighter on the source.

The archive channels are private: not published, not listed, not searchable, and not open to join. Access is limited to the accounts that operate the service. They are nonetheless hosted on Telegram’s infrastructure and are subject to Telegram’s own terms and moderation.

The same file may be delivered to more than one user

If a different user later submits the same link, EVdlc Bot recognises it by the canonical identifier of the source and delivers the copy it already holds to that user, without downloading anything again. That applies to every kind of link, including a Google Drive, MEGA, Dropbox or OneDrive share link: the identifier is taken from the link itself, so a second person holding the same link receives the same file. A file is also matched by its content hash to a request made through a different URL, but only when it came from a publicly retrievable source, or when it is the same user asking again.

What is exempt, and what only looks exempt

The exemption is narrower than it may appear. It covers content the service could only obtain by acting as the requesting user, not content that happens to live on a private platform:

• a file selected through Google’s own picker under https://www.googleapis.com/auth/drive.file is used only for the request of the user who selected it. It is not copied into the archive channels, it is not entered into the de-duplication index, and it is never re-delivered to another user;
• the same applies to anything else the service could obtain only by using the user’s own credentials or session;
• a share link is not exempt, however private the platform behind it. A Google Drive, MEGA, Dropbox or OneDrive link pasted into the chat is fetched as an ordinary link and de-duplicated by the identifier inside it, so the file it points to can be delivered to another user who submits the same link. What such a file does not get is a place in the archive channels, because it did not come from a publicly retrievable source.

Removal of an archived copy can be requested; what that reaches, and what it cannot reach, is set out in Data Deletion Requests.

Data is kept only as long as it is needed for the purpose it was collected for. The rules below are the retention commitments published for EVdlc Bot: each states what the service undertakes to do with a category of data, not a measurement of what has already been deleted.

The 24 hours rule and the indefinite archive rule are separate, and it matters which one applies. The first governs working files on the download server. The second governs the copy of a downloaded file the service keeps once it has been retrieved. A short cleanup window on the download server does not mean the file is gone.

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;
• payment processing, handled by the payment provider that takes the payment;
• message delivery and archive storage, which for this service both mean Telegram: results are delivered through Telegram, and archived copies are held in private channels on Telegram’s infrastructure.

One further disclosure follows from how the service avoids repeat downloads: a file retrieved from a link may be delivered to another user of the service who submits the same link. That is a disclosure of content to another user, it is deliberate, and it is described in full in Archive Copies and Cross-User Reuse. Content the service could obtain only by acting as the user — a file picked through Google’s picker, for instance — is excluded from it. A share link the user pastes, including a Google Drive link, is not.

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, and only where a Drive connection is offered, EVdlc Bot requests the standard OpenID Connect sign-in scopes openid userinfo.email userinfo.profile, which identify the Google account a Drive connection belongs to — its email address and basic profile details — so a transfer reaches the correct account and the connection can be managed and disconnected. That is 4 Google scopes in total, and no others. 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;
• the archive channels are private, unlisted and not open to join, and are restricted to the accounts that operate the service;
• payment links carry a token that is stored only as a SHA-256 hash and is accepted for a set number of uses, normally one, and no card data is handled by the service at all;
• 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 under active development, 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;
• ask for an archived copy of a file to be removed from the archive channels;
• 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.

Removing an archived copy

A request can also cover a specific archived file. Say which file it is, or which link it came from, so the right copy can be identified in the archive channels.

What removal reaches:

• the copy is deleted from every archive channel it was mirrored into, and the identifiers that allow it to be recognised and reused are deleted with it;
• the file stops being re-delivered from the archive to anyone, including to a user who submits the same link afterwards.

What removal does not reach:

• copies already delivered. Once a file has been sent into a Telegram chat, or saved to a device or to someone’s own Google Drive, that copy belongs to whoever received it and is beyond the service’s reach. This includes copies already re-delivered to other users under Archive Copies and Cross-User Reuse, which cannot be recalled;
• the source itself. The original link keeps working if the source keeps serving it, and the same link submitted again can be downloaded again.

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 under active development, 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.