On 5. März 2014 11:47:17 MEZ, "André Fiedler" <[email protected]> wrote:
>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

Sadly doesn't do the trick, as mozstumbler now stores entries in a database so 
that you could upload the data days later together with other routes and it 
uploads the data in batches of 500 I think (maybe less but you won't be able to 
separate different routes server-wise)...

And this would probably exclude data if the gps failed for a short amount of 
time (tunnel) -> two points are widely spread

How big do you want to let those gaps get? (maximal length)

@chris
A user login sounds nice to me as well ;)
You could make an opt-in to prove the genuineness of your uploads by linking 
them to your account. -> the server should prefer those for it's guess of the 
users location and don't accept submits if they are far away from a proved 
location but contain a wifi with the same bssid (as it could be a random number 
of a bot uploading fake data)
-> this could lead to a failing detection of moving wifis though if there are 
not at least two proved entries (maybe even of the same uploader)
-> solution: client could detect such movements as well (was suggested on 
github already) and ignore them client-side

Felix
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation

Reply via email to