yeah, they would be able to use data beaconDB publishes as it will be licensed under CC0
yeah, they would be able to use data beaconDB publishes as it will be licensed under CC0
NeoStumbler v2.0.0 has been released, featuring passive data collection, options to reduce uploaded metadata for your privacy, and a new interface for browsing collected data.
More info here: https://github.com/mjaakko/NeoStumbler/releases/tag/2.0.0
Last year, Mozilla stopped to operate their widely used network location service "Mozilla Location Service" 😐
In order to ensure a continuity of service in /e/OS, we have replaced it by an anonymizer proxy service of our own to the HERE network location service.
Since then, a few initiatives have started to provide alternatives. One of them, BeaconDB, can already be tested in recent /e/OS builds 💪
We'd love to hear from /e/OS users' experience about it! 🙏
👇👇👇
https://community.e.foundation/t/requesting-user-feedback-by-testing-beacondb/68328
@beacondb the AirPort Utility app has a share sheet button for access point details if you enable the wifi scanning feature in its settings, including full data which no other app on ios to my knowledge actually has full access to lol
think i mightve just done the first submission to @beacondb from an iphone (without jailbreak too, without a custom app, entirely from a shortcut lol)
Definitely not convenient, at all, but it is possible kinda!
Some progress mapping for @beacondb using NeoStumbler on my Pixel 9 running GrapheneOS :D
It ain't much but it's honest work (and I can already use it to get pretty good geolocation accuracy on my Laptop running Fedora Linux)
Blog post on Maps and the upcoming GNOME 48 release
TIL about @beacondb
This is one of those projects that reminds me of the early days of #openstreetmap, when the dataset was sparse and parts of the road network weren't fully mapped.
Contributing is really easy. Just run one of the apps listed on the homepage and take a walk around your neighbourhood.
@hipsterelectron there hasn't been a definite plan put in place yet in terms of obfuscating the data, I've shared a few ideas around in the matrix room, and theres been some recent discussion here if you're interested: https://codeberg.org/beacondb/beacondb/issues/68
@sim6 has written a patch that should help remove outliers and increase the reliability of both WiFi and cell tower based estimates! ❤️
If you notice that BeaconDB seems to be returning an IP-based estimate when you expect it to have enough data to give a more accurate WiFi based estimate, please let me know so I can take a further look :)
On the otherhand, hidden SSIDs are already reasonably common, you'll find them in some security camera systems and sound bars, so it's not as obvious. I believe BeaconDB is currently the only database that supports opting-out with a hidden SSID.
Unfortunately this isn't a perfect solution as some devices will then constantly be asking if any APs match your hidden SSID, which is identifiable. It's often used in WiFi fingerprinting to track customers as they move around a store.
Yes, BeaconDB respects _optout and _nomap. It also completely ignores WiFi APs if they have a "hidden" SSID.
In my opinion, adding _nomap or _optout to your SSID is not a great solution for opting-out, as it's extremely obvious to anyone nearby. It's kinda like putting a sign up on your lawn to opt out of Google Street View.
@pixelschubsi @yayacout Yes, definitely not automatically editing the map, and I agree the dataset would still be delayed from ground truth.
I like to think it would be used in a similar way to how the OSM community has access to Bing's street view data, making it easier to map POI in far away places - only it's not woefully out-of-date as it is much easier to collect.
Though the point you raised earlier about the privacy policy stating data would only be obfuscated may make this idea difficult too.
Another use case I am quite interested in is using the data BeaconDB already has to create a public domain business location dataset, which would be based on the presence of certain WiFi SSIDs.
This could then be used by projects like #OpenStreetMap to help identify if a certain business still exists, identify missing locations, and in general just keep OSM more up-to-date as WiFi data is so much easier to collect at scale.
@beacondb @yayacout
As soon as the data is potentially sensitive (as in this case), both storing and publishing should have use-cases in mind and the storing and publishing should be limited to exactly the data needed for those use-cases.
I personally think that it would be very sensible and with minimal restriction to use-cases if the whole system (submission, storage, publication) works with hash(SSID+BSSID) as a key. I'm happy to be convinced with use-cases where that's insufficient.
Hey folks, there has been a fair bit of discussion this week regarding what the community expects from data dumps, and I've realised that obfuscating WiFi AP identifiers may actually be interfering with what the community wants: portable, open data - not some restrictive binary blob.
How would people feel if AP MAC+SSIDs were plaintext in the dumps, instead of obfuscated like originally planned? If an AP moved, it would still be blocked from the database for at least a year to prevent tracking.
I agree that this is largely dependent on whether Apple decides to fix their server or not.
I have opened a ticket with their security team that specifically takes aim at how easy their database is to scrape. Regardless of whether they decide to take action or not, I'm sure their response will provide some insight into why they think this is ok.