microG and /e/ clearly took the public position on the Mozilla Location Service issue tracker that they were against open data, and it's easily proven that they're the ones behind the Positon location service, not a third party:

https://github.com/mozilla/ichnaea/issues/2065

They began coordinating together in a private chat room following this issue tracker thread. We have logs showing they're the people behind Positon, showing their close coordinating together and that they're still strongly against open data. /e/ has been largely providing the funding for microG and that funding is also what's allowing this to be done.

They very clearly view BeaconDB as a competitive threat to their attempt to grab location service market share and convince open source projects to use their service. They've adjusted their strategy to pretend they're supportive of BeaconDB and yet are still trying to stop it to the point that they're making another location service beyond both the one hosted by /e/ for their own usage and the Positon service aimed at getting adoption from other open source projects. There's going to be another one from the same people with "libre" in the name despite being anything but "libre" and with the continued goal of trying to get other open source projects using their service.

In public, on the MLS issue tracker, several people against open data viewed it as important to get everyone using one service to avoid data being split into multiple proprietary databases. In private, they've continued down that path towards repeatedly talking about and emphasizing the importance of everyone using their service. The goal of Positon and the upcoming rebrand is hiding their involvement, portraying it as an independent project and getting lots of open source projects on board using it. We're clearly going to be against centralizing location services instead of an open data approach. Even with BeaconDB, it remains to be seen how open it is and if it satisfies our minimum expectations in that regard so we're linking to it but not wholeheartedly endorsing it until we see the open data approach.

We're going to continue to be strongly against the approach of centralized location services with proprietary data, particularly services that are being dishonest with people about who is behind it, who is providing the funding and their goals. They're clearly contradicting their own statements both in public on the MLS tracker where they had a strong position and in the many weeks following that in a private chat room. It's ridiculous to not acknowledge that the lead microG developer is the one making Positon in close coordination with /e/.

They claimed /e/ OS applied AOSP security patches every month, is it not true?

    Kira902 It's not at all true.

    They ship the Android Open Source Project subset of the Android Security Bulletin patches across devices, but with significant delays of a month or more. Those include most but not all High/Critical severity Android Open Source Project patches. Shipping the full set of High/Critical severity patches and nearly all of the Low/Moderate severity patches requires staying caught up with the latest release of Android. /e/ is far behind the latest release of Android and has far more than the month or two of delays they have for ASB patches for the full set of patches. It's a year or more of delays. It's multiple years of delays for a lot of the devices they support.

    There's a comparison of this subset of another subset of the overall patches here:

    https://divestos.org/pages/patch_history

    ASB is a subset of the overall patches: it does not include most driver/firmware patches and does not include any Low/Moderate severity AOSP security patches or certain High/Critical severity ones. Shipping only the AOSP portion of the ASB is an even smaller subset of the patches. The bigger problem is misleading users about this.

    Many patches require updates for drivers and firmware. /e/ fails to properly ship these for most devices even when they're available. They do not even ship the firmware and vendor updates at all for many devices. Most of the devices they support don't have these patches provided properly in the first place, and they fail to ship them in most cases they are available. They're downplaying the importance of this despite it being no less important than having the AOSP backports. The Android Security Bulletins only list a very small subset of driver/firmware patches, but they do list some of them, and they do require them for claiming to have the current Android security patch level. /e/, LineageOS and CalyxOS ignore this and set an inaccurate Android security patch level along with claiming to provide patches they are not providing. For example, CalyxOS claims to provide all open source patches by shipping the AOSP backports when they're behind on Android releases or for devices not shipping the full patches, despite the fact that many of the missing patches are open source. Each of these projects is heavily downplaying the missing patches and misleading users about it.

    Only the first half are provided through the AOSP security backports alone. The other half requires driver/firmware patches. Only a small portion of the overall driver/firmware patches are listed there. Compare the Android Security Bulletin to the Pixel Update Bulletin which currently mostly lists patches applicable to many other devices including AOSP patches, Broadcom Wi-Fi, Qualcomm Wi-Fi, Qualcomm cellular, Samsung cellular, etc. The patches for Qualcomm cellular and Snapdragon will stop being listed in the Pixel Update Bulletin once the Pixel 5a is end-of-life in the near future though. Qualcomm has their own bulletins with a more complete list of patches than the Android Security Bulletin.

      If I understand correctly about the possible new location service, only some GOS users (since collaboration between Open Source projects seem difficult) enabling an option will send WiFi hotspots location and maybe Bluetooth and cell tower location.

      This will result in a maps with users routes (even more in low population density places)
      This location service will speed the device position for currents versions of OrganicMaps or Magic Earth ?

      4 months later

      GrapheneOS

      So guys instead, contribute to BeaconDB!

      1. Install NeoStumbler
      2. Change the endpoint to https://api.beacondb.net
      3. If you like, go into developer options and disable "wifi scan throttling"
      4. Enable background data for the app
      5. Disable battery optimizations entirely for the app
      6. Enable "automatic upload"
      7. You can also make it only collect data when you move to save battery
      8. Turn it on and forget it!

      Whenever you use GPS, it will use your GPS location and scan for nearby wifis and bluetooth beacons, if you have cell data enabled also for cell towers.

      Once GrapheneOS has it's network geolocation app, you can directly profit from the data you have uploaded, and dont need GPS in the areas you frequently visit anymore!

      I am doing this every day, really fun!

      screenshot 1

      screenshot 2

          missing-root
          How does this affect privacy? I read BeaconDBs privacy statement, but I am worried about my home WiFi information being sent to this database.

            3 months later

            missing-root Does NeoStumbler provide the user with any service/benefit, or is running it purely an altruistic act? (I just installed it and will run it either easy, just like I run a Tor Snowflake bridge, but I'm just trying to understand how the app works. Will we have to wait for GOS to publish their geolocation app before we benefit from this?)

                hemlockiv if you use it, you can use the uploaded data a day later with clients that support it.

                GrapheneOS will do its own stuff, but for future proofing the dataset, and also having one that is truly free (and not just legally scraped), beaconDB is important.

                And GrapheneOS may use the dataset themselves, if they decide that truncated MAC hashes are enough for them XD

                The GrapheneOS geolocation app is ONLY a client. Will probably never upload data to anywhere.

                So using NeoStumbler (which btw just had a great update and is now on Accrescent) is the only way to contribute.