Earlier quoted context omitted.
> I tried to encourage Troy to suggest to implementors that blacklisting all passwords was a Bad Idea. Instead, he doubled down > Please don't use the entire list for blacklisting unless you actively also guide the user in how to generate a random passphrase (if a human must remember it) or a random password (if it will be stored in a password manager). I think he did the right thing, and think you are correct as wel…
As a corpus to download for password research, this is indeed useful. But for providing a blacklist -- his stated purpose - it is not. The crucial tell: his API does not allow the implementor to specify a frequency threshold (by top X in the list, or by Y number of unique uses of the password or higher). By both API and explicit language in the announcement, he is promulgating the idea that checking the entire blackl…
Yes it does. The output contains the number of matching passwords. It's just client side instead of server side. The reason for not doing so on the server is also obvious taking into account his explanation of cost and caching, which informed much of the API design itself.
> By both API and explicit language in the announcement, he is promulgating the idea that checking the entire blacklist is useful
Because the entire blacklist is useful. He's given all the relevant information to the client to do with as they may. It's up to them to choose how to utilize it. I'm not sure why you seem to think some narrower use case is necessarily better, using end use cases as arguments, given it's an API and needs a client implementation fore being usable anyway.