Interesting, but it does not solve the core of THE problem: you still need gogol absurd and grotesquely massive and complex javascript-ed engine (including their SDK), aka blink, to create an account, and re-authenticate this account on a regular time-basis. Ok, it is not completely true, you can use mozilla(=gogol sidekick) and apple(webkit) absurd and grotesquely massive and complex javascript-ed engines (including their SDKs) to do the same... because gogol is still not breaking compatibility, yet.
Not really ideal.
There is no solution to this issue, because accounts can be created and re-authenticated via click farms, and that massively, using humans and all the VPNs around the world.
You can sort of mitigate this issue: the process of creating an account and re-authicate must be something long, really long for the user (do warn the user about this and explain why), and that can work with a noscript/basic (x)html browser. Then "work" for the click farms, or blink|geeko/webkit modified engines with AI (and trained via humans in click farms) would sky rocket until it is not worth it anymore.
Now, let's be serious, but really important online services, account creation should not be online, but IRL at a physical office, or it is made for you after ID verification and mailed/emailed/phoned/smsed, or... well you get the picture.
For online shopping there is a middle ground I don't really like: you mail/html form post a demand of account creation with a credit card number, which will be deeply/humanly verified before anything is done. Then after verification, the account will be sent to you like above. What I don't like, this online shop has your credit card number and must be verified by a salary human (which could be a "point of failure") and that defeats the purpose of wallet codes.
The "physical" identification seems to be what's happening in my country. Namely, those accounts are linked to _really_ you.
For all that, you don't need a javascript-ed web engine, you should never and core functionality should work with noscript/basic (x)html browsers.
And ofc, for those "verified" accounts, you can propose a web API (which is not a good excuse not to provide a noscript/basic (x)html portal).
1 comment
[ 4.4 ms ] story [ 13.0 ms ] threadNot really ideal.
There is no solution to this issue, because accounts can be created and re-authenticated via click farms, and that massively, using humans and all the VPNs around the world.
You can sort of mitigate this issue: the process of creating an account and re-authicate must be something long, really long for the user (do warn the user about this and explain why), and that can work with a noscript/basic (x)html browser. Then "work" for the click farms, or blink|geeko/webkit modified engines with AI (and trained via humans in click farms) would sky rocket until it is not worth it anymore.
Now, let's be serious, but really important online services, account creation should not be online, but IRL at a physical office, or it is made for you after ID verification and mailed/emailed/phoned/smsed, or... well you get the picture.
For online shopping there is a middle ground I don't really like: you mail/html form post a demand of account creation with a credit card number, which will be deeply/humanly verified before anything is done. Then after verification, the account will be sent to you like above. What I don't like, this online shop has your credit card number and must be verified by a salary human (which could be a "point of failure") and that defeats the purpose of wallet codes.
The "physical" identification seems to be what's happening in my country. Namely, those accounts are linked to _really_ you.
For all that, you don't need a javascript-ed web engine, you should never and core functionality should work with noscript/basic (x)html browsers.
And ofc, for those "verified" accounts, you can propose a web API (which is not a good excuse not to provide a noscript/basic (x)html portal).