I think we share the same desire to improve the user experience around this. I do want a way for the user to specify where they are (or want to be). For example, I am in Mountain View, Ca. However, I really want to state that I am in San Jose, Ca. when I do searches. This should be possible.

Btw, sadly websites already know that your are in Melbourne without ever having to ask you anything (they can use a technology called GeoIP. their are free libraries and databases that enable this). I would love to see GeoIP used without the users permission go away. Hopefully Geolocation in the browser will encourage web sites to ask the user before using GeoIP.

Thanks for your comments!

Please default the geolocation provider, next point-release, to *someone with less of a vested interest* in knowing exactly where we live / are / are thinking about being at / in real time / popped out for a smoko with a geolocation-sensitive website loaded on Fennec left running in my pocket by accident, I tend to do this 8:54 AM every workday, next Monday comes and there’s a friendly Zippo salesman 8:53 AM out back of work just as I step out … you see what I’m getting at. (It’s an over-the-top scenario only for the next 10 years, max, then it’ll be mainstream like radio talk-shows.)

I am most wary of the security ramifications of having geolocation directly in the browser. This is the first time I have ever considered avoiding a Firefox update. Geographic information is marketing gold, and plenty of out-of-work programmers are desperate enough to try breaking Firefox’s geolocation permissions if it means food on the table.

This doesn’t mean Firefox will not have fuzzing at some point. It just isn’t good enough for our users.

1) remember the exact location that a geolocation provider returns. The first one we see is put into preferences and not change it (*).

2) any time we are asked for a fuzzed location, we take the stored value, round/truncate the stored value to some number of decimal points, increase the accuracy on the Position object, and return that to the web.

(*) For updating the stored value, we monitor the locations being send in from the geolocation provider. When the difference between our stored location and the current location differ by more than 1/2 of the rounding value we are using, we update the stored geolocation.

For example, suppose we are rounding:

37.012601 -122.001795

to:

37.013 -122.002

We would update the stored value when the actual position moves to:

37.013101 -122.002295

A couple things:

1) this does solve the boundary problem
2) everyone in a give area would be reported at the same position

Thoughts?

Of course, all the averaging and tracking methods are moot if you only give the site location once. That would be my suggested approach. Simply avoid giving the site any more information to use. But that probably comes down to a user decision; I don’t know how to properly impress upon a user that understanding.

1 mile is pretty damned arbitrary. I’d hope that users can set their own “fuzz amount”. I’m also a big fan of SI units

One thing that this fails to take into consideration is uncertainty. Zeroing accuracy will give a false impression to the site. So you have to provide some value. Also, if you already have 3km uncertainty (common enough if you use the serving cell for location), there seems little point in further obscuring the location. All you are doing is making it worse.

My suggestion: take the point (and accuracy) as a circle on the map. Pick another circle of the required size (1 mile can be your default if you like) and put it anywhere you like, as long as it covers the original circle. Use your stored random numbers to pick the offset.

The advantage of this method is that if you get bad location information, you don’t end up making it worse.

I see no point in adding additional randomization. If you aren’t moving, the site will be able to detect the false jitter and be able to detect the randomization.

@ian yup, if you are moving, and there is only one street, someone probably could extrapolate that you are on the street and not off of the street.

>Now, these two numbers will never change, and the reason is that a website, if it sees enough of these displacement vectors, they can average them out and discover your real location. Not so good for “fuzzing”.

One approach that might help is if, on a user’s first use, you generated another random number that doesn’t change. This number would be used in generating the random numbers used for fuzzing, so that the average of the random numbers isn’t 0. (i.e. have a weighted probability distribution that’s different for every user). This way, if a website averages out many reported values to try to get some info on the user, they end up with an incorrect answer.

Why not truncate the Latitude and Longitude (perhaps randomly picking between “ceiling”, “floor”, and “round”) to something like the nearest 33rdth, 100th, 333rd, or 1000th of a degree?

33rd would leave a margin of error in the range of 1.7-2.4 km (if my math is correct), depending on user latitude. 100th would be 580-780 m. 333rd would be 190-260 m. 1000th would be 58-78 m. Those seem pretty reasonable for “my town” though “almost where I am standing”.

They could be called something cute like “Area, Neighborhood, Block, and Shouting Distance”.