-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are a lat/lon/zoom triple in a URL decoration/tracking? #4
Comments
I agree with the above text, but I meant the issue to be more broadly about links that are decorated with privacy-harming values that are not user ids:
#2 in particular is related to, but different from how we've talked about navigational tracking so far. Curious what others think about whether that should be discussed at all in this project |
My initial guess at a definition says that these are link decoration if they don't affect the page the user wanted to navigate to. So, I think adding a lat-lon that's consistent enough across navigations to link storage areas or reveal sensitive information would have to be independent of the user's choice of destination page, and so would count as link decoration. If the lat-lon does control the page the user winds up seeing, as it does in the case of mapping sites, the only scheme I can think of for linking storage areas is to embed data in extra digits that themselves don't change the page the user winds up seeing. Do you see another way? My current understanding of navigational tracking is that it wouldn't include |
https://github.com/privacycg/nav-tracking-mitigations/pull/2/files#r703666279 questions whether the parameters in https://www.google.com/maps/@37.4220328,-122.0847584,17.12z should count as link decoration. The numbers do not encode user-identifying information, and modifying them to embed a user ID wouldn't successfully communicate a user ID to anyone (since nobody's listening within google.com/maps to decode the user ID). But it's hard for an automated system inside a browser to prove that, and even hard for humans reading the URL to be confident of it.
The text was updated successfully, but these errors were encountered: