- From: Tommy Thorsen <tommyt@opera.com>
- Date: Fri, 10 Mar 2017 10:37:13 +0100
- To: Michiel de Jong <michiel@ripple.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Ian Jacobs <ij@w3.org>, Payments WG <public-payments-wg@w3.org>
- Message-ID: <CA+zGpV0i1mJ8QkA=xr06YBDcDp=cpWFsrOfTwJiN74de85ehcg@mail.gmail.com>
I actually made an attempt <https://github.com/tommythorsen/webpayments-polyfill/> at something like what Michiel is describing, using the Chrome Extensions API for the plugin, but I found it a bit tricky to manage and invoke the service workers from within my plugin code. I'm not sure how to make the necessary changes to the ServiceWorkerRegistration interface <https://w3c.github.io/webpayments-payment-apps-api/#extensions-to-the-serviceworkerregistration-interface> from a plugin, and I'm not sure how to add the paymentrequestevent to the ServiceWorkerGlobalScope <https://w3c.github.io/webpayments-payment-apps-api/#extension-to-serviceworkerglobalscope>, and subsequently invoke the event. I wouldn't say it's impossible, but will definitely take a more experienced plugin developer than me to do this. -Tommy On Fri, Mar 10, 2017 at 9:55 AM, Michiel de Jong <michiel@ripple.com> wrote: > Hi Manu, > > I agree with your point that the a polyfill would be useful for debugging > payment apps, and for demos and strawman discussions, and it would be > helpful if we try to build something like that. > > But I cannot think of a way to make it secure enough to use it in > production: If a legitimate payment app can include a script that allows it > to register itself, then a malicious website can also install itself as a > payment app, without the user's consent. Also, if a legitimate webshop can > include the polyfill script to launch the 'choose payment method' dialog > and redirect the user to their preferred payment app, then a malicious > website can also redirect the user to the user's installed payment app and > request payment without getting the user's consent first. > > What if instead of a polyfill, we were to create a browser plugin? The > plugin could host the dialog and store the user's list of installed payment > apps. The downside would be that installing a payment app involves > installing this plugin first, and then installing your favorite payment app > using the plugin's dialog UI. But it would be a nice way to preview the > future. > > WebExtensions are the new cross-browser way to create browser plugins, > might be useful for this: https://developer.mozilla.org/ > en-US/Add-ons/WebExtensions > > Cheers, > Michiel > > On Thu, Mar 9, 2017 at 11:32 PM, Manu Sporny <msporny@digitalbazaar.com> > wrote: > >> On 03/09/2017 12:25 PM, Adrian Hope-Bailie wrote: >> > Assuming that all of the major vendors are going to implement PR API >> > soon what would be the value of the polyfill? Are you suggesting it >> > could add payment apps functionality where that is not available? >> >> Yes, that would be one of the purposes of a polyfill. A secondary >> purpose would be the capability to spec out and iterate on new features >> before browser implementation happens (which is expensive to do and >> takes lots of time to iterate on). >> >> Also, note that implementing the PR API in a browser today still means >> that there will be hundreds of millions of browsers that will not have >> access to it due to the length of upgrade cycles... which puts people >> trying to deploy it into at least one of two situations: >> >> 1) Waiting for deployment to get broad enough to deploy (which could >> take years). >> 2) Writing complicated fallback algorithms which prevents the market >> from experiencing the new technology/flow. >> >> The option always exists to not use the polyfill and take one of the two >> approaches above. However, having a polyfill would enable those of us >> that want to push out Payment Apps and PaymentRequest to have the >> ability to do so while the browser implementations catch up. >> >> At the same time, I don't mean to trivialize the difficulty of writing >> the polyfill. There are concerns around security and deployment and >> there is no clear answer to polyfilling the native apps portion of >> payment app selection... these are issues we'd have to look into further >> (and the group may find that a distraction, which is why we'd try to >> come up with a solution before presenting to the group). >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: Rebalancing How the Web is Built >> http://manu.sporny.org/2016/rebalancing/ >> >> >
Received on Friday, 10 March 2017 09:37:46 UTC