On Jan 23, 2014, at 6:03 PM, Daniel Buchner <[email protected]> wrote:
> On Thursday, January 23, 2014 11:51:59 AM UTC-8, Kumar McMillan wrote: >> 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? >> > > 1) The game would offer up its own wallet ID when asking for payment, > correct. This wallet ID does not need to be affiliated with a payment > processor to get near-instant processing and confirmation. Ahh, ok. So how is this wallet ID different than a bitcoin address? Who controls wallet IDs? I was confused about how a wallet ID might be associated with Coinbase or BitPay. > Here's how that works: > > - The game sends its wallet ID, plus an unique string as the message portion > of the payload, to whatever payment app the user chooses. > > - The payment app prompts the user to sends the game's wallet the desired > amount, this amount and the wallet ID are included in the web activity's data > object and do not need to be entered by the user. When the user is bounced to the payment app, what do they see? Do they see a scrambled string of text (the recipient's wallet ID) or does it say "you are about to pay Game X" ? How can the user trust/verify that they are really about to pay Game X? > > - The payment app completes the transaction to the game's supplied wallet ID, > having encoded within its message value the unique string supplied by the > game. > > - The payment app sends back the success event via the postResult() method, > this message contains the transaction ID generated by the blockchain that > corresponds to this transfer. > > - The game receives this success message and can use the transaction ID to > confirm with the blockchain itself that the transaction occurred and the > correct amount was paid. Depending in the app/game's desired number of block > confirmations (confidence level), the confirmation can be very quick. Here's > the API to do this all from the client: > http://blockchain.info/api/blockchain_api I see. How long would it typically take to gain a good level of confidence that the payment went through? > > Using web activities, and the flow outlined above, the app/game need not run > any server to accept and confirm successful payments. That's pretty cool. > >> >> 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? >> > > The receipt is a combination of a completed transaction ID and any meta data > passed by the game they need to identify what was purchased. All of this can > be found via the blockchain API located here: > http://blockchain.info/api/blockchain_api. Regardless of what service the > user leverages for their wallet, it does not need to know to verify anything, > it simply needs to invoke postResult() when it has completed its flow. The > verification is between the app/game and the block chain. If the app is receiving a post result it has to somehow trust that result. For a very popular game (let's say it uses a server), a malicious user might have incentive to root their phone and hack the app's source code to trick the app into giving them a free or reduced price item. I assume the app can do the block chain verification server side for added trust. But how does it trust that the unique string has not been tampered with? When it looks up a transaction on the block chain does it get back the unique string? It sounds like the unique string would only be passed as a parameter to postResult() which means a malicious user can purchase an item for $0.99 and tamper with the unique string changing the item ID to one of $24.99 (allowing them to get a better item). How would the app detect that the unique string had been tampered with? Thanks for all the details. This is interesting. -Kumar > _______________________________________________ > 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
