Security: Membership Inference, Leakage, and Adversarial Inputs

In one line

A Bloom filter reveals membership to anyone who can query it or download it: attackers can test millions of candidate IDs (enumeration) or check whether a specific person is in a sensitive set. Protect filters like the data they summarise: access control, rate limits, no public distribution of sensitive filters, keyed hashing, and careful API design.

0/4 · 0%

Think of it like this

A club that posts a list of member initials on the door to speed up entry. Anyone walking by can check whether a particular person is probably a member, which is private information in itself.

Key ideas

01
Membership inference: querying "is alice@example.com in the set?" leaks information if the set is sensitive (customers of a clinic, users of a dating app, accounts with debt). False positives give plausible deniability only at high error rates.
02
Filter leakage: shipping a filter to clients (browsers, mobile apps, edge devices) hands attackers an offline oracle: they can test any number of candidates without rate limits. A historical example is Bitcoin's BIP37 Bloom filters for lightweight wallets, which leaked which addresses belonged to a wallet.
03
Enumeration: availability-style APIs ("is this username/email registered?") backed by fast filters make enumeration cheap; rate-limit and return uniform responses where appropriate.
04
Adversarial inputs: if hashing is known and inputs are attacker-chosen, an attacker can craft items that set many bits (pollution, raising FPR for everyone) or that collide with target items. Use keyed hashes (SipHash or HMAC with a secret seed) and validate inputs.
05
Defences: keep sensitive filters server-side, authenticate and rate-limit queries, return consistent response shapes and timing, avoid exposing "definitely absent" signals in public APIs, salt/key hashes, and review who can read filter snapshots in object storage.

Code & diagrams

keyed-hash.javajava

// Keyed hashing: positions depend on a secret, so attackers can't precompute collisions offline.
HashFunction keyed = Hashing.sipHash24(k0, k1);             // k0, k1 from a secret manager
long h = keyed.hashBytes(normalized.getBytes(UTF_8)).asLong();
// derive h1/h2 from two keyed hashes (or a 128-bit keyed MAC), then double-hash as usual.
// Rotating the key = building a new filter version (all positions change).

Interview problem

The problem

A filter of "customers who have an account"

A service uses a Bloom filter of all customer emails to speed up "do you have an account?" checks. An attacker can query millions of emails. Discuss access control, rate limiting, API design, filter exposure, hashing and salting, and authoritative verification.

Explain it without notes

Why is distributing a Bloom filter to clients a privacy risk even though it doesn't contain the items?

Practice

Review one public API that answers membership questions (username check, "forgot password") and propose protections.

Trade-offs

↔
Fast membership APIs are convenient and enumeration-friendly; protections add friction for legitimate users.

Done when you can

I can identify membership-inference and adversarial risks and protect filters appropriately.

Command Palette