Security
This page is written for the person at your company whose job is to say no. It describes how Relay Bridge is built, who can see what, and — at the bottom — what we don't have yet. We'd rather lose a deal than have you find out we shaded something.
Last reviewed 29 July 2026 · questions to support@webpros.net
Nothing listens on your network
The Bridge — our program on a machine at your site — makes outbound connections only. There are no ports to open, no inbound firewall rules, and nothing of ours accepting connections on your LAN.
It reads your cameras locally, keeps recordings on your own disk, and sends us only what's asked for: live video while somebody is actually watching, motion snapshots, and a copy of the recording if you switch the cloud archive on.
If our service is unavailable, your site keeps recording and LAN-connected relays keep switching. That's deliberate: the cloud is where you watch and manage, not a dependency for the equipment to work.
Who can do what
| Layer | How it works |
|---|---|
| Sign-in | Google, or email and password, through Firebase Authentication. We never hold your password. |
| Roles | Owner, admin, operator, viewer — enforced on every request, not just hidden in the interface. A viewer cannot change anything anywhere. |
| Two-factor | Optional per person, and an owner can require it of all admins. It protects the dangerous actions — deleting footage, revealing a camera password, opening remote access, changing who's on the account — rather than nagging you at every sign-in. |
| Shared panel links | A link with no sign-in behind it, for a gate button on a phone. Set a PIN; repeated wrong entries lock it for a growing period. Delete the panel to revoke it instantly. |
| API and widget keys | Scoped to one device and one action. Secret keys are shown once and stored only as a hash. |
Your footage and passwords
- In transit: HTTPS for the app, the API, every upload from the Bridge, and playback. One exception, stated below.
- At rest: encrypted by our cloud provider (AES-256).
- Camera and relay passwords, and two-factor seeds: encrypted again by us, with a key held apart from the database, so a database leak on its own exposes nothing. They're never shown by any screen or API; deliberately revealing one is recorded.
- Panel PINs: stored one-way with a per-panel salt. Not recoverable, not displayable — keep your own note.
- Links to video expire. Clips, archived footage and live streams are served through short-lived signed links tied to one camera, so an address copied out of a browser isn't lasting access.
- Your browser never touches our database. All access goes through our API, the only thing holding keys.
Being straight about one thing: this is not zero-knowledge. We have to hand a camera password to your Bridge so it can open the stream, so we can decrypt it. Anyone claiming otherwise about a system that logs into your cameras for you is mistaken.
Who at Web Pros can see your account
A named list of people, each added deliberately — nobody gets access by working here. Changing that list requires the changer's own two-factor code.
Every operator action is recorded, including simply looking at your account, and including someone being refused. The record is written both to our own database and to a logging system our operators cannot edit or delete. That second copy is the one that matters for an audit, and it's why we can answer "who looked at our footage" with a list.
Ask, and we'll give you the current list, or a report of access to your account over any period.
Reaching a device remotely
You can open a 15-minute session to a device's own web page — a camera's settings, say — through the Bridge's outbound tunnel. No VPN, no port forwarding, no software on your side.
- We inject no credentials. You type the device's own password, so a session is never equivalent to device access.
- The address being reached is set from your device record on our side and never taken from the request, and the Bridge separately refuses anything that isn't a private address on your own network.
- Sessions are served from a separate domain (
remoteui.net) so a relayed page can't touch the app's cookies. If your egress is filtered, allow*.remoteui.net. - Every session is logged — who, to what, when, how much data — and you can cut them off individually or all at once.
How long things are kept
| Data | Default | Who decides |
|---|---|---|
| Recording on your own Bridge disk | 14 days or a disk cap | You, per camera |
| Cloud archive | 30 days | You, per camera |
| Motion events and their snapshots | 30 days | You, per camera (1–3650) |
| Clips and snapshots you saved | Until you delete them | You |
| Live video | Not stored at all | — |
| Event log, invoices, billing detail | Kept | Us — it's the audit and accounting record |
Recovery
Database point-in-time recovery over a 7-day window, daily backups kept a week and weekly backups kept 14 weeks, delete protection on, and versioning on stored media. Installers are published with SHA-256 checksums generated by the build itself.
Companies involved
| Who | What for | What reaches them |
|---|---|---|
| Google Cloud | Hosting, database, storage, video ingest, sign-in | Everything |
| Cloudflare | DNS, TLS, custom domains, remote-access sessions | Traffic in transit |
| Anthropic | Describing what a motion snapshot shows; plain-language search | A single frame per event, and camera names. No continuous video. Only if you switch AI on. |
| Shelly (Allterco) | Switching Shelly relays | Device id and the on/off command. No video. Only if you use Shelly. |
| OpenStreetMap | Turning a site address into map coordinates; map tiles | The address text you type |
| Amazon SES | Account emails — access requests to us, and "your account is ready" to you | Your email address and the text of the message. No footage or device data. |
| Stripe | Holding a card and taking the monthly payment | Your billing contact and card details, which are entered directly with Stripe and never reach us. We hold only a customer reference and the last four digits. |
| Amazon Rekognition | Recognising people you have enrolled — only if we have switched face recognition on for your account after talking it through with you | A faceprint for each person you enrol, in a collection used for your account alone, plus the single frame being checked. Faces we do not recognise are compared and immediately discarded — nothing about them is stored. Off for every account by default. |
No analytics or advertising trackers. No session recording. Your data is never used to train AI models.
What we don't have
- Video from your site to our ingest server is not encrypted in transit. It's authenticated with a per-camera secret, and everything else we do is TLS, but this leg is plain RTMP. Encrypted ingest is on the roadmap; until then, assume live video is readable to anyone who can see that traffic.
- No SOC 2, no ISO 27001, no third-party penetration test. We're a small company. This page, and the tests behind it, are what we have instead — and we'll happily complete your security questionnaire or let you scan us.
- The installer isn't code-signed yet, so Windows warns on first run. Published checksums let you verify the download in the meantime.
- Widget keys are stored in plaintext so we can show you the embed snippet again. They can only fire the one device they're scoped to, and you can revoke them.
- No automated dependency scanning in our build yet.
Reporting a problem
Email support@webpros.net with enough detail to reproduce it. We'll acknowledge within two business days. There's no bug bounty, but we do fix things, and we'll credit you if you'd like. Please don't test against other customers' accounts, and please don't fire other people's relays — those are real horns and lights on real sites.