BitShares Forum

Main => General Discussion => Topic started by: cn-members on October 29, 2014, 03:06:22 pm

Title: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: cn-members on October 29, 2014, 03:06:22 pm
hello everyone,

Recently members of chinese community had a discussion on how to improve user expeirences of BTS wallet, so that we can introduce it to our friends, especially female friends. During this discussion, many people have proposed many good suggestions, especially jerry (aka J-God). So we decided to collect these suggestions and propose it here.

To increase readibility, we summed it up into a mind map (below). Same content  will also be presented in text after this figure. So you can choose either way you like.

(http://www.tu265.com/di-c780683a188f7b021bdc23a80a4c1275.png)


Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences

1. While releasing new version of BTS wallets
Current Status:
- Because of the 'special networking environment',
the downloading speed of github could be extremely slow or unstable
- The downoaded files could be broken if the network is untable
Suggestions:
- While new versions of BTS wallet binaries is released,
their SHA checksums should be posted in github site at the same time
- people in china can share with each other
- I3 or some of us can setup mirror sites
- files can be easily downloaded and check the SHA checksum posted in the github, so we can make sure that files are not modified/broken
- While the built-in function of wallet detects a new version of wallet,
it should also provide the link to BTS wallet download page, so we can conviently check the changelog and download new binaries.

2. Windows version BTS wallet
Current Status:
- 32bit and 64bit installers are sepatated, which makes people feel confused.
Suggestions
- a unified installer should be provided for windows,
and the installer can automatically detect the OS is 32bit/64bit.
- If 64bit installer is still unstable, please address this point so that users can make their choice.

3. While installing BTS wallet
Current Status:
- current installer can only specify the path of wallet programs to install
- the path of wallet data can not be specified
- the default path in windows is inside a hidden folder = > inconvenient to use. Furthermore, if the system failed (e.g., c drive partition error, accidentially formated), the wallet data could be lost
Suggestions:
- installer can let users to choose the path of wallet data
- if the installer detected that there are partitions other than c drive,
the default path of wallet data should not be in c drive
- the default wallet data path should not be inside of a hidden folder

4. Layout of GUI wallet
Current Status:
- While entering passwords in lock screen,
the screen does not show that whether the Caps Lock is open
- the internationalization is not complete (chinese interface), only the messages from web wallet is translated
- messages from bitshares core program is not translated
- messages from qt framework is not translated
- e.g., main menu,  status bar in the bottom
- e.g., 'Block are synced' should be shown as '區塊已經同步完成'
- the progress of syncing shown in status bar is not intuitive. Currently, we only get "days left to be synced". Also, the progress of syncing is not shown in lock screen
Suggestions:
- While entering passwords in lock screen,the screen should show that whether the Caps Lock is open
- an .lng file can be posted in a collaboration platform (e.g., google doc),
so that everyone can help translating it
- The progress of syncing should be shown as ETA, and the percentage of syncing can also be provided
- the progress of syncing should be shown in the lock screen

5. the ease of use of BTS wallet
Current Status:
- basically only advanced users know how to use it, newbies would be scared away
- there is no help page while pressing F1
- we can not check the balance of specified public key
- we can not check public keys with top100 balances,
but this site can do this:
(can not list this url due to this account is a newbie account)

Suggestions:
- find a newbie to help troubleshooting, especially female newbie users: 1.) find a newbie who never know about bitcoin, and only have basic knowledge in computer science. 2.) let her use the wallet. 3.) record her complaint and improve base on it
- while F1 is pressed, a simple guide with pictures should be shown
- newly added functions should be labeled in special ways, and a link to its guide should be promoted while using it. e.g., short
- the functionality to lookup the balance of specified public key should be provided in GUI, also the abilty to check the balance to check a bunch of public keys. this will help exchanges to prove that their funds are sufficient
- add the functionality to list top100 public keys with highest balances

6. GUI Security
Suggestions:
- the fields for entering passwords in lock screen should be anti-keylogger
- the commands/operations should be divided into 2 categories: commands that moves funds or operate private keys and etc. For commands that moves funds or operate private keys,
another 'transaction password', which is different from wallet password,
should be entered to execute these commands.
- For transaction password: 1) transaction password has to be different from wallet password. 2)  this can avoid private being buffered in ram continuously, the private key should only be extracted for short term while the transaction password is provided. 3) to maintain convenience, small payouts (the limit can be customized) can be executed without passwords, but the total amount of small transaction per day should be limited (just like VISA)

7. Wallet syncing
Current Status:
- often 'no connection' or only a few connections
- have to find someone to provide node list, but there is no way to easily add a list of nodes in GUI
Suggestions:
- a function to let people who have good node list to easily extract some 'human-friendly code'
- people with poor connection can easily add a list of nodes by entering this 'code'

8. Wallet Backup
Current Status:
- we can only manually export json files
Suggestions:
- should be able to define the path of backup files
- users should be able to make a schedule or a list of conditions to determine when the backup will be made besides automatic backup.
e.g., you can determine everyday or everytime when a transaction is made,
the wallet would be backed up.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: Xeldal on October 29, 2014, 03:17:06 pm
 +5% Great work. Excellent suggestions.

Quote
Suggestions:
- installer can let users to choose the path of wallet data
This has always bugged me.  Damn near all wallets lack this.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: sschechter on October 29, 2014, 03:51:46 pm
Numbers 1 - 3 could be done by a dev-ops engineer, without sucking up the time of our core blockchain developers.  I would like to see this person hired with AGS funds, it is long overdue.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: CLains on October 29, 2014, 03:56:51 pm
 +5%
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: arhag on October 29, 2014, 04:57:48 pm
1. While releasing new version of BTS wallets
Current Status:
- Because of the 'special networking environment',
the downloading speed of github could be extremely slow or unstable
- The downoaded files could be broken if the network is untable
Suggestions:
- While new versions of BTS wallet binaries is released,
their SHA checksums should be posted in github site at the same time
- people in china can share with each other
- I3 or some of us can setup mirror sites
- files can be easily downloaded and check the SHA checksum posted in the github, so we can make sure that files are not modified/broken
- While the built-in function of wallet detects a new version of wallet,
it should also provide the link to BTS wallet download page, so we can conviently check the changelog and download new binaries.

I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.


6. GUI Security
Suggestions:
- the fields for entering passwords in lock screen should be anti-keylogger
- the commands/operations should be divided into 2 categories: commands that moves funds or operate private keys and etc. For commands that moves funds or operate private keys,
another 'transaction password', which is different from wallet password,
should be entered to execute these commands.
- For transaction password: 1) transaction password has to be different from wallet password. 2)  this can avoid private being buffered in ram continuously, the private key should only be extracted for short term while the transaction password is provided. 3) to maintain convenience, small payouts (the limit can be customized) can be executed without passwords, but the total amount of small transaction per day should be limited (just like VISA)

I seriously question any value of a mouse-based password entry system since if your machine is compromised enough to have a keylogger on it than you should assume it will be able to get your private key one way or another (even if it requires replacing the BitShares client with a fake one that phones home).

For a full client you need to keep the private keys in RAM because of how TITAN works. However, once lightweight clients are ready, I can see a lot of value in two different passwords. The "transaction password" would be what is considered the wallet password today. The "wallet password" would be a new password that serves three functions: it decrypts the data stored on the computer that would be considered plaintext in the exported wallet JSON file (and also any new exported wallet files would be an encrypted blob of the JSON using a key derived from the "wallet password"); it unlocks the GUI; and, it derives the keys used to decrypt KeyMail messages. The client would prompt the user for the "transaction password" (which would be used for its purpose and then discarded from memory) anytime the user needed to do something that required their account private key: signing a transaction (in order to send money, place bid/ask/short orders or remove them, cover shorts, update Key Graph, etc.) or decrypting received funds that were notified by KeyMail. This means that if the GUI was "locked" but running and a user at the computer did not have the "wallet password", they would not be able to even snoop on the amount of funds the computer owner owns or their transaction history, but the wallet could still be running (keeping in sync with the network, keeping up to date with the latest block headers and set of active delegates, listening for any income messages from KeyMail). On the other hand, if the GUI was running "unlocked", then a user at the computer would be able to see transaction details and account balances but they would still not be able to steal funds from the computer owner. The notifications sent through KeyMail (notifying of new incoming funds, notifying that orders were matched, or simply a message sent by some account) would instead be encrypted using the public key derived from the "transaction password" + salt (which would be published on the blockchain) so that the in-memory private key derived when the user first ran and unlocked the GUI client could be used to automatically decrypt and process the KeyMail messages in the background and optionally notify the user through desktop notifications.

The third item you list could be accomplished by using a separate account for the small amount of funds whose private key is derived from the "wallet password" rather than the "transaction password", but personally I think it makes more sense to just implement that functionality through multisig instead. There would be some other company on the other end providing one of the keys of the 2-of-3 multsig. They could then create all kinds of interesting policies where the strength of your authentication proof would depend on your spending habits.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: gamey on October 29, 2014, 06:05:53 pm

I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: Shentist on October 29, 2014, 06:22:23 pm
 +5%

very good points. i go along with your improvments, i would like to see to choose a different wallet path with installation. i run 2 times in disc overflow and i have no idea why it happened. scared the shit out of me. I am running the OS on a smaller SSD, so i would prefer to place the wallet on a different drive.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: arhag on October 29, 2014, 07:01:51 pm

I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.

No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 29, 2014, 10:33:03 pm
- If 64bit installer is still unstable, please address this point so that users can make their choice.

Are there specific issues with the 64-bit installer?  Can these crashes be reproduced?  Is the issue discussed in any other threads?
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 29, 2014, 10:43:27 pm
- if the installer detected that there are partitions other than c drive, the default path of wallet data should not be in c drive

I disagree.  On a typical system, a drive letter other than C: might be a recovery partition, an optical drive, a network drive or a removable USB drive.  Installing to any of these by default would be a problem.  If a user is technically un-sophisticated and goes with the default, then C: drive is most likely the right place.  If a user is technically knowledgeable enough to have multiple partitions / drives, then they will be technically knowledgeable enough to decide which drive they want to install it to, and change the installation path from the default.  (And I agree with you that it should be possible to change the installation path in the installer.)

If we install to the same partition as Windows by default, it makes sense:  (1) Users expect it because that is the default behavior of most programs, and (2) The Windows partition is likely to be a partition on a local SATA hard drive.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: gamey on October 29, 2014, 10:56:54 pm
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

I'm not even saying multiple hashes being posted have to be signed with pgp etc.  They just need to be posted in separate places through separate channels that are known. 
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 29, 2014, 11:02:13 pm
- the internationalization is not complete (chinese interface), only the messages from web wallet is translated
- messages from bitshares core program is not translated
- messages from qt framework is not translated
- e.g., main menu,  status bar in the bottom
- e.g., 'Block are synced' should be shown as '區塊已經同步完成'

Where are you seeing messages from BitShares core and qt framework?  Screenshots might be helpful.

Chinese locale is available at https://github.com/BitShares/web_wallet/blob/master/app/static/locale-zh-CN.json and a directory listing of other translations is available at https://github.com/BitShares/web_wallet/tree/master/app/static

If you have additional translations, the best way for us to receive them is pull requests to the above Github repo.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: luckybit on October 29, 2014, 11:04:28 pm

I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.

How about the password entry be through their smart phone which connects to the client somehow?
They enter the password on their smart phone so that it is keylogger proof?

I'm not sure how to set this up yet but I think Trezor has an interesting way of doing thnigs.

Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 29, 2014, 11:16:54 pm

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

He's trusting v0.4.22 to verify the hash of v0.4.23 is signed by known key(s).  Which is legitimate.

If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer

Only whoever compiled a given binary version really knows what source code went into that version.  We need to set things up so that every delegate can compile his own version from source and all get the same binaries.  This will require some work though.  So for now we should encourage everyone to compile from source (especially delegates), and sign binaries with a single key for people who insist on using them.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 29, 2014, 11:19:12 pm
How about the password entry be through their smart phone which connects to the client somehow?

This isn't a viable approach.  The problem of securing two devices and the connection between them is clearly harder than securing a single device.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: arhag on October 29, 2014, 11:34:21 pm
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

That's the thing, you aren't trusting the client to verify itself. One client is always verifying another client. When I want to upgrade, I obviously already trust my existing client (call it client A). I want to upgrade to the next version (client B). So I use my trusted client A to verify the installer for client B. If that verification passes, I can use the installer to upgrade client A to client B. Now I can repeat the process again using the now trusted client B for any future upgrade to say client C.

Assuming you had some other way (not the way I proposed) to verify client A (or really any client that is first being installed by a user on their computer with no other clients available to verify), then the chain of trust makes this upgrade process secure. I prefer that it be done this way rather than expecting the user to manage tools like GPG and storing the public keys of trusted community members manually, because it is far easier for the user to just remember the human-memorable names of trusted community members ('bytemaster', 'toast', etc.). The validating client could also flag whether the signing names are not included in the user's favorites to prevent against phishing attacks.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: jamesc on October 29, 2014, 11:44:54 pm

I would go further than this. The executable should be accompanied by a text file (in some standard format) that includes signatures by various trusted members of the community that sign the hash of the executable concatenated by its official version string (including the version number and platform type). The client should be updated to include a feature that allows the user to drag and drop both the executable and the text file into a window which then checks the signatures (using the existing blockchain). The window should include the official version string of the executable (as determined from the text file) and list all the valid TITAN names included in the text file as well as whether their signature successfully matched the executable or not. If a user sees that all of the trusted members have signed off that the executable is indeed the valid installer for the particular version of the BitShares software, the user would then know that they can quit the current version of the BitShares program and run the executable to safely upgrade. Also, the client should provide an easy-to-use method for the trusted members to sign a particular given executable and generate the lines that need to be appended to the text file. Obviously this doesn't help the very first time they want to install the BitShares client. They will need to rely on TLS or PGP for that.



When you start putting the validation into the client itself for ease of use you've thrown all the security out the window.  The validator would need to be a separate program that is distributed separately in a different channel.  Seems better to just have a hash.  Would be nice to have 2 sources of the hash if not more.  It is the same level of protection you have, but a lot easier for the everyday geek to validate.

How about the password entry be through their smart phone which connects to the client somehow?
They enter the password on their smart phone so that it is keylogger proof?

I'm not sure how to set this up yet but I think Trezor has an interesting way of doing thnigs.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: arhag on October 29, 2014, 11:53:19 pm
How about the password entry be through their smart phone which connects to the client somehow?
They enter the password on their smart phone so that it is keylogger proof?

I'm not sure how to set this up yet but I think Trezor has an interesting way of doing thnigs.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .

We have been through this discussion (https://bitsharestalk.org/index.php?topic=8867) before on this forum. Two factor authentication is no good without multisig if you are trying to protect against attacks where your computer is compromised (which would have to be the case if a keylogger is running on it). This is why multisig is so important. Once that is built and there are companies to support, multi-factor authentication mechanisms can actually provide security.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: gamey on October 30, 2014, 12:17:03 am
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

That's the thing, you aren't trusting the client to verify itself. One client is always verifying another client. When I want to upgrade, I obviously already trust my existing client (call it client A). I want to upgrade to the next version (client B). So I use my trusted client A to verify the installer for client B. If that verification passes, I can use the installer to upgrade client A to client B. Now I can repeat the process again using the now trusted client B for any future upgrade to say client C.

Assuming you had some other way (not the way I proposed) to verify client A (or really any client that is first being installed by a user on their computer with no other clients available to verify), then the chain of trust makes this upgrade process secure. I prefer that it be done this way rather than expecting the user to manage tools like GPG and storing the public keys of trusted community members manually, because it is far easier for the user to just remember the human-memorable names of trusted community members ('bytemaster', 'toast', etc.). The validating client could also flag whether the signing names are not included in the user's favorites to prevent against phishing attacks.

Oh I see, you're using a chain of installers.  So instead of a blockchain we have an installerchain. :) That is a very interesting idea.  Just have the wallet be able to verify the hash of any arbitrary executable.  Likely not that hard once we get keyid etc in place.

Honestly I was wondering how you could think an intaller could verify itself.  You seem to be a person with some of the better (best?)  ideas so I was at a loss. :)
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: cn-members on October 30, 2014, 05:01:26 am
- If 64bit installer is still unstable, please address this point so that users can make their choice.

Are there specific issues with the 64-bit installer?  Can these crashes be reproduced?  Is the issue discussed in any other threads?

e.g., sometimes in 64bit wallet, after you entered your password in lock screen, the unlock button doesn't work. So you have to restart wallet.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: cn-members on October 30, 2014, 05:10:17 am
- if the installer detected that there are partitions other than c drive, the default path of wallet data should not be in c drive

I disagree.  On a typical system, a drive letter other than C: might be a recovery partition, an optical drive, a network drive or a removable USB drive.  Installing to any of these by default would be a problem.  If a user is technically un-sophisticated and goes with the default, then C: drive is most likely the right place.  If a user is technically knowledgeable enough to have multiple partitions / drives, then they will be technically knowledgeable enough to decide which drive they want to install it to, and change the installation path from the default.  (And I agree with you that it should be possible to change the installation path in the installer.)

If we install to the same partition as Windows by default, it makes sense:  (1) Users expect it because that is the default behavior of most programs, and (2) The Windows partition is likely to be a partition on a local SATA hard drive.

Whie d drive may be recovery partition, optical drive, usb drive as you said, c drive could be formatted while re-installing OS. Furthermore, current default data-dir path is in a hidden folder, which normal users doesn't regularly backup. At least I think it should be at some places that users can see and regularly backup.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: mint chocolate chip on October 30, 2014, 05:21:22 am
- If 64bit installer is still unstable, please address this point so that users can make their choice.

Are there specific issues with the 64-bit installer?  Can these crashes be reproduced?  Is the issue discussed in any other threads?

I just installed the latest 64 version over the top of an existing version yesterday and got an error message at the end of it. Even though it closed because of the error, when I opened the software it worked fine. It automatically created an error file that was sent.


I would add to the suggestions is to start dropping the X in BitShares X. I see it everywhere and those X's need to be gone in a week, might as well start phasing them out now.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: Musewhale on October 30, 2014, 07:24:13 am
 +5% +5% +5% :P
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: 麥可貓 on October 30, 2014, 02:32:48 pm
- the internationalization is not complete (chinese interface), only the messages from web wallet is translated
- messages from bitshares core program is not translated
- messages from qt framework is not translated
- e.g., main menu,  status bar in the bottom
- e.g., 'Block are synced' should be shown as '區塊已經同步完成'

Where are you seeing messages from BitShares core and qt framework?  Screenshots might be helpful.

Chinese locale is available at https://github.com/BitShares/web_wallet/blob/master/app/static/locale-zh-CN.json and a directory listing of other translations is available at https://github.com/BitShares/web_wallet/tree/master/app/static

If you have additional translations, the best way for us to receive them is pull requests to the above Github repo.

translation of locale-zh-CN.json has been completed. the problem is the remaining part.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: 029xue on October 30, 2014, 04:05:15 pm
According to i3's production rate, I would say this is not an easy work...
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: gamey on October 31, 2014, 08:30:29 am
No you haven't. Think it through more carefully. You trust iteration 1 through some other means TLS or PGP signatures of the hash. The trusted iteration 1 is used to verify iteration 2 which is used to verify iteration 3, etc. The reason you prefer to use this rather than a separate program is because you rely on the blockchain to verify the mappings between the public key and the TITAN name. This makes validation for the end-user a lot easier than using PGP.

When you trust the client to verify itself, it can just report whatever it wants.  This is where I'm lost.  How can that be secure regardless of whatever complicated system you create under the hood?

That's the thing, you aren't trusting the client to verify itself. One client is always verifying another client. When I want to upgrade, I obviously already trust my existing client (call it client A). I want to upgrade to the next version (client B). So I use my trusted client A to verify the installer for client B. If that verification passes, I can use the installer to upgrade client A to client B. Now I can repeat the process again using the now trusted client B for any future upgrade to say client C.

Assuming you had some other way (not the way I proposed) to verify client A (or really any client that is first being installed by a user on their computer with no other clients available to verify), then the chain of trust makes this upgrade process secure. I prefer that it be done this way rather than expecting the user to manage tools like GPG and storing the public keys of trusted community members manually, because it is far easier for the user to just remember the human-memorable names of trusted community members ('bytemaster', 'toast', etc.). The validating client could also flag whether the signing names are not included in the user's favorites to prevent against phishing attacks.

So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: arhag on October 31, 2014, 02:58:26 pm
So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?

The easiest thing to do would be to just rely on HTTPS. Yeah, the user could be at a risk of a man-in-the-middle attack, but the risk is only for that one time they download the installer for the first time.

More advanced users could use GPG to verify that the hash of the installer is signed by the appropriate trusted developers and auditors. Obviously you need to somehow get the public key fingerprints of these people to know you have the right public keys (they could read the fingerprints aloud in a YouTube video for example).

You could also read the hash of the executable over the phone to a few trusted friends (or if not trusted, at least friends who you are confident wouldn't collude together to harm you) who already have the blockchain clients setup and ask them to use their client to verify that it is valid.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: xeroc on October 31, 2014, 03:07:01 pm
So what do you do for fresh installs?  If you put too much expectation in and installer verifying itself, then you ignore the scenario where someone who hasn't installed BTS yet ?  So what do you think is best way to do that as it has to be indepedent of blockchain?

The easiest thing to do would be to just rely on HTTPS. Yeah, the user could be at a risk of a man-in-the-middle attack, but the risk is only for that one time they download the installer for the first time.

More advanced users could use GPG to verify that the hash of the installer is signed by the appropriate trusted developers and auditors. Obviously you need to somehow get the public key fingerprints of these people to know you have the right public keys (they could read the fingerprints aloud in a YouTube video for example).

You could also read the hash of the executable over the phone to a few trusted friends (or if not trusted, at least friends who you are confident wouldn't collude together to harm you) who already have the blockchain clients setup and ask them to use their client to verify that it is valid.
key signing party in mumble! .. yhea ... i'd love to have a signature of BM in my keyring :)
though a trusted signature requires a physical meeting .. (IMHO)

however, in GPG there are different kinds of "trust" when signing keys .. so seriously, why not organize a key signing party?
BM could make a photo/video of him holding up the fingerprint .. and most of us know the voice of BM pretty well already to accept making a minimum-trust signature
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: liondani on October 31, 2014, 03:11:49 pm
How about the password entry be through their smart phone which connects to the client somehow?
They enter the password on their smart phone so that it is keylogger proof?

I'm not sure how to set this up yet but I think Trezor has an interesting way of doing thnigs.
You can use the RSA key. Google Authenticator is one compatible phone app.   The app creates a private key and you put that in your phone and then you get a new number that changes every 10 seconds.  Only someone with the private key can know what the number is.  You could check the number before any transfer or market operation.  The private key is not the same as the wallet's private key .

We have been through this discussion (https://bitsharestalk.org/index.php?topic=8867) before on this forum. Two factor authentication is no good without multisig if you are trying to protect against attacks where your computer is compromised (which would have to be the case if a keylogger is running on it). This is why multisig is so important. Once that is built and there are companies to support, multi-factor authentication mechanisms can actually provide security.
what about a combination with yubikey ?

Sent from my ALCATEL ONE TOUCH 997D

Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on October 31, 2014, 04:41:25 pm
- the fields for entering passwords in lock screen should be anti-keylogger

I don't think there's anything we can do to protect users when their workstation has been compromised to that extent.  If you have a specific anti-keylogging mechanism in mind, more details will allow a more specific analysis.
Title: Re: Suggestions of Jerry (aka J-God) to improve BTS wallet user experiences
Post by: theoretical on November 04, 2014, 02:53:32 pm

I've put most of the suggestions in this thread in various tickets, there is a list here:  https://github.com/BitShares/qt_wallet/issues/62

There is some public discussion of these suggestions in the individual tickets linked in that ticket.  Specific, actionable feedback is always appreciated.