Security & Infrastructure

Last updated: April 16, 2026

This page describes the security practices and infrastructure that underpin the Vox service. We aim to be transparent about what protections are in place so you can make an informed decision about using the product.

1. Data in Transit

All communication between the Vox application on your device and our servers is encrypted using Transport Layer Security (TLS). This applies to both the WebSocket connection used for real-time audio streaming and any HTTPS API calls. TLS certificates are issued by a recognised certificate authority and renewed automatically. Connections using outdated TLS versions or insecure cipher suites are rejected.

The Vox application does not communicate with our servers over plain HTTP. If your device cannot establish a TLS connection, the transcription request will fail rather than transmit data unencrypted.

2. Infrastructure

Vox server infrastructure is hosted on cloud computing platforms. We operate nodes in two locations:

• Hong Kong SAR — primary node handling requests from the Asia-Pacific region.
• Singapore — secondary node providing regional redundancy.

Servers run in isolated environments with access controls limiting which processes and personnel can reach each component. Server-to-server communication between nodes also occurs over encrypted channels.

3. Audio Handling

When you press the hotkey to record, audio is streamed from your device to our server in real time over the encrypted WebSocket connection. On the server, audio frames are decoded in memory and passed directly to the speech recognition pipeline.

Audio data is not written to disk at any stage of processing. It exists only in server memory for the duration of the transcription pipeline, which typically completes within a few seconds of you releasing the hotkey. After the pipeline returns the transcription result, the audio buffer is released and not retained. We do not store recordings, and no audio data is replicated to external storage.

4. Authentication

User passwords are stored as hashed values using bcrypt with a sufficient work factor. We do not store plaintext passwords or use reversible encryption for credential storage.

Authenticated sessions are managed via server-side session tokens. Session cookies are marked HTTP-only (not accessible to JavaScript) and are transmitted only over HTTPS. Sessions expire after a period of inactivity.

Rate limiting is applied to authentication endpoints to mitigate brute-force attempts. Accounts with repeated failed login attempts within a short window are temporarily locked.

5. Payment Security

We do not process card payments directly. All payment data — including card numbers, expiry dates, and verification codes — is handled by Airwallex, our payment processing provider. Payment entry forms are served directly by Airwallex's secure infrastructure. We receive only a payment status and a subscription identifier from Airwallex; card details never pass through our servers.

Airwallex maintains PCI DSS compliance for its payment processing operations. We rely on this compliance for the card data handling portion of the payment flow.

6. Access Controls

Access to production systems is restricted to personnel who require it for their role. Server access is via SSH using key-based authentication; password-based SSH login is disabled. Administrative access to the database is not exposed to the public internet. All production deployments follow a review and staging process before being applied to the live system.

7. What We Do Not Claim

We aim to be accurate about our security posture. We do not make the following claims:

• We do not claim to hold ISO 27001, SOC 2, or equivalent certifications at this time. If this changes, we will update this page.
• We do not claim that our systems are impenetrable. No system can provide an absolute guarantee against all possible attacks.
• We do not describe our encryption as "military-grade" or use similar marketing language, as these terms carry no technical meaning.

8. Incident Response

If we become aware of a confirmed security incident affecting user data, we will notify affected users by email within 72 hours of confirming the scope of the incident, in accordance with applicable data protection obligations. The notification will describe the nature of the incident, the data involved, and any steps you should take.

9. Reporting a Security Concern

If you believe you have discovered a security vulnerability in the Vox application or our servers, we ask that you report it to us responsibly before disclosing it publicly, so that we can investigate and address it.

To report a security concern, email security@buirlake.com. Please include:

• A clear description of the vulnerability or concern.
• Steps to reproduce the issue, if applicable.
• The potential impact as you understand it.

We will acknowledge your report within 2 business days and aim to provide a substantive response within 7 business days. We do not currently operate a formal bug bounty programme, but we will communicate our gratitude and handle your report with care.

10. General Enquiries

For general security questions that are not vulnerability reports, you may also contact us at support@buirlake.com.