Its a multistep KYC aka proof-of-life, the wallet code is open and already up. Yesterday there was an interview of Dan and he explained that its not about knowing the person, but knowing that there is one person behind multiple accounts. There will be also the possibility to anonymously interact with the blockchain. You can also have multiple accounts. E.g if you have a business. But you cant benefit from UBI and this is only fair. The UBI and the voting is for users.
Voice is not only a front-end. You can also implement it into blogs and websites. Steem needs to know its unique selling point.
Exactly. This is a common misunderstanding. What they have done is create a system that takes the biometric information etc. of a person and calculates a unique hash of that data. If the same person tries to use another identity, there will be a mismatch between the biometric data and other data. If they try to use the exact same data, the system will know that that particular hash is already tied to a certain account.
great explanation. I think this is in a few sentences, how we can >>maybe?<< solve the problems Steem has.
I should add that they have to calculate several hashes, each from the different parts of the multi-layered identification system.
Just for clarity, I think trusting that system is another thing. If it's open source, it can be verified to do just that. But if it's not, there is no telling whether or not it is going to harvest sensitive personal data.
the new EOSIO Reference Authenticator is open source and the code is now on git-hub. AFAIK they use face lock but I guess one can combine all possible inputs.
The crypto-hardware in smart devices and wallets like the secure enclave processor is closed-source and it's in the best interest to the chip company (ARM) or the smartphone company that there is no leak.
It can be done decentralized with homomorphic encryption etc but there is great risk to adding your biometric data to any blockchain in an unencrypted or even encrypted form. Do we know the code is reliable enough or that the SGX or secure execution environment is that safe?
I'm not saying I would not use it but I would proceed with the same caution that I would with a centralized exchange.
You're right about the need for caution. If only a hash of the data is saved on chain, then it should be safe. I wouldn't want my fingerprints or personal data on any blockchain, encrypted or not. A hash of my fingerprint data, yes, provided that it the hash function would be good enough.
Of course, that code needs to be checked to see that it does what it is supposed to.
When something is hashed with sha256 and your unconfortable, this is just your preference being unconfortable, because 2^256 possible combinations means an attacker has to try as man combinations as the earth has grains of sand on its beaches and deserts and if those grains of sand would be earthes itself with grains of sand on it and you sum up all the grains, than you have the amount of cominations.The probability to get a collusion is zero.
Most of us have given away their identity (real identity not just a biometric) for an steemit account. At least here i n Europe due to "anti-terror regulations" your phone number is associated with your full ID. And this phone number is saved on the server of steemit.inc.
It's more complex than that. The challenge of cryptography actually isn't and never has been simply developing unbreakable codes by way of theoretically (or practically) proven algorithms. The problem is who and what can you trust to properly implement those algorithms to specification? Cryptography has to be used not merely be a pretty algorithm on a chalkboard somewhere.
The US Military does not trust random chip makers in China. The Department of Defense for example relies on the Trusted Foundry Program which are a list of trusted hardware suppliers. People in the crypto community in my opinion naively seem to think that because something is "decentralized" that it automatically makes it more trustworthy. I have seen people for example mention that they don't trust the secure execution environment but then these same people may in fact then trust some random programmers writing smart contracts in a new programming language like Solidity or a notoriously difficult to check programming language like C++.
As much as I like EOS and do tend to trust the majority of the code the simply fact is that if you are using EOS Voice it is because you trust the judgment of Dan Larimer and the team of programmers he is leading. How much should you trust these programmers? To be honest in the crypto community I would say that Dan Larimer and his team of programmers are more trustworthy than most but then there is always a limit to how much trust you can give to any untested source code.
Biometrics are notoriously high risk information to upload for a variety of reasons. There are some good reasons why people don't want to attach their biometric data to a blockchain even if somehow it's done via homomorphic encryption or is done as a hash. I think when you refer to hash you are referring to the hash table approach to doing it which I'm familiar with as a general approach but there are many possible ways to do it.
The fact is, this is very sensitive information, and I'm not entirely sure right now that I could sign off on the implementation. I have to learn more. I'm not someone who is against using biometrics as I've been looking at this since speaking about the Enigma Protocol years ago on Steemit but I also know it's going to be hard to do (because I gave it much thought myself).
Where is the biometric data stored and how? There is risk here.
I don't think the data itself even needs to be stored, only a hash of it. Or hashes of its separate parts.
There are many ways to do it but for the most part doing this safely is going to be a major technical challenge. It is not trivial. If they pull it off then we all can learn something.
One thing that concerns me about it is whether or not the developers have anticipated the potential introduction of vastly more powerful computing architectures than what we have today. For instance, what if large scale quantum computers because feasible in the next 20 years? Would be it be realistic to think that the biometric data stored by Voice could be cracked using quantum computers?
I think brute force is the least likely approach to cracking algorithms if they choose the right ones. I think it is more likely statistically that you'll see a hardware failure or developer failure than some brute force cracking even if there is 30 or 50 years effort. But this is just my opinion.
In this case I have to reserve judgment until I see the code and use the platform. If they can strike the perfect balance then they could beat Facebook and Steem. Steem is dangerously transparent and Facebook is dangerously centralized.
In that case maybe it can work based on what you say. I think it's a problem if people cannot speak off the record. If people can speak off the record then all the problems I mention in my posts can be resolved by that capability.
The only way to have free speech is to give people an ability to communicate off the record.