[ajanuary]

I've had an idea floating around my head:

The site implements an api which describes what data it needs to perform the check, and the standard would be to accept hashes of the data.

There are then sites that provide a UI over the api. The user can point it to the api URL (they can also allow it to be specified in the URL so it can be linked to), it performs the hashing client side and makes requests to the API.

The worst the people providing the api can get is hashes, and people can check the source for the UI to verify it isn't siphoning off data.

Because the UI is decoupled from the data leak, there is less code to check.

[nezza-_-]

Yeah, but it's still easy to do mistakes this way. For instance, the keyspace of phonenumbers isn't really large, so just hashing wouldn't help much against someone trying to get phone numbers. With e-mail addresses it's a bit better I guess.

A client-side, bloom-filter based solution would be nice IMHO. You would get either a definitive "No, your data wasn't leaked" or a "Your data was very likely (xx% possibility) leaked."

This all still doesn't help non-technical people decide whether a site can be trusted though :)