eliawk
commented
7 years ago We are now in scenario number [ 1 ], and we are trying to move to the [ 3 ]. in my opinion the [ 2 ] is two complicated for the user (he have to use tow password for the same application, not easy to understand the difference) and the [ 4 ] is not a option!
jellegerbrandy
Premiss:
There are several ways of presenting this to the user - it is a tradeoff between giving the user control or having the user trust the player with his money.
when to ask for password
The player handles the keystore. Period. We never ask for a password to open the keystore (we might check if the user is logged in). This is basically how we (plan to) handle anonymous acccounts, cf #105. In practice, this means that the player (or the meteor db) knows the password of the keystore - and this represents some security risk for the user. (Not that big: an attacker needs access to the keystore file itself to steal the money).
The user is asked explicitly for the password at the beginning of the session, to unlock his keystore. The keystore is then unlocked an available to the app/ This presents some friction to the user - he needs to input his pass every time he watches a video
The user is asked for a password to authorize batches of payments, something like "authorize the player to transact with 10 PTI". Such a logic makes sense in a scenario where we use payment channels: i.e. the keystore holds the money safely, and the payment channel is controlled by the player, and the user authorizes the transfer of money from the keystore to the payment channel.
[just mentioning this point for completeness]: The user is asked to confirm each single transaction. This is what plugins like metamask and parity do. This is, for us, clearly not an option - the user needs in any case to trust our player to handle the money in his account.