One of the issues with building a security application that requires a high degree of user trust is resistance. Users are savvy, and have every right to be cautious when using your system.

My tool, Ward, is a browser extension that analyzes page content to detect phishing and scams. The challenge: we need to send text to an LLM backend without knowing which user sent it.

Given the track record of data breaches and privacy violations from small companies to large mega-corps over the past decade, it’s crucial to consider privacy as a foundation to your application. In this article, I’ll discuss how we implemented a version of Cloudflare’s Privacy Pass protocol for Python and Web.

Trust is not given; it’s earned.

Log as little user data as possible

Still collect required text inputs (URL, page content, etc.) for our LLM-powered backend

Our objectives were simple: We wanted to log less data. Unfortunately, given that inputs to LLMs are simple text, there was no way to obfuscate this all the way to the point from User API request → LLM input. So we had to get creative.

The solution?

We needed a cryptographic solution that when audited could stand up to our goal of being non-reversible.

An easy way would be to give every user the same auth key. But this wouldn’t hold up to attackers who wanted to abuse our system, and would destroy any monetization model. We had to think outside the box.

We came up with the following model. It consists of the client requesting a batch of signed tokens at once (100+) which can be redeemed later on anonymously. We use Firestore for storing our quota information for low latency.

Client generates a 256-bit random token t. 1.

Client hashes and pads *t *to create message m. 1.

Client blinds *m *with a random factor r. 1.

Client sends blinded token and installId identifier 1.

Server checks installId and quota for issued tokens 1.

Server signs the blinded token with standard RSA and sends to client 1.

Client unblinds token 1.

Client stores newly issued anonymous tokens locally

Client sends URL + page content + anonymous token 1.

Server checks token not spent (to avoid a race condition) 1.

Server marks token as spent 1.

Server processes scan and returns result to client.

Importantly, we chose to not roll our own crypto implementation, which can introduce flaws if overlooked (we’re not math experts, after all!).

Chrome (JS) → We used the web crpyto API crypto.subtle.digest, built into the browser which provides SHA-256 hashing out of the box.

Backend API (Python) → We used the standard library cryptography for RSA signing.

The blinding factor r is the "blinding factor" that cancels out during unblinding. It’s:

Generated randomly on the client: crypto.getRandomValues(rBytes)

Never sent to the server

Used to unblind locally: s = s' × r^(-1) mod n

Without r, the server cannot link blinded_message (seen at issuance) to token (seen at redemption).

Even if the server stored every blinded token at issuance, they still cannot deanonymize users.

We’ve accounted for common attacks by using:

jittered refreshes

batch size fingerprinting

random token usage order usage

We RSA over ECC (Elliptic Curve) for simplicity: Blind RSA is just easier to implement in standard libraries.

Most services on the web are not built to be privacy-first, and use the common one API key per user, or protocols like OAuth2 which are not blind.

This practice enables data collection that is often not needed outside the scope of the service - for advertising, marketing, tracking, and more.

If you’re architecting a new service, think strongly about the privacy guarantees you make to users and whether you can pursue a blind signatures model.

There’s not enough open source user privacy resources out there, especially for Python. If anyone reading this wants to collab, drop me a line!

https://github.com/cloudflare/blindrsa-ts

https://developers.cloudflare.com/waf/tools/privacy-pass/

This was the inspiration for this model in Ward. Cloudflare has really led the pack on user privacy research recently, and was an excellent reference.

Caution, it’s TypeScript-only.

This architecture is standard today in Ward, starting with version 1.2.0 that we released this past week! You can try it out yourself in our extension.

This redesign represents a massive shift forward in Ward’s privacy posture, but there’s still more work to go.

We’re exploring methods such as OHTTP Relays using Cloudflare or Fastly that also will make our backend blind to the user’s network request by routing through a managed proxy service.

We’re tightening our privacy policy to be more transparent and consistent with the data we collect.

We have an exciting announcement coming soon regarding a solution that scans other Chrome extensions for detailed threats, natively integrated into the Ward platform.

Are you considering a similar approach? Drop me a comment here or feel free to reach out directly: cedric@tryward.app!

No posts