Choose the material before sharing

The sender selects the intended cookies and creates a transfer through the configured team service. The browser profile stays closed during the operation. Review the selected domains and entries before continuing; a cookie value may grant access to an authenticated session. A project name or profile label does not describe the full contents of a transfer.

Encryption happens on the client

Orbit encrypts the payload with AES-256-GCM before upload. Its key is carried in the link fragment rather than sent as part of the server request. The server holds encrypted transfer data. This design limits what the transfer service receives, but the full link or QR code still contains the material needed by the recipient and should be handled accordingly.

Receiving requires an explicit action

A transfer has a short, five-minute availability window and a one-time claim. The receiving page asks for an explicit action before claiming and decrypting it. The recipient can obtain a JSON or Netscape representation for a compatible destination. Opening a camera or showing a QR preview should not be confused with completing the handoff.

A phone download is still a file

Scanning the link on an iPhone does not install cookies into Safari or recreate a Mac browser session. The receiving browser can display or download the exported material; a separate supported import mechanism is required at the destination. Orbit also does not transfer localStorage, IndexedDB, all tabs or arbitrary application memory.

Verify the destination and outcome

Agree on the receiving tool and file format first. Confirm that the recipient obtained the intended entries and test the authorized workflow there. Expiration of the transfer link does not delete a file the recipient already saved, nor does it revoke a website session. Treat successful delivery and successful destination login as two separate checks.