Privacy of Geolocation Implementations

Here is my position paper, “Privacy of Geolocation Implementations” (PDF ~500K), that I prepared for the W3C Workshop on Privacy for Advanced Web APIs.

UPDATE: the presentation slides are now available.

It’s a little bit drafty, so any feedback or comments welcomed. I will republish as a HTML file soon.

Investigating privacy in depth has been one of the most interesting things I’ve done in a long time… though it has left me a little bit creeped out. Hopefully I’ll get around to writing a bit more about what I read, what I’ve learned, and what practical changes I’ve made.

5 thoughts on “Privacy of Geolocation Implementations”

  1. > because of the Internet [end of intro]

    Nope: surveillance cameras, credit card, cell phone logs are all used by police, preferably before having to scare off those Californian freetards at InternetHippies, Inc. What you digital or searchable database, maybe semantically-informed database if you consider the recent ad “We help catch muggers by tattoos“ by IBM.

    > if they understood the consequences

    I know that’s a quote, but I much prefer Scheider’s more reasonable take that those had little to no visible consequence to most people so far, and that they behave rationally by not freaking out. Don’t assume lack of ethics where a lack of knowledge suffices; and don’t assume the majority of the people are wrong not to care.

    Solove forgets to mention that most users have no idea who can see what information: Facebook tried to implement something imperfect, but by defending reader’s privacy you prevent the most useful aspect of control: illustrated feedback.

    > how their location is being derived

    It is relevant? (Apart from having a third party access Personally identifiable information during the query.) The information is provided as is, and Apple presumably guarantees enough anonymity.

    > changing the geolocation provider

    That’s a competition issue, not a privacy one—and Apple’s pretty much a monopsony, so I don’t think it’s a problem. It’d be one if you consider a possible interference from US Armed forces with Apple, though.

    More generally, I’m not sure that debate at the website level is relevant: once they have location, they have the technical means to abuse it, while Apps are controlled against those. Trust is alas the only option there — and possible deniability would be interesting to explore, however, some services (namely, FourSquare) use iPhone location as a trustworthy option, and offer deniability below that.

    I believe the real issue is with Terms of Services: short of having the entire website hosted in a controlled environment (Google AppEngine, Amazon E3C, etc.) they are not enforceable; more importantly, they are a UX nightmare — so I believe you’d rather focus on a legalese-to-plain-icons translator for those. I’ve seen couple of Privacy scanners implemented as bookmarklets; maybe reading LBS ToS would help identify key issues and implement something similarly simple?

  2. Bertil, re: 1… how about “Bottom line is: because of computers, the Internet, the mass of data third parties are recording, maning, and sharing about us, and a lack of protection and education about privacy, our privacy and reputation is more at threat than at any other time in human history”?

    Re: is it relevant?: It is relevant, I don’t want my data being sent over the wire unencrypted.

    Re: changing location provider, same as above. If Apple drops Google as a provider (and swaps to, say Yahoo!, which I don’t trust), I should have the ability to change back to Google. Also, regarding Terms of Services, see [8] in the paper. But yes, this has not all been tested in an actual court, AFAIK. Regarding icons, the Mozilla guys’ paper is about that, I think. See

  3. That’s a decent paper, and could perhaps serve as a motivating force for improving the understandably immature implementations of geolocation privacy mechanisms we have today.

    I’m somewhat surprised that Chrome has a more transparent and flexible privacy mechanism than the other browsers compared (two methods of modifying access rights: centralised interface and the on-the-fly activity indicator, etc), given the popular contention that Google’s thirst data collection may not be in the best interests of individual privacy. On the other hand, I’m not surprised that Apple’s privacy mechanism in Mobile Safari is somewhat poor.

    One thing that seems to be missing from the paper is a summary scoring of the browsers across the different privacy needs – accessibility, control, confidentiality.

    1. @oisin, yes, you are correct that the paper would benefit from a discussion in those terms. I did that for the actual presentation I gave at the W3C workshop. I will publish those slides now.

      [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

Comments are closed.