Send·to·PhoneBack to sender

Privacy Policy for Send to Phone

Effective date: August 29, 2026

Publisher and data controller: Yury Baranikhin, an individual based in Armenia

Privacy contact: privacy@sendtophone.app

1. What Send to Phone does

Send to Phone lets you link supported devices, select a file on the web, a computer, or Android, place it in private temporary cloud storage, and save it to a user-visible location on the linked receiving device. The service has no mandatory account and does not create public file links.

This Policy describes the data handled by the web sender, browser extension, macOS and Windows clients, Android sender and receiver, iPhone receiver, and the supporting cloud service (together, the "Service").

2. Data we process

Files and transfer information

When you send a file, we process the file body and its filename, media type, size, SHA-256 integrity digest, temporary object reference, transfer state, retry/failure codes, timestamps, and the bounded destination code reported by the receiving client. A selected file may contain personal or sensitive information depending on what you choose to send. Please send only files you are authorized to use and disclose.

Linked-device and authentication information

We process random device and pairing identifiers, user-editable device labels, platform and bounded capability values, link status and timestamps, one-time claim material, and directional bearer credentials. The server stores claim and bearer values as keyed hashes rather than plaintext. The participating clients retain the credentials they need to authenticate.

Push and technical information

If phone notifications are enabled, we process an encrypted Firebase Cloud Messaging (FCM) registration token and related registration state. Firebase processes a Firebase installation ID, app version, Firebase user-agent information, and other network/service data needed to route and operate push messages. For iPhone delivery, FCM uses Apple Push Notification service (APNs).

The Service also processes network information needed to receive requests and protect the Service. Application rate limiting stores a keyed hash derived from the request IP address, not the raw IP address. We retain bounded aggregate operational counters and timings, but not per-user behavioral analytics.

Data kept only on your device

Clients keep their device identity, pairing credentials, settings, active jobs, and a bounded local transfer history using the browser or operating system's protected storage. Sender clients may keep a selected file locally while an active job needs it. Android keeps up to 20 recent incoming transfer records. Separately, its sender queue retains every active outgoing job plus up to 20 terminal outgoing records, and may retain a read grant to the selected source or a private staged copy while a job needs stable file access. iPhone keeps up to 20 recent receiver records. Final received files are saved in a user-visible location and remain under your control. This client-local history is not uploaded as analytics.

The Android QR flow uses Google Play services Code Scanner. The camera image and recognition are processed on the device; the app receives the decoded pairing value. The iPhone QR flow also processes the camera image locally.

When you choose to use a WebMCP-aware browser agent on the public web sender, the browser may give that agent the tool descriptions and the bounded result of a tool you ask it to use. Those results may include paired-device display names, platforms, and aggregate transfer-state counts. They do not include file contents or paths, filenames, pairing codes or links, bearer credentials, signed URLs, or raw internal link identifiers. The browser and agent provider, rather than Send to Phone, control any additional observation of the visible page and process it under their own settings and terms.

3. Why we process data

We use the data described above only to:

We do not use file contents, filenames, selected website content, browsing activity, device-link data, or push identifiers for advertising, profiling, sale of data, or behavioral analytics. The browser extension uses website access only for the resource the user explicitly chooses to send; it does not continuously monitor browsing history or page activity.

4. How files move and how they are protected

File bodies move directly over HTTPS between the sending or receiving device and a private Cloudflare R2 bucket. The control-plane Worker handles metadata and authorization but does not proxy file bodies. R2 uses Cloudflare-managed encryption at rest. Download/upload authorizations are short-lived and limited to an object and operation. Pairing can be inspected and revoked.

The current Service does not provide client-side or end-to-end encryption. Cloudflare and an authorized service operator may technically access a temporarily stored file. Do not use the Service for a file if this security model is not appropriate for it.

No security measure is perfect. You are responsible for protecting access to your devices, pairing links/codes, bearer credentials, and any file after it is saved on a receiving device.

5. Retention and deletion

Backups, security records, and records required by law may follow the applicable provider or legal retention rules. The Service does not enable persisted Cloudflare Workers invocation logs in the release candidate because control-route URLs contain internal identifiers.

6. Service providers and disclosures

We use the following providers to operate the Service:

These providers process data on our behalf or provide platform services under their own terms. Data may be processed in countries where they or their subprocessors operate. We use provider terms and other safeguards required by applicable law for international processing.

We may also disclose information when reasonably necessary to comply with law, respond to valid legal process, protect rights or safety, investigate abuse, or complete a merger, acquisition, or asset transfer. Where required, we will give notice or obtain consent. We do not sell personal data.

7. Your choices and rights

You can:

There is no mandatory account profile. To exercise an applicable privacy right that cannot be completed in-product—such as access, correction, deletion, restriction, objection, portability, or appeal—contact privacy@sendtophone.app. We may need enough information to verify the request without collecting unnecessary identity documents. Some data cannot be recovered or mapped to a person because the Service uses random device identifiers and no account.

8. Children

The Service is not directed to children. Do not use it if you cannot validly consent to this processing in your location, unless a parent or guardian provides any consent required by law. If you believe a child provided data in violation of applicable law, contact privacy@sendtophone.app.

9. Changes to this Policy

We may update this Policy when the Service, providers, or legal requirements change. We will update the effective date and provide any additional notice or consent required by law or store policy. Materially different data use will not be hidden in an update.

10. Contact

Questions or requests about privacy: privacy@sendtophone.app

Publisher/controller: Yury Baranikhin, an individual based in Armenia

Browser extension limited-use statement

The browser extension's use and transfer of information received from browser APIs is limited to providing and improving its single purpose: sending a user-selected file or resource to the user's explicitly linked phone and reporting its delivery. That information is not used or transferred for personalized advertising, creditworthiness, lending, or sale to data brokers. Human access is not permitted except with the user's specific consent for support, where necessary for security, where required by law, or for internal operations after aggregation and de-identification, consistent with applicable browser-store limited-use requirements.