[Webkit-unassigned] [Bug 189580] Intelligent Tracking Prevention 2 for Single sign-on

[bugzilla-daemon at webkit.org]

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

--- Comment #6 from John Wilander <wilander at apple.com> ---
(In reply to Ed from comment #5)
> > We are working with Mozilla to get the Storage Access API standardized.
> is there any way to see the progress? or even to participate?
> 
> I can describe what we want and our current data (and cookies) flow
> 1) we have following domains: main-example.com and example.com. They belong
> to the same company.
> 2) user logs in at main-example.com  (this sets session_cookie on
> main-example.com)
> 3) (after some time) user goes to example.com 
> 4) example.com makes CORS request w/credential to main-example.com gets
> user's info and displays it (for example it shows user's avatar). 
> As you can see there are no interactions with user so we cannot use storage
> access api and it seems like there is no way for example.com to get user's
> information (except maybe for HTTP redirect which is really bad for UX and
> may not be possible with some sites due to architecture limits)
> 
> this way we "share" one session between all our site (we have more than 2)
> which achieves following
> 1) makes user's life easier (no need to login multiple times + you always
> logged in with the same user profile and therefore there is no need to
> always keep in mind where and how you are logged in)
> 2) keeps user's sessions secure: only main-example.com has access to
> HTTP-only session_cookie and therefore there are less places the this cookie
> can be compromised (compared to every site setting it's own cookies). Plus
> we can implement required security policies in one place.

Understood. And we hear others that have similar setups. But what you’re describing is the exact same technology that’s used for cross-site tracking. Any solution we come up with has to keep the user protected in the presence of adversaries. Thus, passively allowing main-example.com access to its cookies under example.com does not work if main-example.com shows up as a third-part under multiple websites.

-- 
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/20180927/4ca4e281/attachment.html>