On 10/09/13 02:13, Brian Smith wrote: > On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson <[email protected]> wrote: >> Google's Location Service prevents people from tracking individual access >> points by requiring requests to include at least 2-3 access points that >> Google knows are near each other. This "proves" the requester is near the >> access points. > > I assume by "prevents people from tracking individual access points" > means the following: Some people have a personal access point on them > (e.g. in their phone). If somebody knows the SSID and MAC of this > personal access point, then they could track this person's location by > polling the database for that (SSID, MAC) pair. Google tries to limit > this type of abuse as much as practical while providing still > providing a location service based on such crowdsourced data.
Actually, it more means: "prevents people from figuring out where their ex-partner moved to". The database update frequency is not sufficient to worry about real-time tracking of mobile phones. > MAC addresses are 48 bits. SSIDs are often guessable or predictable. > Therefore, using the H(MAC+SSID) instead of just the plain MAC+SSID is > not buying you much in terms of privacy, IMO. It is, because raw SSIDs are personal information, and being unable to separate the two pieces reliably means that neither is retrievable. > Basically, if you are > really trying to use this as a privacy mechanism then you should store > the MAC+SSID according to best practices for storing passwords. For > example, use PBKDF2 with a large number of iterations. What's the threat model here? If I hash MAC+SSID, someone could say "OK, if the SSID happened to be "linksys", then the MAC would be "12:34:56:79:90", but how does that help them at all if they don't _know_ that the SSID is "linksys"? > If you know the MAC+SSID of person X's personal access point and the > MAC+SSID of person Y's personal access point, then you can use this > database to ask the question "are person X and person Y in the same > location?" This seems bad. Can you envisage a scenario where one might know this information, but not the shared location? (Note that mobile access points are fairly well excluded by the protections Chris outlines.) > I think that these things are much more important than the protection > offered by H(x). My concern is that if you store the data on the > server as H(x) then you will not be able to do the above filtering on > the server unless H(x) is ineffective. I believe the plan is to have a database of raw findings, then a processed database used by the web service, and a published database which may have even more data reduction. Chris P: can we get permission to store the raw SSID in the _unpublished_ database? Gerv _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
