On Jan 23, 2014, at 1:03 PM, Daniel Buchner <[email protected]> wrote:
> This is a non-issue. While any app can declare as a handler for a web > activity, the user must explicitly select the app they want to use to > complete the activity. The Bitcoin wallet apps in question are a lot like a > user's banking app, let me use this similar banking example to illustrate two > major reasons why this concern is unwarranted: > > 1) The user has a bank account for their fiat dealings - let's assume they > bank with Wells Fargo. It's highly unlikely a user would install any app > besides Wells Fargo to do their banking. This fact implicitly eliminates much > of the concern. > > 2) But let's assume for some reason they install Evil Bank's app. Evil Bank's > app declares a web activity handler, and now appears in the user's list of > apps for that activity. Still, this is meaningless. Remember, not only must > the user select a malicious app, but also have *funds already in it*. The > latter is incredibly unlikely, and faces an untenable chicken and egg > problem: the user must be fooled into first putting funds into Evil Bank, > before Evil Bank could possibly "send funds to the wrong person". > I might be missing some details to fully understand this. Let's say a user installs their trusted bitcoin payment app. Let's say a game calls the web activity to start a payment using their wallet ID (which is only valid with one of a few instant payment processors, correct?). When the user selects their payment app from the picker, what would the payment flow look like? Does the user need to manually enter the bitcoin address of the recipient? How do they know they are entering the right address? Does something in chrome pass the wallet ID securely to the app handling the payment? I'm still curious as to what a receipt would look like because I think that part is important. How would a merchant be able to instantly verify that the payment went through when they get the onsuccess callback? If a wallet ID is something specific to Coinbase or BitPay, how do they know to verify the transaction? Kumar > - Daniel > > > On Jan 23, 2014, at 12:03 PM, Daniel Buchner <[email protected]> wrote: > > > On Thursday, January 23, 2014 9:50:15 AM UTC-8, Kumar McMillan wrote: > >> [+warner in case he has insights…] > >> > >> > >> > >> On Jan 23, 2014, at 11:11 AM, Daniel Buchner <[email protected]> wrote: > >> > >> > >> > >>> With a web activity, we could enable apps that handle crypto-currency > >>> payments to transact value for the user. This would make payment with > >>> crypto-currencies a trivial process, here's how it could work: > >> > >>> > >> > >>> 1) Apps that supported crypto-currency payments/transfers would add a > >>> hook for a "crypto-payment" web activity: > >>> https://gist.github.com/csuwildcat/8582305 > >> > >>> > >> > >>> 2) Any app that desires to offer the option to pay or transfer value via > >>> crypto-currency, could then do so by invoking the activity: > >>> https://gist.github.com/csuwildcat/8582556 > >> > >>> > >> > >>> Using the existing Web Activities mechanism, we could allow > >>> crypto-currency apps to do the heavy lifting without adding much > >>> complexity to our platform. > >> > >> > >> > >> Using web activities to process payments has always seemed appealing to me > >> because the merchant can say "give me money but I don't care how." Any app > >> can register themselves to take money and give it to the merchant. The > >> tricky part is the latter: how does the merchant trust that it will > >> receive money? Due to the nature of web activities it has no control over > >> *who* processes the payment. If any app can register themselves as a > >> handler for the the web activity then what is that app's incentive to pay > >> the merchant? It's a gold mine for thieves. > >> > >> > >> > >> I hadn't considered the case of bitcoin before in this scenario. Bitcoin > >> is unique in that the payment can be verified on the block chain and that > >> is how a merchant can trust it will eventually receive the money. > >> Theoretically, I can see how a merchant can start a web activity for > >> receiving money via Bitcoin and not care how that money is processed since > >> it can be verified. However, block chain verification is not > >> instantaneous. The story for processing the payment in this manner seems > >> weak. What does the merchant tell the user? Please wait 15 minutes while > >> we verify your transaction? > >> > >> > >> > >> The only way (I know of) that bitcoin payments can be done instantaneously > >> is to use a specific wallet service that gives you "credit" while it > >> verifies the block chain in the background. To get instant payments you > >> have to trust the wallet service but you can't use a web activity to say > >> "only process my payment with these wallet services I trust." > >> > >> > >> > >> Let's say that a merchant could somehow verify bitcoin payments > >> instantaneously when it receives the onsuccess callback. Even then, how do > >> we protect the user from fraudulently making a bitcoin payment to the > >> wrong address (and so on)? By the time the merchant can reject a > >> transaction it's too late, the user may have given money to the wrong > >> person. The merchant wins but the user loses. > >> > >> > >> > >> Kumar > >> > >> > >> > >> > >> > >>> > >> > >>> Feedback welcome - especially if I missed something! > >> > >>> > >> > >>> - Daniel > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> _______________________________________________ > >> > >>> dev-webapps mailing list > >> > >>> [email protected] > >> > >>> https://lists.mozilla.org/listinfo/dev-webapps > > > > The merchant, let's say a game app, for example, would use a wallet ID from > > a service like Coinbase or BitPay. This would allow the transaction to be > > verified in seconds, not minutes. > > What would the receipt look like? How would the merchant be able to verify > this specific wallet ID transaction? > > > > > As for the "user pays the wrong person" concern: The merchant (the game the > > user is playing) dictates the destination of the transfer. > > How does the merchant dictate the destination of the transfer? A web activity > is a passive intent to perform an action. Some other app on the system must > be selected by the user to process the action. Unless I'm mistaken, any app > could register themselves as a 'crypto-payment' handler. What mechanism is in > place to ensure that each handler takes the user's money and puts it in the > right wallet ID? Does Mozilla have to bless each crypto-payment handler? > > > > To "go to the wrong person", it would require the game's app code to be > > hacked and replace that wallet ID with another. With packaged apps, that's > > impossible (I think), but even with hosted apps, it would require the app > > to be compromised. > > > > I believe this is a really simple way to get is in the payment game for > > crypto-currencies without needing to do much on the platform side. > > _______________________________________________ > > dev-webapps mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-webapps > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
