What Are Zero-Log Proxies and Why Logging Policy Matters

"Zero-log" has no definition in any standard, statute, or certification scheme. It is a marketing phrase, and every operator using it picks which data classes the word covers. Two providers can both say "zero logs" while one drops per-request destinations after 60 seconds and the other keeps a 90 day table of account ID, exit IP, target hostname, and byte counts, calling that "operational data" rather than logs.

The rename is the tell. Read any logging policy looking for the word carrying the exception: "operational metrics", "aggregated data", "diagnostic data", "connection records", "abuse prevention data". Those are all logs. Most are justified, and a provider that names them plainly is more honest than one that reaches zero by definition.

One version of the claim is meaningful and achievable: the operator does not retain, past a short and stated window, any record that links a specific customer to a specific destination. That is a real engineering commitment with real costs, and the only version worth a premium. It is not what most marketing pages assert.

Before judging any policy, work out the floor. Some processing is not a privacy choice, it is what the service is.

The abuse row quietly kills the strict reading. When a target site or an upstream network sends a complaint naming an exit IP, a timestamp, and a destination, the operator has to act on it. A provider retaining nothing could not identify which customer to suspend, leaving it to null-route the exit IP or ignore the complaint. Do that at volume and transit providers stop wanting the relationship.

So the honest floor is: some window exists in which traffic is attributable. How long that window is, and who can reach into it, are the two numbers the rest of a logging policy hangs off.

Most confusion here comes from treating "logs" as one thing. There are three classes with very different privacy weight, and providers routinely answer a question about one using a fact about another.

"We never log your traffic" almost always means the content class, the easiest one to not have. "We do not store browsing history" is about the request class and is a stronger claim. Neither says anything about the connection class, where billing and abuse data live and where a subpoena is aimed. Sort every sentence in a policy into one of these three rows before deciding what you were told, and notice that the sentences nobody writes are usually the connection ones.

For HTTPS traffic through a forward proxy, the operator cannot see the URL path. The client opens a tunnel with the CONNECT method defined in RFC 9110, which carries only host and port, then negotiates TLS end to end inside it. The path, query string, headers, and body are inside the encrypted stream.

So "we do not log the URLs you visit" is, for almost all modern traffic, a description of what the protocol already prevents rather than a policy choice. The operator still sees the hostname, from the CONNECT line and again from the TLS Server Name Indication extension in RFC 6066. Hostname plus timestamp plus account is usually all an investigator needs.

Two consequences worth holding onto:

• Ask about destination hostnames, not URLs. That is the field with the actual signal, and it is the one that survives TLS.
• Encrypted Client Hello removes plaintext SNI where both ends support it, but the proxy still learns the host from CONNECT. ECH changes what passive observers on the wire see, not what a forward proxy sees.

Plain HTTP is the exception: full URLs and query strings are visible to the proxy. If you still have unencrypted traffic in a workload, the logging policy is not your first problem. The related failure mode is DNS resolving outside the tunnel, covered in our guide to proxy DNS leak testing and mitigation.

Given that some data must exist, the only variables that change your exposure are how long it survives and how many copies exist. "We delete connection records after 24 hours" describes one table. Data has more homes than that.

The backup window is the real retention floor, and almost no buyer asks about it. Deleting rows from a live table does nothing to a snapshot taken before the deletion. A provider running a managed database with a 30 day point-in-time restore window while claiming 24 hour retention is stating two literally true things whose practical answer is 30 days. Ask explicitly. A provider that has thought about it will have shortened the window on those tables, excluded them from backups, or told you the honest number.

The second underasked question is whether retention is enforced by a mechanism or by a document. "We delete after 72 hours" backed by a cron job someone can pause is weaker than a TTL on the storage engine, which is weaker again than never writing the field. Ranked by strength: not collected, dropped in memory, storage-enforced TTL, cron job, deleted on request.

A logging policy is a promise the operator makes. Lawful access is an obligation a court imposes. When they conflict, the court wins and the policy quietly acquires an exception.

Four jurisdictions matter, often four different countries: where the legal entity is incorporated, where the servers sit, where the staff holding production credentials live, and where the payment processor operates. A provider incorporated somewhere with no retention mandate, but with engineers and infrastructure inside the EU or the US, is reachable through those.

In the United States, stored records are compelled through the Stored Communications Act. 18 U.S.C. section 2703 sets out the tiers, from subpoena for basic subscriber information up to warrant for content, and subsection (f) lets an agency require a provider to preserve existing records for 90 days, renewable once, before any legal process arrives. That preservation power matters more than it looks: a provider with a 24 hour retention policy that receives a preservation letter today keeps whatever it holds today. The CLOUD Act reach, codified at 18 U.S.C. section 2713, extends this to records in the provider's possession, custody, or control regardless of where they are stored.

In the EU, blanket retention mandates have repeatedly failed at the Court of Justice. Digital Rights Ireland (C-293/12) invalidated the Data Retention Directive in April 2014, and Tele2 Sverige and Watson (C-203/15) struck down general and indiscriminate national retention in December 2016. Traffic data handling for billing purposes remains permitted under Article 6 of the ePrivacy Directive 2002/58/EC, which is the legal hook under which connection metadata legitimately persists.

The "eyes" country framing on comparison pages is mostly noise. Intelligence sharing arrangements are not the mechanism that produces a specific customer's records. Compulsion through a court with jurisdiction over the entity is. Ask which courts those are, and whether the provider publishes a transparency report with request counts, since one that never has offers no track record to evaluate.

Audits are the strongest evidence available in this market, and they are systematically overread. What an assurance engagement delivers depends on three things: who set the scope, which standard was used, and whether it covered a point in time or a period.

A SOC 2 report under the AICPA Trust Services Criteria tests controls that the service organisation itself described. A Type I opinion covers design at a point in time. A Type II covers operating effectiveness across a period, typically 3 to 12 months. Many privacy attestations outside the US are performed under ISAE 3000, the IAASB standard for assurance engagements other than audits of historical financial information, with a similarly client-defined scope.

What that structure does prove, when the report is real:

• The controls listed in the report existed and, for a Type II, operated over the stated period.
• An independent firm inspected configuration and records rather than taking management's word.
• Someone is on the hook professionally for the opinion.

What it cannot prove:

• That no data exists outside the audited systems. Scope is set by the client, and anything excluded is invisible to the report.
• That the state persists after the report date. An audit is a photograph.
• That the operator would not comply with a lawful order. No audit tests that, and none claims to.

Ask for the report, not the badge, and read the scope section and system description first to see which systems and which period are inside them. If the provider will only share a marketing summary, you have a marketing summary. Also: a penetration test is not a logging audit, and a code review of a client application says nothing about server-side retention.

The counterexamples are instructive. In the 2017 US prosecution described in the Department of Justice announcement in United States v. Ryan Lin, records obtained from a VPN provider that publicly advertised a no-log policy contributed to the investigation. Policy pages are not architecture.

If your traffic touches EU or UK data, roles matter more than marketing. Under the GDPR, the controller determines purposes and means of processing and the processor acts on the controller's instructions. For a normal proxy or scraping engagement the split runs like this:

• You are the controller for the data you collect through the proxy. You chose the targets, the fields, and the retention. If you scrape personal data, that is your processing and your legal basis to justify.
• The provider is a processor for the traffic it carries on your instruction, which triggers Article 28 and requires a written data processing agreement covering subject matter, duration, sub-processors, security measures, and deletion or return at the end of the service.
• The provider is simultaneously a controller for its own account, billing, security, and abuse records. Those exist for the provider's purposes, not yours. This dual role is the part almost no logging policy explains, and it is where "we hold nothing about you" and "we invoice you monthly" collide.

The EDPB Guidelines 07/2020 on the concepts of controller and processor are the reference for drawing this line, and they make clear that the label in a contract does not decide the role. Actual influence over purposes and means does.

Two provisions make an absolute zero-log claim legally incoherent for a provider in scope. Article 30 requires processors to maintain records of processing activities carried out on behalf of each controller. Article 33 requires notification of a personal data breach to the supervisory authority within 72 hours where feasible, including the categories and approximate number of records concerned, which is impossible to establish without a trail. A provider claiming to keep literally nothing is claiming either that it is out of scope or that it is non-compliant.

One more piece of doctrine is load bearing. In Breyer (C-582/14), decided 19 October 2016, the Court of Justice held that a dynamic IP address is personal data in the hands of an online service provider with legal means to identify the person behind it. The exit IP and timestamp pairs in a proxy operator's abuse table are therefore not neutral technical data. They are personal data, with everything that follows: a lawful basis, usually legitimate interests under Article 6(1)(f), a defined retention period, and data subject rights. That last point makes the first test below work.

Reading policies is weak evidence. These four probes produce evidence, and none of them require trusting the answer at face value.

1. File a subject access request against your own account

Under Article 15, a data subject can obtain confirmation of whether personal data concerning them is processed, plus a copy, and the controller must respond within one month. You are a data subject for the provider's account, billing, and security records, because those are held about you as an identified customer.

Send it in writing to the privacy contact and keep it narrow:

To: privacy@example-provider.tld
Subject: Article 15 subject access request, account 4471

Under Article 15 GDPR I request confirmation of whether personal data
concerning me is processed, and a copy of it. Specifically:

1. All records associating my account with connection metadata
   (timestamps, source IP addresses, assigned exit IP addresses,
   destination hostnames, byte counts) for the last 90 days.
2. The retention period applied to each category, and the criteria
   used to set it.
3. The recipients or categories of recipient to whom the data has
   been or will be disclosed, including sub-processors.

Please respond within one month under Article 12(3).

The answer beats any policy page as evidence. It is a legal statement rather than marketing copy, it enumerates categories never written down publicly, and a refusal or a silence is itself a result. Point 3 is the sharpest: sub-processor disclosure often reveals a logging or observability vendor the privacy page never mentioned.

2. Ask the abuse question, not the logging question

Send this: "You receive an abuse complaint naming exit IP 203.0.113.40, timestamp 14 days ago, destination example.com. Walk me through what happens." The reply is the retention policy stated operationally, and it is much harder to spin. If they can identify and suspend the account, they had 14 days of attribution data whatever the policy says. If they cannot, ask what they tell the complainant and how they keep transit.

3. Ask for the backup and restore window

One question: "What is the point-in-time restore window on the database holding connection records, and are those tables excluded from backups?" That is the retention floor. It doubles as a competence test, since a provider that cannot answer quickly has not thought about retention at the storage layer.

4. Read what the API itself returns

Product surfaces disclose their own architecture. Job identifiers, session labels, and usage counters imply persisted records, whatever the policy says. SparkProxy's own Scraping API returns identifiers in the response headers:

curl -sD - -o /dev/null \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  "https://scrape.sparkproxy.io/api/v1?url=https%3A%2F%2Fexample.com&render_js=false&tag=audit-check"

HTTP/2 200
x-job-id: 9f2c41ae-1b77-4a3d-9d0e-2c8e51f0a6b1
x-credits-used: 1
x-duration-ms: 412

A job ID means a job record. A credit counter means metered usage tied to an account. Run the same check against any provider's API before you read their privacy page, and you will know which questions to ask.

A provider that answers seven of these well and admits a weakness on the eighth is more trustworthy than one that answers all eight perfectly and vaguely. Precision about limits is the signal, the same principle that governs evaluating a residential or datacenter proxy service, where the specific number always beats the superlative.

Applying the article to ourselves, since a buyer should be able to use it on us.

We meter bandwidth and credits per account, so byte and request counts are attributed to an identified customer. That is how usage-based pricing works, and every provider billing per gigabyte does the same whatever its homepage says.

We answer abuse complaints, so a window exists during which traffic is attributable to an account. A residential or mobile pool strengthens that obligation rather than weakening it, because the addresses belong to real subscribers whose ISPs escalate. An operator claiming it runs a residential pool while retaining nothing is describing a network that would lose its supply.

Our Scraping API is structurally not a zero-log product, and we would rather say so than word around it. It takes a URL, fetches it, and returns the body, so processing the destination and the content is the function rather than an accident of implementation. The response headers above carry a job ID and a credit count, and the session_id and tag parameters in the Scraping API documentation exist to label records for grouping. Anyone buying a managed fetch service from anyone, us included, buys a product whose provider sees the request. The honest question for that class is retention and access control, not existence.

A plain forward proxy is a different shape. There the request class is genuinely optional, since the operator need not parse anything above the transport to move bytes, and TLS puts the path out of reach anyway as covered in the CONNECT section. Anonymity and logging are therefore separate axes. A proxy can be elite by the proxy anonymity levels taxonomy, stripping identifying request headers, while the operator still keeps a full connection table. The reverse holds too: a transparent proxy announces itself in headers and might retain very little. Header behaviour is what the target sees. Logging is what the operator keeps. Conflating them is the most common error in this subject.

Two constraints apply to every operator in the market. Payment records outlive traffic records by years because card schemes and anti-money-laundering rules require it, so the account-to-identity link survives long after any connection table. And authentication method matters: IP allowlisting means your own source addresses are processed on every connection, a data point that username and password authentication never creates.

None of this argues for indifference. It argues for buying on stated fields, stated windows, stated jurisdictions, and a signed Article 28 agreement rather than a two-word claim. Pair that with a defensible collection posture on your own side, the subject of our guide on ethical scraping and rate limiting, and you have something to put in front of a compliance reviewer.