We could validate the uploaded data set before storing it. We should check if the
location points in the data set are "one after another" or if they are widely
spread. Something like:
dLatitudeAverage = ( ( p[1].latitude - p[0].latitude ) + ( p[2].latitude -
p[1].latitude) + .... ) / p.length
dLatitude = dLatitudeAverage * 1.5;
for(i = 1; i < p.length; i++) {
d = p[i].latitude - p[i - 1].latitude
if(d > dLatitude) {
goto fail;
}
}
Am 05. März 2014 um 00:25 schrieb Chris Peterson <[email protected]>:
On 3/4/14, 2:59 AM, André Fiedler wrote:
And if someone feeds real world data, but does:
latitude + random()
longitude + random()
?
Wouldn't it mess up the geolocation service? Maybe 1 out of 100 won't
mess it up, but 1 out of 2 will.
This is a tough problem. The server can't really trust the data
submitted from stumbler clients because malicious people could modify
their stumbler code or write bots to upload bogus data. We could require
stumblers to register a user account, but storing user data in
connection with location data could be a slippery slope for privacy.
Fortunately, even if the database is flooded with bogus data, someone
using (say) a Firefox OS phone to geolocate their position with query
the server with the nearby Wi-Fi BSSIDs. The bogus BSSIDs are unlikely
to match real-world BSSIDs, so most would never be queried. But even if
someone uploaded enough bogus BSSIDs that are matches, the server is
still going to compare multiple Wi-Fi AP positions and if one is
suspiciously far away from the others, we can ignore it.
Real-world data is messy, so I'm definitely interested in hearing other
ideas people have for cleaning up the data on the client, server, or
database side. :)
chris
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
