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

Thanks for the considered thoughts @othermaciej. Note that this issue is [already explicitly called out in the spec](https://www.w3.org/TR/appmanifest/#privacy-consideration-start_url-tracking) with recommendations to implementers - it certainly isn't being ignored.

However, I'm not really sure we can say that "tracking via bookmarks" is more likely be noticed or easier than using the start_url given the flexibility of URL processing. Specifically, the identifying token need not be consistent - each navigation, new, random, but still uniquely identifying tokens could be generated for every single in-scope link to create obfuscation - and these IDs don't have to just be in the query string or fragment identifier, as @mgiuca pointed out.

Concrete example: Stack Overflow's canonical question URLs are of the form `https://stackoverflow.com/questions/15476907/recommended-usage-of-stdunique-ptr`. However, the URL still resolves correctly with any arbitrary text after the question ID, e.g. `https://stackoverflow.com/questions/15476907/id-goes-here`. Each navigation that text can be changed in a way that still uniquely identifies the user.

Indeed, Stack Overflow also generates links where the user ID is appended to the end of the question ID (see `https://meta.stackexchange.com/questions/164194/is-there-a-way-to-shorten-stack-overflow-urls`), which is a case where the identifying token is even more difficult to discern through observation.

In general, one challenge with mitigations here is that they would be straightforward to overcome for sufficiently motivated parties - at the expense of eliminating very legitimate use cases.

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