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

I think bookmarks is a fine analogy to the capability, but I think user confusion is likely to be very present here. If you're used to "apps" between self-contained software that you download from an app store, or from a web site, it might seem very surprising that state about you at the time that you indicated an interest in installing them is embedded in the app -- even after clicking a button like "clear local state". 

Related: deleting a bookmark might be understood as a non-destructive action in a way that deleting an app might not obviously be similar. One option is to frame these installed web apps as bookmark-like things, and UAs can tell users that to clear cookies for this app, we'll just delete it and open up the site's home page in your browser so you can access it again. Or, we can advise sites that apps shouldn't embed user-specific identifiers this way and try to take measures (probably measures outside of a single browser, and they'd be tricky, but possible through some observatory-like thing) to try to detect it and discourage it. But I get the impression we need to decide which is the goal.

I also wonder if some isolation of local state is important here. If I install an app that has an identifier embedded, maybe I can be taught that it's like going to a bookmark where they already know it's me, and the privacy surprise can be limited to those instances, since I'm specifically opening that app. But if the cookie jar is shared, then the risk is that cookies can be re-spawned in such a way that I'm tracked whenever an embedded resource from the same domain is included in any page that I subsequently browse. That's a common experience of Web browsing today, but it would be an extension if items presented to the user as different "apps" also had a shared state, and one that could be persistent just from having "installed" one of them. I think isolating state would be an advantage we could embed in to the design, and it would also substantially limit the risk of surprises from `start_url` identifiers.

-- 
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-482450887