(In reply to Tom Ritter [:tjr] from comment #3)
To me, this seems very related to the HSTS supercookie problem.
I think the attack is different to HSTS: HSTS was a passive attack in which the user had no control or knowledge of what was going on - they also didn't have a means to inspect the requests of an origin.
With manifest, it's different because manifests are literally just a bookmarking mechanism. A presupposition with manifests is that:
- a web application is installed via a user gesture (same as a bookmark, a user has to access a menu, click on thing, etc.).
- The start URL should be inspectable and changeable (same as a bookmark).
However, if the browser was to passively install PWAs without user consent, then yes... this would be a problem. However, I don't think we have any plans to do passive installation of web applications (e.g., into the new tab page). But if we do, then this becomes a concern
This is similar to any other passive bookmarking mechanisms, like "top suggestions" from the awesome bar. But if those get cleared when you clear history, so would these. Will add a screenshot.
If we restricted start_url to be a top level domain (like Bug 1447011), we would push the economic cost for attackers to be too expensive to track everyone.(In reply to Ehsan Akhgari (:ehsan) from comment #4)
Marcos, do you think such a restriction could fly for start_url?
Again, because installation requires user interaction (via an installation ceremony of sorts) I think the cost to attackers is already significantly high. Chopping the start_url seems like it would limit the utility of the feature significantly.