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

Mandating separate storage at the spec level seems a pretty heavy-handed way of addressing this issue. It would cause a number of other (not necessarily desirable) ramifications that greatly affect the utility of web apps. For instance:
- let's say you use a web app for a while in the browser, and then you install it. After installation, the web app loses all of its existing local state, including cookies, local storage, service workers, offline cache, etc.
  - there's no sensible way to migrate everything to the new storage unless you copy the entire ETLD+1's cookies and the whole origin's worth of data, which may include way more than the web app actually owns
  - assuming you've figured out that copy manoeuvre, do you then delete the stuff you copied?
- OAuth is broken (or otherwise severely crippled) as the 3rd party OAuth providers won't be logged-in within the new storage partition.
- what backing storage should off-scope browsing within the installed web app use? The browser storage? The web app's storage? Both have undesirable consequences for reasoning about where the user's data is. If you use the browser storage, you then break OAuth even more (you'll be logged into the browser storage but not in the web app storage).

This isn't to say that separate storage for installed PWAs is a bad idea - we've debated applying this policy in Chrome for *years* now as a way of addressing privacy concerns. However, the questionable user and developer consequences are why we think separate storage for browser-installed web apps is not really viable.

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