3
One human, one account, without an orb: how SOV Network does proof of personhood (open source, live, try it) (lemmy.world)
submitted 3 days ago* (last edited 3 days ago) by to c/privacy@lemmy.ml
4 comments fedilink hide all child comments
 

Disclosure: I'm one of the developers. SOV Network is open source (Apache-2.0), live and working today, and I'd love this community to try it and give honest feedback.

Proof of personhood usually means a company scanning your eyes with custom hardware and keeping the result. SOV Network takes a different route. Here is exactly what happens.

On your phone: you enrol with a palm scan and a live face check using your own phone's camera. No photo of your palm or face is stored or sent anywhere. The app turns each scan into a set of numbers describing it (a feature vector, not a picture) and sends that over an encrypted link.

On the network: the node turns those numbers into a protected (cancelable) template and stores only that. Nodes compare templates for one purpose: making sure one human has exactly one account. There is no picture of anyone on the network.

Messages: end-to-end encrypted. Joining needs no phone number and no email. Nodes refuse plaintext and keep no message content; if the recipient is offline, the message waits on the sender's own device. For delivery receipts a node keeps a small record (message ID, two pseudonymous IDs, type, time) that deletes itself after 90 days by default, and citizens can vote that down to 7.

Proven on the live network: enrolment across nodes, wallet restore, signed payments, a simultaneous double-spend refused by the nodes, cross-node messaging, the built-in exchange, the inheritance Vault and citizen votes.

Next on the roadmap: liveness verified by the nodes as well as the app, the template key split across independent operators, and more operators joining the founding servers. The whitepaper covers the full design and threat model.

Try it (Android, Windows, macOS, Linux): https://sov-network.github.io/ Whitepaper: https://sov-network.github.io/whitepaper.html Source: https://github.com/sov-network-dev/sov-build-source Questions of any kind are welcome here or in our public Q&A: https://github.com/sov-network-dev/sov-build-source/discussions

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 days ago* (1 child)

Can the feature vector be used to identify someone if it escapes somehow? Can it be fooled by images constructed from surveillance video? Overall I'm skeptical but it's interesting.

I had a scheme a while back to turn anonymous nonprofit cash donations into login credentials, or you could just collect the cash yourself to help fund your service. Person would enter the serial number of a 10 dollar bill when they enroll an account on your server, and either send you the bill by snail mail, or send it to a participating nonprofit (the FSF was at one point willing). The nonprofit would receive the bill, accept it as a donation, and post the serial # someplace on their web site. Once you saw the ser# appear there, you'd activate the account.

If the person abused the account and got banned, they could re-enroll the same way, but it would get expensive after a while. I had a domain for this but eventually let it expire. We referred to the scheme as a "money-burning service".

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 1 day ago

    Good questions, and I like the money-burning idea: it's honest about what it does.

    Feature vector escaping: nodes never store the raw feature vector. The phone sends it over an encrypted link, and the node turns it into a protected (cancelable) template and keeps only that. A stolen template on its own is scrambled numbers. As detailed in the whitepaper, today the key that scrambles them is held by the full nodes (currently the project's own servers), so a compromised node could unscramble its templates back into feature vectors. Never a photo, but a feature vector could in principle be compared with the same model run on a photo of the same person. That is why rotating the key and splitting it across independent operators are next on the roadmap.

    Surveillance-video spoofing: enrolment needs a flat palm close to the camera plus a live face check where the app asks for a random movement, which ordinary surveillance footage does not give you. Currently, that liveness check runs in the app, meaning a modified app could theoretically bypass it. Server-verifiable liveness is the next item on the roadmap. What the nodes do enforce already: a palm or face that matches someone enrolled is refused, so a person cannot open a second account with their own body.

    Your scheme versus ours: yours makes abuse expensive, which works for spam. We went for one account per person regardless of money, because the same accounts vote on the network's rules, and with a price per account whoever can pay most gets the most votes.

    (I'm one of the developers.)

  • permalink
  • fedilink
  • source
  • parent