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, selected traffic from your device travels to TYO Reach's gateway over an encrypted HTTPS connection. The gateway — running on Google Cloud Run in Sydney — forwards the request to the destination server on your behalf. The destination sees the gateway's IP address, not yours. TLS is enforced at every hop: your device to the gateway, and the gateway to the destination.
TYO Reach uses mitmproxy as its underlying proxy engine. "Man-in-the-middle" is a technical description of how the proxy intercepts the connection, not a description of intent. This interception is necessary for two specific purposes:
- Authentication. Reach adds a
Proxy-Authorisationheader so the gateway can identify which account the request belongs to and enforce your data allowance. - Policy enforcement. Routing rules — which domains exit through which gateway — are applied at this layer.
The proxy terminates your TLS session, inspects the HTTP metadata (host name and method), applies policy, and re-encrypts the request before forwarding it. Destination TLS certificates are validated normally by the gateway. This is the same model used by enterprise web security gateways.
What we log — and what we deliberately don't
Reach measures how much data you use. It does not record what you do with it.
What we log
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. Connection-level metadata may be retained briefly for debugging and abuse detection.
What we don't log
We do not log URL paths, query strings, search terms, page content, or a history of domains you visit. We don't build browsing profiles. We don't share traffic data with advertisers or analytics providers.
Retention
Byte-count metering data is retained for your current billing period plus a short tail for dispute resolution. Any raw connection-level logs used for debugging are retained for a maximum of 30 days and then deleted. All logs are stored in Google Cloud 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 Google Cloud 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.
Google SSO
Teams can sign in via Google SSO. Additional enterprise identity providers are on the roadmap.
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.
Google Cloud Run
The Reach proxy gateway runs on Cloud Run — Google's managed serverless container platform. Cloud Run scales automatically, applies Google's underlying 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 Google Cloud's deployment pipeline. Rollbacks are performed via redeployment, not console access.
GCP Secret Manager
Sensitive credentials — API keys, service tokens, database connection strings — are stored in GCP Secret Manager, not in environment variable files or code. The gateway retrieves secrets at start-up over an authenticated internal API.
Automatic platform patching
Cloud Run handles OS and runtime patching automatically. We maintain the application layer; Google maintains the platform. 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?
If you're logging in to a site over HTTPS — which virtually all login pages use — the content of the login form, including your password, is encrypted end-to-end between your browser and the destination site. The Reach gateway sees the host name of the connection but cannot read the content of the request, including password fields. As a general rule: avoid sending credentials over unencrypted HTTP on any network.
Can Reach read my HTTPS browsing content?
For HTTPS connections, the gateway sees the host name (e.g. example.com) but not the URL path, query string, or page content. We do not log host names for browsing-history purposes. For the small minority of unencrypted HTTP traffic that still exists on the internet, the gateway is technically capable of reading the request, but we do not log or store it.
Where is my data stored?
Account data, metering records, and any logs are stored in Google Cloud in the Sydney region. We do not replicate personal data to jurisdictions outside Australia except as required by Google's standard infrastructure 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.