Security and frequently asked questions

File contents sent directly are encrypted on the sending device and checked at the authorized receiver. Device identities, releases and receipts are part of the transfer flow. You decide which devices or applications may access, and whether a transfer may be forwarded through pipeit when needed.

The service needs metadata for accounts, devices, rights, transfer states and diagnostics. End-to-end encryption therefore does not make all use invisible. Security also depends on your own devices, their account access and correct releases.

Are my files stored on the server?

Direct transfer: the file data goes from device to device. On the server route, encrypted data is forwarded without turning it into a lasting retrievable file. Control data and time-limited transfer metadata are different from that.

pipeit Cloud: files you keep in the cloud are stored in your account. They are stored so that the service can work with them for search, thumbnails and safety scans, and they are not end-to-end encrypted. See pipeit Cloud. If a file must stay private, send it directly.

Our infrastructure backups are not a backup of your files; use pipeit Cloud backup for that.

Can the receiver be offline?

For device-to-device transfers both endpoints must be reachable; the server route is no mailbox for switched-off devices. If the receiver is not online, share by link or put the file in pipeit Cloud. Local native offline operation means no internet service is needed, but it requires a prior explicit pairing and a working local or routed network connection.

Does direct automatically mean LAN or Wi-Fi Aware?

No. Direct describes the data path without a pipeit data relay. WebRTC can use different network paths. A native TCP route can run across routers. Nearby transfers between the pipeit apps (Wi-Fi Aware, Wi-Fi/LAN, Bluetooth discovery) are direct as well and are shown as such in the connection details. Only the recorded method is shown as actually used.

What does “Received and verified” confirm?

A valid receipt confirms the respective transfer according to its protocol. A server status alone, or “all bytes sent”, is no substitute. In the browser, the local export is separate: pipeit can detect that saving has started, but cannot confirm universally that the operating system placed the file where you wanted it. A folder activation receipt or a confirmed change to a managed set is again an action of its own.

Why is an email code sometimes needed again?

A longer-lived sign-in and the fresh confirmation of a sensitive action serve different purposes. The code is confirmed in the open dialog. The normal flow needs neither a complete sign-out nor choosing the files again.

What happens if I lose a device?

Revoke a device that is no longer used, and check unknown sessions and connector releases. Without a remaining paired device there is an explicit restart of device access. It replaces the old bindings but does not restore lost file keys. Copies already saved on other devices are not removed remotely.

Is a contact request already a file release?

No. Contacts, accounts, devices and destinations are separate. Accepting a contact does not replace the necessary receive or destination authorization. Likewise, workspace membership does not automatically grant the right to delete a server directory.

Who decides where a server stores the file?

The receiver sets up the private folder and an alias and allows specific senders. The sender optionally picks that alias. The client checks the directory with the actual service rights. An alias carries no arbitrary path invented by the sender.

Are folders a ZIP file?

In the native folder stream, original blocks and structure are transferred without a complete intermediate archive. In the browser, folders are sent as a protected archive that pipeit unpacks on the receiving side. A folder is therefore not the same local file type on every client; the result and the rights stay clearly named.

Can pipeit start programs on the target?

A successful file or folder transfer does not run programs. An explicitly allowed folder activation is not general remote shell access either. Your own operating steps, such as a service restart, are organized separately. That way ordinary file receivers do not have to grant execution rights.

What may an AI connection see and do?

For the MCP connector you sign in to pipeit and choose which devices and Cloud spaces the assistant may use. It can list your released devices and destinations, check transfers, and send files to a device, person, server or your pipeit Cloud; every send is shown to you first and needs your confirmation. With pipeit Cloud it can also list and search your Cloud spaces and, with a separate permission, search content and show previews. Cloud files are not end-to-end encrypted, and snippets or previews can reach the model provider of your AI application. Files on a device are sent through the pipeit app on that device, never read in the background. Tools and setup: Connect ChatGPT, Codex, Claude, Gemini and Grok.

An AI cloud application may already know its own uploaded or generated files in plain text. pipeit’s end-to-end encryption does not revoke that earlier access. Do not assume that “AI never has access to content”.

Do I need to keep browser data?

Local device keys, send caches and received temporary copies are part of the client state. Signing out, clearing browser data or ending private sessions can make this data unusable or remove it. Deliberately save important received files. For interruptible native folder transfers, also keep the unchanged originals.

Are there fixed promises for speed, size or availability?

The actual limits come from profile, client, plan or budget and the end device. Up to 8 GiB in a supported profile means neither unlimited cloud storage nor a fixed rate. Prices, service levels and certifications are only stated where they are published.