No-logs policy

Last updated: October 1, 2026

No-logs policy

We do not store behavioral data, network traffic, or connection logs. Anonymity is baked into our core architecture. We've eliminated traditional credentials entirely; our system neither requests nor stores names, email addresses, usernames, passwords, or any other Personally Identifiable Information (PII). When you sign up, a unique 16-digit account number is generated to serve as your sole identifier, ensuring your access remains completely decoupled from your personal identity.

Data that we do not log

We do not monitor, record, or store any data passing through our proxy servers. Specifically:

• No logging of IP addresses.
• No logging of connections, including when one is made, when it disconnects, for how long, or any kind of session or connection timestamp.
• No logging of traffic.
• No logging of DNS requests.
• No deep packet inspection or monitoring of data payload contents.
• No tracking of physical location or GPS data.
• No logging of hardware identifiers, MAC addresses, or operating system metadata.
• No collection of telemetry or diagnostic data from our web or client applications.
• No logging of behavioral metadata.

For a complete technical breakdown of how we enforce this in every proxy server deployed, see our Server hardening.

Data that we store

To keep our service operational, enforce data limits, and manage your secure connections, we maintain a limited database. Here's the data we store from you:

Accounts table

This table holds your generated account number. We do not request any PII to create an account. Instead, our system utilizes a cryptographically secure random number generator to create a 16-digit integer. We enforce strict, database-level validation ensuring that this field can only accept exactly 16 numeric digits. It's structurally impossible for this field to store an email address, name, or arbitrary text string.

account_number
--------------
xxxxxxxxxxxxxx

Plans table

This table holds your plan type and billing cycle, your link to our payment processor, and your data usage.

The plan field stores a static identifier for your plan tier and billing frequency (e.g., 'professional_monthly'). We require this operational flag to enforce your account's technical allowances, such as maximum active simultaneous proxy servers and data limits.

Payments are processed securely via external webhooks by Stripe. We never see or capture your card details, ensuring we hold no information from your payment method. We only store the blind stripe_id to synchronize your active plan status.

The start_timestamp and end_timestamp fields define your billing cycle and determine your access window.

The usage and extra_data fields are aggregated integer counters. They track your data volume and one-time add-on purchases, containing absolutely zero qualitative data about the nature of your traffic.

We maintain the reset_timestamp linked to a high-performance database index. An independent, stateless serverless function sweeps this index, automatically resetting both your usage and extra_data counters to zero the moment your monthly data cycle ends. Historical data usage is erased, never archived.

account_number | plan | stripe_id | start_timestamp | end_timestamp | usage | extra_data | reset_timestamp
---------------|------|-----------|-----------------|---------------|-------|------------|----------------
xxxxxxxxxxxxxx | xxxx | xxxxxxxxx | xxxxxxxxxxxxxxx | xxxxxxxxxxxxx | xxxxx | xxxxxxxxxx | xxxxxxxxxxxxxxx

Web sessions table

Used to maintain secure active login sessions on this website. When you log out, the entire record is permanently deleted.

When you authenticate, we generate a high-entropy, 32-byte Base64-encoded session token, hash it using SHA-256, and store only the resulting token_hash. The raw token is passed exclusively to the user's browser cookie, and is never written to disk or our database. We explicitly omit any creation or expiration timestamps in this table. Standard web applications use timestamps to track exactly when you log in or log out. By actively stripping this metadata and hashing tokens at rest, we prevent the creation of behavioral timelines and ensure active sessions remain secure even in the event of a database compromise.

account_number | token_hash
---------------|-----------
xxxxxxxxxxxxxx | xxxxxxxxxx

Client sessions table

Used to maintain secure active login sessions on the desktop or mobile client applications. When you log out or explicitly revoke a device, the entire record is permanently deleted.

As with web sessions, we generate a high-entropy, 32-byte Base64-encoded session token and immediately hash it using SHA-256 before storing it as token_hash. The raw token is returned exclusively to your local device for client authentication, and it is never written to disk or stored in our database. These session tokens are generated completely free of creation or expiration timestamps to prevent behavioral tracking. We refuse to capture hardware identifiers, MAC addresses, IP addresses, or operating system metadata from your devices.

The client_name field dynamically assigns a random name to each device when it logs in (utilizing a dictionary algorithm to generate a unique Noun-Noun combination, like Apple-Tree). You can use this anonymous identifier to manage your active tokens and revoke access if needed.

account_number | token_hash | client_name
---------------|------------|------------
xxxxxxxxxxxxxx | xxxxxxxxxx | xxxxxxxxxxx

Proxy servers table

Provisions your temporary secure connection to our infrastructure. This entire record is managed ephemerally. Once the server is terminated, it's permanently deleted.

The site_id references your chosen geographical data center, while the ip_address and port store the standard network routing parameters required for the client application to connect to the server.

The password field is generated as a secure 32-byte Base64-encoded key, and the encryption_method field statically dictates the cipher protocol required for the connection (we currently use the 2022-BLAKE3-AES-256-GCM encryption method). Before the proxy server password is saved to the database, it's encrypted at rest using AES-128-CBC (Fernet symmetric encryption). This ensures that even in the event of a catastrophic server compromise, the raw connection keys remain completely unreadable to anyone examining the database files.

The status is a simple integer flag used for server orchestration.

account_number | site_id | ip_address | port | password | encryption_method | status
---------------|---------|------------|------|----------|-------------------|-------
xxxxxxxxxxxxxx | xxxxxxx | xxxxxxxxxx | xxxx | xxxxxxxx | xxxxxxxxxxxxxxxxx | xxxxxx

Application-level logging

Our public API and web application do not log, parse, or store your source IP address, connection timestamps, or behavioral data. We deploy zero behavioral analytics, tracking scripts, or third-party marketing cookies (for a complete breakdown of the strictly necessary cookies we do use, see our Cookie policy).

Our desktop and mobile client applications are built entirely without telemetry, crash reporting software, or diagnostic trackers. They do not send error logs, connection states, or diagnostic data to our servers or any third-party monitoring service.

Our application backend generates standard operational logs for debugging purposes (such as crash reports or internal server errors), but these logs are structurally stripped of PII. They contain only non-identifying system events.

Edge-network boundary

To protect our public API and web application from DDoS and brute-force guessing attacks, we route public web traffic through a Web Application Firewall (WAF) managed by AWS CloudFront. This edge network temporarily processes incoming web request IP addresses strictly to enforce algorithmic rate limits and block malicious bot traffic before it reaches our application. This security layer applies exclusively to our public API and web application. It does not touch, monitor, or route your encrypted proxy server connections.

Network-layer boundary

While we control our application and database layers, evadity operates on third-party cloud infrastructure (Google Cloud Platform and Amazon Web Services). When you connect to a proxy server, these cloud providers independently log basic network connection metadata (your source IP address, connection timestamps, and data volume) at the hypervisor level. To understand why we made this architectural trade-off for performance, and how our zero-knowledge database isolates your identity from these network logs, please see our FAQ.