Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Greenaddress / Blockchain.info "Visit website" on Web wallet section #512

Closed
HostFat opened this Issue Aug 9, 2014 · 11 comments

Comments

Projects
None yet
4 participants
Contributor

saivann commented Aug 9, 2014

@HostFat That is actually intended, using browser extensions is recommended as they are increasing security. And these extensions are the "local apps" that are allowing both of these two wallets to be displayed in the "Desktop" subsection. If any of these wallets would somehow force the user to use the extension, linking to the main webpage would make sense IMO, but none of them does.

HostFat commented Aug 9, 2014

I agree that browser extensions are more secure, and I'll suggest to use them for sure, but I still think that "Visit website" has just one meaning.
I think that the common user has to find what it asks by clicking the text that he read.
It should give a direct link to the website, but also suggests that the best secure way is to use browser extension.

Contributor

saivann commented Aug 9, 2014

Maybe we could just use "Install extension" and "Install app" for browser extensions / mobile apps (mobile apps often link to the app and not to a website). Otherwise, I think we shouldn't be linking to a web wallet website from the Desktop category. Only local apps.

HostFat commented Aug 9, 2014

I agree that it can be a good idea for the Desktop category, but I still think that they should be linking to the website on the "Web" wallet section. (and also suggest them to use the Desktop version instead)

I just don't like to hide things to users. I think that it's better to show them everything, but also give the right warnings

Contributor

saivann commented Aug 9, 2014

Well, maybe others could share their thoughts on this, but IMO this is a choice between convenience (compatibility) and security. Bitcoin.org should IMO prioritize security, so although I agree the webpage would be acceptable for the "Web wallet" subsection, the extension still seemed like a better choice to me. In the end, the user just ends up on the same website.

As for just recommending the extension, in my experience, this isn't efficient. You have to point the user to the extension to get them to install it the first time they're using the wallet, similarly to how wallets are often "forcing" the user to write down wallet seeds mnemonics, otherwise they just forget about it.

Contributor

harding commented Aug 9, 2014

I agree we shouldn't say "Visit Website" if we aren't linking to a standard website. Using something else like "Install App" or just the "Download" that we use elsewhere sounds good to me.

I also agree that linking directly to the browser extension in both the Desktop and Web sections is likely to increase the number of users that install the extensions, which may increase the security for those users. (On the other hand, if one of the extensions we link to goes rogue, I guess it could help steal from other web wallets.)

A website may have extra information, but the extension store does seem to give extension creators plenty of room to describe their extension and upload screenshots, so I don't see any particular reason to link to the webpage when we can hopefully get more security by linking to the extension and agree with @saivann that we should continue linking to the extensions in the Desktop and Web sections.

Contributor

greenaddress commented Aug 9, 2014

I tend to agree with @harding and with @saivann

Security should be preferred over convenience and it sounds less confusing to change the label to be more appropriate, like harding said either 'Install App' or 'Download'.

p.s. on the topic of security, we are working on some multiplatform desktop apps that do not autoupdate and that are not based on a browser nor javascript (i.e. python and maybe java too). When these mature it may be preferable to point to those (i.e. on top of no autoupdate they do memlocking to avoid swap and set core limits to 0 where possible asking the user if they should proceed if not permissioned to take these actions)

Contributor

saivann commented Aug 10, 2014

I have just opened a pull request for the "Download" button: #515.

@harding The "extension goes rogue" scenario is interesting. Unless I'm mistaken, at least the new app requiring increased permissions to steal other web wallets would open a dialog to the user. What I do not know very well however is if Google has some process in place to report / detect / drop rogue extensions and how much time it would take to block the extension. At a first glance, it seems unlikely to me that an extension could go rogue without a crooked employee with access to the signing key.

@greenaddress Great! However will your users at least be notified of updates? Thus far auto-updates have proven helpful with fixing critical bugs within a short timeframe with the Android SecureRandom bug. Without auto-update, users still need to trust you when installing / updating the app and may not be aware when it's important to do so.

Contributor

harding commented Aug 10, 2014

@saivann I hardly use extensions (and never with Chromium) so I don't know exactly what's possible or not. I only mentioned rouge extensions because I've heard about a couple extensions that stole bitcoins. As for permissions, if the developer of the app wanted to steal bitcoins, he'd ask for the permissions he needed while the app was still legitimate, then change to the steal-bitcoins code and hope everyone auto updates.

I don't know how much of a risk this is, but it's one reason I personally shy away from auto update. (And, of course, I'd love it if more wallets were deterministically built. :-)

As for GA.it, I imagine they can simply refuse to cosign any transactions from users who haven't upgraded past a known security vulnerability. For example, they might require you to update your client software, generate a new seed, and send them your new master public key before they'll authorize any transactions. (Of course, you can also restore from the backups they automatically email you after the time lock expires.)

Contributor

greenaddress commented Aug 10, 2014

@saivann i agree, auto update is one thing, notification of updates is another 👍

We can have a topic for upgrades in our sub/pub API and in case of serious vulnerabilities refuse to sign unless they upgrade or as @harding said even go as far as to force them to move their funds to a new wallet in case there's reason to believe their seed may be compromised.

Contributor

saivann commented Aug 11, 2014

Just fixed texts in the buttons. Links to the extension will be kept for now, thanks!

@saivann saivann closed this Aug 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment