The web app and its limits
The web app is a full easysync device that runs in a browser tab. It has its own identity, pairs like any other device and uses the same encrypted connections. A browser is limited, though, and this page lists how.
What is different #
- It always uses a relay. A browser cannot open UDP sockets, listen for connections or discover devices on the local network. The web app therefore has no direct connection: every session goes through a relay, and the relay must present a certificate that your browser trusts, over
wss://. The relay sees the IP address, the timing and the amount of data of those connections; see What the relay sees. - Joining needs no setup, inviting does. The web app can join a pairing without a relay set up in advance, because the link names the relay. To invite another device, or to wait for connections on a relay of your own, you add a relay with its access token. The form that adds a relay (on the Relays page, and in the pairing view when you invite without a relay) has a drop-down: "easysync official relay (relay.easysync.me)" is preselected, and "Another relay" shows a field for the address of a relay of your own. The drop-down only fills in the address; the web app has no default relay and connects to one only after you have added it with its token or, for the official relay, after it has obtained an access key for this browser. For the official relay the web app asks the relay for an access key by itself when you add it, in both modes, so you enter no token. In passphrase mode the key is stored in the browser together with the other keys, wrapped by the passphrase. In session mode it is held in the session storage of the tab and disappears when the tab closes. For a relay of your own you still enter the token you got from its operator. The official relay is operated by the project; what a relay sees is described in What the relay sees.
- It is there only while the tab is. There is no delivery in the background. Other devices treat the web app like any device that is off: no text is queued for it, and a running transfer pauses and continues when the tab is back.
- One tab per browser profile. A second tab reports that the state is in use.
- The clipboard works on your action. Browsers allow access to the clipboard only on a page that has focus, and mostly after a gesture. You send with a button or a paste box; a received text appears on the page with a copy button. Nothing is read in the background.
- Files. A received file is offered to you as a download when it has been checked. A file to send is chosen again if the page was reloaded, because a browser may not keep access to it.
Pairing with a phone #
When the web app invites another device, the pairing view shows the invitation link as text and, below it, a QR code of the same link. A phone can scan the code. The code is drawn by the page itself and is removed when the screen closes, like the link. If the link is too long for a QR code, the page says so and shows the text only. Paste link on the phone still works: copy the link and paste it on the other device.
Where the keys are #
There is no operating system key store in a browser. When you create the device, you choose between two modes:
- Passphrase. The keys are stored in the browser, wrapped with a key derived from your passphrase (at least 12 characters, never stored). The passphrase is the only protection against someone who copies your browser profile. You enter it each time the page loads. Resume of transfers works in this mode.
- Session. The keys of your device exist only in memory. Closing the tab ends the device. A transfer must finish within one session, and it cannot resume. For the official relay the web app also asks for an access key at the start of the visit and holds it in the session storage of the tab: it survives a reload of the tab, disappears when the tab closes, and is never written to the persistent storage of the browser. Each such request counts against the limit of keys per network address and day, so many visits from one network in one day can reach it. The token field stays for relays of your own.
If you clear the site data, or the browser removes it to free space, the identity is gone. The device then starts as a new device that nobody trusts, and you pair again. The app asks the browser to keep its storage, and shows the answer.
A relay you did not enter #
The web app does not connect to a relay that you did not enter or confirm. If a pairing link, or a device you pair with, names a relay, the page shows the host in full and asks you before it connects. This matters because a web page that is compromised could otherwise lead the app to send data to a relay of someone else.
Trusting the place that serves the app #
The code of the web app is part of what protects you: whoever controls the server that sends it to your browser, or the build, can send code that leaks your identity key. The app is served as static files with a strict content security policy, no code from other sites, and a service worker that, when the host is honest, keeps the installed version until you confirm an update; a malicious host can ship a service worker without this behaviour. These rules reduce the risk and do not remove it. A compromised server can still send harmful code to anyone who loads or updates the app. If you cannot accept that, use a native program or host a pinned copy yourself.
Browsers #
How far the web app has been tried in browsers:
- Web app (Runs in the browser): Tested by hand in all browsers except Safari; Safari not tested. A browser cannot connect directly, so the web app always uses the relay. The maintainer tested it by hand in all browsers except Safari (statement of 2026-10-27); no browsers or versions are recorded, and Safari is not tested. Automated browser tests ran in headless Chromium, Firefox and WebKitGTK on Linux.