Closed mar-v-in closed 2 years ago
chirayudesai
commented
2 years ago Some additional features that benefit when microG is a system app:
jonaharagon
commented
2 years ago A module that reroutes requests to GPS is entirely possible.
Does such a module exist?
mar-v-in
commented
2 years ago Does such a module exist?
Not as far as I know. I doubt it would be extremely useful as most apps request fused location these days (that is, ask the OS to get network-based and GPS location and give the first/best result available from both), which would already handle the case of no network-based location gracefully by using GPS data.
thestinger
commented
2 years ago The Android API is mostly backwards compatible - otherwise, regular apps would also break with major system updates. Previous major updates did not require specific updates in microG. For example, microG was not adjusted for Android 12 yet and thus does not make use of certain new features, yet it works perfectly fine on Android 12 systems.
Play services API is changed for each major Android version, and newer APIs are required on newer Android versions. microG doesn't provide broad app compatibility in the first place so you don't know the breakage but there is breakage for major version upgrades.
This is not true. While microG has a handful of convenience features that only work when run privileged (e.g. accounting the battery use from geolocation to the app actually requesting it), those features are entirely optional and microG works perfectly fine in the default untrusted_app domain. For example, ProtonAOSP suggests installing microG as a regular app resulting in exactly such a setup. I myself am also running microG as regular unprivileged app.
It's not an unprivileged app if you're giving it the ability to bypass security checks and other changes. Another misrepresentation.
While technically true, I think this statement is misleading. A lot of code on Android runs in the privileged mode and one should only allow trusted code to run in this mode, but as microG is entirely open-source, reviewing it is possible, whereas Google Play Services code is proprietary and thus must be trusted blindly if used.
microG runs proprietary Google binaries in that privileged context. Open source doesn't make microG more private or secure. Closed source doesn't prevent reviewing the Play services code as you're falsely claiming. 100% of real world apps using it are still using Google's proprietary libraries, and you're still using Google proprietary services.
Your own claims can be applied to the app sandbox which is completely open source and can be reviewed, as can the sandboxed Google Play compatibility shims which are very simple and not a large amount of code.
Both yourself and other developers including @chirayudesai have repeatedly engaged in downplaying and covering up security vulnerabilities in your code. You've engaged in misinformation campaigns and have encouraged/orchestrated harassment towards security researchers for pointing out the problems.
As always, your dishonest behavior here has been archived and will be used in the legal proceedings against you based on your libel and harassment to show how you also engage in spreading misinformation. You financially benefit from this since you receive money to work on this project you're misrepresenting as providing things it isn't and as being a secure approach when it isn't and allows blatant data leaks between apps and doesn't properly secure the connections or APIs with the expected security checks.
microG uses a modular system that provides multiple options for location resolution. A module that reroutes requests to GPS is entirely possible. Also there is the possibility to do the location only based on cell towers and not wifi and prefetch a database of cell towers in a whole country (much smaller than a database of wifis would be), allowing for local location resolution without leaking any data (and this is already developed).
This "modular system" violates the OS security model and has multiple security vulnerabilities. You partially fixed one kind of vulnerability that I reported you years ago, but not the rest. Due to the abusive behavior from microG, vulnerabilities and security weaknesses we've discovered don't get reported to you anymore, but we're more than happy to prove they exist to people not involved with the project who formally agree not to work with abusers.
It should be noted that the microG implementation (in contrast to Google's location system in Play Services) does not make use of cookies or identifiers that would allow to identify a single user when contacting the Mozilla (or any other) backend. As such profiling users is hardly possible except for network-(IP-address)-based profiling, which can be prevented by various means (including carrier-grade NAT).
This isn't true. microG doesn't prevent doing that for your use of those location backends at all. Those things aren't required to identify a user and track them with your implementation.
You also don't control the client side or service side code. You trust Google just as much and they can do whatever they want in their libraries. You make claims about what you provide which are fundamentally not possible.
Again, I'm only talking about microG in general, not about potential restrictions that apply on CalyxOS. So it might be sufficient to rewrite as "microG on CalyxOS" across the page. I just fear that information on this page is understood or quoted out of context, making people believe it applies in all cases.
The information is accurate, and you have a history of trying to mislead people about how microG works and of trying to harm the GrapheneOS project. You engaged in malicious behavior behind the scenes along with CalyxOS developers to do that which you have financially benefited from.
thestinger
commented
2 years ago On that note, I don't think someone like @chirayudesai who has openly engaged in severe bullying and harassment should be permitted on the Privacy Guides GitHub. We're completely willing to provide proof of this and of the almost daily interactions they have with people involved in openly raiding the GrapheneOS chat rooms and extremely toxic behavior including repeatedly telling me to kill myself and claiming that I'm delusional / schizophrenic across platforms. They worked with the main person orchestrating this harassment campaign and promoted their YouTube channel along with making content with them, not just in spite of their harassment towards me but because they have tried to encourage it.
thestinger
commented
2 years ago Waking up apps from idle for push notifications (though I'm sure there's some way around this)
GrapheneOS does it without requiring privileged access. Sandboxed Google Play apps are completely regular unprivileged apps, unlike microG and several proprietary Google apps on CalyxOS. Despite that, sandboxed Google Play provides far broader app compatibility and people can use the official Play Store app with all the services it provides to apps. It's a fundamentally more secure approach which provides ZERO additional access to the Google Play code compared to what it has via the Google Play libraries. CalyxOS / microG developers (overlapping group) have tried to misrepresent how it works and have repeatedly made false claims about sandboxed Google Play. It's unfortunate that since you can't compete on a technical level at all you choose to engage in a prolonged misinformation campaign about many topics and severe bullying/harassment.
SafetyNet (Last I tried this didn't work when microG was a user app, happy to be proven wrong here though)
GrapheneOS passes basic integrity without requiring privileged access. We've chosen not to violate their intended security model by tricking it into thinking that our OS is certified. Google hasn't cracked down on that yet but has told us they intend to do it and they recommended not trying to bypass the checks.
TommyTran732
commented
2 years ago Sorry for the late reply @mar-v-in
those features are entirely optional and microG works perfectly fine in the default untrusted_app domain.
Sure, I will just change it to "MicroG on CalyxOS". I'd note that MicroG can work without system_app, but not all features will be functional.
While technically true, I think this statement is misleading.
I do not see how it is misleading. MicroG being open source doesn't make it more secure. A Linux distribution being open source doesn't make at anymore trustworthy or secure than something like macOS. At the end of the day, the user is putting trust in whoever compiles their OS, open source or not. I think the same argument applies here.
A module that reroutes requests to GPS is entirely possible.
Well the problem is that it doesn't already exist so we can't really recommend something that doesn't exist to the readers at all.
Also there is the possibility to do the location only based on cell towers and not wifi and prefetch a database of cell towers in a whole country (much smaller than a database of wifis would be), allowing for local location resolution without leaking any data (and this is already developed).
Yeah, this is a real privacy benefit. I would note that. I don't see it being useful at all however, because I have tried using it myself and it really doesn't do anything noticeable for location locking (and yes, I am in the US). So the benefit here is really theoretical.
ghost
commented
2 years ago SafetyNet spoofing isn't created by microG and microG being installed doesn't spoof SafetyNet. Apps can query SafetyNet status regardless of microG or not.
https://github.com/ProtonAOSP/android_frameworks_base/commit/e7cb4d9db7fd59f5909835c64ae084c4ad011062 https://github.com/ProtonAOSP/android_frameworks_base/commit/05ca4b85f66f818805eca3be2e592b1e6de58931 https://github.com/ProtonAOSP/android_system_core/commit/2955b5f7fc47f33d1a413f38cda5aa3ffe131f4c
It's also entirely possible to wake up apps without privileged integration just fine using unprivileged Android APIs.
It's important for this organisation to know they have attempted to push this same misinformation on https://github.com/madaidans-insecurities/madaidans-insecurities.github.io/issues/46 including derailing the thread away from their false claims into personal attacks on us with other CalyxOS members.
thestinger
commented
2 years ago Linking to the CalyxOS website is also problematic due to many cases of misleading spin and misinformation on their website. For example, they mislead users about which features are provided by AOSP or added by CalyxOS, they falsely claim to have started the SeedVault project and they have an inaccurate list of default connections made by CalyxOS which does not include all the Google services it uses. There are many cases of these things across their site. Their site has tried to downplay and mislead people about the consequences of them regularly not providing security updates and they set inaccurate security patch levels. That is also among other things one of several ways they violate the security properties expected for the attestation feature and is part of why they would have had to be removed from Auditor regardless of the false claim repeated several times from Nicolas Merrill (a known abuser who @chirayudesai works for and defers to) that it was because I'm crazy, delusional and threw a fit resulting in their OS being removed, rather than the truth of it being because they stopped submitting updates so it started giving users errors on newer devices we got blamed for and they wouldn't comply with the Android security model rules.
thestinger
commented
2 years ago 99.9999999% of real world apps using it are using microG through Google binaries: the official Play SDK libraries and other Google libraries. microG supports using Google binaries as part of the microG app context which have access to all privileges available to microG. On CalyxOS, snet/droidguard run as privileged processes, compared to GrapheneOS where they run in the same app sandbox as the Play SDK libraries in the apps using Google Play with no additional access or privileges whatsoever with no exceptions.
The primary purpose of microG is to make the proprietary libraries in those apps more functional. Some of those libraries notably work without Play services, because they implement their own fallbacks. People can see for themselves that apps like Google Maps work fine without Play services and that Google Ads work fine without it too. Clearly, the client-side libraries and apps themselves are fully capable of using Google services on their own and they often do that. It's trivially proven. It's also easily proven that sandboxed Google Play runs in the same most recent revision of the app sandbox, with all the improvements to that implemented by GrapheneOS, and that it does not receive additional privileges either via a single privileged permission or any kind of changes to the way the APIs work which give it more access.
Would like to hear in exactly what way the CalyxOS and microG developers think sandboxed Google Play gives any additional access to Google Play and how they justify the dishonest claims they have made about it across platforms. In reality, CalyxOS is giving privileged access to Google Play while GrapheneOS is not. Google Play code can access strictly more on CalyxOS than GrapheneOS even while ignoring our hardening completely.
That's identical to how the sandboxed Google Play approach works. Sandboxed Google Play can't do anything that the official Play SDK libraries cannot do themselves without it. That's the whole point of the approach and attempts to mislead users about it are dishonest and malicious behavior. It would be nice if you could actually admit what it provides and what you provide, and how they actually contrast with each other.
thestinger
commented
2 years ago @jonaharagon Considering that you work for the person who has orchestrated the harassment / bullying campaign against me with the help of CalyxOS, you shouldn't be involved in threads related to GrapheneOS and shouldn't be marking my comments as off-topic. If you truly never had any involvement in that beyond making a couple nasty jokes, fine, but it's a serious conflict of interest. My comment about the CalyxOS website is not off-topic. The topic is an article which links to it.
jonaharagon
commented
2 years ago @thestinger It actually is off-topic, by definition, because it has nothing to do with the original topic of this issue, which is potential factual inaccuracies with our coverage of microG. If you want to start a discussion about our listing of CalyxOS feel free to do so (i.e. it's not off-topic for our organization, just this specific issue). My goal is only to prevent this issue from becoming a dumpster-fire of "everything that is wrong with anything related to microG" because it is very difficult for us to manage and keep track of multiple discussions in a single issue from an organizational perspective.
Description
URL of affected page: https://www.privacyguides.org/android/grapheneos-vs-calyxos/
On the page comparing GrapheneOS and CalyxOS, there are a few statements made about microG, which may be true for microG on CalyxOS but do not apply to microG in general:
The Android API is mostly backwards compatible - otherwise, regular apps would also break with major system updates. Previous major updates did not require specific updates in microG. For example, microG was not adjusted for Android 12 yet and thus does not make use of certain new features, yet it works perfectly fine on Android 12 systems.
This is not true. While microG has a handful of convenience features that only work when run privileged (e.g. accounting the battery use from geolocation to the app actually requesting it), those features are entirely optional and microG works perfectly fine in the default
untrusted_appdomain. For example, ProtonAOSP suggests installing microG as a regular app resulting in exactly such a setup. I myself am also running microG as regular unprivileged app.While technically true, I think this statement is misleading. A lot of code on Android runs in the privileged mode and one should only allow trusted code to run in this mode, but as microG is entirely open-source, reviewing it is possible, whereas Google Play Services code is proprietary and thus must be trusted blindly if used.
microG uses a modular system that provides multiple options for location resolution. A module that reroutes requests to GPS is entirely possible. Also there is the possibility to do the location only based on cell towers and not wifi and prefetch a database of cell towers in a whole country (much smaller than a database of wifis would be), allowing for local location resolution without leaking any data (and this is already developed).
It should be noted that the microG implementation (in contrast to Google's location system in Play Services) does not make use of cookies or identifiers that would allow to identify a single user when contacting the Mozilla (or any other) backend. As such profiling users is hardly possible except for network-(IP-address)-based profiling, which can be prevented by various means (including carrier-grade NAT).
Again, I'm only talking about microG in general, not about potential restrictions that apply on CalyxOS. So it might be sufficient to rewrite as "microG on CalyxOS" across the page. I just fear that information on this page is understood or quoted out of context, making people believe it applies in all cases.