https://github.com/mozilla/ichnaea/issues/2065 Skip to content Toggle navigation Sign in * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Resources + Learning Pathways + White papers, Ebooks, Webinars + Customer Stories + Partners * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing Search or jump to... Search code, repositories, users, issues, pull requests... Search [ ] Clear Search syntax tips Provide feedback We read every piece of feedback, and take your input very seriously. [ ] [ ] Include my email address so I can be contacted Cancel Submit feedback Saved searches Use saved searches to filter your results more quickly Name [ ] Query [ ] To see all available qualifiers, see our documentation. Cancel Create saved search Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert {{ message }} mozilla / ichnaea Public * Notifications * Fork 139 * Star 539 * Code * Issues 82 * Pull requests 41 * Actions * Projects 0 * Security * Insights Additional navigation options * Code * Issues * Pull requests * Actions * Projects * Security * Insights New issue Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub By clicking "Sign up for GitHub", you agree to our terms of service and privacy statement. We'll occasionally send you account related emails. Already on GitHub? Sign in to your account Jump to bottom Retiring the Mozilla Location Service #2065 Open mostlygeek opened this issue Mar 13, 2024 * 23 comments Open Retiring the Mozilla Location Service #2065 mostlygeek opened this issue Mar 13, 2024 * 23 comments Comments @mostlygeek Copy link Collaborator mostlygeek commented Mar 13, 2024 The accuracy of Mozilla Location Service (MLS) has steadily declined. With no plans to restart the stumbler program or increase investments to MLS we have made the decision to retire the service. In 2013, Mozilla launched MLS as an open service to provide geolocation lookups based on publicly observable radio signals. The service received community submissions of GPS data from the open source MozStumbler Android app. In 2019, Skyhook Holdings, Inc contacted Mozilla and alleged that MLS infringed a number of its patents. We reached an agreement with Skyhook that avoided litigation. This required us to make changes to our MLS policies and made it difficult for us to invest in and expand MLS. In early 2021, we retired the MozStumbler program. We are grateful for the contributions of the community to MLS to both the code and the dataset. To minimize disruptions and allow people time to make alternative arrangements, we have created a schedule that implements the retirement in stages. The retirement plan can be tracked in this issue. There will be five stages. 1. As of today (Mar 13th, 2024) we will stop granting new API access keys. All pending applications will be rejected. 2. On March 27th, 2024 we will stop accepting POST data submissions to the API. All submissions will receive a 403 response and the submitted data will be discarded. Additionally, we will stop publishing new exports of cell data for download. 3. On April 10th, 2024 the cell data downloads will be deleted and will no longer be available. 4. On June 12th, 2024 third party API keys will be removed and the service will only be available for Mozilla's use cases. 5. On July 31st, 2024 this source repo (https://github.com/mozilla/ ichnaea) will be archived. The source code for the MLS application, Mozilla Ichnaea, will remain available under the Apache License 2.0. The text was updated successfully, but these errors were encountered: 1 libreom reacted with thumbs up emoji 15 Danny3, FitikWasTaken, jthoward64, thibaultmol, onli, r0bbie, jezdez, tmccombs, ghishadow, QINGCHARLES, and 5 more reacted with thumbs down emoji 117 mar-v-in, Be-ing, wezm, valpackett, diogotcorreia, Wojtaz0w, vixalien, ThomasFrans, byquanton, FineFindus, and 107 more reacted with confused emoji [?] 12 gene1wood, vfosnar, sylvestre, runiq, SpectreVert, libreom, izaim, cpeterso, Atemu, ThatOneCalculator, and 2 more reacted with heart emoji All reactions * 1 reaction * 15 reactions * 117 reactions * [?] 12 reactions @mostlygeek mostlygeek pinned this issue Mar 13, 2024 @heftig Copy link heftig commented Mar 13, 2024 Firefox still uses MLS for browser.region.network.url; will that also move to Google Location Services? All reactions Sorry, something went wrong. @alexcottner Copy link Collaborator alexcottner commented Mar 13, 2024 * edited Firefox still uses MLS for browser.region.network.url; will that also move to Google Location Services? This endpoint will be migrated to another service (classify-client) that will return the expected response. We'll adjust DNS entries when it's time to make that move so firefox won't see any difference. All reactions Sorry, something went wrong. @heftig Copy link heftig commented Mar 13, 2024 Will downstream builds of Firefox need to obtain API keys for this new service? 7 alexcottner, GamerHun1238, sohzm, mweinelt, tebowy, tmccombs, and blocktrron reacted with eyes emoji All reactions * 7 reactions Sorry, something went wrong. @mar-v-in mar-v-in mentioned this issue Mar 13, 2024 Mozilla Location Service is retiring microg/GmsCore#2237 Open @rtsisyk Copy link rtsisyk commented Mar 14, 2024 Does anyone want to collaborate to run MLS in some jurisdiction that isn't concerned about patents? Drop a message to roman@organicmaps.app 40 sonnyp, mkf, floe, mar-v-in, eliastorres, kravietz, RedAuburn, fgaz, coolasbreeze, DylanVanAssche, and 30 more reacted with thumbs up emoji [?] 29 fgaz, kannes, HU90m, j13m126, mentalrooster, soundasleep, d-k-bo, maxwelldb, Krafting, stardustspirit, and 19 more reacted with heart emoji All reactions * 40 reactions * [?] 29 reactions Sorry, something went wrong. @mar-v-in Copy link mar-v-in commented Mar 14, 2024 * edited @rtsisyk Do we have any insights on which patents are applicable in this context and which jurisdictions they apply in? As you might know, Europe is generally far less into software related patents, so maybe the "some jurisdiction" could be very easy to find. The other question would be if Mozilla is willing to handover the WiFi dataset to a new organization running an ichnaea server or if we'd have to start from scratch. 25 mkf, nico-famedly, fynngodau, chirayudesai, grote, coolasbreeze, kannes, DylanVanAssche, santiagofn, LuccoJ, and 15 more reacted with thumbs up emoji All reactions * 25 reactions Sorry, something went wrong. @DylanVanAssche Copy link DylanVanAssche commented Mar 14, 2024 Also the Bluetooth beacons would be useful. I know Mozilla did not publish the WiFi and Bluetooth beacons for privacy reasons, but handing them over would be super beneficial. We would be set back by a decade if we have start from scratch. 9 Danny3, stardustspirit, onli, r0bbie, Wowfunhappy, mweinelt, Vuizur, libreom, and aembleton reacted with thumbs up emoji All reactions * 9 reactions Sorry, something went wrong. @KovalevArtem KovalevArtem mentioned this issue Mar 16, 2024 Retiring the Mozilla Location Service zamojski/TowerCollector#223 Open @thestinger Copy link thestinger commented Mar 16, 2024 * edited GrapheneOS Foundation has been planning to host a network location service for GrapheneOS and projects collaborating with us for a while now. We've received significant funding we can put to use for this to make a high quality, modern implementation on both the client and server side. A new unified app (cellular, Wi-Fi, Bluetooth beacons) for gathering data to publish as fully open data could also be part of it. We also plan to make a SUPL implementation as part of the same service as an alternative to our Google SUPL proxy to replace it as the default in the long term. The main issue is obtaining high quality and reliable data to run the service. It's necessary to get a lot more users helping with it than Mozilla had submitting data. It seems to have been dying off for a while now. Simply accepting all user submissions of data also makes it easy to poison the database, which becomes a major concern for a less research focused project that's meant to be widely used in production. We have a plan for dealing with this using hardware-based attestation able to support submitting data from any modern Android device with the security model intact and recent security patches. Other mitigations are also needed. OpenCelliD exists but it would be very easy for people to ruin it if they haven't already, and we're dealing with those kinds of attacks on a regular basis so we know we can't use something not resistant to it. The experience of users with the existing services indicates to us that the existing data is problematic. We're not aware of sources for Wi-Fi and Bluetooth data. It would be best to gather it from a unified app handling all of it with the resulting database being completely open data. We've never understood the privacy concern with providing a map of networks that are publicly broadcasting and are meant to be static landmarks. If they move around regularly, they shouldn't be included anyway, and those should be possible to distinguish. It seems highly unlikely that Mozilla would pass on this data to anyone else based on how they see it. They also may be forbidden to do that from the settlement they reached. The key is figuring out how to get a large number of users to run an app submitting cellular, Wi-Fi and Bluetooth beacon data in a way that it's difficult enough to mess with it maliciously. The people who care about this tend to care about their privacy and probably don't want to be submitting this kind of data during regular use of their devices, especially if the data is kept tied to the accounts submitting it for anti-abuse. Publishing it all as open data available for any purpose is crucial for getting people to be interested in submitting the data. Anyone being able to use for anything without constraints will give a lot of incentive to contribute to it. Mozilla wasn't making the most valuable data available to others. Having that data public also allows people to use it locally, which is important for privacy. Sending your location in real-time to a service isn't great regardless of who is hosting it even if you can do it without an account via a VPN / Tor, particularly if relatively few people use it. We're not at all happy with the existing approaches in this area and if anyone wants to build something better, we're interested in funding serious work on building it as remote work by people with experience working on similar things. This has been something we haven't considered a near term project but if there's suddenly a bunch of interest in it, perhaps it could be. Relying on another centralized service that's not publishing the data would be a shame. 38 miklobit, serdarth, mustaqimM, Jules-Bertholet, surfaceflinger, Khyta, matchboxbananasynergy, DamonHD, seankhl, TheW0LVERIN3, and 28 more reacted with thumbs up emoji [?] 10 vfosnar, AlbertoFabbri93, awandepan, tx71, herrwusel, decathorpe, codethief, ThatOneCalculator, aembleton, and pashynskykh reacted with heart emoji All reactions * 38 reactions * [?] 10 reactions Sorry, something went wrong. @badrihippo Copy link badrihippo commented Mar 16, 2024 What's the plan for KaiOS devices? IIRC they rely on MLS for location. I hope mine continues to function! All reactions Sorry, something went wrong. @vfosnar Copy link vfosnar commented Mar 16, 2024 * edited @thestinger We have a plan for dealing with this using hardware-based attestation able to support submitting data from any modern Android device with the security model intact and recent security patches. This feels bad. Can't see this implemented in a open source/community friendly way. We've never understood the privacy concern with providing a map of networks that are publicly broadcasting and are meant to be static landmarks. +1 The people who care about this tend to care about their privacy and probably don't want to be submitting this kind of data during regular use of their devices, especially if the data is kept tied to the accounts submitting it for anti-abuse. Hot take, I'm okay with that. Trying to fight anti-abuse when only collecting anonymous data is impossible. I would data connected to my account as long as I can trust the provider (clear privacy policy, legal limitation on the use of provided data) and a good anonymization process of the data (wifi endpoints only published after multiple accounts have seen them independently) and obviously if both backend and clients are open source. 4 woj-tek, aembleton, dos1, and lyynd reacted with thumbs up emoji 1 libreom reacted with thumbs down emoji All reactions * 4 reactions * 1 reaction Sorry, something went wrong. @badrihippo Copy link badrihippo commented Mar 16, 2024 Hot take, I'm okay with that. Trying to fight anti-abuse when only collecting anonymous data is impossible. I would data connected to my account as long as I can trust the provider (clear privacy policy, legal limitation on the use of provided data) and a good anonymization process of the data (wifi endpoints only published after multiple accounts have seen them independently) and obviously if both backend and clients are open source. I'm thinking of this as an "OpenStreetMap of location data". When people contribute locations to OSM, they are by nature implying that they were in the area--and they're fine with that. Of course, location data is very different because the sharing process will likely be automated, not submitted through a conscious process. I can't speak for everyone, but I personally would be happy to submit this data to a trusted organisation. To make things even better, perhaps the account data can be de-linked after a reasonably long time, when most of the anti-abuse use-case has expired. All reactions Sorry, something went wrong. @cookieguru Copy link cookieguru commented Mar 16, 2024 We're not aware of sources for Wi-Fi and Bluetooth data wigle.net 3 davefiddes, loops, and aembleton reacted with thumbs up emoji All reactions * 3 reactions Sorry, something went wrong. @oguz-ismail Copy link oguz-ismail commented Mar 16, 2024 good firefox next 26 r0bbie, demurgos, nextgenthemes, hrefhref, Wowfunhappy, kacperwyczawski, Simon-Losier, AmrikSadhra, gholm, Vuizur, and 16 more reacted with thumbs down emoji 5 egasimus, everypizza1, Candinya, BillyCroan, and aembleton reacted with laugh emoji 1 cadeyrn reacted with confused emoji All reactions * 26 reactions * 5 reactions * 1 reaction Sorry, something went wrong. @thestinger Copy link thestinger commented Mar 16, 2024 * edited We're not aware of sources for Wi-Fi and Bluetooth data wigle.net Unfortunately, this isn't open data for any usage. It's not clear what they would allow but it's non-commercial usage only which somewhat implies not making a service usable for anything including commercial usage. All reactions Sorry, something went wrong. @Goldmaster Copy link Goldmaster commented Mar 16, 2024 I am a little surprised as it helps improve accuracy when GPS is not very good. It doesn't help that the option to help map was removed from the Web browser rewrite and that the stumbler app didn't get updated or made compatible with modern android versions. All reactions Sorry, something went wrong. @thestinger Copy link thestinger commented Mar 16, 2024 @vfosnar We have a plan for dealing with this using hardware-based attestation able to support submitting data from any modern Android device with the security model intact and recent security patches. This feels bad. Can't see this implemented in a open source/ community friendly way. Data could be accepted from anywhere and simply not trusted without a way to confirm, with this being one way to show it has high confidence. It's possible to support any alternate OS as long as it implements a security model where the app can have strong confidence that it's not getting poisoned data. Apple and Google have a massive amount of data being submitted and can use lots of signals to determine if it's valid too. For a service with very little data, it's very easy for people to mess with it submitting poisoned data. It's too easy to submit fake data to a service like OpenCelliD, or even more so with Wi-Fi networks and Bluetooth beacons. That brings the overall data into question. Making it significantly harder will get rid of nearly all the poisoned data even though it's still theoretically possible to do it. The rest can be handled with moderation. Hot take, I'm okay with that. Trying to fight anti-abuse when only collecting anonymous data is impossible. I would data connected to my account as long as I can trust the provider (clear privacy policy, legal limitation on the use of provided data) and a good anonymization process of the data (wifi endpoints only published after multiple accounts have seen them independently) and obviously if both backend and clients are open source. There could be an opt-in to the level of privacy provided where the default could be something like not using the data until 3+ accounts have seen the networks, but with the option for less. Hardware attestation can give high confidence in the data being valid without needing to confirm it from several accounts believed to be separate people, and any app can use hardware attestation without any special privileges since it's privacy preserving, so I really think that's a good way to avoid needing to do something privacy invasive to confirm accounts are legitimate. 1 aembleton reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @cookieguru Copy link cookieguru commented Mar 16, 2024 We're not aware of sources for Wi-Fi and Bluetooth data wigle.net Unfortunately, this isn't open data for any usage That is incorrect, the EULA very explicitly states that you have a "right to use the maps and access point database...solely for your personal, research or educational, non-commercial purposes" It's not clear what they would allow but it's non-commercial usage only which somewhat implies not making a service usable for anything including commercial usage. Your misuse of the apostrophe makes it difficult to decipher the intent, but if you're using the data for commercial purposes then you by definition have the funds to license the data. Whether or not it the license fees are feasible for your project can only be speculated. It certainly sounds like you're forging ahead on this path 3 dos1, thestinger, and lyynd reacted with thumbs down emoji All reactions * 3 reactions Sorry, something went wrong. @thestinger Copy link thestinger commented Mar 16, 2024 @cookieguru That is incorrect, the EULA very explicitly states that you have a "right to use the maps and access point database...solely for your personal, research or educational, non-commercial purposes" That's what I said: it's not open data usable for any purpose. Non-commercial usage restriction would prevent hosting a service which can be used for commercial usage itself. Normally, you can't simply bypass a license wrapping it behind something. They'd need to be asked what they would permit and there's no way to make an open data service from licensing proprietary data. We want anyone to be able to host it. Your misuse of the apostrophe makes it difficult to decipher the intent, but if you're using the data for commercial purposes then you by definition have the funds to license the data. Whether or not it the license fees are feasible for your project can only be speculated. Writing "it is" as "it's" twice in a row is not misuse of the apostrophe, and I'm not sure how it would make it harder to understand. but if you're using the data for commercial purposes then you by definition have the funds to license the data Publishing a service usable by anyone for any purpose for free is likely considered commercial use of the data because people would be using the service for commercial purposes. Cannot simply wrap it up in a non-profit service that's used commercially. They may also have an issue with taking donations to support a service. We want an open source service with open data. Paying for data with heavily restricted usage terms wouldn't work. It certainly sounds like you're forging ahead on this path Mozilla's location service wasn't even an implementation of what we want because it was no longer maintaining / promoting data submission and the Wi-Fi/Bluetooth data wasn't open. It has degraded over time. I hadn't seen the legal situation it was in before yesterday and that partially explains the situation. I think it would have rotted away and been discontinued either way, but it probably accelerated that. I think the death of the service was inevitable with FirefoxOS. Cannot really expect them to maintain a service they don't need and which has little to do with their main project. Wigle is a proprietary service with proprietary data. Making an open source and open data service is not reinventing the wheel. Mozilla's service had largely proprietary, non-published data too, for the Wi-Fi/Bluetooth part of it. The service itself and the cell data were published. All reactions Sorry, something went wrong. @maciejsszmigiero Copy link maciejsszmigiero commented Mar 16, 2024 Note that Geoclue has always allowed submitting data to MLS from systems where it can access a GNSS receiver. It is opt-in, however, both for privacy reasons and because that's what our users expect. 1 cpeterso reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @woj-tek Copy link woj-tek commented Mar 16, 2024 Hot take, I'm okay with that. Trying to fight anti-abuse when only collecting anonymous data is impossible. I would data connected to my account as long as I can trust the provider (clear privacy policy, legal limitation on the use of provided data) and a good anonymization process of the data (wifi endpoints only published after multiple accounts have seen them independently) and obviously if both backend and clients are open source. There could be an opt-in to the level of privacy provided where the default could be something like not using the data until 3+ accounts have seen the networks, but with the option for less. Hardware attestation can give high confidence in the data being valid without needing to confirm it from several accounts believed to be separate people, and any app can use hardware attestation without any special privileges since it's privacy preserving, so I really think that's a good way to avoid needing to do something privacy invasive to confirm accounts are legitimate. my 3c: I try to be privacy focused but at the same time I do (try to) contribute to openstreetmap, which requires account. I think there could be a group of people that wouldn't mind using account to help collect the data (assuming it would be only used for verification during submission and would be anonymised/erased) 2 herrwusel and aembleton reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @bittorf bittorf mentioned this issue Mar 16, 2024 Mozilla Location Service is retiring erfanoabdi/geoclue#1 Open bittorf added a commit to bittorf/kalua that referenced this issue Mar 16, 2024 @bittorf kalua: wifi: scan_geolocation_api_query() needs work, mozilla API wil... ... b4aad72 ...l retire sson - https://news.ycombinator.com/item?id=39724505 - see mozilla/ichnaea#2065 - maybe we use https://wigle.net/ @aembleton Copy link aembleton commented Mar 16, 2024 my 3c: I try to be privacy focused but at the same time I do (try to) contribute to openstreetmap, which requires account. The data collection could even be build into something like Street Complete. As you're using it to update OSM, it could listen for SSIDs and feed those back. It's already using the GPS for Street Complete and so wouldn't hurt the battery life. 2 woj-tek and iam-py-test reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @mar-v-in Copy link mar-v-in commented Mar 16, 2024 * edited For users that are very privacy aware, I suggest to prefetch the cell towers in their region and not use accurate wifi-based location at all. Prefetched cell tower data would also be sufficient for faster GPS via local SUPL, which doesn't need high accuracy and can handle inaccuracies of tens of kilometers pretty fine. I doubt that protecting a location service with device attestation makes a lot of sense for two reasons: 1. You want people that are able and willing to collect wifi locations using highly sensitive long distance hardware to do that and contribute. This hardware is very likely not compliant with any attestations, but can be an extremely good source. 2. Even when device attestation is used, it is "trivial" to introduce wrong records, as we're talking about uploading data that was previously retrieved from public radio airspace. Setting up a device that appears as a hotspot with arbitrary strength and mac address is easy enough for people that are willing to abuse. Publishing the raw data (both raw data of submissions and raw locations of wifi hotspots) can be a serious privacy issue - entirely independent of what privacy laws might state. As you are concerned with abuse, please also consider the abuse risk of this data. For example, stalkers will be able to follow their victims even when they move to a different location for as long as they continue to use the same wifi hardware. Requiring an account for uploading data is not generally a bad idea, however this account setup should be as easy as possible (e.g. could be just generating a unique random id client side). If passive contributing (that is: uploading data about wifi networks when GPS is already in use anyway) is easy to activate (e.g. just ticking a box) this would allow users to contribute without any downsides. A unique random id would still be useful for abuse prevention, as continued and proven correct submissions from a unique id could be used to increase trust in its data - so the "account" would only be used to gain trust, not to ban bad actors (which is hard anyways, as they will likely be able to create a new identity). 4 Atemu, dos1, woj-tek, and iam-py-test reacted with thumbs up emoji 1 thestinger reacted with thumbs down emoji All reactions * 4 reactions * 1 reaction Sorry, something went wrong. @thestinger Copy link thestinger commented Mar 16, 2024 I doubt that protecting a location service with device attestation makes a lot of sense for two reasons Any service we provide needs to be heavily protected from abuse, as do the people involved in it. All of our services are targeted with attacks including denial of service, Child Sex Abuse Material spam, gore spam and harassment. If the service has any form of comments or discussions related to it, all of that is relevant too. This gives us the advantage of already being prepared for the abuse that will eventually target a service like this once it becomes popular. We're already thinking about it and preparing for it before even starting. You want people that are able and willing to collect wifi locations using highly sensitive long distance hardware to do that and contribute. This hardware is very likely not compliant with any attestations, but can be an extremely good source. It's possible to have both the concept of trusted contributors who have an established account with a history of submitting valid data and can apply to submit data from a non-verified device. The quality of the resulting data heavily depends on not simply accepting any data submission and treating all data submissions as equal. The data submitted by different hardware will also vary in how it needs to be treated. Even when device attestation is used, it is "trivial" to introduce wrong records, as we're talking about uploading data that was previously retrieved from public radio airspace. Setting up a device that appears as a hotspot with arbitrary strength and mac address is easy enough for people that are willing to abuse. Hardware attestation provides a baseline which allows deploying other mitigations against abuse. People doing this also have a limit to how much money they're willing to spend on new phones. Publishing the raw data (both raw data of submissions and raw locations of wifi hotspots) can be a serious privacy issue - entirely independent of what privacy laws might state. As you are concerned with abuse, please also consider the abuse risk of this data. For example, stalkers will be able to follow their victims even when they move to a different location for as long as they continue to use the same wifi hardware. Wigle supports lookups by SSID/MAC already: https://wigle.net/ Therefore, it doesn't seem to be a valid reason to oppose publishing open data. Many people believe in gathering and publishing this as data in the public domain usable for any purpose. A service making the data available to everyone has a much higher chance of success than one hoarding it and building a business model around it. That's not what we want to do. Submitting data to companies profiting off it without compensating the people submitting it or giving them rights to the overall data doesn't seem right. Some of the main perpetrators of the attacks on GrapheneOS and myself are among the main developers of your project. It was one of your supporters who did multiple swatting attacks targeting me in April 2023 with the clear aim of having me killed by law enforcement. It was carefully crafted to maximize the chance of that outcome. Perhaps if was one of the people who makes commits to your project who did it. You probably wouldn't kick them out even if we obtained proof of that based on past experience. Doesn't make any sense for someone like yourself who says you only care about the code and will allow nazis to contribute to your project if they write good code to start pretending to care about abuse. 1 iam-py-test reacted with thumbs down emoji All reactions * 1 reaction Sorry, something went wrong. fossfreedom added a commit to BuddiesOfBudgie/budgie-control-center that referenced this issue Mar 16, 2024 @fossfreedom Make the Location panel an optional panel ... 150a282 Mozilla will deprecate its service at the end of March 2024. Thus location support will be broken until a replacement solution is found. mozilla/ichnaea#2065 @fossfreedom fossfreedom mentioned this issue Mar 16, 2024 Make the Location panel an optional panel BuddiesOfBudgie/ budgie-control-center#79 Open 2 tasks @mar-v-in Copy link mar-v-in commented Mar 16, 2024 Wigle supports lookups by SSID/MAC already: https://wigle.net/ Therefore, it doesn't seem to be a valid reason to oppose publishing open data. Many people believe in gathering and publishing this as data in the public domain usable for any purpose. A service making the data available to everyone has a much higher chance of success than one hoarding it and building a business model around it. Someone else doing it this way doesn't mean it's a good idea ;) There likely are reasons why the database of Mozilla had many more contributors even if the Wigle database is more open. I personally would not want to contribute to a database that can be easily abused by people with malicious intent. And I wasn't suggesting to make a business model out of it, nor to "hoard" it. Making data not open to everyone is not the same as keeping data private. Data could be provided to others under clear rules that prevent or make abuse sufficiently hard, while not impacting its usefulness. For example, a rule could be that a full dump of raw data is provided to researchers, if usage is monitored by an IRB and all copies of the data is removed within a year after the research was conducted. I'm not saying it's easy to come up with appropriate rules for this, but I would argue it would be worth it to prevent abuse. Off-topic: on accusations As I previously said, I feel sorry for what happened to you and you are open to provide detailed accusations and supporting material by email to me, e.g. by mail to admin at microg.org, or to some independent third-party. And of course these can lead to a ban of individuals from the project. I don't think it's fair to claim wrongdoings by me personally because of a conflict you seem to have with an unnamed contributor to my project. I'd also like to point out that the project only has a single "main developer" beside myself and I doubt you are referring to that person, so maybe you should downgrade your wording to "minor contributor". And to reiterate the obvious: I don't want any contributions from Nazis and will happily ban those, no matter how good or how much code they were to contribute. But I also don't think this is the venue to discuss any of this. All reactions Sorry, something went wrong. Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Assignees No one assigned Labels None yet Projects None yet Milestone No milestone Development No branches or pull requests 15 participants @mostlygeek @heftig @aembleton @woj-tek @mar-v-in @thestinger @rtsisyk @cookieguru @DylanVanAssche @Goldmaster @badrihippo @vfosnar @maciejsszmigiero @oguz-ismail @alexcottner Footer (c) 2024 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact * Manage cookies * Do not share my personal information You can't perform that action at this time.