[Webkit-unassigned] [Bug 266744] New: Safari 17+ Anti Tracking feature breaks walmart.com OAuth

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 20 16:45:49 PST 2023


https://bugs.webkit.org/show_bug.cgi?id=266744

            Bug ID: 266744
           Summary: Safari 17+ Anti Tracking feature breaks walmart.com
                    OAuth
           Product: WebKit
           Version: Safari 17
          Hardware: All
                OS: All
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: Platform
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cdaringe at gmail.com

- A clear description of the problem

Users cannot login via walmart.com.

In Safari 17+ private browsing sessions, all query params are stripped during cross-domain navigation, breaking critical OAuth authentication flows for Walmart business.

- A step-by-step set of instructions
I posted this report to Apple Feedback via FB13481858, however, it may be more appropriate to post here. Please assist in closing whichever report is less relevant, and engaging in the report that is more relevant.


> What does the Safari issue you are seeing involve?

Private Browsing

> Please provide the URL to one or more websites where you are seeing this problem:

https://www.walmarthealth.com/vc/getVirtualCare

> What extensions or content blockers do you have enabled?  Example: AdBlock, 1Blocker

None

> What time was it when this last occurred? (Example: 12:00 pm EST 02/14/2018)

Dec 20, 2023 at 12:21 PM

> Please describe the issue and what steps we can take to reproduce it:

Perform the below steps inside and outside of Safari's private browsing mode.

1. Visit a Walmart owned web URL, such as https://www.walmarthealth.com/vc/getVirtualCare
2. Click the “Login” button.
2a. When clicked outside of private browsing, the visited URL should take the general form: https://www.walmart.com/account/login?client_id=OAUTH_CLIENT_ID&state=RETURN_STATE&redirect_uri=RETURN_URI&scope=OAUTH_SCOPE&nonce=NONCE. These query params are clearly used for authentication, not for tracking purposes.
2b. When clicked inside of private browsing mode, all critical query params are removed, breaking OAuth capability.

- What result you expected

I expected my URL search parameters to not be deleted.

- What results I saw

Safari removes critical authentication inputs from the URL search params.
The end result is that my OAuth workflow does not complete, and the user does
not return to the OAuth integrating site with the expected OAuth datas needed
by the OAuth integrator.

- Research

It was just shared with us (mid report) that https://webkit.org/tracking-prevention-policy/ calls out “unintended impact” for “Federated login using a third-party login provider.” We can investigate alternate mechanisms, however, even our most-web-aware experts were caught by surprise by deleting this foundational browser I/O mechanism. Other documents in the apple ecosystem have stated that the feature removes known tracking queries. Can a known set of OAuth params be permitted? What guidance do you have for us as consumers of standard web APIs to implement standard web flows for which you no longer support?

"We may alter tracking prevention methods to permit certain use cases, particularly when greater strictness would harm the user experience". Breaking logins by altering web standards seems like harming the user experience, albeit this is certainly perceived as subjective given the nature of the entire feature.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231221/a08abb32/attachment.htm>


More information about the webkit-unassigned mailing list