You're right, but i think this type of wallet can still be usable to do casual transactions/tipping. The attacker still needs to have access to the phone, no? I mean, one could totally refute piggy banks as worthless because they're easily broken into. I for one liked this tutorial

I think you're touching on something of a holy grail for bitcoin user experience design. The inherent contradiction of bitcoin is that if someone else is in custody of your keys you don't control your coins. This makes it very hard to create services for bitcoin because you basically need to win user trust AND if you fuck up someone will steal all deposited coins.

A way forward would be a model like you're describing - webapps that provides all the logic but the keys and transaction signing still resides at the user end, distributing risk which is good for both developers and users. If a webapp can coordinate multiple users to create multisig addresses, then suddenly we have "dumb" smart contracts - perhaps not self-executing, but still programmable money on top of a webstack which everyone already knows how to use!

I've been trying to talk to people on reddit about this, but the interest has been mild. The obvious missing component here is a BIP standard employed by all wallets. There is already a way to do payment requests, which is basically the above but with simple one-way payments. What we need is support for multisig, message signing (authentication) so that we can write more complex applications with minimal risk.

This is really the missing link for bringing about the "internet of value".

Okay, so obviously U2F won't work because it's secp256r1, however UAF (similar fido alliance scheme, but for auth instead of 2-factor) uses secp256k1! This actually makes more sense, semantically, than U2F.

Apparently the challenge can be anything up to a sha516 hash in length, so signing bitcoin transactions should not be a problem. Unfortunately the FIDO spec uses nonces, which will fuck up the signature. I'm not good enough at cryptography or the inner workings of bitcoin to know if this can be circumvented somehow...

Obviously the hardware wallet makers should spearhead their own scheme for this somehow, but it would be cool to find a solution within the FIDO spec, since it is a bit more broad and endorsed by Google among others.

Any thoughts on if it's even possible to sign the hash with a nonce somehow?

I know this is a bit of a bump, but i've been thinking about U2F recently and this is quite an interesting design idea.

For example:
1) Alice provides Webapp with her U2F public key
2) Bob provides Webapp with his U2F public key
3) Webapp constructs a 2-of-2-multisig address using both their public keys.
4) Now Alice and Bob can do business using the webapp. However, the webapp itself never has access to the private keys but only acts as a service provider.

If this design pattern is possible it will make it so much easier to develop single page applications that only provides the contract but doesn't hold any keys. Developers can focus more on the service and be less paranoid about security.

I recently bought a Ledger Nano S which is on it's way, i will try to find out if this works.