Security at TYO Reach
Security is foundational to what Reach does — you're routing your traffic through our infrastructure, so you have every right to know exactly how it's handled.
How your traffic moves through Reach
Understanding the data path helps you evaluate what we can and cannot see — and why the design is the way it is.
When Reach is active, the client app runs a small local proxy (HTTP CONNECT and SOCKS5) that your browser connects to. For HTTPS, when your browser opens a connection, the local proxy hands back "200 Connection Established" and relays the raw, still-encrypted bytes onward to TYO Reach's gateway — running on managed cloud infrastructure in your selected region — over an authenticated tunnel; the gateway relays those same bytes on to the destination server. Your browser's original TLS session runs end-to-end to the destination site through that tunnel — Reach is a pipe, not an endpoint. It never sees plaintext, never generates or presents a substitute certificate, and installs no root CA on your device. The destination sees the gateway's IP address, not yours.
The tunnel itself, not your traffic, is what's authenticated: the client sends an X-Reach-Key header when it opens the tunnel to the gateway, so the gateway can identify your account and enforce your data allowance. Policy enforcement (which domains exit through which gateway) and metering are applied from connection metadata — the destination host your browser asks the proxy to reach, and byte counts — never by reading decrypted content.
What we log — and what we deliberately don't
Reach measures how much data you use. By default it does not record what you do with it — an optional connection log, off unless you or your organisation enable it, is the only exception.
What we log by default
We record the total volume of data (bytes) transferred through your account per billing period. This is the only information needed to enforce your monthly data allowance, and it is the only thing we log unless you turn on the optional connection log.
What we don't log
We do not log URL paths, query strings, search terms, or page content — ever. We do not record a history of the domains you visit unless you (or your organisation) switch on the optional connection log, and even then only the host name and connection timing are stored, never paths or content. We don't build browsing profiles or share traffic data with advertisers or analytics providers.
Optional connection log & retention
Byte-count metering data is retained for your current billing period plus a short tail for dispute resolution. The optional connection (access) log is off by default; when you or your organisation enable it, connection-level metadata (host, time, duration) is retained for a maximum of 30 days and then deleted. All logs are stored in our cloud infrastructure in the Sydney region.
Identity backed by TYO ID
Authentication for TYO Reach is handled by id.tyo.com.au — TYO's own identity service — not a third-party platform we don't control.
Australian-hosted identity
TYO ID runs on cloud infrastructure hosted in Australia. Your account credentials never transit a US or EU identity platform. Sign-in flows use OAuth 2.0 with short-lived session tokens — long-lived credentials are never stored in the client app.
MFA and TOTP
Multi-factor authentication is available via TOTP (time-based one-time passwords — compatible with any RFC 6238 authenticator app). Team admins can require MFA for all group members; users cannot opt out of a group-enforced MFA policy.
Push-to-approve, with number-matching
Approve a sign-in from your phone instead of typing a code — but the code itself stays on the computer you're signing in on, and you confirm the matching number on your phone. A push notification alone can be approved by habit; number-matching closes that MFA-fatigue gap.
Google & Microsoft sign-in
Teams can sign in with Google or Microsoft. Enterprise Azure AD / OIDC directory federation is available on request for organisations that need it. Windows also supports native in-app sign-in — no browser hand-off — for locked-down devices and restrictive networks.
How the gateway is built and operated
The gateway runs on managed serverless infrastructure — no persistent virtual machines, no SSH access, no long-lived secrets in the environment.
Managed serverless containers
The Reach proxy gateway runs on a managed serverless container platform. It scales automatically, inherits the underlying platform's infrastructure security, and means there are no persistent VMs for us to patch or for an attacker to persist on between deployments.
No SSH access to production
There is no SSH or shell access to the running gateway. All deployments go through our automated deployment pipeline. Rollbacks are performed via redeployment, not console access.
Managed secret storage
Sensitive credentials — API keys, service tokens, database connection strings — are stored in a managed secret store, not in environment variable files or code. The gateway retrieves secrets at start-up over an authenticated internal API.
Automatic platform patching
The platform handles OS and runtime patching automatically. We maintain the application layer; the platform provider maintains the infrastructure layer. There is no unpatched-VM surface.
Found a security vulnerability?
If you've found an issue in TYO Reach, we want to hear about it before it's disclosed publicly.
Send a description of the issue to [email protected]. Please include:
- A clear description of the vulnerability and its potential impact.
- Steps to reproduce (a proof of concept helps us triage faster).
- Screenshots, logs, or any supporting evidence.
We aim to acknowledge all security reports within one business day and provide a resolution timeline within three business days of confirming the issue. Please give us reasonable time to fix the issue before any public disclosure.
We ask that you:
- Do not access or modify data belonging to other users.
- Do not perform denial-of-service testing against production systems.
- Act in good faith.
We don't currently run a paid bug bounty programme, but we'll acknowledge researchers in release notes with their permission.
Does Reach see my passwords?
No. If you're logging in to a site over HTTPS — which virtually all login pages use — your TLS session runs end-to-end between your browser and the destination site through Reach's tunnel; Reach relays encrypted bytes and never decrypts them. It's structurally unable to see the content of the login form, including your password. As a general rule: avoid sending credentials over unencrypted HTTP on any network.
Can Reach read my HTTPS browsing content?
No, for HTTPS — effectively all modern browsing. Reach does not intercept or decrypt HTTPS — it relays your already-encrypted traffic through a tunnel, and your TLS session runs end-to-end to the destination. The gateway knows the destination host name (e.g. example.com) only because your browser tells the proxy where to connect (the standard CONNECT target), not by parsing anything inside the encrypted handshake — and it never sees the URL path, query string, or page content. That's a structural guarantee of the tunnel design for HTTPS, not just a logging policy. By default we do not log host names at all; they are recorded only if you or your organisation enable the optional connection log (host name and connection timing only, kept for 30 days). For the small minority of unencrypted HTTP traffic that still exists on the internet, that structural guarantee doesn't apply — the local proxy is technically capable of reading the request, same as it would be for any plaintext forward proxy, but we do not inspect or store its content.
Where is my data stored?
Account data, metering records, and any logs are stored in our cloud infrastructure in the Sydney region. We do not replicate personal data to jurisdictions outside Australia except as required by our infrastructure provider's standard operations. See our Privacy Policy for full details.
How do I report a vulnerability?
Email [email protected] with a description of the issue, steps to reproduce, and any supporting material. We aim to acknowledge all reports within one business day. Please give us time to address the issue before public disclosure.