A way to minimize the exposure of personal information using ENS

đź’¬ General Discussion
1

For various reasons, a lot of our personal information has been excessively collected by many people or services for reasonable reasons, which may lead to the abuse of information. We can use ENS to minimize the exposure of personal information and to some extent make it convenient for people. Here is an example to illustrate the idea.

Suppose Alice (alice.eth) wants to buy a hat from ensmerchshop.xyz (Shop) for Bob (bob.eth), the process would look something like this:

  1. Alice contacts Bob in a private message to inquire about his Shipping Address (SA).
  2. Alice orders a hat from Shop and fills in Bob’s SA.
  3. Shop provides the hat and SA together to the shipper (such as DHL).
  4. DHL delivers the hat to SA and Bob got the hat.

In this example, there is one piece of personal information: Bob’s Shipping Address (SA). In the above process, this personal information needs to be exposed to Alice, Shop and DHL, which is obviously a bit overexposed.

First of all, Alice does not need to package or deliver the hat in person, so she does not need to know the specific contents of the SA. She just needs to state that the hat she bought is to be delivered to bob.eth. So we have the 1st solution:

20230418-private-infomation-in-ens-1.drawio
20230418-private-infomation-in-ens-1.drawio2142Ă—1272 227 KB

In the illustration above, the process becomes:

  1. Bob saves the encrypted SA (*SA*) into the record of bob.eth in the App of Shop in advance. (one-time setting, indicated by blue lines)
  2. Alice orders a hat from Shop and labels the recipient as “bob.eth”.
  3. Shop retrives *SA* from bob.eth’s record and decrypts it as SA, then supplies the hat with SA to shipper DHL.
  4. DHL delivers the hat to SA and Bob gets the hat.

In this process, Alice has not been exposed to the specific content of SA.

If we think about it more carefully, it is also unnecessary for Shop to know the specific content of SA, because only DHL, which is responsible for delivery, must know SA. In addition, in the 1st solution, ENS record *SA* of bob.eth can only be decrypted by Shop, which obviously limits the range of use of a record. So we have the 2nd solution:

20230418-private-infomation-in-ens-2.drawio
20230418-private-infomation-in-ens-2.drawio2142Ă—1272 227 KB

In the illustration above, the process becomes:

  1. Bob saves the encrypted SA (*SA*) in the record of bob.eth on DHL App/Api in advance. (one-time setting, indicated by blue lines)
  2. Alice orders a hat from Shop and labels the recipient as “bob.eth”.
  3. Shop provides the hat together with the addressee’s ENS name (“bob.eth”) to shipper DHL.
  4. DHL retrieves *SA* from bob.eth’s record and decrypts it as SA, then delivers the hat to SA and Bob gets the hat.

In the whole process, neither Alice nor Shop had access to the specific content of SA.

Now, we have minimized the exposure of personal information.

While this is a simple example and covers only one scenario, there is definitely a lot of room for improvement in this approach, and many other scenarios could be applicable. That’s it for now, very glad to share my thoughts here.

Sample Code

https://github.com/hibbb/minimize-exposure

4 Likes
2

I think this is a pretty interesting and useful concept. I thought of something similar awhile back. I wanted to figure out a way to send a book to a friend I knew online, but not good enough to ask them for their address to ship them something. I thought it would be neat to be able to order and pay for a gift, and somehow send them a link where they could just input their own address, and have the gift sent that I paid for to them.

I didn’t know anywhere to do this, so it never happened. I recently read Amazon now has some hacky way to do this with Prime gift option.

I think what you designed would work the same way. For illustration #1, using the example of Amazon, I pay for an item and Amazon sends a gift NFT to bob.eth. Bob.eth could log into Amazon proving they owned the gift NFT and are wanting to redeem it for the physical item. When bob.eth signs on his wallet, Amazon would receive the SA address unencrypted.

For illustration #2 to work the shipper would need to integregrate some type of system to pickup the packed item from Amazon(who doesn’t know the SA). The shipper would get the SA by receiving some type of proof /NFT from Amazon, which was generated when bob.eth accepted the gift on their website. Only shipper.eth could decrypt the SA contents.

Instead of using NFTs, would it be possible to use wrapped subnames (which would also be NFTs of course)?

3 Likes
3

Yes, that’s exactly one of the situations what I want to say.

I didn’t know anywhere to do this too :sweat_smile: So I came up with this idea, hoping that there will be applications to solve this problem through ens in the future. And as a web3 identity, ens should not only be able to store fully public information.

Amazon doesn’t need to send a nft IMO, it just need to tell the shipper that the receiver is “bob.eth”, then the shipper could fetch the *SA* from bob.eth’s record and decrypt it. But this solution needs to be driven by an industry to succeed. It’s not that easy. I think it’s just an idea at the moment.

2 Likes
4

Interesting stuff.
Do you guys see any issues with estimating shipping costs at the time of purchase since the SA isn’t yet revealed?
Or, potential issues with availability in certain regions if the destination isn’t known at time of purchase?

5

It does exist in a hacky way… There are drawbacks because one could only do this through Amazon. They’ve built to architecture for it. Using ENS names would widen the availability for othet stores to use a blockchain/ENS architecture.

The purpose of this would be so that bob.eth will confirm he wants something sent to him. Otherwise, it would just come automatically?

These are great points @5pence.eth

6

Right, this is really a practical problem.

It makes sense👍. Maybe I didn’t understand you correctly at first.