[Webkit-unassigned] [Bug 209586] New: recent ITP changes causes breakage for seamlessaccess.org

[bugzilla-daemon at webkit.org]

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

            Bug ID: 209586
           Summary: recent ITP changes causes breakage for
                    seamlessaccess.org
           Product: WebKit
           Version: Safari 13
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: leifj at sunet.se

Hi,

The seamlessaccess.org project aims to improve the login user experience in the case when the user needs to select among a large number of IdPs (aka the NASCAR problem) without revealing any personal information to the site before the user has decided to proceed through an authentication flow via an external IdP. 

Our approach to the UX is to only force the user to identify (typically through search at seamlessaccess.org) their most commonly used IdP once and remember that and provide a way for sites to initiate a login flow to that IdP without learning the IdP until after the authentication response comes back to the site. 

Our current implementation (which we believe suffer breakage as a result of recent ITP changes) stores the users choice of IdP in localStorage at seamlessaccess.org and we provide a component for inclusion on sites which makes it possible for users to initiate a login flow. This is an approach similar to google accountchooser but unrelated to that implementation. An important difference is that we do not store any personal information (aka account) data but only the public URL of the IdP.

The part that seems to break under recent ITP changes is that we provide a login button as an iframe component (our implementation uses zoid) which displays the login choice to the user but without exposing the information to the top page; the component iframe wraps an inner iframe with which it communicates using postMessage calls to retrieve the IdP choice. The top page is not providing an API into the data displayed in the iframe and only after the user has clicked the button does the login flow eventually reach the site.

- We are aware that our service *could* track users if we wanted to. We rely on community audit and oversight to ensure that we behave responsibly.
- We understand that our pattern may be indistinguishable from sites that engage in predatory tracking behaviour
- We understand that we may need to find other ways to implement our pattern.
- We believe that switching to the recommended oauth2 flow would actually increase the amount of trackable state available about users in the whole system. Currently the service has no information about who the user is other than which IdP they have chosen to use.

We do not see what mechanism is available to us now or in the near future for the webkit platform to achieve our goals while maintaining user privacy.

Please advise.

-- 
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/20200326/fb7686d4/attachment.htm>