Contribute Data disables Location Service

[Bridouz]

I've installed your backend from F-Droid, backend is up to date. This afternoon I wanted to enable the "contribute data" option but when I enable it the backend does not working after. Tried to disable the option it works great again.....

Don't know how to provide a logcat or anything else but would be happy to help

[mar-v-in]

Mozilla disabled the API that was used for contribution a few days ago, the usage of the alternative contribution API would require additional network traffic and thus will not be implemented in this backend.

@hannosch If Mozilla does not choose to bring the old "mixed locate/submit mode" of their geosubmit API(or an equally featured one, contribution support will be removed.

[hannosch]

@mar-v-in sorry, you implemented that weird API. It was a bad idea and it took us too long to remove it. We didn't know of anyone using it.

The old geosubmit API had three different modes:

1. You submitted a batch of reports: Response was an empty HTTP OK and data was contributed
2. You submitted a single report which had no lat/lon attached: Functioned exactly the same as the geolocate API, response was a lat/lon estimate. Since there was no lat/lon attached, no data was contributed.
3. You submitted a single report which had lat/lon attached: Data was contributed and you got a lat/lon response based on the lat/lon you submitted. In this mode no actual db lookup for cell/wifi data was done.

We only removed the weird third mode.

From a client perspective you have the following situations:

1. You don't know the devices current location (GPS lat/lon). So you call geolocate to get a position estimate.
2. You do know the devices current location. Any outside network query done here is overhead and not strictly required. If you want to contribute data to the service you can call the geosubmit API. But since these are extra requests which aren't needed, you should keep a local log and only submit them in a batched fashion. This is what the geosubmit batch mode does, though you could even send a batch with a single item in it.

So we didn't remove anything useful. When you called geosubmit with a lat/lon attached to it, you only got the lat/lon back, which you send in. That was additional network traffic which wasn't required.

[mar-v-in]

@hannosch I see. Seems I misinterpreted what the mixed API is doing.

I thought the API would allow me to:

1. Get the approximate location the same way as geolocate would do.
2. Store a single data set as if it was done using geosubmit.

In my opinion, there is use for this API, as it is handy to have multiple different data sources for privacy (not providing GPS data to some apps even if it's available), accuracy (combining different sources) and security (comparing sources can allow to find fake networks/GPS satellites/whatever). As Android apps can decide whether they wan to know the network-based location, gps-based location, both or just any, this should be honored by the system. Also note that it can happen that the location known by GPS (or any other location source) might be less accurate than the approximation provided by the Ichnaea service.

Or in short: if the user wants to know the location approximation calculated by Ichnaea, let him - and if there is already a location known to the system, why shouldn't it be used to contribute to the database?

Last time I looked at the source code I found no indices on the usage of backward feedback (usage of the approximation to submit unknown cells) in Ichnaea. I agree that this should be an optional feature (as some might not like it), but nonetheless it should be there. This could become a valuable alternative, as it will also allow to contribute without additional (client side) resource usage.

I guess the contribution done by users of this backend shows that they're willing to contribute if it's not complicated or resource hungry (both being the case with MozStumbler right now). At the end, we all want an amazing and open geolocation database, having less ways to contribute will harm that goal...

[hannosch]

As you discovered, the mixed geosubmit API was confusing, so I still think it didn't make sense in its old form.

In the future we may want to get something similar, if we can deal with getting imprecise/old position estimates together with cell/wifi data. But right now we don't deal with those, but simply trust the position to be precise. I think if we wanted to add this, we'd use the same approach that combain used and add an extra section to the geolocate API. You can see their approach at http://combain.com/api/ - choose the "Old GPS" example.

As for query based feedback, you are correct. Currently we don't have anything like this. Primarily because so far the number of pure queries is vanishingly small compared to the number of data submissions we get, and the queries we do get are almost always from the same places where we also have active contributors. But as we get more users doing normal queries, we'll start thinking about how to use those to improve the overall service. There's a good chance we'll get to this during this quarter.

[mar-v-in]

But as we get more users doing normal queries, we'll start thinking about how to use those to improve the overall service. There's a good chance we'll get to this during this quarter.

Please ping me, once this is done, so I can add it.

[rfc2822]

Is there a possibility to add contribution again?

[hannosch]

We’ve since extended ichnaea to also use non-GPS verified data to validate and extend the dataset. So by using this backend you are contributing back.

[rfc2822]

@hannosch Thanks for this information