Consent banners give digital consumers a right of refusal that websites do not reliably honor. A dual-persona audit of 100 highly trafficked domains across five consumer-facing sectors (news, e-commerce, health, finance, and government) found third-party cookies set before any interaction on 33.0% of domains; no programmatically reachable rejection path on 69%; and, where rejection was possible, third-party cookies continued to be stored on 51.6%, and identifier-pattern cookies were retained on 74.2%. Guided by these findings, we present CyberGuard, a Manifest V3 browser extension that enforces privacy at the client through a minimal network blocklist; fingerprint fuzzing across canvas, WebGL, and audio; behavioral masking; and a human-in-the-loop cookie vault. In a replication matched by browser mode on the same corpus, run on two separate days with all cookies accepted in both conditions, CyberGuard reduced third-party cookies by 56.5% on average (11.3 to 4.9 per domain; Wilcoxon W = 66.5, p = 1.7 × 10⁻¹¹). The initial campaign, in which the two conditions ran under different browser modes, had measured 70.8% (15.37 to 4.49; W = 20.0, p = 1.16 × 10⁻⁵); part of that figure reflects the mode difference rather than the extension. The reduction is structural: its pattern is consistent with a single blocked advertising entry point suppressing a downstream header-bidding stratum far beyond the two targeted networks, while platform embeds largely persisted. Client-side enforcement thus lowers tracking exposure even when consent is granted; the datasets, the consent selectors, and the crawler harness are released.

Published database comparisons usually cover engine pairs, conflate engine and schema effects, and compare queries that compute different results. StreamCart, a realistic e-commerce benchmark, decomposes performance across an optimized relational baseline (PostgreSQL) and five specialized engines (MongoDB, Cassandra, Neo4j, Elasticsearch, and TimescaleDB), each at a naive and an engine-optimized level. All eleven configurations were measured in three independent runs, and the analytics results of Elasticsearch, and those of Neo4j on rolling revenue, were verified row by row. A naive port outperformed the baseline in two of 35 query cells, and no single engine dominated. Engine and implementation level explained 10.0% and 6.0% of the variance of log latency as main effects and 10.6% through their interaction. Optimized Elasticsearch answered the two revenue analytics queries 35 and 45 times faster than PostgreSQL, but load-time precomputation that PostgreSQL can adopt as well accounts for factors of 12 and 6.8. Latency grew less with dataset size for optimized Elasticsearch and Cassandra than for PostgreSQL, though their incremental growth was not distinguished, and against PostgreSQL with the same precomputation, only Elasticsearch on rolling revenue kept that advantage. PostgreSQL led in concurrent writes while acknowledging every insert after an fsync. All code, data, and timings are public.

Published database comparisons typically cover engine pairs, conflate the engine effect with the schema effect, and compare queries that do not compute the same result. We present StreamCart, a benchmark built on a realistic e-commerce workload, and use it to decompose performance across six systems, PostgreSQL as an optimized relational baseline and five specialized engines (MongoDB, Cassandra, Neo4j, Elasticsearch, TimescaleDB), each implemented at a naive migration level and at an engine-optimized level, eleven configurations in all. Result equivalence for the claim-bearing analytics queries is verified row by row against the relational reference. Across seven read query classes, no naive implementation outperforms the baseline on any query, and no single engine dominates, with the classes splitting between PostgreSQL, optimized Elasticsearch, and optimized MongoDB. Schema design emerges as a factor on par with engine choice, improving performance by up to 3892 times on Cassandra and 137 times on Elasticsearch, where load-time denormalization lets the optimized form outperform PostgreSQL by 15.8 and 6.3 times on identical results, while a single omitted uniqueness constraint reduced Neo4j write throughput a hundredfold. Concurrent write throughput spans roughly two orders of magnitude (165 to 12,603 events per second). All code, data, and raw timings are public.