- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Sat, 8 Oct 2016 10:05:17 +0100
- To: "'Adrian Bateman'" <adrianba@microsoft.com>, "'Ian Jacobs'" <ij@w3.org>, <public-privacy@w3.org>
- Cc: "'Adam Roach'" <abr@mozilla.com>, "'Telford-Reed, Nick'" <Nick.Telford-Reed@worldpay.com>, "'Adrian Hope-Bailie'" <adrian@ripple.com>, "'Mike West'" <mkwst@google.com>
The secure context requirement mitigates rogue script being inserted externally, say by a MITM, but not the risk of bad script generated by a compromised third-party script server or poor site administration procedures. Given the honeypot the API creates it could be a good idea to have a belt & braces approach, say with a new "allowpaymentrequest-src" CSP directive i.e: Content-Security-Policy: allowpaymentrequest-src paywidgit.com; [other CSP directives] -----Original Message----- From: Adrian Bateman [mailto:adrianba@microsoft.com] Sent: 07 October 2016 19:14 To: Mike O'Neill <michael.oneill@baycloud.com>; 'Ian Jacobs' <ij@w3.org>; public-privacy@w3.org Cc: 'Adam Roach' <abr@mozilla.com>; 'Telford-Reed, Nick' <Nick.Telford-Reed@worldpay.com>; 'Adrian Hope-Bailie' <adrian@ripple.com> Subject: RE: Seeking feedback on "user consent" text in Web Payments Working Group specification > On Fri, Oct 07, 2016 at 06:42:59, Mike O'Neill wrote: > I wonder if the "allowpaymentrequest" attribute on an iframe is > sufficient to stop rogue script dynamically creating iframes which > present bogus payment requests to the user. Maybe a CSP directive would > work here, or at least block payment requests from iframes when the top > level context is not secure. iframes for which the top level context is not secure are not Secure Contexts and so the PaymentRequest API isn't available.
Received on Saturday, 8 October 2016 09:06:20 UTC