Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's hoping for #3 :)). I agree with your points on the difficulty of making either user activation or capability delegation work across navigation (though I still personally think there are reasonable use-cases! :D). We're definitely paying attention to potential abuse scenarios here, though we do agree with Rick's take that getting user activation is unfortunately a fairly weak protection today already.
Wrt the PR status - yes, the WG has now endorsed it, but we will definitely be landing the PR before trying to ship this. We've re-targeted the launch from M116 to M117. On Tue, 27 Jun 2023 at 03:52, Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM2 conditional on the PR landing > > On Mon, Jun 26, 2023 at 5:02 PM Rick Byers <rby...@chromium.org> wrote: > >> This makes good sense to me. Obviously there's so much risk and potential >> for abuse around payments, getting the user to click seems like a very weak >> mitigation anyway (eg. the prevalence of "click to read more" buttons). +1 >> to waiting for the PR to land, but it looks like the WG has now approved >> it, so proactive LGTM1 for when the PR actually lands. >> >> It's too bad Apple isn't currently a member of the WG, so we're not >> likely to get their thoughts on this in time to influence our launch >> decision. But I also don't think it's a substantial interop risk - Payment >> Request is already very different on Apple browsers due to the tight >> coupling only with Apple Pay. >> >> Rick >> >> On Tue, Jun 13, 2023 at 2:54 PM Nick Burris <nbur...@chromium.org> wrote: >> >>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org, >>> i...@chromium.org >>> >>> Specificationhttps://github.com/w3c/payment-request/pull/1009 >>> >>> Design docs >>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4 >>> >>> Summary >>> >>> To help developers reduce friction in Payment Request flows, we are >>> removing the user activation requirement for PaymentRequest.show(). Spam >>> and clickjacking mitigations are put in place to mitigate security and >>> privacy risks with this change (see design doc >>> <https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.9tic5lqm5god> >>> ). >>> >>> >>> Blink componentBlink>Payments >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>> >>> TAG reviewNone >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility*Gecko*: No signal >>> >>> *WebKit*: No signal >>> >>> *Web developers*: We've received direct feedback from web developers >>> that they would be able to reduce friction in their redirect-based payment >>> flows if PaymentRequest.show() could be initiated without a user activation. >>> >>> *Other signals*: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Debuggability >>> >>> Existing debuggability for PaymentRequest; e.g. a specific SecurityError >>> is thrown when an activationless show() call is not allowed. >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)?Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> Flag name--enable-blink-features=PaymentRequestActivationlessShow >>> >>> Tracking bug >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1454204 >>> >>> Estimated milestones >>> DevTrial on desktop 117 >>> DevTrial on Android 117 >>> >>> Anticipated spec changes >>> https://github.com/w3c/payment-request/pull/1009 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/4879115349393408 >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_7ZCW3f-uEv%3DcsRY_qtmOzJGujoXVcXfvC7BiCusUfhg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_7ZCW3f-uEv%3DcsRY_qtmOzJGujoXVcXfvC7BiCusUfhg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maev1jVfi8f4ZAt57x0nZF2OdpCQBEu9qbiNbm%2BLfvx0wA%40mail.gmail.com.
