Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy: Don't not collect names & Twitter handles #171

Open
vietlq opened this issue Jul 18, 2018 · 6 comments
Open

Privacy: Don't not collect names & Twitter handles #171

vietlq opened this issue Jul 18, 2018 · 6 comments

Comments

@vietlq
Copy link

vietlq commented Jul 18, 2018

It's the best to capture a secret field where people can put whatever they want or pre-generate a 16 digit/char PIN/code

@makoto
Copy link
Owner

makoto commented Jul 18, 2018

BlockParty is an event management system and majority of the case we do need to collect name for building security purpose.

Twitter handles is collected so that we can notify users.

We are planning to start collecting email, name, and twitter handles as part of the registration system and keep it offline (aka storing on normal dbms). Once that's done, probably we just ask people to sign transaction and turn the digital signature into QR code which admin can scan.

Please let me know if you can think of other alternatives.

@vietlq
Copy link
Author

vietlq commented Jul 18, 2018

You can collect those data and Merkelize them. The register function needs only Merkle proof to keep the gas cost consistent & predictable. Users should only sign on the Merkle proof, and not on variable sized input data.

@makoto
Copy link
Owner

makoto commented Jul 18, 2018

How do you collect the data to construct the Merkle proof if register is the first function user interact with BlockParty? Would you mind describing end 2 end flow specifying which part is on chain, and which part is off chain?

@makoto
Copy link
Owner

makoto commented Jul 18, 2018

Also, it would be a good idea to let event organiser to decide whether they want to collect personal info or not. For some casual dinning event, they don't really need to collect any info as long as they can proof the registration.

@vietlq
Copy link
Author

vietlq commented Jul 18, 2018

  1. User enters name, twitter (off-chain)
  2. User clicks Submit (off-chain)
    2.1. Name & twiter & random seed are sent to the company (off-chain)
    2.2. Name & twitter & random seed are mekelized (off-chain)
    2.3. Merkel proof of name & twitter & random seed to be signed with Ethereum browser (on-chain)
  3. On the event day they user just presents his/her name/random seed and the company can verify & enroll (off-chain & on-chain)
  4. On the refund, the user can claim without seed (on-chain)

The seed can be any random 16 chars/num to avoid collision of users who have the same name but both have no twitter. The seed can be generated by the service when loading the web page and user should not be able to change it. I have done similar thing using UUIDv4 on server:

https://github.com/vietlq/enki-login/blob/master/enki-login-app/controllers/mongodb.ts

@vietlq
Copy link
Author

vietlq commented Jul 18, 2018

For some casual dinning event, they don't really need to collect any info as long as they can proof the registration.

That's exactly why we need random seed. UUIDv4 is standard and user-friendly. It can be hashed/merkelized without or with empty name/twitter.

Simple way to get hash data that is reproducible from organiser's DB: HASH(version || HASH(name || twitter || UUIDv4)). The same data is hashed, signed & hash is published to the chain by the attendees. Everyone can verify signed hash without revealing private info to 3rd parties! Works well even with name & twitter empty. No encryption required and no more fluctuating gas costs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants