Re: [w3c/manifest] Privacy Review: handle start_url tracking (#399)

@dominickng @benfrancis Is there documentation or a little more detail on the authentication (or other) use cases that are broken by using a separate cookie jar for an installed web app's origin? I fully believe those problems exist, but I could benefit from learning more. In particular, I thought the OAuth dance was specifically designed so that the user authenticates with the authenticating site in a browser navigated to the authenticating site rather than through shared cookies.

Are implementations of installed web apps currently staying in scope when the user browses to a link outside the app's scope? That seems surprising to me as a user, and I'd be curious to learn the motivation for that design choice. Why not just have an installed web app that operates in its scope and when users click a link to another origin it opens in the user's web browser, like with other installed apps?

Maybe we're getting confused by the definition of separate storage. It seems like one feasible approach that @marcoscaceres may be describing is that at install-time data from the origin is copied (or started fresh) to a new cookie jar for the installed web app, but that if you subsequently clear all data from that origin in your browser then you're still logged in in the app but not in the browser, even after you open the app again. This may be the current implementation in mobile Safari/iOS.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/399#issuecomment-634776659