3 ms·

Making the location fuzzy was a notion I had - it's still not great. One problem here is doing location name without calling any external APIs. We store all pla

Making the location fuzzy was a notion I had - it's still not great. One problem here is doing location name without calling any external APIs. We store all place names in the app. Not ideal.

hackuser 11y ago
How about four options: ( ) Accurate location ( ) Fuzzy location (within 4 miles) ( ) Super-fuzzy location (state/country and time zone) ( ) No location
- daviddahl 11y ago
  yes! that is a much better set of options. I will file an issue.
  - darkmighty 11y ago
    How are you doing fuzzy locations? You're probably not doing it this way, but note that just adding a random 4 mile radius vector to the users location in insecure (against multiple samplings), you need to quantize it to a fixed set like a 4 mile grid or something like that. I remember tinder made this mistake and you could locate users very precisely anonymously.
    - johann28 11y ago
      Grids are problematic because one can observe you at the boundaries, moving from one cell to another, so there are moments when you are very accurately localizable.
      - darkmighty 11y ago
        Ah yes good point (you'd be briefly localizable to a line), you'd need to add some hysteresis and delay for dynamical targets. So something like shown_pos(t) = mode(quantize(pos(t-j)),...,quantize(pos(t-j-k))) For some delay j and hysteresis k.
    - daviddahl 11y ago
      The dataset of all towns in the world with > 1000 inhabitants is bundled into Kloak. The GPS location was originally highly accurate, but we rounded down to 2 decimal places. So if your GPS coordinates match the center of the city (rounded down), a place name can be generated. It basically will place you near the center of the closest town, again, its naively rounded to 2 decimal places. I want to go back to make this code a bit more sophisticated, with more choices for the user.
      - darkmighty 11y ago
        Yea just rounding the coordinates is problematic at high latitudes. Curiously, the problem of finding a "nice" quantization set on the sphere is a well known mathematical problem called Spherical Coding [1]. But you don't need anything this fancy I guess, you can just round the coordinates if the latitude is less than e.g. 60 degrees , and if above you chose another pole and round the coordinates with respect to the second pole. It would probably be a good idea to add some hysteresis as suggested below too (so you're not localizable when you're at one of the edges). Then you can give it some fancy name like "Advanced location privacy protection" :) http://mathworld.wolfram.com/SphericalCode.html http://mathworld.wolfram.com/SphericalCode.html https://en.wikipedia.org/wiki/Tammes_problem https://en.wikipedia.org/wiki/Tammes_problem

Making the location fuzzy was a notion I had - it's still not great. One problem here is doing location name without calling any external APIs. We store all place names in the app. Not ideal.

hackuser 11y ago

How about four options: ( ) Accurate location ( ) Fuzzy location (within 4 miles) ( ) Super-fuzzy location (state/country and time zone) ( ) No location

daviddahl 11y ago
yes! that is a much better set of options. I will file an issue.
- darkmighty 11y ago
  How are you doing fuzzy locations? You're probably not doing it this way, but note that just adding a random 4 mile radius vector to the users location in insecure (against multiple samplings), you need to quantize it to a fixed set like a 4 mile grid or something like that. I remember tinder made this mistake and you could locate users very precisely anonymously.
  - johann28 11y ago
    Grids are problematic because one can observe you at the boundaries, moving from one cell to another, so there are moments when you are very accurately localizable.
    - darkmighty 11y ago
      Ah yes good point (you'd be briefly localizable to a line), you'd need to add some hysteresis and delay for dynamical targets. So something like shown_pos(t) = mode(quantize(pos(t-j)),...,quantize(pos(t-j-k))) For some delay j and hysteresis k.
  - daviddahl 11y ago
    The dataset of all towns in the world with > 1000 inhabitants is bundled into Kloak. The GPS location was originally highly accurate, but we rounded down to 2 decimal places. So if your GPS coordinates match the center of the city (rounded down), a place name can be generated. It basically will place you near the center of the closest town, again, its naively rounded to 2 decimal places. I want to go back to make this code a bit more sophisticated, with more choices for the user.
    - darkmighty 11y ago
      Yea just rounding the coordinates is problematic at high latitudes. Curiously, the problem of finding a "nice" quantization set on the sphere is a well known mathematical problem called Spherical Coding [1]. But you don't need anything this fancy I guess, you can just round the coordinates if the latitude is less than e.g. 60 degrees , and if above you chose another pole and round the coordinates with respect to the second pole. It would probably be a good idea to add some hysteresis as suggested below too (so you're not localizable when you're at one of the edges). Then you can give it some fancy name like "Advanced location privacy protection" :) http://mathworld.wolfram.com/SphericalCode.html http://mathworld.wolfram.com/SphericalCode.html https://en.wikipedia.org/wiki/Tammes_problem https://en.wikipedia.org/wiki/Tammes_problem