deso-protocol
Node owners can fetch PII for Jumio verified accounts
Previously the verification info returned from Jumio (ID scans urls, liveness image urls, name, dob, address, etc) was being directly stored in userMetadata as part of the Jumio callback. This was changed in #105 so that the info is no longer being directly stored, but the JumioTransactionID (which appears to be a Jumio scan reference) is still being stored in the userMetadata here: https://github.com/bitclout/backend/blob/07676b2a874d7c37dd3a1bc8f4679f5621b46cbf/routes/verify.go#L805
It seems this Jumio API can be used to fetch this same info given a scan reference and Jumio API secret, both of which the node owners have access to. Is this intentional?
Since it is the node owner providing the funds for this verification bonus (right now not aware of anyone outside of bitclout.com / identity.bitclout.com doing this) I suppose it is within their rights to be able to look up this information, but I would like to hear about if the intent is for this to be a temporary measure to help debugging abuse while this rolls out or something that is intended to stick around long term (for KYC compliance or other reasons). Both seem potentially reasonable, but In either case it seems like this should be called out as part of the verification flow, or at the very least on https://docs.bitclout.com/faq/privacy-and-security so that users are aware of the transaction they are making.
As it stands right now I feel a bit uncomfortable verifying my account without this being addressed, and feel especially uncomfortable about onboarding users and recommending they verify, be it directly on bitclout.com or as part of any app I might build on the network that wishes to take advantage of "gas on the fire" bonus to attract new users.
Also. I considered opening this as a CIP discussion but it seems worth first understanding the intent of what has already been implemented before diving into any specific discussions about changes or alternatives.
This is a great catch. Huge thanks for continuing to research Jumio-specific privacy concerns @netpro2k! I'm sure, as with the metadata changed in #105, this isn't intentional, however, if the Ref. can't be used as a uid, what could be used in it's place that doesn't have the ability to fetch this data?
The transaction ID is not actually used anywhere as far as I can tell apart from storing it. https://github.com/bitclout/backend/search?q=JumioTransactionID
The actual check for duplicate verification uses some other properties from the callback but not the transaction id https://github.com/bitclout/backend/blob/main/routes/verify.go#L795
I previously pointed out that this uniqueJumioKey was using a piece of possibly sensitive information as well (the document id number) but am not really very concerned about that anymore since its not being linked with an account anymore, so it's not particularly meaningful.
With the release of referrals and apparent sharing of global state with diamondapp.com (a third party) this issue seems now even more pressing. I would very much like to onboard people, but really don't feel comfortable doing so without this being addressed.
Again not calling for this info not to be collected necessarily, just to understand why it is being collected and what goes into decisions to share it with other parties such as diamondapp.
