Privacy · XB Field Notes

DoT and DoH protect the connection to the resolver you authenticate

Thu, 07 Oct 2027 00:00:00 +0000

DNS over TLS and DNS over HTTPS protect DNS traffic on the encrypted connection between their endpoints. For a typical client, that connection ends at the selected resolver. The resolver can read the question and answer, and its later queries may follow different transports. Encrypting this hop does not automatically encrypt every recursive exchange or make the resolver unable to log the names it handles.

Read the encryption boundary and the authentication evidence separately. Ports 853/443 are normal protocol choices; 8531/8443 belong to the article’s loopback fixture. Its certificate-failure diagnostics override an exit code of zero. This is source-based illustration only: the encrypted-DNS runtime review remains pending, and the exercise was not rerun.

When it breaks

An encrypted socket without the intended certificate validation can connect to the wrong endpoint. Verify both the certificate’s trust chain and the resolver identity expected by the client. A successful handshake alone does not prove those checks were enabled. Configuration that silently uses a different resolver or a plaintext path on failure also changes the privacy contract and must be understood through the actual caller.

DoH uses HTTPS, but port 443 does not make its traffic unidentifiable, unblockable, or indistinguishable in every network. Destination addresses, connection timing, and other metadata remain observable. TLS termination points can inspect plaintext HTTP. Choose a resolver and transport policy with those boundaries in mind rather than assuming that an HTTPS URL removes every source of DNS-related information exposure.

The two protocols also have different message framing. DoT normally uses port 853 and carries DNS messages with the TCP two-byte length prefix inside TLS. DoH normally uses an HTTPS endpoint on port 443. Standard DoH carries DNS wire-format messages using application/dns-message; POST places the message in the body, while GET uses a base64url-encoded dns parameter. It is not defined as arbitrary JSON over HTTPS.

Check it quickly

Save this as check-encrypted-dns.py and run python3 check-encrypted-dns.py with Docker. The pinned BIND 9.18.49 environment supports DoT and DoH through its linked TLS and HTTP/2 libraries. The script creates a disposable certificate, trusts it explicitly for successful probes, and uses isolated loopback ports 8531 and 8443. It does not install a new host-wide trust anchor:

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends bind9=1:9.18.49-1~deb12u2 bind9-dnsutils=1:9.18.49-1~deb12u2 dnsmasq-base=2.90-4~deb12u2 python3-dnspython=2.3.0-1 && rm -rf /var/lib/apt/lists/*\nCMD ["/usr/bin/python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,re,signal,subprocess,time
import dns.exception,dns.message,dns.query,dns.rcode,dns.rdatatype

def run(*args,check=True):
 result=subprocess.run(args,capture_output=True,text=True,timeout=15)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def query(name,kind='A',port=1053):
 return dns.query.udp(dns.message.make_query(name,kind),'127.0.0.1',port=port,timeout=1)
def values(response,kind='A'):
 wanted=dns.rdatatype.from_text(kind)
 return [item.to_text() for rrset in response.answer if rrset.rdtype==wanted for item in rrset]
def show(response):
 def section(records):return [{'name':str(rr.name),'type':dns.rdatatype.to_text(rr.rdtype),'ttl':rr.ttl,'data':[item.to_text() for item in rr]} for rr in records]
 return {'rcode':dns.rcode.to_text(response.rcode()),'answer':section(response.answer),'authority':section(response.authority)}
def wait(predicate,timeout=15):
 deadline=time.monotonic()+timeout
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except (OSError,dns.exception.Timeout):pass
 time.sleep(.05)
 raise AssertionError('DNS fixture condition did not become true')
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=5)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=5)

@contextmanager
def lab(records,soa_ttl=8,minimum=4,extra=''):
 with TemporaryDirectory(prefix='xbcatm-dns-') as directory,ExitStack() as stack:
 root=Path(directory);zone=root/'zone';conf=root/'named.conf';log=root/'named.log';serial=1
 def save(body):
 zone.write_text(f'$ORIGIN lab.test.\n$TTL 30\n@ {soa_ttl} IN SOA ns.lab.test. hostmaster.lab.test. ({serial} 60 60 3600 {minimum})\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\n'+body+'\n')
 run('named-checkzone','lab.test',str(zone))
 save(records)
 conf.write_text(f'''options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}}; listen-on-v6 {{none;}};
recursion no; dnssec-validation no; notify no; querylog yes; max-cache-size 8m; pid-file "{root}/named.pid"; session-keyfile none;
{extra} }};
controls {{}};
zone "lab.test" {{ type primary; file "{zone}"; }};
''')
 run('named-checkconf',str(conf))
 output=stack.enter_context(log.open('w'))
 authority=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 stack.callback(stop,authority)
 def ready():
 assert authority.poll() is None,log.read_text()
 response=query('lab.test.','SOA');return response.rcode()==0 and response.answer[0][0].serial==serial
 wait(ready)
 def update(body):
 nonlocal serial
 serial+=1;save(body);authority.send_signal(signal.SIGHUP);wait(ready)
 def cache(port=1054,upstream=1053,size=150,options=()):
 logfile=root/('cache-'+str(port)+'.log');stream=stack.enter_context(logfile.open('w'))
 command=['dnsmasq','--no-daemon','--conf-file=/dev/null','--no-resolv','--no-hosts','--bind-interfaces',
 '--listen-address=127.0.0.1','--port='+str(port),'--server=127.0.0.1#'+str(upstream),
 '--cache-size='+str(size),'--log-queries','--log-facility=-',*options]
 process=subprocess.Popen(command,stdout=stream,stderr=subprocess.STDOUT);stack.callback(stop,process)
 def cache_ready():
 assert process.poll() is None,logfile.read_text()
 return query('lab.test.','SOA',port).rcode()==0
 wait(cache_ready);return process,logfile
 def queries(name,kind='A'):
 return sum(bool(re.search(r'query: '+re.escape(name.rstrip('.'))+r' IN '+kind+r'\b',line)) for line in log.read_text().splitlines())
 yield root,update,cache,queries

@contextmanager
def named_process(root,config):
 root.mkdir(exist_ok=True);conf=root/'named.conf';log=root/'named.log';conf.write_text(config)
 run('named-checkconf',str(conf))
 with log.open('w') as output:
 process=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 try:
 def ready():
 assert process.poll() is None,log.read_text()
 return re.search(r'\brunning\s*$',log.read_text(),re.M) is not None
 wait(ready);yield process,log
 finally:stop(process)
import socket,ssl,struct
def exact(stream,count):
 data=b''
 while len(data)<count:
 more=stream.recv(count-len(data));assert more,'unexpected EOF';data+=more
 return data
with TemporaryDirectory(prefix='xbcatm-dot-') as directory:
 root=Path(directory);certificate=root/'certificate.pem';key=root/'key.pem'
 run('openssl','req','-x509','-newkey','rsa:2048','-nodes','-days','2','-subj','/CN=resolver.lab.test',
 '-addext','subjectAltName=DNS:resolver.lab.test,IP:127.0.0.1','-keyout',str(key),'-out',str(certificate))
 zone=root/'zone';zone.write_text('$ORIGIN lab.test.\n$TTL 30\n@ IN SOA ns.lab.test. hostmaster.lab.test. (1 60 60 3600 30)\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\nservice IN A 127.0.0.2\n')
 config=f'''tls local-tls {{ key-file "{key}"; cert-file "{certificate}"; }};
http local-http {{ endpoints {{ "/dns-query"; }}; }};
options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}};
listen-on port 8531 tls local-tls {{127.0.0.1;}};
listen-on port 8443 tls local-tls http local-http {{127.0.0.1;}};
listen-on-v6 {{none;}}; recursion no; dnssec-validation no; notify no;
pid-file "{root}/named.pid"; session-keyfile none; max-cache-size 8m; }};
controls {{}}; zone "lab.test" {{ type primary; file "{zone}"; }};
'''
 with named_process(root,config):
 context=ssl.create_default_context(cafile=str(certificate));context.set_alpn_protocols(['dot'])
 with socket.create_connection(('127.0.0.1',8531),timeout=2) as raw,context.wrap_socket(raw,server_hostname='resolver.lab.test') as stream:
 q=dns.message.make_query('service.lab.test.','A');wire=q.to_wire();stream.sendall(struct.pack('!H',len(wire))+wire)
 count=struct.unpack('!H',exact(stream,2))[0];response=dns.message.from_wire(exact(stream,count))
 assert response.id==q.id and values(response)==['127.0.0.2'];tls_version=stream.version();alpn=stream.selected_alpn_protocol()
 failures={}
 for name,ctx,hostname in [('untrusted',ssl.create_default_context(),'resolver.lab.test'),('wrong_name',context,'different.lab.test')]:
 try:
 with socket.create_connection(('127.0.0.1',8531),timeout=2) as raw,ctx.wrap_socket(raw,server_hostname=hostname):pass
 raise AssertionError('certificate validation unexpectedly succeeded')
 except ssl.SSLCertVerificationError as error:failures[name]=error.verify_code
 https={}
 for mode in ('https-get','https-post'):
 output=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+'+mode,'+tls-ca='+str(certificate),
 '+tls-hostname=resolver.lab.test','+short','+tries=1','+time=2').stdout
 assert output.strip()=='127.0.0.2',output;https[mode]=output.strip()
 doh_rejections={}
 for label,verification in [('untrusted',['+tls-ca','+tls-hostname=resolver.lab.test']),
 ('wrong_name',['+tls-ca='+str(certificate),'+tls-hostname=different.lab.test'])]:
 rejected=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+https-get',*verification,'+short','+tries=1','+time=2',check=False)
 diagnostic=rejected.stdout+rejected.stderr
 assert 'TLS peer certificate verification' in diagnostic and 'failed:' in diagnostic,(label,diagnostic)
 assert not re.search(r'^127\.0\.0\.2$',diagnostic,re.M)
 doh_rejections[label]={'exit':rejected.returncode,'diagnostic':diagnostic.strip(),'no_DNS_answer':True}
 wrong_path=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+https=/wrong',
 '+tls-ca='+str(certificate),'+tls-hostname=resolver.lab.test','+tries=1','+time=2',check=False)
 assert wrong_path.returncode!=0
 print(json.dumps({'DoT':{'answer':values(response),'TLS_version':tls_version,'ALPN':alpn},'certificate_rejections':failures,
 'DoH_verified_TLS':https,'DoH_certificate_rejections':doh_rejections,'wrong_DoH_path_exit':wrong_path.returncode,
 'wrong_DoH_path_diagnostic':wrong_path.stdout+wrong_path.stderr},sort_keys=True))
"""
name='xbcatm-dns-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 built=docker('build','-t',name,str(root));assert built.returncode==0,built.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--memory','384m','--pids-limit','128',name,
 '/usr/bin/python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

The Python DoT client authenticates resolver.lab.test, negotiates TLS 1.3 with ALPN dot in the recorded run, and sends a length-prefixed DNS question. It reads the complete framed response, verifies the message ID, and receives A 127.0.0.2 for service.lab.test. Supplying the loopback connection address separately from the expected TLS hostname keeps endpoint location and authenticated identity explicit.

Two DoT controls fail certificate verification: using the system trust store without the disposable certificate, and requesting a different hostname while trusting that certificate. These failures demonstrate both trust and name checks. The test catches the specific certificate-verification exception; it does not classify an arbitrary socket failure as successful proof that certificate validation worked.

For DoH, dig performs HTTPS GET and POST queries against /dns-query with explicit CA and hostname validation. Both return 127.0.0.2. The untrusted-certificate and wrong-hostname controls emit certificate-verification errors without a DNS answer, despite exiting zero in this version. The assertions inspect those diagnostics instead of trusting exit status. Querying /wrong with valid trust settings also fails: authenticated HTTPS still needs the correct endpoint path.

The bad-path diagnostic is a failed exchange, not NXDOMAIN and not evidence that service.lab.test disappeared. This example does not extract a specific HTTP status from that diagnostic. It preserves the distinction between transport or endpoint failure and a completed DNS response carrying a DNS response code, preventing a generic command failure from being reported as an authoritative negative answer.

Keep the resolver and bootstrap configuration visible

A client needs an address for its encrypted resolver before it can connect. Deployments can provide bootstrap addresses or another documented discovery path. The fixture supplies loopback directly, avoiding a circular dependency on the same resolver. In production, verify how bootstrap, certificate renewal, endpoint changes, and connection failures behave for the client implementation actually in use.

Check whether application queries traverse the configured encrypted connection. Other processes may use the operating system’s resolver, another browser setting, or cached data. One successful DoH command demonstrates that command’s path, not a machine-wide policy. Observe the intended applications and their failure behavior before claiming that all their name lookups receive the same transport protection.

Finally, DNSSEC and encrypted DNS address different properties. DNSSEC can authenticate signed DNS data through a trust chain; TLS protects and authenticates the selected transport endpoint. Neither mechanism automatically supplies the other’s guarantee. Use both where the service contract requires them, and keep evidence for certificate validation, actual encrypted queries, resolver trust, and DNS-data validation distinct.

Sources

RFC 7858 DNS over TLS, TLS transport, dedicated port, and connection framing, checked 2026-09-12.
RFC 8484 DNS over HTTPS, DoH GET and POST mapping and application/dns-message, checked 2026-09-12.
BIND 9.18.49 tools, dig encrypted transports and explicit certificate validation, checked 2026-09-12.

Sequential identifiers reveal allocation patterns

Sat, 29 May 2027 00:00:00 +0000

A sequential identifier makes nearby values easy to guess. Seeing order number four thousand gives an observer a useful place to probe, and collecting identifiers over time may reveal allocation activity. It does not establish that four thousand orders exist, that all numbers represent successful purchases, or that the largest identifier committed last. Those conclusions require information that a sequence does not contain.

When it breaks

PostgreSQL sequences allocate values outside ordinary transaction rollback. An aborted insert can consume a number permanently. Deleted rows, reserved cache ranges, explicit sequence changes, and multiple writers further separate the counter from the table’s current population. Using the largest identifier as a customer count produces misleading business reports even without malicious activity.

Allocation order also differs from commit order. One transaction can obtain a smaller number and wait while another obtains a larger number and commits immediately. A consumer that treats increasing identifiers as a complete committed event stream can advance past the smaller row before that row becomes visible. A numeric key is not a change-data-capture position or a complete ordering of business events.

Random identifiers reduce easy enumeration but do not grant access control. A UUID can appear in logs, shared links, or another response. Anyone who learns it must still pass the resource’s authorization check. UUIDv4 contains random bits; UUIDv7 starts with a millisecond timestamp field and is designed for time ordering. Its prefix is not random, and its timestamp is not proof of database commit time.

Allocation, commit order, population count and authorization are different facts. The UUID stays unchanged when the ownership policy changes access. Source fixture only; not rerun.

Check it quickly

Use PostgreSQL 18 with two administrator psql sessions, A and B, against a disposable database. Version 18 is needed here for uuidv7() and UUIDv7 timestamp extraction; extraction functions themselves already exist in version 17. Ensure the schema and two role names are unused. Begin with autocommit enabled and the usual Read Committed isolation. In B, create the fixture:

CREATE SCHEMA article_ids;
CREATE ROLE article_id_alice NOLOGIN;
CREATE ROLE article_id_bob NOLOGIN;
SET search_path=article_ids,public;
CREATE TABLE objects (
 id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 public_id uuid NOT NULL DEFAULT gen_random_uuid() UNIQUE,
 owner text NOT NULL,
 label text NOT NULL
);

In A, allocate the first identifier without committing:

SET search_path=article_ids,public;
BEGIN;
INSERT INTO objects (owner,label) VALUES ('article_id_alice','allocated first') RETURNING id;

In B, insert the second row and inspect visibility:

INSERT INTO objects (owner,label) VALUES ('article_id_bob','committed first') RETURNING id;
SELECT array_agg(id ORDER BY id) FROM objects;

B returns identifier two and sees only {2}. A has already obtained one, but its uncommitted row is invisible to B. Now commit A:

COMMIT;

Continue in B, making a deliberate rollback gap and inspecting both UUID versions:

SELECT array_agg(id ORDER BY id) FROM objects;
BEGIN;
INSERT INTO objects (owner,label) VALUES ('article_id_alice','rolled back') RETURNING id;
ROLLBACK;
INSERT INTO objects (owner,label) VALUES ('article_id_alice','after gap') RETURNING id;
SELECT max(id),count(*) FROM objects;
SELECT bool_and(uuid_extract_version(public_id)=4) FROM objects;
WITH sample AS MATERIALIZED (SELECT uuidv7() AS value)
SELECT uuid_extract_version(value),uuid_extract_timestamp(value) IS NOT NULL FROM sample;

The outputs include {1,2}, the abandoned identifier three, the next identifier four, and 4|3: maximum four, only three rows. The final checks report true for version four and 7|t for version seven with an extractable timestamp. Exact UUID values change on each run and are not expected constants.

Still in B, save Bob’s UUID in a client variable and query as Alice before installing any row policy:

SELECT public_id AS bob_id FROM objects WHERE owner='article_id_bob' \gset
GRANT USAGE ON SCHEMA article_ids TO article_id_alice,article_id_bob;
GRANT SELECT ON objects TO article_id_alice,article_id_bob;
SET ROLE article_id_alice;
SELECT count(*) FROM objects WHERE public_id=:'bob_id'::uuid;
RESET ROLE;

Alice sees one matching row despite knowing only Bob’s random public identifier. Enable ownership filtering and repeat the identical lookup:

ALTER TABLE objects ENABLE ROW LEVEL SECURITY;
CREATE POLICY owner_only ON objects FOR SELECT USING (owner=current_user);
SET ROLE article_id_alice;
SELECT count(*) FROM objects WHERE public_id=:'bob_id'::uuid;
SELECT array_agg(id ORDER BY id) FROM objects;
RESET ROLE;
SET ROLE article_id_bob;
SELECT count(*) FROM objects WHERE public_id=:'bob_id'::uuid;
RESET ROLE;

Now Alice receives zero matches and sees only identifiers one and four, while Bob receives one match for his own identifier. The changed result comes from the policy, not from changing UUID generation. These test roles are neither table owners nor superusers; privileged roles can bypass row security. Clean up in B after A has committed:

DROP SCHEMA article_ids CASCADE;
DROP ROLE article_id_alice;
DROP ROLE article_id_bob;

Choose identifiers and permissions separately

An internal sequence plus a public random identifier can support efficient joins and less predictable URLs. It also adds another unique index and another identifier to maintain. Evaluate that cost against the actual enumeration and disclosure requirements. A time-ordered UUID may improve insertion locality in some workloads, but exposes time information and does not automatically improve every database index.

Authorize every lookup using the authenticated principal and requested object, including alternative lookup routes. The demonstration maps principals to database roles for clarity; an application must establish its own trusted identity context rather than accept an owner name supplied by the requester. Measure totals with the appropriate business query, and use a documented event or replication position when completeness across concurrent commits matters.

Sources

PostgreSQL 18 CREATE SEQUENCE, gaps and sequence allocation semantics, checked 2026-09-10.
RFC 9562, UUIDv4 randomness and UUIDv7 timestamp layout, checked 2026-09-12.
PostgreSQL 18 UUID functions, generation and extraction used in the exercise, checked 2026-09-12.
PostgreSQL 18 row security, ownership policies and privileged bypass, checked 2026-09-12.
PostgreSQL 17 UUID functions, pre-existing extraction functions and the version-specific UUIDv7 boundary, checked 2026-10-15.

Referrer-Policy chooses how much source URL to send

Wed, 24 Mar 2027 00:00:00 +0000

The HTTP Referer request header can tell a destination which page initiated a request. Its historical spelling differs from Referrer-Policy, the policy that controls how much source information the browser supplies. Depending on that policy and the destination, the value may include the source path and query, contain only the source origin, or be omitted. Sending the full URL to every external destination is not the modern default.

The usual current default is strict-origin-when-cross-origin. It sends path and query information for same-origin requests, only the origin across origins at an acceptable security level, and no referrer on a security downgrade such as HTTPS to HTTP. Explicitly selecting a policy still makes the intended behavior reviewable. Origin-only disclosure is smaller than a full URL, but the hostname itself can remain meaningful information.

Distinguish the policy choices

no-referrer omits the header. same-origin retains the fuller value only for same-origin destinations. unsafe-url can disclose origin, path, and query more broadly, including where stricter policies would suppress them. URL fragments are removed from the referrer calculation, so a fragment visible in the address bar should not appear in the received Referer header. Do not confuse that omission with a promise that fragments are secret from page scripts or browser state.

Set the document policy through the response header, or use HTML’s <meta name="referrer" content="..."> mechanism when appropriate. An invented http-equiv="Referrer-Policy" tag is not the equivalent syntax. Some elements and fetch requests also support a per-request referrer policy. These possibilities mean that the document header alone may not explain every observed request; inspect the initiating context and any explicit request-level choice.

When it breaks

An application can depend on receiving a full Referer path and then fail when a stricter policy or browser privacy behavior removes it. Referrer data is not a reliable authentication credential or a substitute for explicit application parameters. Likewise, changing this policy cannot grant CORS access to a response or remove an access token already placed in the destination URL. It controls one piece of request metadata, not every information flow.

Another mistake is assuming cross-origin and cross-site are interchangeable. Different ports on the same host are different origins, which is enough to change the policy result in this example. Same-origin requests can still reveal sensitive path or query information to another endpoint on that origin. Review what each receiver genuinely needs, and inspect redirect chains or resource-specific policies when the observed value differs from the document’s apparent default.

Compare what each receiver gets under the four policies. The full value means origin, path, and query after fragment removal; this equal-security fixture does not exercise HTTPS downgrade behavior.

Check it quickly

Save this as referrer-policy.py, run python3 referrer-policy.py --serve, and open the printed page URL with ?policy=strict-origin-when-cross-origin&demo=visible#fragment-not-sent. Python 3.14.4 and Chrome 152 were used. Two temporary loopback servers provide a page and a cross-origin receiver. The page fetches both a same-origin and a cross-origin endpoint, which return the Referer values they actually received. Control-C closes both servers.

import json
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.parse import parse_qs, urlsplit
from urllib.request import urlopen

policies = {"strict-origin-when-cross-origin", "no-referrer", "same-origin", "unsafe-url"}


class Receiver(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 body = json.dumps({"referer": self.headers.get("Referer")}).encode()
 self.send_response(200)
 self.send_header("Content-Type", "application/json")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Access-Control-Allow-Origin", app_origin)
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)


class App(Receiver):
 def do_GET(self):
 url = urlsplit(self.path)
 if url.path == "/collect":
 return super().do_GET()
 policy = parse_qs(url.query).get("policy", ["strict-origin-when-cross-origin"])[0]
 assert policy in policies
 body = ("""<!doctype html><meta charset="utf-8"><title>Referrer policy lab</title>
<h1>What did the receiver see?</h1><pre id="result">Running...</pre><script>
const receiver=""" + json.dumps(receiver_origin) + """;
async function run() {
 const same=await (await fetch('/collect')).json();
 const cross=await (await fetch(receiver+'/collect')).json();
 window.labResult={page:location.href,same:same.referer,cross:cross.referer};
 document.getElementById('result').textContent=JSON.stringify(window.labResult,null,2);
}
run().catch(error=>{window.labError=String(error);});
</script>""").encode()
 self.send_response(200)
 self.send_header("Content-Type", "text/html; charset=utf-8")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Referrer-Policy", policy)
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)


receiver = HTTPServer(("127.0.0.1", 0), Receiver)
app = HTTPServer(("127.0.0.1", 0), App)
receiver_origin = f"http://127.0.0.1:{receiver.server_port}"
app_origin = f"http://127.0.0.1:{app.server_port}"
threads = [Thread(target=server.serve_forever, daemon=True) for server in (receiver, app)]
for thread in threads:
 thread.start()
try:
 for policy in sorted(policies):
 with urlopen(app_origin + "/page?policy=" + policy + "&demo=visible", timeout=5) as response:
 assert response.headers["Referrer-Policy"] == policy
 response.read()
 print(json.dumps({"app_url": app_origin + "/page", "wire_policies": sorted(policies)}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 for server in (receiver, app):
 server.shutdown()
 server.server_close()
 for thread in threads:
 thread.join(timeout=5)

Under the strict default policy, the same-origin result includes /page, the policy parameter, and demo=visible, while the cross-origin result contains only the page origin and trailing slash. Neither contains the fragment. Change the policy parameter to no-referrer: both results become null. With same-origin, only the same-origin result remains. With unsafe-url, both receivers obtain the source path and query. All four cases were verified in the browser.

The Python-only run checks policy headers, not browser referrer calculation. This fixture uses equal-security HTTP loopback origins; it does not exercise HTTPS downgrades, redirects, external stylesheets, or every browser privacy setting. Those cases need checks in their actual contexts. After selecting a production policy, confirm what the receiving endpoint sees rather than inferring it from the address bar, and keep sensitive values out of URLs when their persistence elsewhere would still be a problem.

Sources

MDN Referrer-Policy, policy values, the current default, and HTML integration, checked 2026-09-13.
W3C Referrer Policy, referrer calculation, origin boundaries, and URL filtering, checked 2026-09-13.

Cache-Control private versus shared

Fri, 23 Oct 2026 00:00:00 +0000

Storage scope is not an identity system. Cache-Control: private tells a conforming shared cache not to store a response; it does not teach a browser which application account owns the bytes. This distinction matters when a person logs out, another account logs in, and the same browser requests the same URL again.

The article’s fresh-response fixture separates storage eligibility from reuse without validation. A second boundary shows why a private cache can still match an old account response. Header matching does not establish current authorization.

Not all cacheable should be shared

An unqualified private directive permits storage by a single-user cache, subject to other caching requirements. Browsers are a common example, not the only implementation. public explicitly permits caching in circumstances that might otherwise prohibit it, including some responses to authorized requests. Public is not required on every already-cacheable response, and it never means that every possible cache must store the response.

The unqualified forms of no-cache and no-store answer different questions. No-cache allows storage but requires successful validation before reuse. No-store prohibits HTTP cache storage and subsequent reuse, for both shared and private caches. Neither is encryption, an access-control check, or a guarantee that application logs and previously saved copies have disappeared. This article uses unqualified directives, not the less widely implemented forms listing individual field names.

Freshness is separate again. A five-second shared lifetime still permits five seconds of incorrect disclosure if the wrong person’s response is stored under a shared key. Shortening max-age cannot repair an identity boundary. Conversely, s-maxage controls shared-cache freshness only; it is not a synonym for private.

When it breaks

Cookies do not automatically prohibit shared caching under HTTP’s general rules. Authorization has specific shared-cache restrictions, but directives such as public can explicitly permit storage. Adding public to improve a hit ratio can therefore undo a protection the application was relying on. Review the actual response body and authentication path before changing that directive.

Vary refines request matching; it does not grant permission to store. Adding Vary: Cookie cannot make a private response eligible for a shared cache. Within a private cache it can distinguish differing Cookie fields, but that is still field matching, not an authorization decision. A token that remains unchanged while permissions change illustrates why matching headers alone cannot establish current access rights.

For sensitive account data, select an explicit response policy and test account transitions. Include logout, switching accounts in one browser profile, and changes in permissions. Keep actual secrets out of diagnostic captures. An origin header inspection alone cannot prove that every proxy on the deployed path honored the policy.

Check it quickly

Use Node.js and npm; this experiment was run with Node 26.0.0 and http-cache-semantics 4.2.0. Install the pinned policy library in a temporary directory, then execute the JavaScript block with NODE_PATH="$cache_lab/node_modules" node. Installation needs the network; the fixture itself makes no requests and contains only invented cookie and authorization values.

cache_lab=$(mktemp -d)
npm install --prefix "$cache_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const request = {
 url: "https://example.test/account",
 method: "GET",
 headers: { cookie: "account=alpha" },
};
const cases = [
 ["private, max-age=300", [false, false], [true, true]],
 ["public, max-age=300", [true, true], [true, true]],
 ["no-cache, max-age=300", [true, false], [true, false]],
 ["no-store, max-age=300", [false, false], [false, false]],
];
for (const [directive, sharedResult, privateResult] of cases) {
 for (const shared of [true, false]) {
 const policy = new CachePolicy(request, {
 status: 200,
 headers: { "cache-control": directive },
 }, { shared });
 const result = [policy.storable(),
 policy.storable() && policy.satisfiesWithoutRevalidation(request)];
 assert.deepEqual(result, shared ? sharedResult : privateResult);
 console.log(shared ? "shared" : "private", directive, result);
 }
}

const authorized = { ...request, headers: { authorization: "Bearer example" } };
for (const [directive, expected] of [
 ["max-age=300", false], ["public, max-age=300", true],
]) {
 const policy = new CachePolicy(authorized, {
 headers: { "cache-control": directive },
 }, { shared: true });
 assert.equal(policy.storable(), expected);
 console.log("authorized shared:", directive, expected);
}

const otherAccount = { ...request, headers: { cookie: "account=beta" } };
for (const vary of [false, true]) {
 const headers = { "cache-control": "private, max-age=300" };
 if (vary) headers.vary = "Cookie";
 const policy = new CachePolicy(request, { headers }, { shared: false });
 assert.equal(policy.satisfiesWithoutRevalidation(otherAccount), !vary);
 console.log("different cookie, Vary enabled:", vary, "reuse:", !vary);
}

Each result pair means storage eligibility followed by reuse without validation. Private yields false/false in shared mode and true/true in private mode. Public yields true/true in both. No-cache yields true/false, while no-store yields false/false. The storage check deliberately comes first: callers must not insert forbidden entries into a cache and rely on a later lookup to repair that mistake.

The Authorization checks show the explicit public opt-in changing shared storage eligibility from false to true. They do not establish that any real personalized response is safe to share. Finally, changing the synthetic cookie still matches the private entry without Vary, but stops matching with Vary. That is the concrete counterexample to treating private as account isolation.

This is a policy-library experiment, not a browser, CDN, or logout implementation. Production evidence still needs two distinct accounts, observable origin requests, and body assertions through the real delivery path. Choose that acceptance test before tuning freshness or measuring the hit ratio.

Sources

RFC 9111: response cache directives, storage scope, authorization exceptions, and qualified directives, checked 2026-09-07.
MDN: Cache-Control, private, public, no-cache, and no-store, checked 2026-09-07.
http-cache-semantics 4.2.0, shared/private options, storage checks, and request matching, checked 2026-09-07.

Cookie scope should be narrower than the application boundary

Mon, 15 Jun 2026 00:00:00 +0000

Cookies are attached to requests according to browser rules, not according to the server component that originally set them. A broad Domain or Path can expose state to unrelated routes or subdomains, while missing transport and script restrictions enlarge the damage from other failures.

Review the dimensions together, but keep their roles separate: where cookies are sent, who can read them through JavaScript, and which stored identity a deletion targets.

When Domain is omitted, the cookie is scoped to the host that set it. Adding Domain=example.test allows it to be sent to eligible subdomains too. Use the broader form only when multiple hosts genuinely share the same application and trust boundary.

Inspect the response without printing real cookie values into logs. Header names are case-insensitive, so redaction must work for lowercase HTTP/2-style names too:

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($0) ~ /^set-cookie:/ {
 sub(/^[^:]*:[^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

Review the attributes together

Secure restricts cookie transmission to secure transport, normally HTTPS; it does not encrypt the stored value.
HttpOnly prevents JavaScript access through document.cookie; it does not stop the browser from sending the cookie.
SameSite influences cross-site requests and must match the application’s navigation or embedding needs.
Path controls when a cookie is sent, but it is not an authorization boundary between applications on the same host.

A cookie using SameSite=None also needs Secure in modern browsers. Avoid copying that pair into applications that do not require cross-site use.

Same-site is broader than same-origin: sibling HTTPS subdomains can be same-site while remaining different origins. SameSite therefore cannot replace the host boundary or the application’s CSRF defenses. Cookies are also not isolated by port, even with the __Host- prefix.

Use prefixes when their constraints fit

Cookie name prefixes such as __Secure- and __Host- let supporting browsers enforce additional requirements. A __Host- cookie must use Secure, omit Domain, and use Path=/, which makes the host-only intention explicit.

Test deletion with the same scope

Delete the same cookie name and domain/path scope using Max-Age=0 or a past Expires value; not every attribute is part of its storage identity. Meet the prefix and secure-origin requirements when sending the deletion. Preserve whether Domain was omitted: expire a host-only cookie without adding Domain, and specify its original Path. The current 6265bis draft includes the host-only flag in storage identity, so matching only the displayed domain string is insufficient as a portable deletion recipe. Verify deletion in the target browsers. A logout that clears only one scope can leave another active, and server-side sessions or tokens may also need invalidation.

A genuinely static documentation site normally has no reason to set application cookies. Check representative public responses for Set-Cookie and inspect browser storage after navigation, including any third-party scripts. A curl header check alone cannot detect JavaScript-set cookies or other browser storage; avoid adding storage the site does not need.

Sources

RFC 6265 — HTTP State Management Mechanism, cookie storage and scope, checked 2026-10-15.
MDN: Set-Cookie, attributes and cookie prefixes, checked 2026-10-15.
HTTPWG cookie specification draft, SameSite and cookie-prefix requirements, checked 2026-10-15.

Privacy · XB Field Notes

DoT and DoH protect the connection to the resolver you authenticate

When it breaks

Check it quickly

Keep the resolver and bootstrap configuration visible

Sources

Sequential identifiers reveal allocation patterns

When it breaks

Check it quickly

Choose identifiers and permissions separately

Sources

Referrer-Policy chooses how much source URL to send

Distinguish the policy choices

When it breaks

Check it quickly

Sources

Cache-Control private versus shared

Not all cacheable should be shared

When it breaks

Check it quickly

Sources

Cookie scope should be narrower than the application boundary

Prefer a host-only cookie

Review the attributes together

Use prefixes when their constraints fit

Test deletion with the same scope

Keep static sites cookie-free

Sources