- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 27 Jan 2020 16:29:54 +0100
- To: Adrian Hope-Bailie <adrian@coil.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>, Adrian Hope-Bailie <adrian@hopebailie.com>, Jake Archibald <jakearchibald@google.com>, Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, jungkee.song@microsoft.com
On 2020-01-27 11:50, Adrian Hope-Bailie wrote: > Hi Anders, > > Following an initial review from the TAG the decision was made to assemble some concrete use cases enabled by this feature. > Also, Google are going to be doing some UX research. Good. > > The biggest challenge, as I understand it, is demonstrating the ability of browsers to implement this feature in a way that is not easily phishable. > i.e. Can we be certain that malicious websites aren't able to render something that appears to be a secure modal (but is just web content) and convince users to enter their login/payment credentials? The "Trusted UI" has been on the road(map) for decades without really going anywhere. Fortunately there is no problem to solve for login or payments because a properly designed 2FA scheme is unaffected by this kind of UI spoofing. If for example a PIN is spoofed it doesn't help the attacker if the associated key is bound to the application (service worker in this case). However, there is another attack that you need to cater for and that is traditional phishing which becomes an issue when SOP effectively is disabled. PaymentRequest for Android preserves the security context (including cert-path) of the caller which means that login tokens etc. can be securely tied to the caller's origin. That is, "evil-example.com" will only be able to mint login assertions for "evil-example.com". What is less clear to me is how this fits with WebAuthn and WebCrypto. That seems like a necessity, otherwise Web2Native (my "specialty") will continue to rule. Anders > > Adrian > > On Mon, 27 Jan 2020 at 09:48, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > Hi Adrian & WG, > > What is the current state of this proposal? > https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md > > Years ago, I suggested that we need a "mechanism" to deal with "breaking" SOP in a more universal way where an application served as a "moderator". The Modal Window could be that solution for "pure" Web applications (for Web2Native applications, PaymentRequest as implemented in Android[*] is a pretty good "emulation" of what I once requested). > > This could have a huge number of quite different applications so it doesn't seem to be a suitable work items for the Payment WG. BTW, I don't see how you actually could restrict the Modal Window feature to only work with payment applications (unless the Window UI is cast in stone which would be very bad). My use of PaymentRequest for Android seems to support that statement. > > Thanx, > Anders > *] https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf >
Received on Monday, 27 January 2020 15:30:01 UTC