Privacy stalwart Nicholas Merrill spent a decade fighting an FBI surveillance order. Now he wants to sell you phone service—without knowing almost anything about you.
Can someone with experience doing ZK Proofs please poke holes in this design?
One doesn’t need to know about zero-knowledge proofs to poke holes in this design.
Just read their whitepaper:
You can read the whole thing here but I’ll quote the important part: (emphasis mine)
Double-Blind Armadillo (aka Double Privacy Pass with Commitments) is a privacy-focused system
architecture and cryptographic protocol designed around the principle that no single party should be able
to link an individual’s real identity, payments, and phone records. Customers should be able to access
services, manage payments, and make calls without having their activity tracked across systems. The
system achieves this by partitioning critical information related to customer identities, payments, and
phone usage into separate service components that communicate only through carefully controlled
channels. Each component knows only the information necessary to perform its function and nothing
more. For example, the payment service never learns which phone number belongs to a person, and the
phone service never learns their name.
Note that parties (as in “no single party”) here are synonymous with service components.
So, if we assume that all of the cryptography does what it says it does, how would an attacker break this system?
By compromising (or simply controlling in the first place) more than one service component.
And:
I don’t see any claim that any of the service components are actually run by independent entities. And, even if they were supposedly run by different people, for the privacy of this system to stop being dependent on a single company behind it doing what they say they’re doing, there would also need to be some cryptographic mechanism for customers to verify that the independent entities supposedly operating different parts were in fact doing so.
In conclusion, yes, this is mostly cryptography-washing. Assuming good intentions (eg not being compromised from the start), the cryptographic system here would make it slightly more work for them to become compromised but does not really prevent anything.
The primary thing accomplished by cryptography here over just having a simple understandable “we don’t record the link between payment info and phone numbers, but you’ll just have to trust us on that” policy is to give potential customers a (false) sense of security.
If a payment processor implemented this (or some other anonymous payment protocol), and customers paid them on their website instead of on the website of the company selling the phone number, yeah, it could make sense.
But that is not what is happening here: I clicked through on phreeli’s website and they’re loading Stripe js on their own site for credit cards and evidently using their own self-hosted thing for accepting a hilariously large number of cryptocurrencies (though all of the handful of common ones i tried yielded various errors rather than a payment address).
Stripejs is PCI compliant via tokenization. That is to say, your PII does not touch the merchant’s site. The only thing the merchant sees is random placeholders.
One doesn’t need to know about zero-knowledge proofs to poke holes in this design.
Just read their whitepaper:
You can read the whole thing here but I’ll quote the important part: (emphasis mine)
Note that parties (as in “no single party”) here are synonymous with service components.
So, if we assume that all of the cryptography does what it says it does, how would an attacker break this system?
By compromising (or simply controlling in the first place) more than one service component.
And:
I don’t see any claim that any of the service components are actually run by independent entities. And, even if they were supposedly run by different people, for the privacy of this system to stop being dependent on a single company behind it doing what they say they’re doing, there would also need to be some cryptographic mechanism for customers to verify that the independent entities supposedly operating different parts were in fact doing so.
In conclusion, yes, this is mostly cryptography-washing. Assuming good intentions (eg not being compromised from the start), the cryptographic system here would make it slightly more work for them to become compromised but does not really prevent anything.
The primary thing accomplished by cryptography here over just having a simple understandable “we don’t record the link between payment info and phone numbers, but you’ll just have to trust us on that” policy is to give potential customers a (false) sense of security.
If they use a payment processor, doesn’t that become the second service component?
If a payment processor implemented this (or some other anonymous payment protocol), and customers paid them on their website instead of on the website of the company selling the phone number, yeah, it could make sense.
But that is not what is happening here: I clicked through on phreeli’s website and they’re loading Stripe js on their own site for credit cards and evidently using their own self-hosted thing for accepting a hilariously large number of cryptocurrencies (though all of the handful of common ones i tried yielded various errors rather than a payment address).
Stripejs is PCI compliant via tokenization. That is to say, your PII does not touch the merchant’s site. The only thing the merchant sees is random placeholders.
So it sounds like this might work, then?