[Webkit-unassigned] [Bug 202640] New: [Safari 13] Tracking blocking breaks remembering login on editor.construct.net

[bugzilla-daemon at webkit.org]

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

            Bug ID: 202640
           Summary: [Safari 13] Tracking blocking breaks remembering login
                    on editor.construct.net
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: DOM
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ashley at scirra.com

In Safari, the "Prevent cross-site tracking" setting breaks our site from remembering the user's login state. In our case I believe Safari ought to have reasonable heuristics to allow the case.

Steps to reproduce:

1. Register an account on construct.net (it's free)
2. Visit editor.construct.net
3. Choose Menu - Account - Log in
4. Enter login details, tick "Keep me logged in", and click "Log in"
5. Once logged in, reload the page

Expected result: login remembered
Observed result: login forgotten and reverts to guest state; user has to log in again

Turning off "Prevent cross-site tracking" in preferences fixes it and allows it to work again.

As a security defense-in-depth, our login form is on a different origin to the web app. The app is on editor.construct.net and the login form is on account.construct.net. Therefore the user is interacting with a cross-origin iframe, typing in their password, and submitting this to that origin. However Safari still blocks the attempt for this origin to remember the login state.

I completely understand the desire to block the ability for third-party ads to track users and similar user-hostile cases, but in this case it seems Safari has gone too far. Surely typing in your login details to an iframe ought to be considered sufficient interaction to allow storage? It works in Firefox 69, as well as Chrome.

-- 
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/20191007/d041d723/attachment-0001.html>