There are a few reasons why the export is limited to cells: 1) the bssid/mac exposes the company that produced the product and maybe even the product type, which is bad. If MLS would offer this data for download, then attackers could filter a region for vulnerable routers (vulnerable for certain exploits) MLS would be more accurate than shodan...
2) if there are less observations at one place then this data could expose a stumbler's home/working place or whatever (privacy concerns) There might be more reasons. We would need a way to apply the 2/3 atleast rule for the offline data to offer such data correctly. (atleast 2/3 means at least 2 or 3 wifi aps have to be guessed correctly for an area so that it is sure that the user is at this position) Regards, Felix On 3. September 2014 18:26:09 MESZ, Adrian Custer <[email protected]> wrote: >Hello Hanno, > >Thanks for your response. > > >You are right that I failed to understand that you were proposing an >API >whose primary concerns were sharing with OpenCellID and maintaining >backwards compatibility with their existing format. > >Unfortunately, those goals directly conflict with the other goals I >have >heard related to sharing the data in the database with the contributors > >to MLS and related to the other two goals you outline in your message. >Hence, my confusion. > > > > >You have promised us, from earlier in the project, an API to get access > >to the data we were contributing, although only a distilled version >because you have some privacy concerns about the raw data. I had been >expecting you to meet that promise. I have already stated and will >repeat in a different way below, the data offered by your current API >do >not meet this promise: the export data lack a 'horizontal accuracy' >estimate and other data quality metadata required to use summary data >rather than raw observations. The export data also lack any information > >whatsoever of the contributed wifi data. So this is not the export API >I >feel you have promised the community. > >Furthermore, your second and third points do not seem to be met either >by your current API. > >On 9/3/14 11:09 AM, Hanno Schlichting wrote: >> Hi Adrian, >> >> thank you for ... >> >> There are three main use-cases for the data format today: >> 1. Allow a data exchange between OpenCellID and MLS >> 2. Allow anyone to download the data and run their own instance of >ichnaea with the same data we have in MLS >> 3. Allow community members to help validate, visualize and play with >the current data > > >The second point suggests we could download your API and run an ichnaea > >service. However, the Service API defines, in >https://mozilla-ichnaea.readthedocs.org/en/latest/api/index.html#geolocate >, that > A successful result will be: > > { > "location": { > "lat": 51.0, > "lng": -0.1 > }, > "accuracy": 1200.4 > } >which means we must be able to go from the exported database to an >estimate of horizontal accuracy, something my earlier message suggested > >was missing and could only really be done well from the raw data you do > >not share so should be present in the export. But perhaps I am wrong. >Do >you actually have a running instance of your service using data >exported >via your API? If so, how do you generate the horizontal accuracy >estimate in the API from the export database values? > >Your third point suggests that you expect this data to serve the >community to 'help validate, visualize and play with the current data'. > >However, for evaluating data quality, you can see that the number of >observations 'samples', and the antenna range estimate 'range' are >insufficient. As an example, we can look at Montevideo, Uruguay where I > >have contributed the vast majority of the data to both services so we >are not treading on any one else's privacy toes. OpenCellID provides a >great visualization tool to let you see where it estimates the antennae > >locations and lets you see the observation locations it used to make >that estimate. Looking at: > >http://opencellid.org/#action=filters.GPSPositions&mcc=748&mnc=7&zoom=16&lat=-34.92149&lon=-56.16738 >you see a bunch of markers. If you click on the marker at the top >right, >you will see it is placed in the middle of a linear set of >observations. >(The map will move a little.) If you click on the marker inside the >water, you will see that it is sharing observations on both side of the > >small bay. Both are wrong for different reasons: the first because >there >is no off-axis observation to anchor the collection set, the second >because the antennae has a long line of sight across open water and the > >position estimate is unconstrained. The data your API offers do not >provide sufficient information for me to filter the position estimates >for quality. The antenna to the right of the 'Facultad de ingeneria,' >for example, is pretty close to being in the right place: the >observations used in the estimate have a good spatial distribution >without gaps between observation and antennae position estimate. So, >with the OpenCellID web service, I can individually identify the >quality >of each location estimate. I don't see how to do anything vaguely like >that with the exported data format. > > >As for your argument that you want to keep bad names for compatibility, > >it conflicts directly with your argument that the names don't matter >anyhow because this csv is a positional API. No matter, yours is not >the >first API with poor names nor will it be the last. I had again assumed >you were interested in making great API without knowing that your >backwards compatibility goal came first. > > >Maybe in the future your API will eventually evolve to meeting the >goals >you set for yourself and being of use to analyses like the kind I >envision. I had assumed there would eventually be some way to use your >data export to make a wifi density map of Montevideo. I had also >thought >there might be some way for me to flag the cell antennae with >inaccurate >spatial location to go make further stumbling passes nearby. Both are >trivial analyses, neither appear possible with the current export data. > >Fortunately for me, I have been stumbling in the latter half of my >survey of Montevideo with my own tool that gives me access to my own >raw >observations so I can use my own observations directly. > > >Unfortunately, I have grown discouraged by the attitude in this >project. >There seems remarkably little bandwidth dedicated to fostering >collaboration (or perhaps simply little interest). Personally, I have >done way more than my fair share of trying to persuade others to >standardize on a great, correct, standardized API. So if you are happy, > >fantastic. As for me, my time seems better spend on other efforts >absent. > >Good luck in your work and have great fun, > ~adrian > >_______________________________________________ >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
