> Normally, it is undesirable for users’ passwords to be cracked. However, in the case of law enforcement, we often need to obtain suspects’ passwords in order to access encrypted evidence. The obvious solution is to build powerful (and expensive) dictionary cryptanalysis computers. A less obvious approach is to use the distributed power of web users’ computers, as has been done in the Seti@Home (https://setiathome.berkeley.edu/ — suspended project) or Folding@Home projects (https://foldingathome.org/). The proposed approach can therefore support law enforcement activities while providing the desired functionality to the web community

"You're not allowed to visit this website unless you submit your computer to being part of the fed's password cracking botnet" that's a whole fresh hell. A better use case is right there in their own description! I'd love my captchas to be little Folding@Home problems.

Can't we just submit bogus hashes?

Generally that is countered by asking for a mix of known and unknown solutions; your accuracy on the unknown is assessed through your accuracy on the known.

Is it possible to do some other sort of cryptographic trick than simply seeding the mix with known and knowns. Some sort of sum of many answers combined? Maybe it isn’t possible in this use case though (brute forcing passwords). For example is crypto POW really just doing a mix of known and unknowns or is there more cryptographic magic to it than that?

But there are only a few suspect passwords, you can just know all of them, and thus reliably differentiate.

That is shady as hell. Welp this is dead on the vine

Bitcoin network used to bruteforce 85 bits per year, which is slightly bigger than capacity of [a-z0-9]{16}

btw no, cap does not contribute to any "fed botnet". you can build the WASM binaries yourself and compare the hashes. added a clarification about that to the docs.

2030: to enter the site you must allow us to mine few ethereal on your pc...

You better not show me any ads if you want my system to make some crypto for you then.

We’ll, who am I kidding

Then the ads and the crypto and the blood sample testing for genome stealing it is

Interesting discovery. This research sounds creepy and ill-advised, but my intuition suggests to me this is an innocent attempt to do something useful rather than waste energy on a PoW algorithm. My intuition also tells me that if this project became popular enough, attackers would break the algorithm fairly easily and the project would just revert to a more conventional PoW algorithm that doesn't try to be smart.

Wasn't there a crypto that use GPU to solve LLM computation as PoW. Wouldn't that be better approach?

Definitely concerning, although I'm having trouble finding anything in the codebase to support this.

This paper even seems to contradict aspects of the project's no tracking stance. If someone told me this paper was for a different (but similar) project, I'd believe it after looking at the two side by side.

Would definitely want this to be addressed before I'd consider using it.

There are two binaries commited to the repo (cap_wasm_bg.wasm) but from what I can tell, it doesn't seem to be making any network calls or what have you. They still should get rid of them and add a Rust build step for their browser/node packages.

Can you elaborate on why you would want this? You can run their build script[1] if you're trying to compare outputs and behavior.

[1]: https://github.com/tiagorangel1/cap/blob/main/wasm/build.js

you can compare the hashes of the wasm lmao the build script is very much public

It's not a good practice to commit binary blobs in a repository. And I don't think it would be difficult to add a prepublish step to your npm packages so that you can remove them. The end user shouldn't need to run the build script and compare hashes whenever the source code changes.

Very surprised to get pushback on what I thought was an industry standard lmao

feel free to make a pr to add a worker, currently not my first priority tho

I think there's a good chance they just linked to the paper for technical background, unrelated to the paper's mention of law enforcement usage. The website mentions self-hosted, no third-party requests, etc. Unless they're flat-out lying.

Yes, the code is open-source for you to check

Cap does not send any of the calculated hashes ANYWHERE, the white paper just details a bit how proof-of-work works and I thought that it would be interesting to share.

added a note saying that to the docs, should hopefully clarify stuff a bit!

In case you weren't aware, a blue hat is typically associated with law enforcement in the US. On its own it'd be no problem, but the logo, the paper, and the comment above correctly pointing out concerns/lack of acknowledgement on your site (until now) really comes off as suspicious.

FWIW, I do believe you just made a few unintentional awkward choices instead of being malicious... But a product associated with something like this is a hard sell.

> a blue hat is typically associated with law enforcement in the US

what it's literally just the default emoji for cap

> lack of acknowledgement on your site (until now)

i've added a note