DEV Community: Ciphera

Why Swiss Infrastructure Matters for Privacy

Usman — Thu, 05 Nov 2026 00:43:05 +0000

In June 2025, Microsoft executive Anton Carniaux sat before the French Senate and testified under oath that Microsoft "cannot guarantee" that French citizen data won't be transmitted to American authorities. One of the world's largest cloud providers, in the most public setting possible, admitted it can't keep your data out of a foreign government's hands. That admission cuts to the core of why infrastructure location matters — and why Switzerland has become the jurisdiction of choice for privacy-focused companies.

In short

Switzerland sits outside the US CLOUD Act, Five Eyes surveillance alliances, and EU bulk data directives. Its revised FADP (2023) protects encryption rights with no backdoor legislation. European sovereign cloud spending is set to triple from $6.9B to $23.1B by 2027 (Gartner, 2026). Ciphera pairs Swiss data storage with client-side encryption (the technique behind zero-knowledge encryption) for defense in depth: passwords never reach its servers, and vault contents arrive only as ciphertext.

Updated 18 October 2026: we corrected what the encryption protects and what a legal order could still reach.

Can the US Government Access Your Data Stored Abroad?

Yes. The US CLOUD Act (2018) gives American authorities the legal power to compel US-headquartered companies to hand over customer data regardless of where that data is physically stored. If your files sit on a Google server in Frankfurt, a Microsoft server in Dublin, or an AWS instance in Singapore — the US government can demand access. FISA Section 702 surveillance targets rose to nearly 292,000 in 2024, up from 269,000 the year before (ODNI/Lawfare, 2025).

The numbers tell the story. Microsoft's own transparency report shows 6,288 legal demands for US consumer data in the first half of 2025 alone. Of those, 59 were warrants seeking content stored outside the United States. And 31% — nearly a third — came with secrecy orders, meaning the customer is never told their data was accessed. For enterprise customers specifically, Microsoft received 168 requests globally and was compelled to disclose data in 73 cases.This isn't theoretical. It's operational, scaled, and growing. And it applies to every company incorporated in the United States — regardless of where they put their servers. The CLOUD Act doesn't care about your data center's postal code.

What Makes Swiss Data Protection Different?

Switzerland's revised Federal Act on Data Protection (FADP) took effect on September 1, 2023. It raised maximum penalties from CHF 10,000 to CHF 250,000, introduced mandatory data breach reporting, expanded the definition of sensitive data to include genetic and biometric information, and established extraterritorial scope — meaning it applies to foreign companies processing Swiss residents' data. The EU reconfirmed Switzerland's adequacy decision in January 2024, allowing personal data to flow freely between the EU and Switzerland without Standard Contractual Clauses.

But the FADP is only part of the story. What makes Switzerland genuinely different is what it isn't part of. Switzerland is not a member of the European Union. It's not in Five Eyes, Nine Eyes, or Fourteen Eyes intelligence-sharing alliances. It's not subject to the EU's bulk data retention directives. And — this matters more than most people realize — there is no Swiss legislation limiting or undermining the right to encryption. No backdoor mandates. No key escrow requirements. Compare that to the UK's Investigatory Powers Act, Australia's Assistance and Access Act, or the EU's recurring proposals for "client-side scanning."

Category	Switzerland	EU (GDPR)	United States
Government data access	No CLOUD Act	GDPR limits	CLOUD Act + FISA
Intelligence-sharing alliance	None	14 Eyes members	Five Eyes founder
Encryption rights	Fully protected	Scanning proposals	No protection
EU adequacy status	Confirmed (2024)	N/A (origin)	Under ECJ appeal
Bulk data retention	No directive	State directives	NSA bulk collection
Maximum penalty	CHF 250,000	4% global revenue	No federal law

The practical result: data stored in Switzerland by a non-US company is outside the reach of the CLOUD Act, outside Five Eyes intelligence sharing, and governed by a law that explicitly protects encryption. That's a combination no other major hosting jurisdiction can match.

Why Is the EU-US Data Privacy Framework on Shaky Ground?

The European Court of Justice has struck down trans-Atlantic data transfer frameworks twice — Safe Harbor in 2015 and Privacy Shield in 2020. The current replacement, the EU-US Data Privacy Framework (DPF), survived its first legal challenge on September 3, 2025, when the EU General Court dismissed French MP Philippe Latombe's case. But Latombe appealed to the ECJ on October 31, 2025 — the same court that struck down both predecessors.

The structural problems haven't gone away. The Privacy and Civil Liberties Oversight Board (PCLOB), which is supposed to verify that US agencies comply with privacy commitments, had its membership gutted in early 2025. The Federal Trade Commission, another pillar of enforcement the DPF relies on, saw similar disruption. These are the institutions the European Commission pointed to when it declared the DPF adequate. If the ECJ concludes those safeguards have been hollowed out, the framework collapses — again.

The pattern is clear: Safe Harbor lasted 15 years before being struck down. Privacy Shield lasted 4. The DPF is barely 2 years old and already at the ECJ. Each framework falls faster than the last. Companies building on US infrastructure are effectively gambling that this one will hold. Swiss adequacy, by contrast, was originally granted in 2000 and has never been questioned.

For companies processing European personal data, this instability is expensive. Every time a framework falls, organizations scramble to implement Standard Contractual Clauses, update data processing agreements, and potentially restructure their entire cloud architecture. Swiss infrastructure avoids this cycle entirely.

The Swiss Data Center Boom

The market is responding. Switzerland now hosts 75 data centers with 6 more under construction, totaling 280+ MW of IT load capacity with approximately 900 MW in the pipeline. The Swiss data center market was valued at $1.02 billion in 2024 and is projected to reach $1.99 billion by 2030 — a compound annual growth rate of 11.72% (Research and Markets, 2026). Zurich is the dominant hub.

But Switzerland is part of a much bigger trend. Gartner forecasts worldwide sovereign cloud IaaS spending will hit $80 billion in 2026 — up 35.6% from 2025. European sovereign cloud spending specifically is set to explode: from $6.9 billion in 2025 to $12.6 billion in 2026 (an 83% jump), then nearly doubling again to $23.1 billion in 2027.Why the surge? Gartner predicts that by 2030, more than 75% of European and Middle Eastern enterprises will geopatriate their virtual workloads into solutions designed to reduce geopolitical risk — up from less than 5% in 2025. Over 60% of Western European CIOs say geopolitical factors are driving them toward local cloud providers. And a Kiteworks survey (2026) found that 33% of organizations reported a sovereignty-related incident in the past 12 months, with 44% citing sovereignty concerns as the top barrier to cloud adoption.

The direction is unmistakable. Data sovereignty isn't a niche concern anymore — it's mainstream enterprise strategy, and Switzerland is positioned at the center of it.

Why Ciphera Chose Swiss Infrastructure

Ciphera is a Belgian company. We're subject to GDPR and Belgian data protection law. We could host our servers anywhere in the EU and be legally compliant. So why did we choose Switzerland? Because compliance is the floor, not the ceiling. We wanted a jurisdiction where the legal protections match our technical architecture — and Switzerland is the only one that does.

Our approach is defense in depth — four independent layers, each of which provides protection even if the others fail:

Layer 1 — Technical encryption. Client-side encryption means data is encrypted on your device with AES-256-GCM before it ever leaves your browser. In Ciphera's sign-in, that covers the contents of your vault: the server receives ciphertext and never holds the decryption key. Your password never reaches the server at all. Pulse, our analytics platform, collects zero personal data — no cookies, no fingerprinting, no IP storage. A salted daily hash counts a returning reader once for each day they visit, and nothing links a reader across days or across sites.

Layer 2 — Jurisdictional protection. Data physically resides in Switzerland, governed by the FADP. No CLOUD Act reach. No Five Eyes intelligence sharing. No bulk data retention directives. The Swiss Federal Data Protection Commissioner (FDPIC) operates independently.

Layer 3 — Corporate structure. Ciphera is incorporated in Belgium, not the United States. The CLOUD Act's extraterritorial reach applies specifically to US-incorporated companies and their subsidiaries. A Belgian company hosting data in Switzerland simply isn't subject to it.

Layer 4 — Limited access by design. Even if every legal barrier failed and some future law compelled a Swiss hosting provider or Ciphera to hand over data, what they handed over would not contain your password or your vault's readable contents. It could include account ids, timestamps, the encrypted vault, the sign-in record, hashed IP addresses, notification metadata, backups, two-factor secrets and the email address (your browser seals a copy for our mail service, which decrypts it to send mail).

Why this matters in practice: Most privacy companies offer either strong encryption or a favorable jurisdiction. Combining client-side encryption with Swiss infrastructure means that jurisdiction is the second line of defense, with encryption as the first. If the encryption is ever broken (it won't be with AES-256), the jurisdiction protects you. If the jurisdiction is ever compromised (Switzerland's track record says it won't be), the encryption still protects your password and the contents of your vault. Neither has to be perfect for the combination to be.

How Much Does Getting Jurisdiction Wrong Cost?

The IBM Cost of a Data Breach Report 2025 puts the average US breach cost at $10.22 million — an all-time record and 2.3 times the $4.44 million global average. European regulators levied approximately EUR 1.2 billion in GDPR fines in 2025, bringing the cumulative total since May 2018 to EUR 7.1 billion ($8.4 billion). Data breach notifications across Europe averaged 443 per day — the first time the daily average exceeded 400, a 22% increase year-over-year.

The cost isn't just financial. A Kiteworks survey (2026) found that 44% of IT and security professionals cite sovereignty concerns as their top barrier to cloud adoption. The biggest data breaches of 2025-2026 show what happens when jurisdiction fails — 280 million people affected across just six incidents. Getting jurisdiction wrong doesn't just risk fines — it risks losing customers who won't trust you with their data in the first place.

The global trend is accelerating. 172 countries have now enacted data privacy laws (Greenleaf, 2025), up from an average growth rate of 3.3 new countries per year since Sweden's pioneering 1973 law. The era of "move fast, host anywhere" is over. Where your data lives is now a business-critical decision.

Jurisdiction isn't a checkbox. It's a strategic decision that compounds over time. The companies making that decision well today, choosing Swiss infrastructure and transparent corporate structures, won't be scrambling when the next framework collapses. They'll be exactly where they planned to be: in a jurisdiction that has never had to restart from scratch.

If you're ready to start with infrastructure that matches this standard, explore Pulse for privacy-first analytics. Your data deserves better than a jurisdiction that can't guarantee where it ends up.

Pulse vs GA vs Plausible vs Fathom (2026)

Usman — Wed, 04 Nov 2026 00:43:04 +0000

Cookie-based analytics is bleeding data. According to SealMetrics (2025), websites running cookie-dependent analytics tools lose 80-90% of their visitor data in EU markets. Visitors either ghost the consent banner entirely, actively reject cookies, or browse with ad blockers that strip tracking scripts on arrival. Meanwhile, EU regulators levied EUR 1.2 billion in GDPR fines in 2025 alone — and Google itself was hit with a EUR 325 million penalty from France's CNIL for Gmail ads and invalid cookie consent.

So what's the alternative? Privacy-first analytics tools promise accurate data without cookies, consent banners, or legal risk. But how do they actually compare? We put four tools — Pulse, Google Analytics, Plausible, and Fathom — through a side-by-side comparison on privacy compliance, script performance, data accuracy, and total cost of ownership.

In short

Cookie-based analytics loses 80-90% of EU visitor data and exposes you to GDPR fines that exceeded EUR 1.2 billion in 2025 (Bitdefender). Privacy-first tools like Pulse, Plausible, and Fathom capture every visit without cookies and are designed to need no consent banner, though the site operator makes that call. Pulse stands out with its open-source client and script, Swiss data residency, and a free tier — making it the strongest option for teams that want accurate analytics without surveillance trade-offs.

Updated 18 October 2026: Pulse's plans are Personal (free) and Business, so the pricing section links to the pricing page. We also re-measured the script sizes, removed the version-pinned script, and corrected what Pulse's tracker stores and what is open source.

Update, 19-07-2026 — This post has been corrected in three places: we previously (and wrongly) credited Fathom Analytics with SOC 2 and ISO 27001 certification — that's a different company, the AI meeting notetaker at fathomhq.com. We've replaced that with Fathom's actual strengths below. The Cologne court date and case citation were wrong and are now fixed. And every price in this post has been updated to current, July 2026 tiers.

How Much Data Are Cookie-Based Analytics Actually Losing?

A 2025 SealMetrics study found that cookie-based analytics loses 80-90% of total visitor data in European markets. The loss happens in three stages: 40-60% of visitors never interact with the consent banner at all (they "ghost" it), another 25-35% actively click reject, and only 10-20% actually accept cookies and get tracked. In Germany, the worst case, fewer than 10% of visitors are tracked.

That's not a minor gap in your data. It's a chasm. You're making product decisions based on the behavior of the 10-20% of visitors who happened to click "Accept." Are those visitors representative of your entire audience? Almost certainly not. Cookie acceptors tend to be less privacy-conscious, less technical, and less likely to use ad blockers — which means your analytics paints a systematically skewed picture. The picture looks different in the United States, where cookie acceptance rates exceed 80% (CookieYes, 2026). But if you serve any European traffic — and most websites do — the data loss is severe. Privacy-first analytics tools sidestep this problem entirely by not using cookies in the first place. Every visitor gets counted, regardless of whether they interact with a banner.

Privacy Compliance: Who Passes the GDPR Test?

EU regulators issued EUR 1.2 billion in GDPR fines in 2025, and DLA Piper's cumulative tally since 2018 reached EUR 7.1 billion through 10 January 2026. Google was directly targeted: France's CNIL fined Google EUR 325 million on 1 September 2025 for Gmail ads and invalid cookie consent, and the Cologne Regional Court (LG Köln) ruled on 23 March 2023 that transferring personal data to the US without Schrems II-adequate safeguards violates GDPR (case 33 O 376/22, against Deutsche Telekom) — a precedent with direct bearing on GA's US data flows. These aren't hypothetical risks. They're active enforcement actions against an analytics tool installed on tens of millions of websites (W3Techs). If you're weighing your own exposure, we cover the two questions that sit underneath these fines in depth: whether your analytics actually needs a cookie banner, and what GDPR compliance really requires.

So how do the four tools compare on privacy compliance? The differences are stark.

Feature	Pulse	Google Analytics	Plausible	Fathom
Cookie-free	Yes	No	Yes	Yes
Designed to need no consent banner	Yes	No	Yes	Yes
Open source	Client + script (AGPL-3.0)	No	Yes	No
Data residency	Switzerland (FADP)	No	Yes (Germany)	EU isolation (EU visitors only)
No data sampling	Yes	No	Yes	Yes
Self-hostable	No	No	Yes	No
Score	5/6	0/6	6/6	4/6

Pulse, Plausible, and Fathom are all built to minimise the personal data they collect, and the site operator still makes the GDPR determination for their own setup. Google Analytics requires explicit cookie consent under GDPR, extensive configuration to approach compliance, and still transfers data to US servers by default. Pulse differentiates itself with Swiss data residency under the FADP — Switzerland isn't in the EU, but the FADP provides equivalent protection and the data is stored in Infomaniak's data centres in Geneva rather than in a US cloud — plus a fully open-source client and tracking script. Plausible leads on self-hosting capability, running on German infrastructure by default. Fathom isolates EU visitor data to servers inside the EU but isn't open source.

With 172 countries now having data privacy laws (up from 120 in 2017), GDPR compliance isn't just a European concern. It's becoming the global baseline. Picking an analytics tool that's compliant by design saves you from playing legal whack-a-mole as new regulations appear.

How Does Script Size Affect Page Speed?

We measured all four with curl on 18 October 2026. Google Analytics' gtag.js is many times larger than the other three, and its exact size varies by property. Plausible's script is about 1.3 KB gzipped, Fathom's is about 2 KB, and Pulse's is about 3 KB.

Pulse is the largest of the three privacy-first scripts, and we'd rather say so than round in our own favour. At this scale the gap between them is noise: a visitor will not feel it. The gap that does matter is Google Analytics, whose script is many times heavier than any of the three.

Does that gap matter in practice? On mobile connections, every kilobyte adds to Time to Interactive, and a script that runs before the page paints can also fail, mis-fire, or get blocked by an ad blocker mid-load. A script of a few kilobytes removes most of that failure surface.

Here's a receipt you can partly check yourself instead of taking a vendor's word for it: Pulse builds one salted SHA-256 hash that resets every day at the site's midnight. A returning reader counts once for each day they visit, and nothing links a reader across days or across sites. The raw IP address is discarded immediately after hashing, and Pulse never stores it. There's no cookie. The tracker keeps nothing in session storage and reads one local-storage flag, pulse_ignore, which a site owner sets by opening a ?pulse-ignore link. None of it is a fingerprint cache. The client and script are open source, and the tracker served from js.ciphera.net is byte-identical to the one in the public repository, so what the script does in your browser is something you can read. The backend that does the hashing runs as a managed service and is not public.

Data Accuracy: Sampling vs Full Counts

Google Analytics applies data sampling when explorations exceed 10 million events (Google Support). Once sampling kicks in, GA4 extrapolates from a subset of your data rather than counting every event. Want unsampled reports? That requires GA 360, which starts at roughly $50,000 per year. For most businesses, that means living with sampled data and hoping the extrapolations are accurate enough.

Pulse, Plausible, and Fathom don't sample. Every pageview is counted, every referrer is recorded, and every metric you see in the dashboard reflects your actual traffic — not a statistical estimate. This isn't just a technical distinction. When your VP of marketing asks why last month's traffic looks different from the board deck, "Google was sampling our data" is not a confidence-inspiring answer.

The privacy-enhancing technologies market reflects this shift. Grand View Research values it at $3.1 billion in 2024, projecting growth to $12 billion by 2030 at a 25.3% CAGR. Businesses aren't just adopting privacy tools for compliance. They're adopting them because the alternatives — sampled data, consent banner friction, legal exposure — are worse in every measurable way.

Our take: The real cost of "free" Google Analytics isn't the price tag. It's the data you never see. Between cookie rejection, ad blockers, and sampling, GA4 shows you a distorted slice of your traffic. Privacy-first tools show you the whole picture — and they're cheaper than GA 360 by orders of magnitude.

What Does Each Dashboard Actually Show You?

Your analytics tool choice isn't invisible to your users. A consent banner asking to track them across the web shapes how visitors perceive your brand before they've read a word of your content — and a large share of them respond by ghosting the banner entirely, per the SealMetrics numbers above.

But what do you actually lose by switching from GA to a privacy-first alternative? Less than you'd think. Here's what each tool offers:

Google Analytics: Page views, sessions, user journeys, conversion funnels, audience demographics, event tracking, cross-site tracking, remarketing audiences, attribution modeling. Requires cookie consent and complex setup.
Plausible: Page views, unique visitors, bounce rate, visit duration, referrer sources, countries, devices, browsers, UTM tracking, custom events, goals. No cookies, 1.3 KB script.
Fathom: Page views, unique visitors, referrers, countries, devices, browsers, UTM tracking, custom events, uptime monitoring included. No cookies, EU visitor isolation.
Pulse: Page views, unique visitors, bounce rate, session duration, referrer sources, countries, devices, browsers, UTM tracking, aggregate user journeys with a Sankey flow view, funnels (up to 8 steps), automatic 404 detection, page rules for grouping or excluding paths, a Google Search Console integration on every plan including free, a 75-integration directory, and a BunnyCDN integration. No cookies, open-source client and script, data stored in Switzerland.

What you won't get from any privacy-first tool: session recordings, cross-site behavioral profiles, or remarketing audiences. Plausible and Fathom give you no person-level user journey either. Pulse has one, but it is off by default: an owner can switch on a Visitors view that lists pseudonymous profiles that each cover one IP address and browser on one day, and it never appears on share links, the public API or exports. Pulse's Sankey flow view and funnels get you most of the way there anyway: they show how visitors as a group move through your site and where they drop off, and the dashboard shows only these aggregates unless an owner switches the Visitors view on. That's not a gap in the privacy-first category — it's the trade-off that makes the rest of this comparison possible. The real question is whether you use person-level journey replay to make product decisions, or whether you mainly look at traffic trends, top pages, referrer sources, and drop-off points. Most teams operate on the latter, which is exactly what aggregate journeys give you.

How we use Pulse at Ciphera: We run Pulse on all our own properties — ciphera.net and our documentation. We stopped asking "what did this specific user do?" and started asking "what patterns do users collectively exhibit?" The latter question drives every product decision we've made. Don't take our word for it — the live Pulse demo is public, viewable by anyone.

Pricing and the True Cost of "Free" Analytics

Google Analytics is free. But is it actually free? If you serve EU users, you need a consent management platform (CMP) to comply with GDPR's cookie consent requirements. CMPs like Cookiebot, OneTrust, or CookieYes cost $100-500 per month depending on traffic. Add legal review time for your privacy policy, DPA negotiations, and the ongoing risk of regulatory fines, and "free" starts looking expensive.

Pulse's free tier covers 1 site, 10,000 events a month, and 6-month data retention — enough for a small site or a side project, but most production traffic outgrows it fast. The paid Business plan covers up to 5 sites, with event-based tiers and two-year retention. Current prices are on the pricing page. The Pulse site also has side-by-side comparisons with Plausible, Fathom and Google Analytics.

Tool	Monthly Cost at 100K Pageviews	Notes
Pulse	Business plan (see the pricing page)	Free tier caps at 10,000 events/mo; designed to need no CMP or consent banner; DPA available on request
Google Analytics	$0*	*Plus $100-500/mo for consent management (CMP)
Plausible	$19/mo	Starts at $9/mo for 10K pageviews
Fathom	from ~$15/mo	No free tier, as of July 2026

At higher volumes, the gap holds. GA4's free tier samples data above 10 million events; unsampled data requires GA 360, which starts at roughly $50,000/year. Plausible scales to $69/month at 1 million pageviews, and Fathom runs around $45/month at 500K pageviews (as of July 2026) — both with full, unsampled data at every tier. The three privacy-first tools are designed to need no CMP on top of the sticker price, which means, unlike GA, the sticker price is close to the real price. A Data Processing Agreement for Pulse is available on request.

Which Tool Should You Choose?

There isn't one right answer for every team. Here's a decision framework based on what matters most to you:

You need the cheapest compliant option for a small site: Pulse. The free tier (1 site, 10,000 events a month) covers the core metrics, with no cookies and a tracker designed to need no consent banner, and the Business plan (up to 5 sites) scales by event tier, with current prices on the pricing page. Because the tracker is open source, you can check what it does in your visitors' browsers.
You want self-hosting control: Plausible. It's the only tool here that lets you run the full stack on your own infrastructure, which is a strong advantage for organizations with strict data residency requirements.
You want a simple, no-frills dashboard with uptime monitoring built in: Fathom. It isolates EU visitor data to EU servers and bundles uptime monitoring into the same subscription — a clean option if you don't need self-hosting or an open-source codebase.
You need advertising integrations and remarketing: Google Analytics. If your business model depends on Google Ads, retargeting audiences, and attribution modeling, GA is still the tool for you — just budget for consent management and legal review.
You're an EU-focused business that values data sovereignty: Pulse. Swiss data residency under the FADP, combined with a zero-cookie architecture, gives you a strong legal position on this list. Companies that treat privacy as an afterthought end up paying for it — in fines, in trust, and in churn.

The Bottom Line

Google Analytics remains powerful, but it carries growing legal risk, loses the majority of EU visitor data to consent rejection, samples data above modest thresholds, and ships a script many times heavier than Pulse's, Plausible's or Fathom's. Pulse, Plausible, and Fathom each offer a genuine alternative with different strengths:

Pulse: Free tier (10,000 events/mo), open-source client and script (AGPL-3.0), Swiss data residency (FADP), script about 3 KB gzipped
Plausible: Self-hostable, 1.3 KB script, German data residency, 19,000+ paying subscribers
Fathom: EU visitor isolation, included uptime monitoring, simple dashboard

The privacy-first analytics market is growing at 25.3% CAGR for a reason. Businesses are realizing that accurate, compliant analytics doesn't require tracking individual users across the web — and the receipts here, from script weight to data residency to open-source code, hold up to scrutiny in a way "trust us" tracking scripts don't.

Open Source Privacy Tools: Complete List 2026

Usman — Tue, 03 Nov 2026 00:43:05 +0000

"Open source" is a verifiable claim — which means a list like this one is only worth publishing if someone actually verifies it. So in July 2026 we re-checked every tool on this page: license (OSI-approved or out), maintenance (a release or significant activity within 12 months), and governance (acquisitions, license changes, funding crises, project-status announcements). Several entries changed as a result, and we've said so rather than quietly rewording.

That's also the honest pitch for open source itself: proprietary apps can promise zero tracking while quietly phoning home; public code can be checked. What follows is 34 tools across 11 categories that passed verification — plus, at the end, the open-source stack we run ourselves, because a list like this from a company that doesn't practice it would be decoration.

In short

34 open source privacy tools across messaging, email, file sharing, analytics, VPN, browsers, passwords, cloud storage and photos, DNS blocking, operating systems, and search — every one license-checked and maintenance-verified in July 2026, with a country tag per tool. Start with Signal, Bitwarden, and Brave for immediate impact. All three are free.

Updated 18 October 2026: we corrected the Pulse entry (the dashboard and tracker are open source, the backend runs as a managed service) and its script size, removed Nomad from the stack we run, and now describe Tessera as SDKs and a sidecar around opaque-ke.

Update, 19-07-2026 — full re-verification of every entry. Notable changes: Session survived a serious funding crisis (note added), Briar entered maintenance mode, Bitwarden's enterprise modules moved to a source-available license (core stays open), Mullvad completed its OpenVPN retirement. Added: SimpleX Chat, Immich, Ente, Pi-hole, AdGuard Home, and a new DNS-blocking category.

How We Verified This List

Four criteria, applied to every entry in July 2026:

Genuinely open source: an OSI-approved license (GPL, MIT, Apache, AGPL, MPL) for the product as you'd actually run it. Source-available licenses (BUSL, SSPL) don't qualify — see the FAQ for why that distinction has teeth.
Active within 12 months: at least one release or significant development activity. Projects in formal maintenance mode are marked as such, not silently kept.
Usable without expertise: a non-technical person should be able to install and use it (underlying protocols like WireGuard excepted).
Governance noted: acquisitions, license moves, funding trouble, and controversies get a clause, not a cover-up. Trust survives bad news; it doesn't survive discovering the list glossed over it.

Three tools on this list are ours (Pulse, and two entries in the "what we run" section). They're labeled. No tool paid for placement.

What Are the Best Open Source Encrypted Messaging Apps?

Signal — Best for Everyday Private Messaging

Signal remains the gold standard: end-to-end encryption by default for messages, calls, and video, with the Signal Protocol so battle-tested that WhatsApp and Google Messages adopted it. Signal itself stores virtually no metadata — subpoena responses have shown account-creation date and last-connection date, nothing more. It's the team default at Ciphera.

License: AGPL-3.0 · Country: US · Cost: Free · Platforms: All

SimpleX Chat — Best for No-Identifier Messaging

SimpleX goes a step further than everyone else in this category: no phone number, no email, and — uniquely — no user identifiers of any kind, not even random ones. Message queues are unidirectional and disposable, so there's no stable "you" for servers to correlate. Actively developed and audited; the most interesting new entrant since our last revision.

License: AGPL-3.0 · Country: UK · Cost: Free · Platforms: iOS, Android, desktop

Element (Matrix) — Best for Decentralized Team Communication

Element runs on the Matrix protocol — a federated network where you control your own server. The French and German governments run internal messengers on Matrix (Tchap, BwMessenger). If any single operator disappears, the network keeps running.

License: AGPL-3.0 / GPL-3.0 (commercial licensing available) · Country: UK · Cost: Free self-hosted; hosted plans available · Platforms: All

Session — Best for Anonymous Messaging

Session requires no phone number or email, and routes messages through an onion network that hides metadata even from relay servers. One honest note from our verification: the foundation behind it nearly shut down in mid-2026 after a funding crisis, surviving on roughly $1M in community donations. The project is alive and shipping, but running leaner than before — worth knowing if you're betting a workflow on it.

License: GPL-3.0 · Country: International (foundation) · Cost: Free · Platforms: All

Briar — Best for Extreme Conditions

Briar syncs peer-to-peer over Bluetooth or Wi-Fi — no internet required, no servers at all — which makes it unique for internet shutdowns and extreme-risk situations. Verification note: Briar formally entered maintenance mode in July 2026 (security fixes only, no new features). For its niche, that's acceptable; for a daily driver, pick Signal or SimpleX.

License: GPL-3.0 · Country: UK · Cost: Free · Platforms: Android

What Are the Best Open Source Private Email Providers?

Proton Mail — Best for Encrypted Email

Proton Mail offers end-to-end encryption between Proton users and zero-access encryption for stored mail, under Swiss jurisdiction, with fully open-source clients. Over 50,000 business customers as of 2026. It's the benchmark for private email, and what several of us use personally.

License: GPL-3.0 (clients) · Country: Switzerland · Cost: Free tier; paid from $3.99/mo · Platforms: All

Tuta — Best for Post-Quantum Email

Tuta has run hybrid post-quantum encryption (TutaCrypt) in production since 2024 — earlier than nearly anyone — and encrypts subject lines, which Proton doesn't. German-hosted and expanding (a government-grant-funded encrypted drive is in beta).

License: GPL-3.0 · Country: Germany · Cost: Free tier; paid from EUR 3/mo · Platforms: All

Thunderbird — Best Desktop Email Client

Thunderbird keeps a local, open-source client viable in a webmail world: any provider, built-in PGP, active 2026 roadmap (Exchange support, database overhaul) under Mozilla subsidiary MZLA.

License: MPL-2.0 · Country: US · Cost: Free · Platforms: Windows, macOS, Linux

What Are the Best Open Source Encrypted File Sharing Tools?

Send — Best for Self-Hosted File Transfers

Send is the community fork of Mozilla's discontinued Firefox Send: end-to-end encrypted transfers with expiring links, self-hostable. Caveat from verification: the flagship public instance is a single-maintainer community project — self-host it if you need it to exist next year.

License: MPL-2.0 · Country: Netherlands (maintainer) · Cost: Free self-hosted · Platforms: Web

OnionShare — Best for Anonymous File Sharing

OnionShare serves files directly from your machine over Tor — no server ever holds the file, and the share vanishes when you close the app. Still actively released.

License: GPL-3.0 · Country: International · Cost: Free · Platforms: Windows, macOS, Linux

What Are the Best Open Source Privacy-First Analytics Tools?

For the detailed comparison of this category, see Pulse vs Google Analytics vs Plausible vs Fathom.

Pulse — Best for Zero-Cookie Analytics

Pulse — ours, so judge accordingly — collects website analytics with no cookies and no fingerprinting, and never stores IP addresses. The dashboard and tracking script are open source, while the backend runs as a managed service. The script is about 3 KB gzipped, data lives in Switzerland, and in many countries a site using Pulse needs no consent banner.

License: AGPL-3.0 (dashboard and tracker) · Country: Belgium (company) / Switzerland (data) · Cost: Free tier · Platforms: Web

Plausible — Best Lightweight Analytics

Plausible pioneered the category: a sub-2 KB script, simple dashboard, EU hosting, no cookies. The Community Edition is self-hostable.

License: AGPL-3.0 · Country: Estonia · Cost: From $9/mo cloud; free self-hosted · Platforms: Web

Umami — Best for Self-Hosted Simplicity

Umami is MIT-licensed, deploys via Docker in minutes, and has become the default "just give me pageviews on my own server" choice.

License: MIT · Country: US · Cost: Free self-hosted · Platforms: Web

Matomo — Best Full Google Analytics Replacement

Matomo is the mature heavyweight: funnels, heatmaps, tag management — the full GA feature set with complete data ownership.

License: GPL-3.0 · Country: New Zealand · Cost: Free self-hosted; cloud from EUR 23/mo · Platforms: Web

What Are the Best Open Source VPN and Network Privacy Tools?

Mullvad — Best No-Nonsense VPN

Mullvad completed its OpenVPN retirement in January 2026 and now runs WireGuard-only. EUR 5/month flat, no email required, cash accepted by post, apps open source and independently audited, and a documented history of having nothing to hand over.

License: GPL-3.0 (apps) · Country: Sweden · Cost: EUR 5/mo · Platforms: All

ProtonVPN — Best Free-Tier VPN

ProtonVPN's free tier has no data caps and no ads — genuinely usable rather than a crippled demo — and Secure Core multi-hops traffic through hardened data centers.

License: GPL-3.0 (apps) · Country: Switzerland · Cost: Free tier; paid from $4.99/mo · Platforms: All

WireGuard — Best VPN Protocol

WireGuard is the protocol underneath the good VPNs: ~4,000 lines of code versus 100,000+ for OpenVPN, in the Linux kernel since 5.6. If you run your own server, this is the primitive to build on.

License: GPL-2.0 · Country: — · Cost: Free · Platforms: All major OS

What Are the Best Open Source Privacy Browsers?

Firefox — Best Independent Browser

Firefox remains the only major browser whose engine isn't Chromium — an independence that matters for the whole web, not just your tabs. Worth one clause of honesty: Mozilla's early-2025 Terms-of-Use wording sparked a real backlash before being walked back; the product's tracking protection is unchanged and strong.

License: MPL-2.0 · Country: US · Cost: Free · Platforms: All

Tor Browser — Best for Anonymity

Tor Browser routes traffic through three relays with fingerprinting defenses layered on Firefox ESR. Slower, by design, in exchange for genuine anonymity. Note: US government funding cuts in 2025 hit the project's budget — the software is unaffected, but it has never needed community support more.

License: BSD-3-Clause (Tor) / MPL-2.0 (browser base) · Country: US (non-profit) · Cost: Free · Platforms: Windows, macOS, Linux, Android

Brave — Best Privacy-by-Default Browser

Brave blocks ads and trackers out of the box on a Chromium base (full extension compatibility), with 100M+ monthly users as of late 2025. Its crypto features are ignorable if they're not your thing.

License: MPL-2.0 · Country: US · Cost: Free · Platforms: All

LibreWolf — Best for Firefox Purists

LibreWolf is Firefox with every telemetry and sponsorship surface removed, tracking Firefox ESR within days of each release.

License: MPL-2.0 · Country: — · Cost: Free · Platforms: Windows, macOS, Linux

What Are the Best Open Source Password Managers?

Bitwarden — Best Overall Password Manager

Bitwarden is cross-platform, regularly audited, self-hostable, and the free tier genuinely covers individual use. Verification nuance: the core clients and server remain GPL/AGPL, but newer enterprise modules ship under a source-available "Bitwarden License," and January 2026 brought a steep premium price hike — on top of private-equity investment taken back in 2022. The open-source core is unaffected today — we're noting the trajectory, not sounding an alarm.

License: AGPL-3.0 (server), GPL-3.0 (clients), source-available enterprise modules · Country: US · Cost: Free; premium $10/yr · Platforms: All

KeePassXC — Best Offline Password Manager

KeePassXC keeps your vault in an encrypted local file you control — no cloud, no account, no company. Pair with Syncthing or Nextcloud for multi-device sync on your own terms.

License: GPL-2.0 / GPL-3.0 · Country: — · Cost: Free · Platforms: Windows, macOS, Linux

What Are the Best Open Source Cloud Storage and Photo Tools?

Nextcloud — Best Self-Hosted Cloud Platform

Nextcloud is the full Google-Workspace replacement — files, calendar, video calls, document editing — self-hosted, with strong momentum from European governments' sovereignty push in 2025–2026.

License: AGPL-3.0 · Country: Germany · Cost: Free self-hosted; enterprise plans · Platforms: All

Cryptomator — Best Encryption Layer for Any Cloud

Cryptomator adds client-side encryption on top of whatever cloud you already use — the vault syncs like a normal folder, but the provider sees only ciphertext.

License: GPL-3.0 · Country: Germany · Cost: Free desktop; paid mobile · Platforms: All

Immich — Best Self-Hosted Photo Library

Immich is the credible self-hosted Google Photos replacement — mobile backup, timeline, search, face grouping — developed full-time under the FUTO umbrella and improving at a startling pace. The standout addition to this list in 2026.

License: AGPL-3.0 · Country: US (FUTO) · Cost: Free self-hosted · Platforms: Server + iOS/Android

Ente — Best Encrypted Photo Cloud

Ente offers end-to-end encrypted photo storage if you'd rather not run a server — and its companion app, Ente Auth, is an excellent open-source 2FA authenticator, filling a category this list previously lacked.

License: AGPL-3.0 · Country: India · Cost: Free tier; paid plans · Platforms: All

What Are the Best Open Source DNS-Level Blockers?

New category this revision — network-level blocking protects every device behind it, including the ones (TVs, IoT) that can't run a browser extension.

Pi-hole — Best for the Home Network

Pi-hole sinkholes ad and tracker domains for your entire network from something as small as a Raspberry Pi. The classic homelab first project, still actively maintained.

License: EUPL-1.2 · Country: — · Cost: Free · Platforms: Linux (incl. Raspberry Pi)

AdGuard Home — Best Polished Self-Hosted DNS Filter

AdGuard Home covers the same ground as Pi-hole with a more polished UI and built-in encrypted DNS (DoH/DoT) upstream support. The Home product is fully open source (the company also sells proprietary apps — don't conflate them).

License: GPL-3.0 · Country: Cyprus · Cost: Free · Platforms: Linux, macOS, Windows, ARM

What Are the Best Open Source Private Operating Systems?

GrapheneOS — Best Secure Mobile OS

GrapheneOS hardens Android for Pixel devices — memory-safety mitigations, sandboxed Google Play compatibility, no Google services by default. It gained its first major OEM partnership in 2026, a strong signal for longevity.

License: MIT / Apache-2.0 · Country: Canada · Cost: Free · Platforms: Google Pixel

Tails — Best Amnesic Live OS

Tails boots from USB, routes everything through Tor, and forgets everything at shutdown. Actively released (7.x series through 2026), and still what journalists reach for.

License: GPL-3.0+ · Country: — · Cost: Free · Platforms: Any PC via USB

QubesOS — Best Compartmentalized Desktop

QubesOS isolates every application in its own virtual machine — a compromise in one compartment stays in that compartment. Demanding, and worth it for high-risk work. 4.3 shipped in December 2025, with 4.3.1 following in June 2026.

License: GPL-2.0 · Country: Poland (origin) · Cost: Free · Platforms: x86 desktops

What Are the Best Open Source Private Search Engines?

SearXNG — Best Self-Hosted Search

SearXNG aggregates results from dozens of engines without any of them knowing who searched. Run your own instance or use a public one.

License: AGPL-3.0 · Country: — · Cost: Free · Platforms: Web (self-hosted or public instances)

Brave Search — Best Independent Index

Brave Search built its own index — no Google or Bing dependency, a feat only a handful of companies have managed — and it's now genuinely independent at 40B+ pages. The index is proprietary; it earns its slot here for independence and no user tracking, clearly labeled.

License: Proprietary index, open-source browser · Country: US · Cost: Free; premium $3/mo · Platforms: Web

The Open-Source Stack We Run Ourselves

A list like this is cheap if the publisher's own stack is a black box. Ours is partly open: the Pulse dashboard and tracker, Tessera and Sigil are public, while the Pulse backend runs as a managed service. What Ciphera ships and runs:

Software	Role	License
Tessera (ours)	SDKs and a sidecar around opaque-ke, Meta's OPAQUE library: the system behind our login	Apache-2.0
Sigil (ours)	SSRF-hardened favicon resolution service	Apache-2.0
Pulse (ours)	Cookieless analytics (listed above); the dashboard and tracker are open source, the backend is a managed service	AGPL-3.0
Stalwart	Self-hosted mail server (Community Edition)	AGPL-3.0
Woodpecker CI	All our build and deploy pipelines	Apache-2.0
Traefik	Reverse proxy as our cluster ingress	MIT
Prometheus + Alertmanager	Metrics and alerting	Apache-2.0
Grafana + Loki	Dashboards and logs	AGPL-3.0
PostgreSQL	The database behind most of our services	PostgreSQL License

And the honesty beat, because the source-available distinction cuts against us too: we also run HashiCorp Vault, which is BUSL-licensed (source-available, not open source), and Teleport, whose repository is AGPL but whose binaries carry usage restrictions since v16. We know the difference, we count them accordingly, and they're on the long-term replacement list. If a vendor's "open source" page doesn't make these distinctions, that tells you something about the rest of the page.

Which Three Should You Start With?

You don't need 34 tools. Start with Signal for messaging, Bitwarden for passwords, and Brave or Firefox for browsing — the three categories where the most personal data actually leaks, all free, all installable this afternoon.

From there: Proton Mail for email, Pi-hole for the whole household, Nextcloud when you're ready to own your cloud. Every claim on this list can be checked against public sources, and where part of a product is closed (for example Brave Search's index or Pulse's backend) the entry says so. That is the entire point: privacy you don't have to take on faith.

Data Privacy Compliance: What It Is and How to Achieve It

Usman — Mon, 02 Nov 2026 10:43:03 +0000

TL;DR

Data privacy compliance means following the laws that govern how you collect, use, store, share, and delete personal data. Key laws include the GDPR, the CCPA, and the Swiss FADP. You prove compliance with policies, consent records, security controls, and a process for user requests.

GDPR fines reach €20 million or 4% of global annual turnover, whichever is higher.
Eight steps get you compliant: identify laws, map data, write policies, manage consent, handle requests, secure data, control vendors, and audit.
Tools that collect less personal data reduce your compliance workload.

What Is Data Privacy Compliance?

Data privacy compliance means meeting the legal and contractual rules that protect personal data. That data includes names, email addresses, IP addresses, location data, and other personal information (PII). A company that handles this data must show it follows every applicable rule.

Compliance is not a single task. It covers policies, consent, security, vendor contracts, staff training, and records. The rules differ by country and state. UNCTAD reports that 137 of 194 countries (71%) have data protection legislation.

Data Privacy vs Data Protection vs Data Security

These three terms overlap. They mean different things.

Term	What it covers	Example
Data privacy	Your right to control how others use your personal data	Consent to marketing emails
Data protection	The laws and safeguards that apply to personal data	GDPR, FADP, CCPA
Data security	The technical controls that block unauthorized access	Encryption, access controls

Data protection and privacy work together. Security is one part of both.

What Data Privacy Compliance Looks Like in Practice

Compliance shows up in these daily actions:

A privacy policy that lists what you collect and why
A cookie consent banner, or a cookieless tool that needs none
A process to answer data subject access requests (DSARs)
A data processing agreement (DPA) with every vendor
A record of processing activities (RoPA)
An incident response plan for a data breach

Data Compliance vs Data Governance and Regulatory Compliance

Data governance establishes internal rules for data quality, ownership, and lifecycle management, while regulatory compliance ensures these practices meet applicable external laws.

Together, they form a data compliance framework that helps organizations manage information responsibly and meet their legal obligations. Governance supports compliance. Compliance proves it to regulators.

Why Data Privacy Compliance Matters for Your Business

Non-compliance costs money, customer trust, and access to markets. Three sets of facts show the scale.

Legal Compliance and Fines

The GDPR sets two fine tiers under Article 83. The lower tier reaches €10 million or 2% of worldwide annual turnover. The upper tier reaches €20 million or 4%. The higher amount applies (McCann FitzGerald).

Enforcement is real. In May 2023, the Irish Data Protection Commission fined Meta €1.2 billion for transferring EU user data to the US. The European Data Protection Board (EDPB) directed the fine. Meta had signed standard contractual clauses. The regulator found they did not protect the data enough (Irish DPC).

Breaches add cost. IBM's 2025 Cost of a Data Breach Report puts the global average at $4.44 million. The US average reached $10.22 million. Teams took an average of 241 days to identify and contain a breach (IBM, 2025). IBM links the US figure partly to steeper regulatory fines (CyberScoop).

Your Customers Care

Cisco's 2022 Consumer Privacy Survey measured how privacy affects buying (Cisco):

81% agreed that how a company treats personal data shows how it views its customers.
76% said they would not buy from a company they do not trust with their data.
37% had switched providers over data privacy practices.

Benefits of Data Privacy Compliance

Lower breach risk: You hold less data, so less data can leak.
Clear answers in due diligence: Customers and partners ask about privacy. You have documents ready.
Cleaner data: Data minimization removes records you never use.
Market access: You can serve users in the EU, Switzerland, and California with confidence.
A base for AI governance: IBM found 63% of organizations lacked policies to manage AI or prevent shadow AI. A privacy program gives you the controls to start.

Which Data Privacy Laws and Regulations Apply to You?

Your obligations depend on where your users live, not where your company sits. Many data privacy laws have extraterritorial scope. One website can fall under several laws at once.

Law	Region	Enforced by
GDPR	EU and EEA	National data protection authorities (DPAs), coordinated by the EDPB
Swiss FADP	Switzerland	FDPIC (orders), cantonal prosecutors (fines)
CCPA and CPRA	California	CPPA and California Attorney General

GDPR Compliance: What the Regulation Requires

The GDPR (EU 2016/679) has applied since 25 May 2018. It replaced the 1*995 EU Data Protection Directive*. Compliance with the General Data Protection Regulation rests on these requirements:

Lawful basis for processing: Pick one for every use of personal data.
Data minimization and privacy by design: Collect only what you need and build protection in from the start.
Data subject rights: Honor access, erasure, rectification, and portability requests within one month (Article 12).
Breach notification: Tell your supervisory authority within 72 hours of becoming aware of a breach (Article 33).
Cross-border data transfers: Use an adequacy decision or standard contractual clauses to move data outside the EU.
Roles: Know whether you act as a data controller or a data processor. Appoint a Data Protection Officer (DPO) when the law requires one.

See our guide to the EU-US data transfer framework for the current status of US transfers.

Swiss Data Protection Law vs EU GDPR

Switzerland's revised FADP took effect on 1 September 2023. It follows the GDPR closely but differs in four ways:

Who pays: FADP fines of up to CHF 250,000 fall on the responsible individual for intentional breaches. GDPR fines fall on the organization (Lenz & Staehelin).
Who enforces: The FDPIC can order changes but cannot fine. Cantonal prosecutors bring the fines.
DPO: The FADP does not require one. The GDPR does in set cases.
EU adequacy: The European Commission confirmed in its report of 15 January 2024 that Switzerland offers adequate protection. Personal data can flow from the EU to Switzerland without extra safeguards (FDPIC).

Read more on why Swiss infrastructure matters for data privacy.

AI Compliance: Where the EU AI Act Meets Privacy Law

When an AI system processes personal data, the GDPR and the FADP still apply. The EU AI Act adds risk-based duties on top. IBM's 2025 report found that 63% of organizations lacked governance policies for AI. Start with the same basics: map the data, set access controls, and record the lawful basis. Our EU AI Act compliance guide covers the extra duties.

Data Privacy and Compliance in the USA

The US has no comprehensive federal privacy law. Congress has considered bills such as the American Data Privacy and Protection Act and the American Privacy Rights Act. Neither became law. States fill the gap. At least 20 states have comprehensive consumer privacy laws in effect in 2026, and more take effect in 2027. Check the IAPP state privacy legislation tracker for the live count.

Sector laws also apply:

HIPAA covers health information.
FERPA covers student education records.
COPPA covers online data from children under 13.

CCPA Compliance Requirements

The CCPA, as amended by the CPRA, gives California residents these rights:

Know what personal information a business collects
Delete and correct their data
Opt out of the sale or sharing of their data
Limit use of sensitive personal information

You must answer most requests within 45 days. You can extend once by another 45 days if you notify the consumer (IAPP). Since 1 January 2025, fines reach $2,663 per violation and $7,988 per intentional violation or violation involving a minor. Consumers can also sue after a data breach for $107 to $799 per incident (CPPA). The CPPA treats a missed Global Privacy Control signal as a violation.

The GDPR and CCPA differ in approach. The GDPR requires a lawful basis, and consent must be opt-in when you rely on it. The CCPA centers on opt-out rights for sale and sharing.

Other Major Data Privacy Regulations

LGPD in Brazil
PIPEDA in Canada
PIPL in China
DPDP Act in India, where the term for a controller is "data fiduciary"
POPIA in South Africa
PDPA in Thailand
Privacy Act 1988 in Australia
Privacy Act 2020 in New Zealand
Personal Data Protection Laws in the UAE and Saudi Arabia

How to Achieve Data Privacy Compliance in 8 Steps

Follow these steps in order. Use them as your data privacy compliance checklist and your compliance readiness roadmap.

1. Identify Which Laws Apply to You

List where your users, employees, and vendors sit. A visitor in Berlin triggers the GDPR. A visitor in Geneva triggers the FADP. A California resident may trigger the CCPA if you pass its revenue and data-volume thresholds. Run a gap assessment against each law and note what you lack.

2. Map Your Data

Build a data inventory. Use data discovery and classification to find where personal data sits. Record what you collect, why, where you store it, who can access it, and how long you keep it. This record becomes your RoPA under GDPR Article 30. Set data retention and disposal rules for each data type across its lifecycle.

3. Write or Update Your Data Privacy Policy and Data Protection Policy

Your data privacy policy is public. It tells users what you collect, why, who receives it, and how to use their rights. Your data protection policy is internal. It sets staff rules for handling data. Review both at least every 12 months. Use a privacy policy generator only as a starting draft. Then match every line to your real practices.

4. Set Up Consent Management

Use consent where the law requires it. Give users an equal choice to accept or decline in your cookie consent banner. Honor Global Privacy Control and other universal opt-out signals. Run a cookie audit with a website scanner to find every tracker. Add a preference center and regional consent settings.Read our guide on whether you need a cookie banner for analytics.

5. Build a Process for Data Subject Rights Requests

Create one intake form or email address for every DSAR. Verify identity. Cover access, deletion, correction, portability, and opt-out. Meet the deadlines: one month under the GDPR, and 45 days under the CCPA with one 45-day extension. Log each request and its outcome. Assign one owner.

6. Put Data Security Compliance Standards in Place

Security standards give regulators evidence. Use ISO/IEC 27001 for your information security system and ISO/IEC 27701 for privacy management. The NIST Privacy Framework also helps. These controls form the core of database security:

Multi-factor authentication (MFA), single sign-on (SSO), and role-based access control (RBAC)
The principle of least privilege for every account
Encryption at rest and in transit
Data masking and redaction in test environments
Anonymization and pseudonymization. Anonymized data falls outside the GDPR. Pseudonymized data stays in scope.
Patch management and vulnerability scanning
Intrusion detection and prevention (IDS and IPS), firewalls, and VPN
Security monitoring and alerting, plus backup and disaster recovery
Defenses against SQL injection, phishing, and social engineering

If you host on a cloud provider such as Amazon Web Services, the shared responsibility model applies. The provider secures the infrastructure. You secure your data and your access settings.

7. Manage Vendors and Sign a Data Processing Agreement

GDPR Article 28 requires a DPA between a controller and each processor. Review every vendor, including sub-processors and cross-border transfers. Keep a vendor list with the data each one receives. Rank third-party risk. Review your vendors every year.

8. Assess Risks, Audit Regularly, and Train Your Team

Run a Data Protection Impact Assessment (DPIA) or Privacy Impact Assessment (PIA) before high-risk processing. Schedule internal and third-party compliance audits. Use continuous monitoring and an incident response plan. Train staff on phishing and data handling.

IBM's 2025 report puts malicious insider attacks at the highest average cost among initial attack vectors, at $4.92 million. Name clear roles: DPO, CISO, compliance officer, and risk manager. Bring in consultants or auditors where you lack skills. Data privacy compliance software can track tasks and evidence.

Common Data Privacy Compliance Mistakes to Avoid

On 30 September 2025, the California Privacy Protection Agency announced a $1.35 million fine against Tractor Supply Company. It was the agency's largest fine at that date. The CPPA found four failures (CPPA):

No privacy policy that told consumers their rights
No notice of privacy rights for job applicants
No effective opt-out of sale and sharing, including through Global Privacy Control
Disclosure of personal information to other companies without contracts that protect it

Those failures map to the mistakes below:

Copying a policy template: Your policy must match your real practices and name every right.
Collecting data you never use: Extra data raises breach cost and legal exposure.
Skipping vendor contracts: Every processor needs a DPA.
Ignoring opt-out signals: Honor Global Privacy Control and give users an equal choice in your banner.
Treating compliance as a one-time task: Laws change, so audit and monitor on a schedule.

How Pulse Analytics Supports Data Privacy Compliance on Your Website

Web analytics is where many sites first meet the GDPR. Google Analytics sets cookies and sends data to US servers. Pulse Analytics, built by Ciphera BV in Belgium, takes a different route.

What Pulse Analytics does for your compliance program:

It sets no cookies and builds no visitor fingerprint.
It stores nothing about individual visitors, so the analytics needs no consent banner.
It hosts data in Switzerland. The European Commission confirmed in January 2024 that Switzerland offers adequate protection under the GDPR.
It does not count visitors whose browser sends Do Not Track or Global Privacy Control.
It exports data as CSV, Excel, or JSON, and deletes data on request.
Its dashboard and tracking script are open source under AGPL-3.0, so you can inspect the code.

Take Control of Your Data Privacy Compliance

Building a strong privacy program starts with understanding how your website collects and processes data.

Pulse Analytics helps you understand website performance while minimizing unnecessary visitor tracking. Get actionable insights with a cookieless analytics approach and Swiss data hosting.

Start making privacy-conscious analytics part of your compliance strategy.

EU AI Act Compliance Guide for 2026

Usman — Mon, 02 Nov 2026 00:43:05 +0000

The EU AI Act's biggest deadline has moved. On June 29, 2026, the Council joined Parliament in adopting the Digital Omnibus on AI, pushing the mandatory high-risk compliance date from August 2, 2026 to December 2, 2027 for standalone systems — and to August 2, 2028 for AI embedded in regulated products like medical devices and machinery. The change was signed July 8, 2026, published in the Official Journal on July 24, 2026 as Regulation (EU) 2026/1744, and has applied since July 27, 2026.

That didn't mean August 2026 went quiet. Article 50's transparency rules (AI-content labeling and watermarking, chatbot disclosure, deepfake marking) took effect as scheduled on August 2, 2026, and so did the Commission's power to investigate and sanction general-purpose AI providers. The penalty regime hasn't moved either: fines up to EUR 35 million or 7% of global turnover have been live and enforceable since August 2025, and EUR 7.1 billion in cumulative GDPR fines since 2018 shows EU regulators use that authority. This guide covers what changed, what took effect on the original date anyway, and what to do with the extra runway.

In short

The EU AI Act's high-risk compliance deadline has been postponed: December 2, 2027 for standalone high-risk systems (Annex III — hiring, credit scoring, education, law enforcement), August 2, 2028 for AI embedded in regulated products (Annex I). The Digital Omnibus on AI making this change was signed July 8, 2026, published in the Official Journal on July 24, 2026 as Regulation (EU) 2026/1744, and has applied since July 27, 2026. Article 50 transparency obligations (AI-content labeling, chatbot disclosure) and the Commission's enforcement powers over general-purpose AI providers were not postponed and took effect on August 2, 2026. Fines remain up to EUR 35 million or 7% of global turnover (Article 99). Start with an AI system inventory and risk classification today — the extra runway is for building compliance properly, not for standing down.

Updated 18 October 2026: the Digital Omnibus on AI was published as Regulation (EU) 2026/1744 on 24 July 2026 and has applied since 27 July. The guide now follows it, including the new wording of the AI literacy duty.

Update, 19-07-2026 — This post originally set the high-risk compliance deadline at August 2, 2026. The Digital Omnibus on AI — adopted by Parliament on 16 June 2026, by the Council on 29 June 2026, signed 8 July 2026, and as of this update still awaiting formal publication in the Official Journal — postpones that deadline to December 2, 2027 for standalone high-risk systems and August 2, 2028 for AI embedded in regulated products (see the Commission's implementation timeline). Article 50's transparency rules and the Commission's GPAI enforcement powers are unaffected and still take effect August 2, 2026. The sections below have been corrected to reflect this.

What Is the EU AI Act and Why Should You Care?

One in five EU enterprises now uses AI technologies — up from 7.7% in 2021 (Eurostat, 2025). The EU AI Act sets the rules for all of them. It's the world's first comprehensive AI law, applying to any AI system placed on the EU market or whose output is used within the EU — regardless of where the provider is based.

Think of it as GDPR for artificial intelligence, but stricter. GDPR's maximum fine is EUR 20 million or 4% of global turnover. The AI Act raises that ceiling to EUR 35 million or 7% for the most serious violations — prohibited practices like social scoring or subliminal manipulation. Two additional tiers cover lesser infractions.

Regulation / Tier	Maximum Fine	% of Global Turnover
AI Act — Prohibited practices	EUR 35 million	7%
GDPR — Maximum	EUR 20 million	4%
AI Act — Other violations	EUR 15 million	3%
AI Act — Information supply	EUR 7.5 million	1%

Why does this matter for businesses that aren't building AI? Because the Act covers deployers too — companies that use AI systems, not just those developing them. If you run an AI-powered hiring tool, a chatbot that makes automated decisions, or a credit scoring system, you're a deployer. And deployers carry their own compliance obligations.

That ceiling makes it the strictest technology regulation globally (Article 99). For SMEs and startups, the lower of the two calculation methods applies, offering some proportional relief.

Here's the catch nobody talks about: the AI Act doesn't just regulate AI products. It regulates how you use AI. An off-the-shelf hiring tool from a US vendor? You're still on the hook as the deployer. Your liability doesn't transfer just because someone else built it.

Gartner predicts AI regulatory violations will cause a 30% increase in legal disputes for tech companies by 2028. Of 360 IT leaders surveyed, only 23% said they're "very confident" in their organization's AI governance capabilities. The gap between AI adoption and AI governance is widening — and the AI Act is designed to close it.

How Does the EU AI Act Classify Risk?

The European Commission estimates that only 5-15% of AI systems will fall into the high-risk category (CEPS, 2024). That's good news for most businesses. The AI Act uses a four-tier pyramid — from unacceptable to minimal — and each tier carries different obligations. Where does your AI fall?

Unacceptable risk sits at the top. These AI practices are banned outright: social scoring by governments, subliminal manipulation that causes harm, real-time biometric identification in public spaces (with narrow law enforcement exceptions), and emotion recognition in workplaces and schools. If your system falls here, there's no compliance path. It's prohibited.

High-risk AI occupies the critical middle tier. These systems must meet strict requirements: risk management, data governance, transparency, human oversight, and accuracy standards. The Act identifies eight high-risk domains in Annex III: biometrics, critical infrastructure, education, employment, essential service access, law enforcement, migration and border control, and administration of justice.

What counts as high-risk in practice? An AI tool that screens job applications. A system that decides creditworthiness. Software that prioritizes emergency dispatch calls. If your AI makes or influences decisions about people's access to opportunities, services, or rights, it's likely high-risk.

Limited-risk systems — chatbots and deepfake generators — face transparency obligations. Users must be told they're interacting with AI. Minimal-risk systems like spam filters or recommendation engines? No obligations at all.

Most businesses use AI for customer service, content generation, or data analysis. These sit comfortably in the minimal or limited tiers. But if you use AI in hiring, insurance underwriting, or credit decisions, you're in high-risk territory. With 20% of EU enterprises now using AI (Eurostat, 2025) — and 55% of large enterprises — many organizations touch at least one high-risk domain without realizing it.

What's the Enforcement Timeline?

Since February 2, 2025, prohibited AI practices have been banned across the EU — and there's a requirement most businesses have missed entirely: Article 4's AI literacy obligation has been enforceable since the same date (European Commission, 2025). Every organization deploying AI must take measures to support its staff's AI literacy. Right now.

The AI Act doesn't arrive all at once. It rolls out in four phases, each adding new obligations.

Our analysis: Article 4's AI literacy obligation is the most overlooked requirement in the entire AI Act. It's already enforceable, applies to every organization that deploys AI regardless of risk level, and has no grace period. If your employees use ChatGPT, Copilot, or any AI tool at work, you're already required to take measures to support their AI literacy.

August 2, 2025 activates the second phase: GPAI (General-Purpose AI) rules take effect, the penalty regime becomes active, and governance bodies are established. Providers of foundation models like GPT and Claude face new transparency and documentation requirements.

August 2, 2026 did not bring full high-risk enforcement. That was the headline change. The Digital Omnibus on AI, adopted by Parliament on 16 June 2026 and the Council on 29 June 2026, signed 8 July 2026 and published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, pushes risk management systems, technical documentation, human oversight, and post-market monitoring for standalone high-risk systems (Annex III) out to December 2, 2027, and for AI embedded in regulated products (Annex I) to August 2, 2028. What didn't move: Article 50's transparency obligations took effect on August 2, 2026 as originally scheduled, covering AI-content labeling and watermarking, chatbot disclosure, and deepfake marking (legacy generative systems get until December 2, 2026 specifically for machine-readable watermarking). The Commission's enforcement powers over general-purpose AI providers (requests for information, model access, recall authority) also activated on August 2, 2026, a full year after GPAI providers' own transparency obligations began. The Omnibus also added a new prohibition on AI systems that generate child sexual abuse material or non-consensual intimate imagery, which applies from December 2, 2026.

August 2, 2027 keeps a role in the calendar, just a different one: it's now the date regulatory sandboxes must exist in every EU member state, postponed a year by the Omnibus from their original August 2026 date. Any remaining AI Act obligations outside the high-risk buckets continue to fall due on their originally phased schedule. The phased rollout was deliberate, and the Omnibus layers a second phase-in on top of it for high-risk systems specifically — that's runway for building compliance properly, not a reason to stop planning.

The Compliance Gap: Are Businesses Ready?

A 2025 Littler survey of 400+ European executives found that only 18% feel "very prepared" for the EU AI Act, while 20% admit they're "not at all prepared." The remaining 62% fall somewhere in between — aware of the regulation but unsure how to comply. That's a lot of uncertainty for a law that's already partially enforceable.

The gap widens for smaller businesses. Only 17% of small EU enterprises use AI, compared to 55% of large companies (Eurostat, 2025). But here's the problem: smaller companies are far less likely to have compliance infrastructure in place, making the AI Act proportionally harder to implement. Fewer than 30% of European SMEs have begun any compliance steps at all (OECD, 2025).

How much does compliance actually cost? The Centre for European Policy Studies estimates that bringing a single high-risk AI product into compliance can reach EUR 400,000 for SMEs starting from scratch. That breaks down to roughly EUR 193,000-330,000 for quality management system setup plus EUR 71,400 in annual maintenance — approximately 17% overhead on AI spending.

Larger enterprises face different challenges. Of 360 IT leaders surveyed by Gartner in 2025, only 23% described themselves as "very confident" in their organization's AI governance capabilities. The readiness problem isn't just about awareness. It's about capacity.

Our take: The compliance cost figures look alarming, but they assume building from zero. Businesses with existing GDPR infrastructure — risk assessments, data protection impact assessments, documentation practices — can repurpose much of it. The AI Act's risk management requirements echo GDPR's structure. Think of it as an extension, not a rebuild.

There's one bright spot for smaller companies. The AI Act includes proportional penalty calculations for SMEs and startups: when calculating fines, the lower of the fixed amount or turnover percentage applies — not the higher. A small company with EUR 5 million in revenue faces a maximum prohibited-practice fine of EUR 350,000 (7% of turnover), not EUR 35 million. For more on how we approach privacy-first software, read about Ciphera.

How Should Your Business Prepare Now?

The postponement changes the calendar, not the destination. Global spending on AI governance is projected to reach USD 492 million in 2026 and surpass USD 1 billion by 2030 (Gartner, 2026) — money spent by businesses that read "postponed" as "delayed," not "canceled." Here's a practical five-step framework, recalibrated for what's actually due when.

1. Inventory your AI systems. List every AI tool your organization uses — purchased, built in-house, or accessed via API. Include seemingly minor tools: chatbots, content generators, email assistants, scheduling optimizers. You can't classify what you haven't mapped.

2. Classify each system's risk level. Map every AI tool to the Act's four-tier framework. Most will land in minimal or limited risk. Flag anything touching hiring, credit, education, healthcare, or public safety as potentially high-risk. When in doubt, classify conservatively — the classification still matters even though the compliance clock on it has moved.

3. Build documentation and risk management. High-risk systems need technical documentation, conformity assessments, and risk management systems — you now have until December 2027 (Annex III) or August 2028 (Annex I) to have them fully in place. Start with data governance: where does your training data come from? Is it representative? Article 10's data-governance requirement doesn't ask you to have less data — it asks you to justify and document what you have. That's a smaller job when the underlying collection was never built to identify individuals. Pulse, for instance, sets no cookies and links a reader's visits only within one day and never across sites; if that kind of data feeds any part of your AI pipeline, there's less personal data in it to document, audit, or defend.

4. Train your staff on AI literacy. This isn't optional — it's been required since February 2, 2025. Every employee who uses or oversees AI needs to understand what the system does, its limitations, and when human intervention is necessary. Formal training programs, not just a policy document.

5. Establish ongoing governance. Set up monitoring and post-market surveillance for high-risk systems. Assign clear ownership: who's responsible for each AI system's compliance? Organizations using governance platforms are 3.4x more likely to achieve high governance effectiveness (Gartner, 2026).

One priority doesn't get the extra runway. If your product touches AI-generated content in any form (chatbots, image generation, synthetic media), Article 50's labeling and disclosure obligations have applied since August 2, 2026. If you have not built that disclosure surface yet, build it now; it's a smaller job than the high-risk documentation package, and it isn't the part of the Act that got postponed.

Privacy-native tools reduce your compliance burden from the start. When your infrastructure doesn't collect personal data in the first place, there's less to govern. Zero-knowledge encryption means the service storing your data structurally cannot read it. Swiss data residency under the FADP adds jurisdictional protection that aligns with EU standards. For more on building privacy-first infrastructure, see our guide to Swiss data privacy and our list of open source privacy tools for 2026.

What Happens After the EU AI Act?

A 2025 Eurobarometer survey found that 84% of Europeans stress the need for careful AI management to protect privacy and ensure transparency. Public demand for AI regulation isn't slowing down — it's accelerating.

The EU AI Act isn't an endpoint. It's a starting gun. Gartner predicts that by 2030, AI regulation will quadruple globally, extending to 75% of the world's economies. Countries without AI laws today will have them within five years. The EU, as it did with GDPR, is setting the template others will follow.

Legal risk is mounting alongside regulatory expansion. Gartner predicts a 30% increase in AI-related legal disputes for tech companies by 2028. Companies that delay governance investment now face compounding risk as new regulations stack on top of existing ones.

What does this mean practically? Compliance isn't a one-time project. It's an ongoing capability. The businesses that build AI governance frameworks now won't just avoid fines — they'll move faster when new regulations emerge, because the documentation, processes, and oversight structures are already in place.

The EU AI Act and GDPR form an interconnected regulatory web, and it's still growing — just not via the ePrivacy Regulation many expected. That proposal was formally withdrawn in the Commission's 2025 Work Programme. The reform effort covering GDPR, ePrivacy, NIS2 and the Data Act sits in a separate Digital Omnibus track, distinct from the Digital Omnibus on AI covered above. In July 2026 it was still under negotiation and not expected before late 2026. Compliance in one area increasingly depends on compliance in the others regardless of which track lands when. Businesses that treat these as separate projects will spend more time and money than those building unified governance.

From our experience: Building Pulse, our cookieless analytics, taught us that privacy-by-design isn't just a compliance strategy. It's an engineering advantage. Systems that never collect personal data don't need governance frameworks for that data. The simplest way to comply with AI data regulations is to minimize what you collect in the first place.

Pulse sets no cookies. Whether a tracker still needs ePrivacy consent depends on what it stores or reads on the visitor's device, which our post on whether you need a cookie banner for analytics explains. The AI Act's data-governance principle and privacy-by-architecture point the same direction: the least regulated data is the data you never collected. See what Pulse collects and what it never touches for exactly what that looks like in practice.

The Bottom Line

The EU AI Act remains the most significant technology regulation since GDPR, but the calendar has changed. Here's what matters now:

AI literacy training is already required — since February 2, 2025, every organization using AI must take measures to support staff AI literacy
5-15% of AI systems fall into the high-risk category — but many businesses don't know which of their systems qualify
High-risk compliance has moved to December 2, 2027 (standalone systems) and August 2, 2028 (embedded systems) — via the Digital Omnibus on AI, signed 8 July 2026 and published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744
Article 50 transparency rules and GPAI enforcement powers took effect on August 2, 2026 — AI-content labeling, chatbot disclosure, and the Commission's authority to investigate GPAI providers were unaffected by the postponement
Maximum fines reach EUR 35 million or 7% of global turnover — nearly double the GDPR ceiling, unchanged and live since August 2025
Only 18% of European employers feel "very prepared" — and as of spring 2026, only around 8-9 of 27 member states had even designated their national enforcement authorities

Start today: inventory your AI systems, classify their risk levels, and begin documentation — using the restored runway to do it properly instead of under deadline pressure. The businesses that build governance now won't just avoid penalties — they'll gain a competitive advantage as AI regulation expands globally.

For more privacy and compliance insights, explore our trust page and our complete list of open source privacy tools.

Zero-Knowledge Encryption Guide (2026)

Usman — Sun, 01 Nov 2026 00:43:04 +0000

Every cloud service promises it can't read your data. Very few can show you why that's true instead of asking you to take their word for it. The difference between the two is the difference between a policy (which can change, be subpoenaed, or be quietly violated) and an architecture, which limits what there is to hand over in the first place.

This guide explains zero-knowledge encryption in plain English, using the sign-in system we run in production. The OPAQUE libraries behind it are open source, so the protocol claims in this post link to real code or a real protocol spec. No math degree required — but receipts throughout.

In short

Zero-knowledge encryption means the service storing your data structurally cannot read it — encryption and key material live on your device, and the server only ever holds ciphertext. We walk through our own production login flow (OPAQUE, RFC 9807) as the worked example: what your browser computes, what our sign-in server stores, and what a stolen database gives an attacker. It holds neither your password nor your vault's plaintext. On its own it gives nothing to test password guesses against; an attacker who also holds the server's OPRF key can test guesses offline, at Argon2id cost per guess.

Updated 18 October 2026: we corrected what a stolen database or a court order could reach, when password guesses can be tested offline, how sign-in handles your email address, and which parts of the code are public.

Update, 19-07-2026 — this guide was rewritten. The previous version misdescribed our own authentication as layered password hashing. The real system is OPAQUE, a password-authenticated key exchange: the password, and anything that could test a guess without the server's own OPRF key, never reach our servers. The corrected walkthrough is below.

Update, 13-09-2026 — account recovery is live, and has been since 3 September 2026. Earlier versions of this post said it was switched off; it was, from 11 August to 3 September, while the browser half of the ceremony was finished. Recovery runs on the **24-word phrase* shown at the end of signup, which enrols a second identity we cannot read. Signup has enrolled it automatically since 7 September 2026; accounts created before that set it up from Security settings, which needs the password. Every claim below has been corrected to say that.*

What "Zero-Knowledge" Actually Means (and What It Doesn't)

Think of a safety deposit box. A traditional cloud service is a bank vault: you hand over your valuables, the bank locks them up, and the bank keeps a copy of the key. They promise security — but they can open your box any time, and so can anyone who compels or compromises them. Zero-knowledge encryption is different: you bring your own padlock, you keep the only key, and the bank stores a sealed box it cannot open.

Formally: all encryption and decryption happens on your device, your keys never leave your device, and the server receives, stores, and serves only ciphertext. The provider's knowledge of your data is zero — not by promise, by construction.

Two distinctions worth making before we go further:

Zero-knowledge encryption is not zero-knowledge proofs. ZKPs are a mathematical protocol for proving you know something without revealing it (NIST); ZKE describes a service architecture. The naming overlap is mostly coincidence — though as you'll see below, modern login protocols like OPAQUE genuinely borrow from the proof-without-revealing idea.

Zero-knowledge encryption is stronger than end-to-end encryption. All ZKE is E2EE, but some E2EE systems still derive or escrow keys server-side, leaving the provider a theoretical path to plaintext. ZKE closes that path entirely.

Why Server-Side Encryption Keeps Failing

Most breached companies had encryption. The Dropbox Sign breach of April 2024 is the instructive example — and it's usually told wrong. The attacker didn't crack any cipher or steal decryption keys. They compromised an automated service account and walked in through the front door with legitimate backend access, reaching customer emails, hashed passwords, API keys, OAuth tokens, and MFA data. The encryption at rest was real. It just didn't matter, because encryption the server can undo is undone the moment someone becomes the server.

That's the general pattern: server-side encryption protects against stolen disks. It does not protect against the vendor itself, compromised employee or service accounts, government compulsion, or bugs in the key-management layer. Credential theft was the top attack vector in cloud breaches again in 2025 (Thales, 2026) — and stolen credentials grant exactly the access that server-held keys were supposed to gate.

Zero-knowledge architecture changes what a breach is. If the server never holds plaintext or keys, then full server compromise yields ciphertext and metadata, and no plaintext. You can't leak what you never had.

A Worked Example: Logging In Without Ever Sending a Password

Here's where most explanations go abstract. We'll do the opposite and walk through our production system. Ciphera ID uses OPAQUE, an asymmetric password-authenticated key exchange specified in RFC 9807 (an IRTF Informational RFC), via Tessera, our open-source wrapper around opaque-ke, Meta's OPAQUE library. The property that makes OPAQUE remarkable: the server verifies your password without ever seeing your password or any hash of it. Without the server's own OPRF key, what it stores cannot be used to test password guesses.

When you sign up:

Your browser computes two independent things. From your email, it derives a blind index (PBKDF2-SHA256 at 1,000,000 iterations), which becomes the sign-in server's only way to look up your account. The sign-in server never sees your email address. Your browser also seals a copy for our mail service, which decrypts it to send mail.
From your password, the browser runs the OPAQUE registration exchange: an oblivious pseudorandom function (OPRF) over Ristretto255, with Argon2id as the key-stretching function. The ciphersuite is RFC 9807's recommended configuration; the Argon2id cost parameters (64 MiB memory, 3 passes) are our own pinned deployment choice in Tessera's client. What travels to the server is a blinded registration message: it contains neither the password nor a hash of it. Without the server's own OPRF key, nothing the server receives in registration lets an attacker test password guesses offline.
The exchange yields two outputs. The server gets a credential record to store — an opaque envelope it cannot invert. Your browser gets a 64-byte export_key that the server never sees and cannot compute without your password.
Your browser then generates a random 32-byte vault master key (VMK), encrypts your profile data (name, email, settings) under it, and wraps the VMK itself under a key derived from export_key. The wrapped key is a 61-byte envelope; the VMK inside it never exists on our servers in unwrapped form.

When you log in:

Your browser recomputes the blind index from your email and starts an OPAQUE login exchange.
The server looks up your credential record and responds. It learns nothing about the password you typed — for accounts that don't exist, it even responds with a timing-safe decoy record, so an attacker can't probe which emails are registered.
If — and only if — you typed the right password, your browser independently re-derives the same export_key from the exchange. Wrong password, wrong key, and the login simply fails. Without the server's OPRF key, nothing transmitted at any step lets an attacker test password guesses offline.
Your browser uses the export_key to unwrap your VMK — imported as a non-extractable WebCrypto key, meaning even our own frontend code can't export its bytes, only use it — and decrypts your vault locally.

Notice what never happened: your password never left your device, and your vault key never reached the sign-in server in unwrapped form.

What a Full Database Breach Would Yield

The honest way to evaluate any zero-knowledge claim is to enumerate what the server actually stores and ask what each item is worth to an attacker. For a Ciphera account, the fields that hold your credentials and vault are, per user:

Stored field	What it is	What an attacker gets
`opaque_record`	The OPAQUE credential envelope	Nothing to test password guesses against on its own. With the server's OPRF key as well, guesses can be tested offline, each paying the full Argon2id cost (64 MiB, 3 passes)
`opaque_credential_id`	16 random bytes	Nothing — it's random
`email_blind_index`	The PBKDF2 email digest, HMAC-peppered again server-side	No email address; peppering means even a rainbow table of common emails doesn't apply outside our infrastructure
`encrypted_vault`	Your profile data, AES-256-GCM under the VMK	Ciphertext
`opaque_wrapped_key`	The VMK, wrapped under a key derived from your `export_key`	A locked box whose key only your password or recovery phrase can re-derive

There is no password column and no password-hash column in the classical crackable sense. The last legacy authentication columns (from the SRP protocol we previously ran) were dropped on 18 June 2026 when the OPAQUE migration completed. The sign-in server never sees your email address. These five fields cover credentials and the vault. A breach or a court order could reach those and more: account ids, timestamps, the sign-in record, hashed IP addresses, notification metadata, backups, two-factor secrets and the email address (your browser seals a copy for our mail service, which decrypts it to send mail). None of it contains your password or your vault's readable contents. For the full accounting of what Ciphera can and cannot see, read our trust page.

The Limits: What ZKE Cannot Protect Against

No encryption system protects against everything, and vendors who skip this section are selling, not explaining.

Endpoint compromise. If malware runs on your device, it sees what you see — before encryption happens. ZKE protects data in transit and at rest, not a compromised screen and keyboard.

Weak passwords. OPAQUE's Argon2id stretching makes each guess expensive. A stolen database on its own gives an attacker nothing to test guesses against, so guesses can only be made online against our rate-limited servers. An attacker who also holds the server's OPRF key can test guesses offline, at Argon2id cost per guess. Needing that second secret is still a major upgrade over crackable stolen hashes. But "correct horse battery staple" still beats "hunter2".

Metadata. Zero-knowledge applies to content. A server still observes that an account exists, when it authenticates, and how large its ciphertext is. We minimize this (blind indexes exist precisely to take email addresses out of that picture), but minimized is not zero.

User error. Losing your password means losing your data unless you enrolled the second key — there is no backdoor for us to helpfully use. The 24-word phrase is that second key: with it enrolled, the sentence is "losing both"; with no phrase enrolled, a lost password cannot be recovered by anyone, including us. That trade-off is the entire point, and you should walk into it with open eyes.

Our take: these limitations are why we publish them. A vendor who claims zero knowledge and effortless password recovery and helpful support access to your files is describing a system that cannot exist. Honest architecture has sharp edges.

Verify, Don't Trust: The OPAQUE Code Is Public

The OPAQUE libraries described above are inspectable. The sign-in service that uses them, including its PBKDF2 email index, is not public. Tessera (the OPAQUE core, the sidecar service, and the SDKs) is open source under Apache-2.0:

ciphera-tessera — the Rust core and sidecar, built on the widely used opaque-ke implementation, #![forbid(unsafe_code)], with the cipher suite pinned to RFC 9807's recommended configuration (Ristretto255-SHA512, 3DH, Argon2id).
@ciphera-net/tessera — the browser SDK: OPAQUE flows, blind index, vault, BIP-39 recovery, WebAuthn-PRF.
tessera-go — the server-side SDK our backend uses to relay OPAQUE messages to the sidecar.

One disclosure we make prominently, because a receipts-driven post cuts both ways: Tessera has not yet had an independent third-party audit. We've published our threat model, security docs, and a detailed self-audit in the repositories, and an external audit is planned — but until it happens, "audited" is a claim you won't find us making. What you can do today is read the code, which is more than most zero-knowledge claims allow.

How to Spot Fake Zero-Knowledge

Four questions expose most pretenders in five minutes:

Can they reset your password without you? If yes, a key exists outside your control. (We can't — a password change requires your device re-running OPAQUE registration.)
Does account recovery work without a recovery secret you generated? If yes, that's a backdoor with a friendlier name. (Ours requires the 24-word phrase your device minted at signup — a second identity enrolled with your own password, so nothing on our side can drive it. Accounts from before 7 September 2026 enrol it from Security settings.)
Can support access your data "for troubleshooting"? Then it isn't zero-knowledge, whatever the marketing page says.
Are the clients closed-source? Client-side encryption you can't inspect is client-side encryption you're taking on faith. (Ours: the OPAQUE libraries, browser SDK included, are open source; the sign-in service around them is not public.)

Ask these of any vendor — including us. The difference with a zero-knowledge architecture is that the answers are properties of the system, not promises of the company. Policies change with ownership, jurisdiction, and pressure. Architecture limits what there is to hand over, whoever is asking.

If you want the broader philosophy behind building this way, read about Ciphera, and if you want the full inventory of what Ciphera does and does not see, we wrote that down too.

Why We Chose BunnyCDN as Ciphera's CDN

Usman — Sat, 31 Oct 2026 00:43:04 +0000

A CDN terminates your TLS, sits in the request path of every visitor, and sees every asset request your pages make. Most engineering teams choose one on price and latency. For a privacy company, those are the second questions — the first is jurisdictional: who operates the box that decrypts every request, and which courts can compel them?

We went through that decision for ciphera.net and our product frontends, picked Bunny, and have now run it in production long enough to have opinions with evidence. This is the checklist we used, what the setup actually looks like, and four things running it taught us — including one embarrassing number worth reading about so you don't repeat it.

In short

We chose Bunny because it's EU-jurisdiction (Slovenia), lets us anonymize IP addresses in its logs or turn logging off, under a GDPR DPA, prices transparently ($0.01/GB in Europe), and performs well (119 PoPs, ~24 ms average global latency). Our setup: Bunny pull zones in front of Bunny's own storage, serving path-keyed immutable assets, with a copy of every file kept in Swiss object storage. Our websites moved onto Bunny Magic Containers between 15 August and 12 September 2026. The lessons: CDN caches collapse things you don't expect, measure your real cache-hit rate, push security rules to the edge, and draw a hard line around what never leaves the origin.

Updated 18 October 2026: our websites moved onto Bunny Magic Containers between 15 August and 12 September 2026, and the setup section now says what that changes.

Update, 19-07-2026 — rewritten around our current production setup, with all network and pricing figures re-verified against bunny.net on this date.

Why a CDN Is a Privacy Decision

The CDN's entire job is to stand between your users and your servers. That means it observes every request — URL, IP, headers — for every visitor, on every page. You can architect so it holds nothing sensitive (more on that below), but you cannot architect away the fact that it sees traffic. Whoever operates it is inside your trust boundary whether you like it or not.

The asymmetry is easy to miss because static assets feel harmless. An icon request is just an icon request — until you notice that every one arrives with an IP address, a user agent, and a referer header naming the exact page being read. Aggregate those across a browsing session and a CDN's logs reconstruct visitor behavior about as well as an analytics script would. A company that won't run invasive analytics on its own pages has no business ignoring the same data accumulating in a vendor's log pipeline.

That makes jurisdiction the first filter. A US-headquartered CDN operates under the CLOUD Act wherever its edge nodes physically sit — the compulsion follows the company, not the server. Our vendor policy is explicit and ranked: residency, then privacy, then security, then robustness. Applied here, that ruled out the default answers (Cloudflare, CloudFront, Fastly) before performance was even discussed — not because they're bad at CDN-ing, but because they move the request path into a legal system we're deliberately building away from. Ciphera is a Belgian company; our data is stored in Switzerland; the CDN needed to be run by a European company.

The Checklist We Used

Five criteria, in the order we applied them:

EU jurisdiction. Bunny is Slovenian, so the edge is operated by an EU company under GDPR. Its network is global (119 PoPs, see the last item), so the jurisdiction we rely on is the operator's, and the nodes sit wherever Bunny places them.
Logging you can live with. Bunny's DPA lets us anonymize IP addresses in its logs or turn logging off entirely, and it is signed in the panel. On the zones that carry our customers' visitors, logging is off. "We anonymize" from an EU company under GDPR enforcement is a materially different promise than the same words from elsewhere.
Content-agnostic serving. The CDN must do its job without interpreting the bytes. For our asset zones we treat the CDN as untrusted infrastructure on principle: it caches and moves opaque objects, whether those are PNGs or encrypted blobs. Any CDN feature that requires inspecting or transforming content gets extra scrutiny before we enable it. The websites that now run on Bunny's platform are the exception, as the setup section below explains.
Transparent pricing. $0.01/GB for European and North American traffic on the standard network, volume tiers from $0.005/GB, and a $1 monthly minimum — all public on the pricing page, no sales call required. (All figures re-checked 19-07-2026.)
Performance, last. 119 PoPs, 250+ Tbps network capacity, ~24 ms average global latency (bunny.net/network). Comfortably more than a content site needs — but it was the fifth question, not the first.

The order is the point. Plenty of CDNs pass criterion five. Very few pass one and two first.

What Our Setup Actually Looks Like

The architecture is deliberately boring:

Origin: all static assets — product illustrations, icons, blog OG cards — live in Bunny Edge Storage, and every upload is also written to object storage in Switzerland, so Bunny never holds the only copy.
Edge: Bunny pull zones (fifteen of them on 19 July 2026, across our sites and services) front that storage at cdn.ciphera.net. The copy in Switzerland holds every file, so swapping CDN providers for these asset zones would mean pointing the new CDN at it, not a migration. The websites are different: ciphera.net, docs, help and status moved onto Bunny Magic Containers (about 42 regions) between 15 August and 12 September 2026, and the Pulse tracker and API are served through Bunny's edge, where TLS ends. Moving the websites would be a rebuild.
Assets are path-keyed and immutable. Every object uploads with Cache-Control: public, max-age=31536000, immutable and is never edited in place — a changed image gets a new path. Edges can cache for a year with zero staleness risk, and there's no revalidation traffic to leak anything about visitors.
Assets are pre-sized at upload. No on-the-fly transformation service sits in the pipeline resizing images per request — what's in storage is exactly what's served.

Belgian company, Swiss storage, EU-operated edge. Each layer's jurisdiction is chosen, not inherited from a default.

Four Things Running It Taught Us

1. Cache keys will collapse things you didn't expect. Next.js ships an image optimizer that serves every image through query-string URLs (/_next/image?url=…&w=…&q=…). Our Bunny zone's cache configuration collapsed query strings — so one cached body was served for every image on the site. The fix is right in our next.config.ts, comment and all: images are served directly from cdn.ciphera.net, path-keyed and pre-sized, unoptimized: true, never through the optimizer. The general lesson: know exactly what your CDN includes in its cache key before you put a URL scheme that depends on query strings behind it.

2. Measure your real cache-hit rate — ours was embarrassing. When we actually audited it in March, our aggregate cache-hit rate was 8.65%. Not 86 — eight point six five. The immutable asset zones were fine; the damage came from zones and paths that were never being cached at all, silently proxying every request to origin. A CDN with a single-digit hit rate is an expensive DNS alias. We fixed the worst offenders the same day with explicit cache rules. Watch the hit rate per zone, too, not just the fleet aggregate — one silently bypassing zone hides comfortably behind nine healthy ones in an average. If you haven't looked at your numbers this quarter, they are probably lower than you think.

3. Push security rules to the edge. Internal paths — metrics endpoints, health checks, anything under /internal/ — shouldn't rely on application middleware alone to stay private. Bunny's edge rules let us block those routes at the CDN, before requests ever reach origin. Defense in depth costs one API call per rule.

4. Decide what never goes on the CDN — and write it down. Not everything belongs behind cdn.ciphera.net. Favicons, robots.txt, sitemap.xml, and PWA manifests stay at the origin, because browsers and crawlers expect them there and some flatly require it. Everything else follows a written rule: images are never committed to a frontend repo's public/ directory — they're uploaded to the bucket under a per-project prefix (website/, pulse/, id/) and referenced through a small cdnUrl() helper that falls back to local paths in development. The payoff of that discipline shows up in purging: because assets are immutable and path-versioned, cache purges are rare, deliberate, single-URL API calls — not panicked zone-wide flushes. If your team purges the whole zone more than a couple of times a year, the asset pipeline is telling you something.

What We'd Tell Another EU Team

Choose the CDN like you'd choose a payment processor — as a counterparty, not a utility. Concretely:

Write the jurisdiction requirement down first, before benchmarks make you fall in love with someone's latency map.
Read the DPA and the logging policy, not the marketing page. "GDPR-compliant" on a landing page is decoration; anonymization commitments in a signed DPA are a contract.
Keep origin and edge separable. The CDN should be replaceable in an afternoon; if it isn't, you've built a dependency, not a cache. Our asset CDN passes that test. Our websites do not: they run on Bunny's container platform, so moving them is a rebuild.
Treat the CDN as untrusted. Serve it opaque, immutable, path-keyed objects and let it do the one thing CDNs are great at.
One honest caveat: Bunny's software is proprietary. We verify behavior through its DPA, its GDPR commitments, and what we can observe operationally — the same "verify, don't trust" standard we apply elsewhere is only partially available here, and pretending otherwise would be exactly the kind of claim we tell you to distrust.

Jurisdiction is also why this choice sits inside a bigger pattern for us — the same reasoning that keeps our data in Switzerland puts our CDN with an EU operator. That argument, with the receipts, is in why Swiss infrastructure matters for data privacy; and the full inventory of what our stack can and can't see about you is on our trust page.

The EU-US Data Privacy Framework Is Built on an Executive Order — and That's the Problem

Usman — Fri, 30 Oct 2026 00:43:04 +0000

Safe Harbor lasted 15 years before the Court of Justice of the European Union struck it down. Privacy Shield lasted four. The Data Privacy Framework is barely three years old, already at the CJEU on appeal — and the US oversight board that underpins it has been gutted to a single member. FISA Section 702 was due to sunset on 20 April 2026 and lapsed on 12 June 2026.

Max Schrems put it plainly: "This deal was always built on sand. Instead of stable legal limitations, the EU agreed to executive promises that can be overturned in seconds." He's been right twice before. Cross-border data flows contribute $2.8 trillion to global GDP (McKinsey/ICC, 2024). The stakes couldn't be higher.

In short

The EU-US Data Privacy Framework depends on Executive Order 14086 — not legislation — and can be revoked at any time. With the PCLOB oversight board stripped to one member, FISA Section 702 having lapsed on 12 June 2026, and a CJEU appeal pending, the legal basis for 2,800+ companies transferring EU data to the US is eroding fast — and by July 2026 it was being tested by a legal theory nobody was watching in April (European Commission, 2024).

Updated 18 October 2026: the lead, the summary and the Section 702 section now say that 702 lapsed on 12 June 2026.

Update, 19-07-2026 — This post's countdown resolved, and not the way the framing implied. FISA Section 702 didn't sunset cleanly on 20-04-2026: Congress patched it twice, then let it lapse anyway on 12-06-2026 — the first lapse of the authority since 2008 (collection continues in practice under March-2026 FISA Court certifications). The DPF adequacy decision is still formally in force. But on 29-06-2026 the US Supreme Court decided Trump v. Slaughter, fully overruling Humphrey's Executor and holding that FTC commissioners can be fired at will — the same independence the Commission's adequacy decision cites 259 times. noyb has already written to the Commission demanding withdrawal and is preparing a fresh CJEU challenge ("Schrems III"). The sections below are updated in place; the shape of the risk has changed as much as its severity.

What Keeps Failing — and Why?

The EU and US have tried three times to create a stable legal framework for transatlantic data transfers. All three rest on the same flawed assumption: that US surveillance law is compatible with EU fundamental rights. Over 2,800 US companies are currently certified under the DPF (European Commission, Oct 2024). Every one of them is exposed.

The timeline speaks for itself.

Framework	Years Active	How It Ended
Safe Harbor	2000–2015	Struck down (Schrems I)
Privacy Shield	2016–2020	Struck down (Schrems II)
Data Privacy Framework	2023–?	CJEU appeal pending

Each time, the CJEU reached the same conclusion: US law doesn't offer protections equivalent to EU fundamental rights. The specific problem? Mass surveillance under FISA Section 702 and Executive Order 12333, combined with the lack of meaningful redress for EU citizens.

The DPF's answer to this was Executive Order 14086, signed by Biden in October 2022. It introduced "proportionality" requirements for signals intelligence and created the Data Protection Review Court (DPRC) as a redress mechanism. But here's the structural weakness everyone warned about: it's an executive order. Not legislation. Revocable at any time by any president.

The European Commission completed its first periodic review in October 2024 and concluded the DPF was "functioning effectively." French MP Philippe Latombe challenged the framework at the EU General Court — and lost in September 2025. But Latombe appealed to the CJEU in October 2025. That's the same court that struck down both predecessors.

Update, 19-07-2026 — Latombe's appeal is now Case C-703/25 at the CJEU, limited to points of law, no hearing date set. On 29-06-2026 the Court granted Microsoft leave to intervene in support of the Commission's defense. Legal commentators now expect a ruling in late 2026 or early 2027.

Switzerland's adequacy decision, by contrast, was granted in 2000 and has never been challenged at any court. For more on why that matters, see why Swiss infrastructure matters for data privacy.

Why Is the DPF Under More Pressure Than Ever?

The structural supports holding the DPF together are failing. On January 27, 2025, the Trump administration fired three of five Privacy and Civil Liberties Oversight Board members — including chair Sharon Bradford Franklin. The board lost its quorum and can no longer initiate investigations or publish reports (CDT, 2025).

Why does a five-person board matter for European data protection? Because the PCLOB's annual review of EO 14086 compliance was a core piece of the DPF's credibility. That review is now on indefinite hold.

Update, 19-07-2026 — A federal court found the firings unlawful in May 2025 and ordered two of the three members reinstated; the administration appealed, and as of this writing the board still has zero quorum in practice. Beth Ann Williams, the sole remaining member, is herself on holdover status — her term expired 29-01-2026.

Update, 19-07-2026 — A larger threat than PCLOB has since emerged. On 29-06-2026 the Supreme Court's Trump v. Slaughter ruling stripped the FTC of for-cause removal protection entirely, and the Commission's own DPF adequacy decision relies on FTC independence 259 times by noyb's count (source: noyb.eu). noyb sent the Commission a formal letter demanding the adequacy decision be withdrawn and is preparing a direct CJEU challenge. Not everyone agrees this is fatal: the DPRC — the actual redress body at issue in Schrems I and II — draws its independence from an executive order and DOJ regulation, not a congressional statute, a distinction Slaughter didn't address (counter-view: iapp.org). The Commission so far: it has "taken note" and "will carefully analyse."

EO 14086 itself hasn't been formally revoked. But an executive order without oversight is a policy without teeth. Schrems raised this point directly: "What does that mean for something that doesn't even have statutory independence, but basically just executive order independence?"

The European Parliament took notice. It filed a formal question (E-000540/2025) asking the Commission about the consequences of the PCLOB firings for the DPF. The Commission's response was measured but didn't dispute the concern.

Meanwhile, the Latombe appeal sits at the CJEU. The court has a 2-for-2 track record of striking down transatlantic data frameworks when surveillance concerns reach it. As the CDT warned, the PCLOB firings "have the potential to significantly disrupt transatlantic transfers."

Our take: The DPF isn't collapsing because of a single event. It's being hollowed out from multiple directions at once — an oversight board without quorum, a redress court without statutory backing, and an executive order that exists at the pleasure of whoever occupies the White House. The EU Commission called it "functioning effectively" in October 2024. That assessment hasn't aged well.

What Happens If Section 702 Lapses?

FISA Section 702 — the surveillance authority at the heart of every EU challenge — was due to sunset on 20 April 2026 and lapsed on 12 June 2026. Congress reauthorised it in April 2024 through the Reforming Intelligence and Securing America Act (RISAA), but gave it the shortest extension ever: just two years. FBI queries of Section 702 data dropped 90%, from roughly 57,000 to approximately 5,500 after RISAA reforms (DNI, 2025).

That sounds like progress. But the picture is more complicated. CIA, NSA, and NCTC queries involving US persons rose from about 3,800 to roughly 7,800 in the same period (DNI, 2025). Surveillance didn't decrease across the board — it shifted.

In April 2026, the Trump administration had taken no public position on reauthorisation. If Section 702 lapses entirely, the DPF's adequacy foundation weakens — the Commission's assessment specifically relied on 702 oversight mechanisms. If Congress reforms it with warrant requirements, as the SAFE Act (Durbin/Lee) proposes, it could actually strengthen the DPF's legal footing.

Update, 19-07-2026 — It didn't get reformed; it lapsed. Congress patched the April 20 deadline twice (to 30-04, then to 12-06) before a further extension failed in the House 198–218 on 11-06-2026, over an unrelated dispute about the acting-DNI appointment. Section 702 has had no statutory basis since 12-06-2026 — the first lapse since 2008. Surveillance continues in practice under FISA Court certifications valid into 2027, but the statutory authority the Commission's adequacy finding assessed is currently unauthorized.

But here's what keeps European data protection officers awake at night: even hosted-in-Europe data isn't safe. Microsoft France's general manager testified under oath that he "cannot guarantee data safety from access by US authorities" even for EU-hosted data. The CLOUD Act allows US authorities to compel data production regardless of where it's stored. So the question isn't just where your data lives. It's who has jurisdiction over the company that holds it.

Europe Is Already Hedging Its Bets

European sovereign cloud spending is accelerating fast. The market hit $6.9 billion in 2025, is forecast to reach $12.6 billion in 2026, and will hit $23.1 billion by 2027 — tripling in two years. Europe is on track to surpass North America in sovereign cloud spending by 2027 (Gartner, Feb 2026).

All 27 EU member states signed the Berlin Declaration for European Digital Sovereignty on November 18, 2025 (Council of the EU). The political intent is clear. But does the infrastructure match?

Not yet. US hyperscalers still hold 70% of the EU cloud market. European providers are stuck at 15% (Synergy Research, 2025). Here's the frustrating part: European cloud revenues tripled between 2017 and 2024, but market share actually halved — from 29% to 15% — because US providers grew even faster.

The EU Data Act is rolling out implementation from 2025 through 2027, with cloud switching and portability provisions taking effect in September 2026. Gaia-X has grown to 180+ data spaces and 600 services, but independent assessments note "just a handful of operational databases." That's sovereignty in theory, not yet in practice.

The gap between political ambition and infrastructure reality remains enormous. But the spending trajectory tells you where this is heading.

Our take: Europe's sovereign cloud push isn't just about cost or performance. It's a direct response to the legal instability of depending on US-controlled infrastructure for European data. The Berlin Declaration made the political commitment. Whether European cloud providers can actually scale fast enough to absorb the demand is the open question — and the answer so far is: not yet.

What Should Businesses Do Right Now?

Don't wait for a court ruling to act. Over 2,800 companies depend on DPF certification as their primary transfer mechanism (European Commission, 2024). If you're one of them, start building redundancy now.

Have Standard Contractual Clauses as a backup. DPF certification alone isn't enough when the legal basis could change overnight. SCCs provide an independent transfer mechanism — though they come with their own compliance obligations.

Map where your data actually flows. Not where your vendor says it's stored — where it actually goes. Processing, backups, subprocessors, support access. The CLOUD Act means US jurisdiction follows US companies, not data location.

Conduct Transfer Impact Assessments for US-bound data. Document the specific risks of US surveillance law for your data categories. If the DPF falls, you'll need this documentation immediately.

Consider European-hosted alternatives for sensitive personal data. Not because European hosting is inherently safer — but because legal stability matters. Analytics is a common culprit: what GDPR actually requires of it — and why keeping the data in the EU takes the whole transfer question off the table — is its own guide. For a deeper look at how zero-knowledge encryption protects data regardless of jurisdiction, we've written a full guide too.

Ciphera chose Swiss infrastructure precisely because Swiss adequacy doesn't depend on an executive order. It was granted in 2000 and has never been challenged at any court. That's the kind of stability businesses need — not a framework that gets rebuilt every few years.

The pattern is clear. Safe Harbor fell. Privacy Shield fell. The DPF is standing, but the ground beneath it is shifting. Whether you're a startup handling EU customer data or an enterprise running transatlantic operations, the time to prepare for the next disruption isn't after it happens. It's now.

Is Your Website Analytics GDPR-Compliant? A 2026 Checklist

Usman — Thu, 29 Oct 2026 00:43:06 +0000

Ask ten website owners whether their analytics is GDPR-compliant and you will get ten confident answers, most of them wrong in the same direction: "we added a cookie banner, so we're fine." A banner is one small piece of a much larger picture, and it doesn't touch the questions that actually decide whether your analytics is lawful — what data you collect, why, where it goes, and how long you keep it.

The good news is that GDPR compliance for analytics is not mysterious. It is a finite checklist, every item of which traces back to a specific article or ruling you can read yourself. The more useful news is that there is one architectural decision that makes most of the checklist evaporate — and it is worth understanding before you spend a quarter arguing with a consent-management platform.

In short

GDPR governs your analytics the moment it processes personal data, and an IP address usually qualifies. That pulls in a lawful basis, data minimisation, retention limits, transparency, sometimes a formal impact assessment, and a separate consent rule for anything stored on the device. The sharpest failure mode is international transfers — Google Analytics was ruled unlawful across the EU in 2022 for sending data to the US, and the framework that restored transfers is in force but under active legal challenge. The cleanest compliance path isn't paperwork: it's processing no personal data and hosting in the EU or Switzerland. This is the checklist, and how Pulse's architecture answers each line.

Updated 18 October 2026: we corrected how Pulse's hashes work, where its location data comes from, what the tracker stores and how requests reach our servers.

When does GDPR even apply to your analytics?

GDPR applies to the processing of personal data — Article 4(1) defines that as "any information relating to an identified or identifiable natural person," including someone identifiable indirectly "by reference to an identifier such as a name, an identification number, location data, an online identifier." The whole question of whether GDPR governs your analytics turns on whether what you collect counts as personal data.

For most analytics, it does — because of the IP address. Recital 30 of the GDPR names IP addresses and cookie identifiers explicitly as "online identifiers" that can be used to profile and identify people. The Court of Justice reinforced this in Breyer (Case C-582/14): a dynamic IP address is personal data for a website operator wherever that operator has a legal means of obtaining, from a third party like an internet provider, the extra information needed to identify the visitor. The ruling is conditional rather than absolute — but in practice, regulators now treat that condition as met in essentially every EU online context, which is why IP addresses are treated as personal data by default. A 2025 CJEU decision (EDPS v SRB, C-413/23 P) refined the edges — whether pseudonymised data is "personal" depends on who holds it and what they can reasonably do — but did not change the baseline for an analytics operator sitting on raw request data.

Here is the trap that catches a lot of "privacy-friendly" tools: not retaining data is not the same as not processing it. Article 4(2) defines processing to include mere collection, not just storage. If a tool reads your IP address for a fraction of a second to derive a country or a counting hash and then throws it away, that fraction of a second is still processing of personal data, and it still needs a lawful basis. "We don't store IPs" is a good and important property — but on its own it does not put you outside GDPR. It changes how much is at stake, not whether the rules apply.

The checklist

Once GDPR applies, these are the obligations that decide whether your analytics deployment is lawful. None of them is exotic; all of them are checkable against your actual setup.

What GDPR requires	Article	How to check your setup
A lawful basis — consent or legitimate interest	Art 6	Can you name your basis? If legitimate interest, is the balancing test documented? (Separate from cookie consent, below.)
Purpose limitation	Art 5(1)(b)	Is every field tied to a stated purpose, or collected "just in case"?
Data minimisation	Art 5(1)(c)	Full IPs, precise geolocation, or per-user journeys you never use?
Storage limitation	Art 5(1)(e)	Is there a real retention period — and does data actually get deleted?
Protection by design & default	Art 25	Built in from the start, or bolted on after?
Transparency	Arts 12–14	Does your privacy notice describe the analytics accurately?
A DPIA where the risk is high	Art 35	Does the tool profile or track at scale? If so, is it assessed?
Records of processing	Art 30	The "under 250 staff" exemption is narrow — most tracking still needs a record.
A lawful transfer if data leaves the EEA	Chapter V	See the next section — where most tools fail.
Consent for device storage (ePrivacy, separate)	Art 5(3) ePD	Sets a cookie or reads storage? You generally need prior consent — see the cookie-banner post.

Two of these deserve emphasis because they are the most commonly botched. The lawful basis and the cookie consent are different questions — you can have a valid legitimate-interest basis for processing analytics data and still be required to get consent before setting the cookie, because those obligations come from two different laws. And the records exemption is a trap: "we're a small company" is not the shield people assume, because the exemption falls away for processing that is regular or that risks people's rights, which is most analytics.

The transfer trap — where most tools actually fail

If there is one line on the checklist that has done the most legal damage, it is international transfers. And the story is best told through the tool most sites reach for.

In 2020, the Court of Justice's Schrems II ruling (Case C-311/18) struck down the EU-US Privacy Shield, holding that US surveillance law did not offer EU-equivalent protection or redress. Then, across 2022, a coordinated wave of complaints turned that principle on Google Analytics specifically. The Austrian authority ruled first (decision published January 2022) that a website's use of Google Analytics was an unlawful transfer of personal data to the US; France's CNIL issued formal notices weeks later; and Italy's Garante followed in June, in a decision against Caffeina Media that made a point worth remembering — it held that Google's "IP anonymisation" feature is pseudonymisation, not anonymisation, because Google retains the capacity to re-identify. These three were the most visible of roughly a hundred near-identical complaints filed across the EEA. The pattern was uniform: US-hosted analytics, EU visitors, no adequate safeguard.

The 2023 EU-US Data Privacy Framework restored a lawful transfer route for US organisations that self-certify under it — and it is formally in force in 2026. But it should be treated as live and contested, not settled: its first court challenge was dismissed by the EU General Court in September 2025, and that dismissal was appealed to the Court of Justice (Case C-703/25 P), which was still pending as of mid-2026 — while separate concerns about the independence of the US oversight board that the framework relies on have added political fragility. Building your compliance on a transfer mechanism that a pending case could unwind is a risk you should at least take with your eyes open.

There is a way to make the entire transfer question disappear: don't transfer. If analytics data never leaves the EU — or sits in Switzerland, whose adequacy the European Commission reaffirmed in its January 2024 periodic review of that country's long-standing adequate status — then Chapter V simply isn't engaged. No standard contractual clauses, no supplementary-measures analysis, no framework-under-appeal to worry about. Residency is not a compliance silver bullet on its own, but it removes the single hardest line on the checklist.

The shortcut: process no personal data

Look back at the checklist and notice something. Almost every obligation is triggered by processing personal data. Lawful basis, minimisation, retention, records, transfers, most DPIA triggers — they all attach to personal data. Remove the personal data, and most of the list has nothing to attach to.

That is the architectural move privacy-first analytics is built around: collect no cookie or cross-site identifier, retain no IP address, and produce output that is genuinely aggregate. If the data you keep cannot be tied back to a person, Recital 26 takes it outside GDPR's scope entirely, because the data-protection principles "do not apply to anonymous information."

But this is exactly where honesty has to be louder than marketing, because two shortcuts here are false:

"Aggregated" is not automatically "anonymous." Aggregation can still leak identity through small cells and singling-out; whether an aggregate output is truly anonymous is a substantive, fact-specific question, not a label you get to apply because you ran a GROUP BY.
Hashed or truncated IPs are pseudonymisation, not anonymisation. The EDPB's 2025 guidelines on pseudonymisation are explicit: data that could be attributed to a person using additional information remains personal data, even if the person holding it has erased that additional information — it becomes anonymous only if the full conditions for anonymity are met. So a tool that same-day-hashes your IP and calls the result "anonymous" is usually overstating it. The data is minimised and pseudonymised — which is genuinely better — but it is not magically outside GDPR.

The honest version of the shortcut, then, is not "we process no personal data, so GDPR doesn't apply to us." It is: we minimise processing to the point where there is almost nothing left to govern, and we build toward genuine anonymity in the output. That is a defensible, checkable claim. "We're exempt" is not.

How Pulse checks each box

Pulse is our own analytics product, and it was designed around exactly this shortcut — not to manage GDPR obligations after the fact, but to remove what triggers them. Here is how it maps to the checklist. (For the full architectural accounting, including the exact hash mechanics, see what we see about you, and what we don't.)

Personal data — minimised to a transient moment. Pulse does process your IP address, and we should say so plainly: to count a visit it needs the IP for the instant it takes to compute the daily hash and, unless the site owner has switched it off, a location lookup. Under GDPR, that momentary use is processing. What Pulse does not do is keep it. A dedicated middleware wipes the raw IP from the request the moment the derived values are computed; the events table has no column for an IP address or a raw user-agent to live in. So the processing exists, but it leaves much less behind for the rest of the checklist to grip.

Data minimisation and by-design (Art 5(1)(c), Art 25). There is no cookie, no fingerprint, and no identifier that outlasts the site's day or reaches another website. Visits and visitors are counted with one server-side salted hash of the IP, user-agent, and domain. The hash rotates every day and ties pageviews into one visit. It removes duplicate visitors within that day, so a returning reader counts once for each day they visit. Nothing links a reader across days or across sites. The dashboard shows aggregates by default; a site owner can switch on a Visitors view (off by default) that lists pseudonymous profiles that each cover one IP address and browser on one day. Minimisation isn't a setting here; it's the shape of the data model.

Geolocation without storing the IP. The CDN edge (Bunny) supplies the country. Region and city are derived from the IP in process, on our own infrastructure, and the IP is then discarded and never stored. A new Pulse site collects country, region and city by default; the site owner can cap it at country or switch it off.

International transfers (Chapter V): only in limited cases. Pulse's data lives in Switzerland (Infomaniak's data centres in Geneva), and there is no US sub-processor in the path. The tracker and the API are served through the edge network of Bunny, an EU (Slovenian) company, where the encrypted connection ends. Our privacy policy lists Bunny as a sub-processor that handles every request, IP addresses included, on a global edge network, and says that in limited cases data may be processed in other jurisdictions, with standard contractual clauses where needed. So the single hardest line on the checklist, the one that sank Google Analytics, arises only in those limited cases. We wrote about why Swiss infrastructure matters for exactly this reason.

Device storage and cookie consent. The tracker sets no cookie. It keeps nothing in the browser except one flag that is written only when a site owner opens a ?pulse-ignore link. We treat this storage as strictly necessary, so the separate ePrivacy consent question that a cookie triggers doesn't arise for it; whether that holds for your own site is for you and your counsel to decide. (The honest footnotes, including the fact that logging into the Pulse dashboard uses ordinary session cookies, are covered in the cookie-banner companion post.)

The net effect is not that Pulse waves a wand and exits GDPR. It is that the obligations which normally pile up around retained personal data — subject-access requests for visitor data, retention schedules, breach exposure, transfer paperwork — have little to attach to, because the only visitor identifier Pulse retains is a hash that rotates daily, and Ciphera deletes the key behind it five minutes after the site's day ends. That is a quieter claim than "100% compliant, guaranteed," and a much more honest one.

Compliant by design, not by disclaimer

If you take one thing from the checklist, let it be this: GDPR compliance for analytics is decided by architecture far more than by paperwork. You can paper over a data-hungry tool with a legitimate-interest assessment, a consent banner, standard contractual clauses, and a retention policy — and you will still be carrying every one of those obligations, plus the risk that a pending court case or a regulator's next decision moves the ground under you. Or you can choose a tool that keeps far less of what triggers the obligations in the first place, and spend that quarter on your product instead.

There is no configuration that makes a US-hosted, cookie-setting, IP-retaining analytics tool disappear from GDPR's scope. There is an architecture that gets most of the way there — cookieless, built on short-lived hashed identifiers, with the data held in Switzerland — and the difference between the two is not marketing. It is what your data model actually does when a visitor loads your page. Ours is partly open: the dashboard and the tracking script are open source; the server that stores the data is a managed service.

This post is an engineering and legal-landscape explainer, not legal advice. Whether a specific analytics deployment is GDPR-compliant depends on your configuration, jurisdiction, and processing purposes; consult a qualified adviser or your supervisory authority for a determination about your own site.

How to Migrate Off Google Analytics: A 2026 Guide

Usman — Wed, 28 Oct 2026 00:43:04 +0000

Leaving Google Analytics used to feel like leaving your bank: technically possible, practically unthinkable, and vaguely frightening. It isn't anymore. The tool changed underneath everyone in 2023, the legal ground under it has been shifting since 2022, and a mature set of privacy-first alternatives now exists that install in one line.

But most "just switch!" advice skips the parts that actually trip people up — the historical data you can't take with you, the metrics that will never reconcile, and the features you'll genuinely lose. This guide is the honest version: the timeline you need straight, why teams are actually leaving, what you gain and what you give up, and the concrete steps to do it without breaking your reporting.

In short

Universal Analytics is gone and GA4 is the only Google Analytics left — so "migrating" now means GA4 to something else. Teams leave for the cookie-consent burden, EU legal uncertainty, GA4's complexity, and data lock-in. The migration itself is straightforward: run the new tool alongside GA for two to four weeks, recreate your goals as events, and cut over. The two hard truths nobody tells you: you can't natively import your GA history into most tools (keep GA read-only or export to BigQuery), and the numbers will never match GA (they measure different things). And moving to a cookieless tool is a real trade-off — you gain simplicity, speed, and no banner; you lose long-term cross-session user journeys and remarketing.

Updated 18 October 2026: we corrected what Pulse can import, how it counts returning visitors, which plans include funnels and the script size. We now suggest running both tools side by side for two to four weeks.

First, get the timeline straight

Half the confusion around "leaving GA" comes from people still picturing the old Universal Analytics. It's worth thirty seconds to fix the mental model, because it changes what you're actually migrating from.

Universal Analytics — the version most people used for a decade — stopped processing data on 1 July 2023 for standard properties. Paid GA360 properties with an active order got a one-time extension, but read-only access to all UA historical data ended on 1 July 2024 for everyone. Since then, GA4 has been the only version of Google Analytics that exists. There is no "classic" mode to fall back to; if you haven't logged in since the UA days, the tool you remember is already gone.

GA4 itself kept moving, too. In March 2024 Google made Consent Mode v2 mandatory for EEA/UK sites that also run Google Ads, and — confusingly — renamed "conversions" to "key events" across the entire product. If you're following a two-year-old migration tutorial, half its screenshots and terminology are already stale. (More recently, in May 2026, GA4 started auto-tagging AI-assistant referrals — ChatGPT, Gemini, Claude — as their own channel; a reasonable feature, and also a reminder that the platform you're standing on keeps shifting under you.)

The practical upshot: you are migrating from GA4's event model, not from the old session-based UA. That matters for how goals map across, which we'll get to.

Why teams are actually leaving GA4

Not everyone leaves for the same reason, but the reasons cluster:

The cookie-consent tax. GA4's default setup relies on a cookie, which in the EU means a consent banner — and a large share of visitors decline. Real-world acceptance varies enormously by banner design and country, but it's common for only a quarter to a half of EU visitors to accept, with acceptance in some markets sitting well under a third. Every declined banner is a visitor GA4 can't see. A cookieless tool removes that trade-off for the analytics piece entirely — there's no consent to lose because there's no cookie to consent to. (Whether that means you can drop the banner is a separate legal question we cover in do you need a cookie banner for analytics?.)

EU legal uncertainty. Three data protection authorities ruled in 2022 that standard Google Analytics deployments involved an unlawful transfer of EU data to the US; the 2023 EU-US Data Privacy Framework restored a legal route, but that framework is contested and under fresh pressure in 2026. This is genuinely complicated and easy to overstate — GA is not "banned" today — so we've kept the detail in a dedicated post: is your analytics GDPR-compliant?. For migration purposes, the point is simpler: teams increasingly don't want to carry that uncertainty at all.

GA4 hides more data than people realise. GA4 applies data thresholding — it suppresses report rows entirely when the numbers are small enough that someone could be re-identified — and rolls any dimension past roughly the top 500 daily values into an (other) bucket. Both are privacy features, but they routinely leave marketers staring at data that looks simply missing.

The complexity. GA4's event model raised the skill floor. The one-click reports many teams relied on in UA are gone, "conversions" now require deliberately configuring key events, and small teams without a dedicated analyst often can't get back what UA gave them for free. For a lot of sites, GA4 is more power than they'll ever use, wrapped in more complexity than they can afford.

Data ownership. With GA, your raw data lives in Google's infrastructure and — through Ads and Signals linkage — can feed Google's advertising ecosystem. A privacy-first tool, especially an EU-hosted one, puts you back in custody of your own numbers.

What you'll gain — and what you'll genuinely lose

This is the section most vendor guides skip, and it's the one that decides whether you'll be happy six months later. Migrating to a cookieless, aggregate-first tool is a trade-off, not a strict upgrade. Anyone who tells you that you get everything GA had minus the cookies is selling something.

You gain	You lose
No cookie banner needed for the analytics itself	Reliable long-term cross-session user journeys: knowing the same person first visited in one month and converted in the next
A much lighter script (a few KB vs GA4's payload)	Individual user IDs and long-term user-level drill-down — by design, not as a missing feature
EU/Swiss data residency and real control over retention	Advertising / remarketing integrations — no Google Ads audience import, no Signals-based remarketing
A simpler, opinionated dashboard instead of GA4's sprawl	Cohort and retention analysis that depends on recognising returning individuals
Often more complete raw counts (no consent gap, blocked less by ad blockers, stricter bot filtering)	The comfort of numbers that "match GA" — they never will (more below)

Read the right-hand column carefully. If your business genuinely runs on user-level funnels, cross-device journeys, or Google Ads remarketing audiences, a cookieless tool will feel like a downgrade on those specific axes — because the thing that powered them (a persistent per-person identifier) is exactly what you're removing. If, like most sites, you mainly want to know how many people came, from where, to which pages, and whether they did the thing you care about, you lose very little and gain a lot.

The migration, step by step

The mechanics are less scary than the decision. Here's the sequence practitioners actually follow.

Audit what you actually use. Before choosing a tool, list the GA4 reports and metrics your team genuinely looks at. Most teams find the real list is short — visitors, sources, top pages, a few goals — which makes the rest of the migration much easier.
Add the new script alongside GA4. Don't rip GA out on day one. Both cookieless scripts are tiny and load asynchronously, so running two trackers costs you nothing meaningful. This is universally recommended.
Run them in parallel for two to four weeks. A few weeks of side-by-side operation lets you get fluent in the new dashboard and confirm your tracking before anything depends on it.
Recreate your goals as events. Since GA4 already calls these "key events," this is a like-for-like exercise: for each key event, define an equivalent custom event in the new tool.
Handle historical data — the step everyone underestimates. GA4's in-app exports are capped (5,000 rows for standard reports, ~10,000 for explorations). For complete, unsampled history, the standard route is BigQuery export, which is free for every GA4 property up to 1M events/day. But here's the hard truth: GA's historical data generally cannot be migrated natively into a different vendor's tool — the schemas and identifiers don't line up. Your realistic options are to keep the old GA4 property read-only for reference, or archive the raw export, and treat the new tool as a clean start. A few tools ship a vendor-specific GA4 importer; most, including Pulse, do not.
Verify by comparing trends, not totals. Watch that key events fire for real user actions, and that week-over-week direction agrees between the tools. Do not chase matching absolute numbers.
Cut over and clean up. Make the new tool authoritative, update the dashboards people actually read, retrain on the new metric names — and remove GA4 along with the consent category it required.

Doing it with Pulse specifically

Pulse is our own privacy-first analytics tool, and it powers this site — so here's the concrete version, with the honest limits stated up front rather than buried.

Installation is one line. You add a single deferred script tag with your domain:

<script defer data-domain="yoursite.com" src="https://js.ciphera.net/script.js"></script>

That's the whole install. It's a script of about 3 KB gzipped (CI fails the build if it ever goes over 3,072 bytes), and it sets no cookies. If you use Next.js, WordPress, or another framework, there's a matching setup path — but the raw tag above works anywhere you can edit the <head>.

Your GA goals become Pulse events. Where GA4 has key events, Pulse has a pulse.track() call and a Goals screen. You fire an event from your frontend — pulse.track('signup_click'), optionally with properties and a revenue value — and create a matching Goal (display name plus event name) in the dashboard. Multi-step funnels are available on every plan, including the free Personal plan. The revenue argument maps cleanly to what GA4 calls a conversion value.

You run it next to GA, then cut over. There's no special wizard — you paste the Pulse tag alongside your GA snippet and compare. The free tier (one site, 10,000 events a month, six-month retention) is enough to evaluate a small site end to end before you pay anything.

Now the honest limits, because a migration guide that hides them isn't a guide:

Pulse does not import your Google Analytics history yet. It imports history from Plausible, Umami, Simple Analytics and Matomo, but not from GA4. Keep your GA property read-only or export to BigQuery for the archive; treat Pulse as a fresh, clean start.
Pulse won't follow a reader for more than a day. By default the dashboard shows aggregates only. A site owner can switch on a Visitors view (off by default) that lists pseudonymous profiles that each cover one IP address and browser on one day. Nothing links a reader across days or across sites. That's the privacy mechanism working as intended, not a gap to be patched later. If you rely on tracking individuals over longer periods, know that going in.

We wrote the full architectural accounting — how the cookieless counting actually works — in what we see about you, and what we don't, and a head-to-head of the leading privacy-first tools in Pulse vs GA vs Plausible vs Fathom.

The numbers won't match — and that's fine

The single most common way a correct migration feels like a failure: someone compares the new tool's dashboard to GA4's, sees different numbers, and panics. Head this off before it happens, because the mismatch is expected and mostly means your new tool is working.

Three things drive the gap. First, the metrics are defined differently. GA4's "users" counts persistent, cookie-based identities across visits; a cookieless tool's "unique visitors" typically comes from a rotating daily identifier, so the same person returning next week is a new unique visitor in such a tool but the same user in GA4. Pulse works the same way: it recognises a visitor for one day at most, so someone who returns on another day counts again. Visitors over a range add up each day's unique visitors. And one person on two devices is one GA4 user but two visitors. These aren't calibration errors; they're different definitions.

Second, the tools see different populations. Visitors who decline the consent banner are invisible to GA4 but visible to a cookieless tool. Ad blockers and privacy browsers block Google's script far more often than a small first-party one. And GA4 has repeatedly been shown to count more bot traffic as real than filtered alternatives do.

Third, double-counting during the parallel run is a myth worth dispelling. Running both scripts doesn't double-count within either tool — each simply counts what its own script sees. The confusion comes purely from comparing the two totals and expecting them to agree.

So during your parallel period, compare trend direction and relative change — did traffic rise or fall, which pages moved, did conversions hold up — not dollar-for-dollar totals. Teams that demand the new numbers match GA are set up to lose confidence in a setup that's working perfectly.

Migrating off Google Analytics in 2026 isn't the ordeal it once was. The tool you're leaving is already not the one you remember, the alternatives install in a line, and the only genuinely hard parts — the history you archive rather than carry, and the numbers you learn to read differently — are one-time adjustments, not permanent costs. What you get on the other side is analytics you can explain to a regulator, run without a banner, and actually understand. For most sites, that's a trade worth making.

This post is a practical migration guide, not legal advice. Whether you can remove a consent banner or how a specific GA configuration maps to EU law depends on your setup; see the linked compliance guides and, where it matters, consult a qualified adviser.

Do You Need a Cookie Banner for Analytics? What EU Law Actually Requires (2026)

Usman — Tue, 27 Oct 2026 00:43:05 +0000

If you run a website in the EU, you have almost certainly clicked "Accept" on more cookie banners than you can count — and you have probably wondered whether the one on your own site is actually required, or just something everyone copied from everyone else.

The honest answer is that most people ask the wrong question. They ask "do I need a cookie banner?" when the law never mentions banners, or consent buttons, or even a management platform. It mentions something much more specific — and once you see what the rule actually governs, the question of whether your analytics needs a banner gets a lot clearer, and a lot more interesting.

In short

The EU consent rule behind cookie banners is triggered by storing or reading information on a visitor's device — not by the word "cookie." First-party analytics cookies are not "strictly necessary," so in most of the EU, Belgium included, they require consent. The ePrivacy Regulation that was supposed to fix banner fatigue is dead — the Commission withdrew it in 2025. "Cookieless" is not a magic exemption, because regulators read "gaining access" broadly. But a tool that sets no cookie, stores no identifier, and retains no personal data removes the mechanism consent exists to govern. Pulse is built to come close to that, and this post spells out where it does not: one small browser value, and a pseudonymous daily id on the server, made with a key we delete five minutes after the site's day ends. The tracker is public, so you can check what it does in your browser.

Updated 18 October 2026: we corrected what Pulse stores and reads in the browser and how its hashing works, and we now say what this site's interactions script records.

The cookie banner isn't about cookies

The law everyone calls "the cookie law" is Article 5(3) of the ePrivacy Directive (Directive 2002/58/EC, as amended in 2009). Its operative sentence is worth reading slowly, because almost every misunderstanding starts by skipping it:

"…the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent…"

Notice what is not in that sentence. The word "cookie" does not appear. Neither does "banner", "tracking", or "advertising". The trigger is a technical action — storing information on, or gaining access to information already on, a device — with two narrow exemptions: doing it purely to carry out a transmission, or when it is strictly necessary to provide a service the user explicitly asked for.

Cookies are simply the most common way to do the triggering thing. A cookie is a small file written to your device and read back on later requests. That is textbook "storing" and "gaining access." But the rule is defined by the action, not the technology — which is why the European Data Protection Board (the body that coordinates EU data regulators) adopted guidelines in October 2024 confirming that Article 5(3) also covers tracking pixels, link decoration, browser fingerprinting, some kinds of local processing, and even certain IP-based tracking. If a technique stores or reads information on the device, it is in scope, cookie or not.

One more thing that catches people out: this consent requirement is independent of whether any personal data is involved. In Planet49 (Case C-673/17), the Court of Justice held that a pre-ticked consent checkbox is invalid, and that the consent obligation for cookies applies regardless of whether the stored information is personal data. So "our cookie doesn't contain personal data" is not a defence to the cookie rule. It is answering a different exam question.

Why analytics cookies need consent — and "first-party" doesn't save you

The most common escape hatch people reach for is: our analytics is first-party, so it's essential and exempt. It is a comforting story. It is also, as a general EU rule, wrong.

Back in 2012 the Article 29 Working Party — the EDPB's predecessor — looked at exactly this question in Opinion 04/2012 and concluded that first-party analytics cookies are not covered by the strictly-necessary exemption. Their reasoning was blunt: a visitor "can access all the functionalities provided by the website when such cookies are disabled." The site works fine without counting you. Measuring the audience is valuable to the operator, but it is not a service the user requested — so it does not clear the "strictly necessary" bar.

That position is still the mainstream one. The UK's ICO says analytics cookies require consent. Belgium's Data Protection Authority (Autorité de protection des données / Gegevensbeschermingsautoriteit) says the same in its official cookie checklist, which states plainly that visitor counting does not fall within the strictly-necessary functional-cookie exemption, citing that 2012 opinion directly.

There is exactly one well-developed exception, and it proves the rule. France's CNIL operates a conditional no-consent regime for audience-measurement cookies — but only if the tool clears a demanding list: used solely to measure audience, output that is anonymous only, no cross-site tracking, no combining with other processing, a cookie lifetime capped at 13 months, and data retention capped at 25 months, with users still informed and able to object. Even then, CNIL warns that most large analytics products do not qualify regardless of how they are configured. And crucially, this is a French carve-out. It is not EU law, and — this matters for a Belgian company writing this post — Belgium has not adopted it. If your reasoning is "France allows it," you are quoting the wrong regulator for most of Europe.

So for the ordinary case — a first-party analytics tool that sets a cookie, in most EU member states — the answer to "do I need consent?" is yes. Not because of some aggressive interpretation, but because of the plain text and twelve years of consistent guidance.

The regulation that was supposed to fix this is dead

Here is where a lot of otherwise-current advice goes stale. For years, the standard reassurance was: don't worry too much, the ePrivacy Regulation is coming and it will sort out banner fatigue. You may still read that in articles written as recently as last year.

It is no longer true. The proposed ePrivacy Regulation — the instrument meant to replace the 2002 Directive — was formally withdrawn by the European Commission. It appeared on the withdrawal list in the Commission's 2025 Work Programme, and the withdrawal was published in the Official Journal as notice C/2025/5423 on 6 October 2025. The European Parliament's own legislative observatory now records the file's status as "Procedure lapsed or withdrawn." After roughly eight years of deadlock, it is not a delayed bill awaiting passage. It is a closed file.

The practical consequence: the 2002 ePrivacy Directive, as transposed into each member state's national law, is the operative cookie law in 2026, and will be for the foreseeable future. There is no modernised successor waiting in the wings to relax it.

There is a new reform effort — the Commission's "Digital Omnibus" package, tabled in late 2025 — but it is a different beast. Rather than reviving a standalone regulation, it proposes to fold storage-and-access rules into the GDPR itself via new articles, including a limited carve-out for first-party audience measurement. Legal analysts covering the draft, such as Osborne Clarke, note two things worth holding onto: it is a proposal, still working through Parliament and Council with no adoption in sight, and even as drafted, the Commission's own explanatory text cautions that common commercial analytics tools are "unlikely to fall within the scope" of the exemption. Betting your compliance posture on a bill that might pass in some form, sometime, is not a plan.

What "cookieless" actually has to mean

So if the rule is about device storage and access — could you just not touch the device, and sidestep the whole thing?

In principle, yes. If a method genuinely never stores anything on the device and never reads anything from it, Article 5(3) is not engaged, and no consent question arises for that step. That is the logic behind the entire "cookieless analytics" category.

But this is exactly where honest engineering has to part ways with marketing copy, because the EDPB's 2024 guidelines read "gaining access" much more broadly than most vendors admit:

A client-side script that reads device attributes and sends them to a server is "gaining access." The guidelines are explicit that when JavaScript instructs the browser to send information back, that transmission itself counts — even if nothing was ever stored. A tool that builds a "cookieless" fingerprint from your screen size, timezone, fonts, and user-agent is doing precisely this. No cookie, still in scope.
Tracking pixels are in scope through caching alone, with no persistent storage required.
Even IP-based tracking is presumed in scope. The guidelines say that gaining access to an IP address triggers Article 5(3) "in cases where this information originates from the terminal equipment" — and that unless an operator can affirmatively show the IP does not originate from the user's device, it should assume the rule applies. That is a hard thing to guarantee for a whole site's worth of visitors.

The takeaway is uncomfortable for the "cookieless = free pass" pitch: most tools that call themselves cookieless still run a script that reads and transmits device signals, and that reading is the trigger. Dropping the cookie while keeping the fingerprint changes the technology and not the legal action. And separately — even in the rare case where Article 5(3) genuinely does not apply, if the tool processes personal data such as an IP address, the GDPR still requires a lawful basis for that. Clearing the cookie bar is not the same as clearing every privacy obligation. (We dig into the GDPR side — lawful basis, minimisation, international transfers — in a companion post on GDPR-compliant analytics.)

Genuinely consent-free analytics, then, is a narrower category than the label suggests. It means: no storage on the device, no client-side reading of device signals to build an identifier, and no retained personal data downstream. That is a high bar. It is also, deliberately, the bar we built Pulse to aim at, and the next section says where it does not quite get there.

How Pulse answers the question

Pulse is our own analytics product, and it powers this very site. Rather than ask you to trust that it is cookieless, here is what the tracker and the server actually do, because "receipts, not promises" only means something if we show the receipts. This site also loads Pulse's optional interactions script, which can record the label of a clicked link or button, how many characters were copied and from what kind of element, and the name and field count of a submitted form. Our privacy policy describes it.

It sets no cookie on your site. The tracking script that runs on a measured website sets zero cookies. Its own header comment says so, and more importantly, the server endpoint the script posts to is registered with no cookie or CSRF middleware at all — only rate limiting. There is no code path that could set a tracking cookie on a visitor, because none is wired up.

It keeps no lasting identifier on your device. This is the part that separates Pulse from most "cookieless" tools. Pulse does not run a fingerprinting script. It does not read your canvas or your fonts to synthesise an ID. It does read your viewport size, language and timezone, plus a coarse operating-system hint and a few human-versus-bot signals, and sends them with each pageview, but none of it goes into the hash. There is no cookie, and no identifier that outlasts the site's day or reaches another website.

Unique visitors are counted server-side, from data your browser sends anyway. When a pageview arrives, the backend computes a session identifier as a salted hash of the request's IP address, user-agent, and the site's domain — roughly SHA-256(daily_salt + domain + ip + user_agent). The daily_salt is a random key made for each site and each day. Five minutes after the site's day ends, we delete it and keep no copy, so Pulse cannot recompute that day's identifiers. The effect: the same visitor on the same day produces the same session hash, so repeat pageviews collapse into one visit, and after the site's midnight the salt changes and the same person produces a completely unrelated one. A returning reader is recognised for one day at most. Nothing links a reader across sites or across days, and there is no cross-device thread to pull. "Unique visitors" in the dashboard is then an aggregate that adds up each day's unique visitors, so a reader who returns on another day counts again. The dashboard shows aggregates by default. An owner can switch on a Visitors view, off by default, that lists pseudonymous readers and their visits for one day at most, never on share links, the public API or exports.

The raw IP is used for a moment, then wiped. Computing that hash needs the IP, and so does the location lookup: the country comes from the CDN edge, and the region and city are derived from the IP in process. But Pulse never stores the raw IP and never forwards it: a dedicated middleware scrubs it from the request context immediately after the derived values are computed. The events table has no column for an IP address or a raw user-agent to live in. What survives is one hash (a session hash that resets daily), a location, and coarse attributes such as device category, referrer and the pages visited. Since 10 September 2026 a new site collects country, region and city by default; the owner can cap it at country or switch it off. The per-reader Visitors view is off by default.

Now the honest caveats, because a post about honesty that hides its own footnotes would be self-refuting:

The tracker does touch one tiny browser value. It reads one flag in local storage and uses no session storage. pulse_ignore is written only when a site owner opens a ?pulse-ignore link, so they can exclude their own visits. The flag is not a cookie, and it cannot follow you to another site. By the test this post set out, it counts as storing or reading information on your device. It exists, and pretending it doesn't would be exactly the kind of overclaim this post is arguing against. Our privacy policy takes the position that this storage is strictly necessary and needs no banner. The site operator decides, with counsel.
The Pulse dashboard uses login cookies — like any product you log into. When you, the site owner, sign in to view your stats, that dashboard sets login cookies and a few preference cookies, all listed in our privacy policy. The login cookies are strictly necessary for a service you explicitly requested, and all of them are completely separate from the tracking script that runs on your visitors' browsers. The cookieless claim is about the tracker, not about logging in to read your own charts.

If you want the deeper accounting of what Pulse can and cannot see, we wrote it all out, including the exact hash mechanics, in what we see about you, and what we don't. And because the servers that count and store the data are in Switzerland rather than in a US cloud, and requests reach them through the global edge network of Bunny, an EU (Slovenian) company, the data-transfer questions that sink so many analytics tools mostly don't arise — a point we made the case for in why Swiss infrastructure matters for data privacy.

So — do you actually need a banner?

Here is the honest synthesis, without the marketing gloss.

If you run a cookie-based analytics tool — Google Analytics and most of its mainstream competitors — on a site aimed at EU visitors, then yes, you almost certainly need consent before those cookies are set, and in most member states, including Belgium, "it's first-party" will not exempt you. (For Google Analytics specifically there is a second, independent problem: several EU regulators ruled its US data transfers unlawful in 2022. You can see how badly the numbers work against cookie-gated measurement in our comparison of Pulse, GA, Plausible, and Fathom.)

If you run a tool that sets no cookie, stores no identifier, and retains no personal data, you have removed the mechanism that cookie consent exists to govern. There is no stored identifier to consent to, and nothing personal being kept. That is a categorically stronger position — but I am not going to tell you it is a guaranteed, universal exemption, because the law is broad and fact-specific and no regulator has issued a ruling blessing any particular vendor's exact model. What I can tell you is that Pulse is built to give you the least to worry about. It sets no cookie, and it touches the device only in the small ways described above. It links a returning reader only within the site's day, never across sites, and it hosts the result in the EU's neighbourhood rather than shipping it across the Atlantic. The final call for your specific site — and any notice you choose to give — belongs to you and your data protection officer. We publish our own architecture openly at /trust and describe exactly what runs on this site in our privacy policy precisely so that call is an informed one.

The cookie banner became the symbol of privacy law because, for two decades, the dominant way to measure a website was to leave something on the visitor's machine and read it back later. The banner is the price of that choice. The more interesting move is not to negotiate a better banner. It is to stop needing one — by not touching the device in the first place.

This post is an engineering and legal-landscape explainer, not legal advice. Cookie and data-protection obligations depend on your specific setup, jurisdiction, and how a given tool is deployed; consult a qualified adviser or your supervisory authority for a determination about your own site.

Ciphera Bunny: Second Place in HopStart Cohort #3

Usman — Mon, 26 Oct 2026 00:43:02 +0000

Most infrastructure stories are about a company picking a vendor. This one is about two companies making the same bet — that "European" can be a technical foundation, not a marketing adjective — and one of them backing the other for it.

Ciphera runs its entire public edge on Bunny, the Slovenia-based CDN and DNS provider. This site, Pulse's marketing pages, our documentation — all of it is delivered through Bunny's network. And on 23 July 2026, Bunny's HopStart Cohort #3 winners announcement put $25,000 in credits behind that choice, with Ciphera placing second. The news is nice. The reason the two fit is the actual story.

In short

Ciphera's entire public edge — this site, Pulse, the docs — runs on Bunny, the Slovenia-based European CDN, because infrastructure jurisdiction is a privacy decision, not a performance line item. Bunny's HopStart Cohort #3 has now put $25,000 in credits behind that choice. It isn't a signed partnership; it's the network we already run on deciding to back a small European privacy company, and a concrete look at how far a European stack goes today: an EU-operated edge and DNS, with customer data and backups in Switzerland.

Updated 18 October 2026: we retitled this post and dropped the claim of a fully European stack. Our websites now run on Bunny Magic Containers in about 42 regions, and customer data and backups stay in Switzerland.

We Were on Bunny Long Before HopStart

Bunny isn't a relationship we picked up chasing a credit program. It's infrastructure we were already standing on. Every public Ciphera surface — this website, Pulse's marketing pages, our documentation — runs through Bunny's CDN and DNS, and has for months. We wrote about why we chose Bunny back in March, well before this cohort entered the picture.

The reasoning then was straightforward, and it's the same reasoning that makes the fit worth writing about now: Bunny is headquartered in Slovenia, an EU member state, so GDPR applies to it natively instead of through a bolted-on Data Processing Agreement with a US parent. For a company built on the idea that infrastructure jurisdiction is a privacy decision — not just a performance one — that mattered more than any feature checklist.

Two Companies, One Bet

Ciphera is a Belgian company. GDPR isn't a compliance layer we bolt on top — it's the legal environment we operate in by default. Choosing a CDN and DNS provider that shares that footing, rather than a US company with a European sales office, follows the same logic that put our data in Switzerland and our authentication on OPAQUE. Sovereignty isn't a slogan on a page; it's a list of vendor decisions, made one at a time, that either hold up under scrutiny or don't.

Bunny made the same kind of bet from the other side of the wire — building a genuinely European edge network at a time when "the CDN" was a synonym for a handful of American giants. So when HopStart came around, the fit wasn't a stretch to explain. Cohort #3 recognized Ciphera, a Belgian software company making privacy-first software. Its one product is Pulse, the analytics tool we built because we didn't want to choose between having good traffic data and respecting the people generating it. Pulse doesn't set cookies, doesn't show a consent banner, and doesn't start sampling your data once you cross an arbitrary event threshold. The tracking script is about 3 KB gzipped. You can watch it running right now in the Pulse demo — no account required.

None of that works without fast, reliable edge delivery underneath it. That's Bunny.

Ciphera's founder: "We're genuinely grateful to the Bunny team — not just for the credits, but for backing a small European privacy company the way they have. We chose Bunny long before HopStart because we believed a fully European stack was worth building on; having them turn around and invest in Ciphera means more than the placement itself."

Where the Credits Go

Practically, the $25,000 in Bunny credits does two things. First, it goes toward making Ciphera's edge delivery even faster worldwide — Pulse's tracking script and dashboards already ride Bunny's global network, and there's room to push that further for visitors outside Europe without giving up anything on the jurisdiction side. Second, it funds evaluating more of Bunny's edge platform, storage and edge compute included. Between 15 August and 12 September 2026, the Ciphera website, documentation, help centre and status page moved onto Bunny Magic Containers, which runs them in about 42 regions. Customer data and backups stay on servers in Switzerland.

We're not going to dress this up as more than it is: it's a credit award and an ongoing infrastructure relationship, not a signed partnership. But that's exactly why it's worth pointing at. Anyone building privacy-first software eventually hits the same question: how far can a stack really be European? Bunny fronting Ciphera's CDN and DNS, and now backing Ciphera through HopStart, is one honest answer. The edge and DNS are run by an EU company, and customer data and backups are on servers in Switzerland. It is also fast enough to build a product on.

If you're curious what a cookie-free, GDPR-native analytics stack actually looks like running in production, the Pulse demo is public. No signup, no sales call — just the dashboard.