What we can and cannot see
Periscope is closed-source, so "trust us" is the weakest thing we could offer. This page is the alternative: what each part of the system does, what it holds, and where the limits are — written so you can check it rather than believe it.
The short version
Your devices talk to a server you own. The cryptography is WireGuard's, unmodified. Your keys are made on your device and the private half is never sent to us. Nothing in our system records what you connect to — there is no table, column or log line anywhere for domains, DNS queries, URLs or destinations.
What we do hold is the metadata needed to introduce your devices to each other: which devices you own, their addresses, when they were last seen, and how much data any relayed session moved. And on one path, described below, your encrypted traffic passes through hardware we operate.
Three different questions
"Can Periscope see my traffic" is really three questions with three answers.
| Someone on your Wi-Fi | Sees encrypted WireGuard packets going to an address — not the sites, not the contents. Defeating this is what Periscope is for, and for IPv4 it works. IPv6 is a real exception today: on a network that offers it, those connections go around the tunnel and are visible. See below for what we are doing about it. |
| Duet, as the operator | Cannot read your traffic on any path. We hold account and device metadata (below), and on the relay path we carry your encrypted packets without being able to open them. We are, however, trusted in the key exchange — see "Where you are trusting us". |
| Someone who compromises your home server | Is on your home network, because that is what the server is for. Periscope does not defend against this; nothing routed through your own hardware could. |
Keys
Every WireGuard keypair is generated on the device that uses it, by Apple's CryptoKit on Apple platforms. The private half is never transmitted to our servers and we have no mechanism to request it.
Storage differs by platform, and we would rather say so than round it up: on iOS the tunnel configuration including its private key is held in the Keychain, marked so it is neither synced to iCloud nor included in backups. On tvOS it is weaker, in two different ways. When an Apple TV acts as a server, its own identity key is in the Keychain, but a copy is also written to storage shared between the app and its network extension, because the extension needs to read it and cannot reach the Keychain copy. When an Apple TV is a client, the tunnel configuration is held in the system's VPN settings rather than the Keychain. Both are readable by anything that can already read that app's container, which on a non-jailbroken device means the app itself. Closing both gaps is on our list.
These are software keys, not Secure Enclave keys. The Secure Enclave cannot perform the Curve25519 operations WireGuard needs.
The cryptography is not ours
We did not write any. Periscope links a fork of Apple's wireguard-apple; our changes to it add a userspace server engine so an Apple TV can act as an endpoint, and nothing else. The vendored cryptographic code is byte-identical to the upstream release it declares.
Handshakes therefore use WireGuard's construction — Curve25519 for key agreement, ChaCha20-Poly1305 for the data, BLAKE2s for hashing. We do not configure an optional pre-shared key, so tunnels run with WireGuard's default. We deliberately avoid the phrase "256-bit encryption": most people read that as AES-256, which is not what this is.
The relay — the part that complicates the story
Periscope prefers a direct connection between your device and your home server, and will punch through most home routers to get one. When a network blocks that — hotel and airport Wi-Fi routinely do — the connection falls back to a relay we operate, and your encrypted packets pass through our infrastructure to reach your home.
The relay copies packets between two sockets. It cannot decrypt them: it holds no keys, and the WireGuard session is between your device and your server. But it is a machine we run that your traffic crosses, and any claim that there is "no third party in the middle" would be false on this path. It records that a session existed, between which devices, and how many bytes it carried.
What we store
| Your account | Email address, subscription state. |
| Each device | A name you chose, its public key, its last-seen public IP address, the private addresses of its own network interfaces, how its router behaves for NAT traversal, and a city and coordinates resolved from that IP. |
| Relayed sessions | Which two devices, when, and total bytes. |
| What we never store | Domains, DNS queries, URLs, destination addresses, or anything about what you did through the tunnel. There is nowhere in the system for it to go. |
Geolocation is resolved on our own servers against a local database file — your IP is not sent to a geolocation vendor. That city is what powers the location shown next to each device in the app.
This data is kept for as long as the account exists. There is no self-service account deletion today — email us and we will do it by hand. We would rather write that sentence than imply a button that does not exist.
What a connected device can reach
When you admit a device to your home server, it gets the internet through your home connection — and it also gets your whole home network: your router, your NAS, your printer, anything listening on your LAN, plus anything running on the server device itself. There is no destination filtering.
That is a deliberate property of running your own exit node, and it is the same reach a WireGuard box or a Tailscale subnet router on the same hardware would give you. But it means admitting a device is equivalent to handing it a network cable in your house. Admit devices accordingly.
IPv6 does not go through the tunnel, and today it does not stop either. Everything above describes IPv4. If the network you are on offers IPv6 — most mobile networks and a growing share of home ones do — then any site reachable over IPv6 is contacted directly, outside the tunnel, from your device's real address, while the app shows itself as connected. The network around you sees those connections and the sites see you. This is the most significant limitation on this page. The fix is written: route IPv6 into the tunnel and drop it there, so those connections fail and retry over IPv4 inside the tunnel rather than escaping it. We have not shipped it, because we have not yet been able to test it on a network that offers IPv6, and we would rather hold it than ship a change to how your traffic is routed on reasoning alone. We will date this paragraph when it lands. Carrying IPv6 properly, rather than blocking it, comes after that.
One smaller specific: ping through the tunnel works to an Apple TV server but not to a Mac or Windows one — the Apple TV forwards traffic in userspace and does not relay ICMP, while the desktop apps let the operating system route it.
Where you are trusting us
The honest weak point is not the cryptography, it is the introduction.
Our coordinating server is what tells your device the public key and address of the server it should connect to. That message is not signed by your server, and your device has no independent way to verify it. A compromised coordinator — or someone who compromised us — could name a different key and a different address, and the handshake would succeed against a machine that was not yours. Adding server-signed identities, so the coordinator can introduce but not substitute, is the most valuable hardening still ahead of us.
For the same reason, the decision to admit a device to your server is currently taken by that coordinating service rather than confirmed on the server device itself. An Apple TV server checks what it can locally — that a request is addressed to it, that a key is not already in use, that it is not being asked to peer with itself. A Mac or Windows server does not yet make those checks, and we would rather write that down than describe the strongest case as if it were all of them. Neither prompts you.
Other companies in the picture
Running the service means using other people's infrastructure. This list is the significant ones rather than a complete inventory, and we would rather say that than present a curated list as exhaustive:
- Our hosting provider runs the coordinating service, the database and the relays.
- Cloudflare resolves DNS for devices connected through a Periscope server. That is currently fixed and not configurable, so your DNS queries leave your home connection and go to Cloudflare's resolvers.
- Public STUN servers — a handful of unaffiliated operators, contacted when a server starts, to discover how your router presents you to the internet. Each one contacted learns your home connection's public address.
- Apple and Stripe handle subscriptions, depending on where you bought.
- Crash and product analytics, and transactional email. Analytics on Apple platforms is opt-in and identifies you by a salted hash rather than your address; crash reporting follows the same choice.
Closed source: what that costs you
You cannot read our code, and this page is not a substitute for that. What it is worth knowing is that the two halves are not equally opaque. Everything on your device can be checked without us: the apps can be decompiled, and every claim here about what leaves your device can be confirmed with a packet capture in about ten minutes. We would rather you did that than took our word.
The coordinator and the relay are the part you cannot verify from outside. Claims about what our servers do rest on trust in us, and no third party has audited them.
Reporting something
If you find a vulnerability, email security@getperiscope.com. We will confirm receipt, tell you what we find, and credit you if you want to be credited. Please give us a reasonable window to fix it before publishing — we will not use that as a way to stall.
Last updated 25 August 2026. When something on this page changes, we will say what changed and when.