www.hyatt.com - The page does not load with `privacy.resistFingerprinting` set to true

[c22]

URL: https://www.hyatt.com/

Browser / Version: Firefox 123.0 Operating System: Windows 10 Tested Another Browser: Yes Edge

Problem type: Site is not usable Description: Page not loading correctly Steps to Reproduce: With privacy.resistFingerprinting enabled, the page does not load and the server returns a 429 error in the network logs.

After disabling privacy.resistFingerprinting and clearing cookies, the page loads fine.

Browser Configuration

• None

From webcompat.com with ❤️

[c22]

This also happens when visiting https://realestate.com.au/

I believe this is very closely related to https://github.com/brave/brave-browser/issues/27021

In that issue, specifically this comment seems quite informative.

[c22]

Also some additional information that might be relevant, I believe both sites are using Akamai CDN. My theory is that Akamai is detecting the resistFingerprint behaviour as bot activity, eg.

https://www.akamai.com/products/bot-manager

[softvision-raul-bucata]

@c22 Thanks for reporting. Is fingerprinting enabled in the pref menu of Firefox?

[qa_11/2024]

[c22]

@softvision-raul-bucata sorry I don't specifically know what setting you are referring to.

Under "Enhanced Tracking Protection" I have "Strict" settings enabled, but in the about:config section, I have manually enabled "privacy.resistFingerprinting".

If I leave "Enhanced Tracking Protection" set to "Strict" but disable "privacy.resistFingerprinting" the site works.

[c22]

I have tested again with "Custom" settings and enabling all the tracking protection, the sites still work OK as long as I have "privacy.resistFingerprinting" set to false, as soon as I set that to true (and clear cookies for the site), the site breaks.

The only relevant setting here seems to be "privacy.resistFingerprinting" and the relevant cookies.

The cookies in my case on hyatt.com were:

tkrm_alpekz_s1.3 tkrm_alpekz_s1.3-ssn

Though on realestate.com.au the cookie is named differently, but there are still 2 cookies, one ending in -ssn.

You have to delete both of those cookies (not just one) and then refresh the page with "privacy.resistFingerprinting" set to true in order to reproduce this.

I've also noticed that once I have those cookies, I can turn the setting back on and seemingly use the site just fine until the cookies expire or are cleared.

[c22]

OK I did some additional digging..

I believe all these sites are "protected" by a product called "Kasada Bot Defense" from here https://www.kasada.io/product/

The sites all exhibit the same behaviour.

1. Visit the site and get a 'x-kpsdk-ct' response header and two cookies with similar names (one ending in -ssn).
2. Early on in the page, a request to ips.js will be made, this is a heavily obfuscated script which presumably tries to do some fingerprinting. The script always seems to start with KPSDK.scriptStart=KPSDK.now().
3. The script will initiate an xhr to an endpoint typically ending in /tl and return updated cookies to the above mentioned cookies, and the response will also contain additional "kpsdk" headers.
4. Presumably based on these cookies, you will either get a 429 and a blank page, or you will be allowed into the site.

The only thing that affects me getting a 429 is the "privacy.resistFingerprinting" setting mentioned above and I really think that Brave Browser maintainers have already figured out what was triggering this, at least in Brave, as mentioned above. My guess is Firefox is doing something similar.

I also managed to find more sites that seem to be using this KPSDK/Kasada product and they exhibit the exact same behaviour and symptoms as described.

https://www.crocs.com/ https://www.canadagoose.com/ https://wbiprod.storedvalue.com/

[softvision-raul-bucata]

Thanks for the extra info. I was able to reproduce the issue by following the steps to reproduce. Since a default pref was changed and we are actively investigating issues with privacy.resistFingerprinting enabled, I will move the issue.

Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=1885101

Tested with:

Browser / Version: Firefox Release 123.0.1 (64-bit)/ Firefox Nightly 125.0a1 (2024-03-12) (64-bit) Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as with the pref set to false

Moving this to Bugzilla.

[inv_11/2024]