This blog is part of the project Reciprocal ecosystem for citizen science where we prototyped a survey system that rewards respondents after filling in a survey and was written by Winfried Tilanus.
Sometimes you don’t want to know..
Maybe because the ethical review board of your university says you may not store identifiable data with your dataset. Or because you don't want to risk a fine for illegal processing of data. Or maybe the burden of storing and securing the data is too much of a hassle. Or maybe because you think some information about your users is really none of your business.
Payment information typically is such a piece of information: you need it to make a payment, but you don't want to know it and don't want to store it. You can only get into trouble with it. So when we were building the cashlink system for submitting (citizen science) surveys and similar cases, using interledger and payment pointers, we asked ourselves: how can we pay people and know as little as possible about the payments?
Totally zero-knowledge is impossible in this case: you need to be able to give an answer when a user calls to ask where their payment is or when your accountant wants to check where the money went. But you definitely don't want a database with STDs people had over the last year linked to their payment wallets.
So we separated. We separated all the sensitive stuff the survey may or may not be doing from handling the payment. The payment is handled by a small separate service, the cashlink service, that is called by the survey. And of course the cashlink service needs to know it really should pay the user and how much. All verified so no fraudulent action is possible. And the cashlink service, well it should just ask where to send the money to, no further questions asked.
So how did we do this? Well, the system is a nice interplay between the survey website and cashlink, a stand-alone payment service. While setting up cashlink, we create an asymmetric key pair, one key for the site and one key for the payment service. And both are kept secret.
So when the survey wants to pay me €2.50 as reward for something I did, it creates a token that says: "somebody has earned €2.50". Great, but here the fun starts: the survey adds to the token a random identifier for this payment. That random identifier can be logged in the server logs. The token is then encrypted with the key the survey received earlier on while setting up cashlink. Next that encrypted token is included in a HTTP request my browser makes to the payment service. Because the payment service has the other key (and both keys are secret) it knows it is from the survey and it is not tampered with. Now the payment service logs the random identifier and asks the user for a payment pointer. Once entered cashlink does the payment and it also logs the payment pointer.
So what is the result? The user gets their money, the survey knows it has sent the payment to cashlink, but knows nothing else, cashlink knows it has made the payment. It is possible to follow an audit trail, but only by combining two different log files from two different services. Both need to be compromised for the information to leak. Or the person checking the audit trail needs to deliberately combine both log files.
So if you don't want to know, you won't know.
Top comments (0)