Cookie restrictions strict list is blocking the use of Amazon Pay
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
Webcompat Priority | ? |
People
(Reporter: jesup, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: regression, Whiteboard: [webcompat])
Attachments
(1 file)
(deleted),
image/png
|
Details |
When trying to pay for something with Amazon Pay, anti-tracking is blocking payments. The WebConsole shows:
"Request to access cookie or storage on ?https://payments.amazon.com/checkout/widgets/v2/wallet#/error? was blocked because it came from a tracker and content blocking is enabled"
Seen on two sites when trying to use Amazon Pay with Beta 67.0b8. I have not tried other versions.
https://sites.fastspring.com/mackiev/order/confirm (online payment supplier for mackiev.com)
https://lovepop.com
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Comment 2•5 years ago
|
||
This is caused by our tracking cookie blocking. I added something to my cart on lovepop and started the checkout with amazon pay. Eventually I end up on the screen in Comment 1. The console contains the error messages:
Request to access cookie or storage on “https://payments.amazon.com/gp/apa/csm/jsonp?sellerId=undefined&data=%7B%27counters%27%3A%5B%5D%2C%27timings%27%3A%5B%7B%27name%27%3A%27addresswidget-pre-render%27%2C%27time%27%3A803%2C%27tags%27%3A%5B%5D%7D%5D%2C%27info%27%3A%5B%5D%2C%27entries%27%3A%5B%5D%7D” was blocked because it came from a tracker and content blocking is enabled.
and
Request to access cookie or storage on “https://payments.amazon.com/checkout/widgets/v2/addressBook” was blocked because it came from a tracker and content blocking is enabled. 3b6363c6f09691018a6a9d60477d56c4:1:149
If I click "Continue" in the iframe, I see the following error message: "User declined!". I also see more cookie warning messages. Digging into the code, the "Continue" button calls ajaxReloadWidget
on click. I've pasted in the code snippet below [0], but this function attempts to call the Storage Access API and is presumably declined. I have my profile set to always prompt, so this is an automatic denial.
The iframe that contains the "Continue" button is loaded from https://payments.amazon.com/checkout/widgets/v2/addressBook#
. The auto-denial is due to the fact that I have never interacted with the payments.amazon.com
origin before (despite having used my amazon account) [1]. Unfortunately, navigating to payments.amazon.com
redirects immediately to https://pay.amazon.com/us
, so it's not clear to me that any user would ever interact the payments.amazon.com
origin.
The solution here would either be for amazon to serve this embedded iframe from amazon.com
or for us to allow storage access prompts (but perhaps not auto grants) when a user has interacted with the eTLD+1 of the requesting origin at some point in the past.
[0] In https://d35u8xwkxs8vpe.cloudfront.net/amazon-pay-checkout-widgets-assets/spa_widget_js.98a53e3cc5f59c1ce8ad.js
we see the following code
}, e.ajaxReloadWidget = function() {
$.post(m, {
counter: "itp_continue_clicked"
}), document.requestStorageAccess().then(function() {
t.$apply(function() {
t.showLoading = !0
}), $.post(m, {
counter: "itp_prompt_accept"
}), $.post(window.location.pathname, window.originalRequestData, function(e) {
var n = /<body.*>([\s\S]+)<\/body>/.exec(e);
"undefined" != typeof errorDetails && (errorDetails = void 0), "undefined" != typeof commonWidgetParams && (commonWidgetParams = void 0), delete window.PYOP,
function() {
for (var e = t.$$childHead; e;) {
var n = e.$$nextSibling;
e.$destroy(), e = n
}
for (var i in t) t[i] && 0 != i.indexOf("$$") && "object" == typeof t[i] && (t[i] = null)
}(), $("body").html(n[1]), t.showLoading = !1
})
}, function() {
$.post(m, {
counter: "itp_prompt_decline"
}), console.log("User declined!")
})
}
[1] https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#Concepts_and_usage
Reporter | ||
Comment 3•5 years ago
|
||
Thanks for digging in. Fixing this should be a high priority since having all Amazon Pay uses break is a big problem and will lead to people switching browsers. Unless we can get Amazon to make an immediate fix, we'll need to do something, even if it's only a bandaid or temporary special-case. (IMO) It also concerns me what other sites might break like this without us knowing; most users would never find what I did and report it; they'd just switch browsers (or complain to the site, which likely would have no idea and not link to firefox, at least for a while - and then they might put a "please use Chrome" tag on).
Mike: do we have contacts at Amazon Pay?
Updated•5 years ago
|
Comment 4•5 years ago
|
||
One thing to note: amazon.com
is only on the "Strict" version of the cookie blocking list, which is only enabled in pre-release channels. Release users should not experience this breakage.
Comment 5•5 years ago
|
||
(we have an Amazon partner list, but I'm poking around to see if we have more direct Amazon Pay contacts before going that route. will leave ni?)
Updated•5 years ago
|
Comment 6•5 years ago
|
||
When running this page with the MOZ_LOG=AntiTracking:5 environment variable set, we have the following lines in the log:
[Child 9728: Main Thread]: D/AntiTracking Adding a first-party storage exception for https://payments.amazon.com...
[Child 9728: Main Thread]: D/AntiTracking The current resource is third-party
[Child 9728: Main Thread]: D/AntiTracking Tracking principal (https://payments.amazon.com/checkout/widgets/v2/addressBook) hasn't been interacted with before, refusing to add a first-party storage permission to access it
This is because the origin of the iframe calling the storage access API (https://payments.amazon.com) has not been interacted with as a first-party yet. This is a requirement for the API which we document in https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API but we should also perhaps document it in https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using as well.
The fix for the website would be to call the storage access API from an origin which the user would have interacted with in the first-party context. Since the Amazon Pay interaction already requires a flow where the user interacts with Amazon as a first-party hopefully this will be possible for Amazon to implement.
Comment 7•5 years ago
|
||
Carter, do you have contacts at Amazon Pay?
Comment 8•5 years ago
|
||
Carter told me he doesn't have direct contacts. I'm following up.
Comment 9•5 years ago
|
||
(In reply to Steven Englehardt [:englehardt] from comment #2)
or for us to allow storage access prompts (but perhaps not auto grants) when a user has interacted with the eTLD+1 of the requesting origin at some point in the past.
FWIW this isn't super easy for us to do, because the user has probably interacted with www.amazon.com, and the way we store this data it's not easy to ask "has the user interacted with the eTLD+1 of the requesting origin in the past"?
But more importantly, for users outside of the US using Amazon's ccTLDs this wouldn't solve anything at all since those users would have been interacting with domains such as www.amazon.ca and so on...
Comment 10•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 11•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 12•5 years ago
|
||
This works for me now on https://lovepop.com, closing the bug. Please reopen if you can reproduce on another site.
Description
•