Closed alohapersona closed 1 month ago
eylenburg
commented
1 month ago I think the only rows affected would be the ones you mentioned: network-based location, Android Auto support and Google Pay support. A simple solution could be just adding a different formatting or footnote to make it clearer that these features require having Play Services/MicroG installed.
alohapersona
commented
1 month ago I think the only rows affected would be the ones you mentioned: network-based location, Android Auto support and Google Pay support
It also affects:
I guess those are obvious for people that know about the topic, but certainly not for everyone.
thestinger
commented
1 month ago GrapheneOS can be used with or without Sandboxed Play Services
It doesn't come with sandboxed Google Play. It's not a configuration option but rather you can install the apps
Android Auto support in GrapheneOS requires Sandboxed Play Services
That's about running the Android Auto app with full functionality. There's also generic display mirroring, audio output, mouse/keyboard support, etc. There could be another implementation of Android Auto but that entry seems to be about using the full official implementation, similar to how it says Google Pay and not tap-to-pay since tap-to-pay is available with apps permitting an alternate OS.
DivestOS, CalyxOS and iodeOS can be used with or without microG
CalyxOS always has microG installed and having it installed has an impact even when it's disabled. It's not the same as DivestOS where installing it is optional. On DivestOS, it has the special privilege of impersonating Play services but not more privileges it has on CalyxOS.
LineageOS with Play Services can even be made compatible with Google Pay (at least on some devices)
Using Magisk and spoofing things to temporarily bypass the checks can be detected and risks getting your account banned. If you're modifying the OS by replacing the core OS, it's hardly the same OS anymore.
thestinger
commented
1 month ago Network-based location on GrapheneOS is implemented via GNSS + A-GNSS by default. The table already makes that clear. GrapheneOS does not include Google Play as an option but rather users can install it as regular apps. It reroutes location requests made by apps to Google Play to the OS by default. The option to disable that is not what you are claiming it is above. GrapheneOS has no way to provide network location via Google Play, that's incorrect. OS network location is always provided via GNSS + A-GNSS.
alohapersona
commented
1 month ago It doesn't come with sandboxed Google Play. It's not a configuration option but rather you can install the apps
I didn't say it comes with it preinstalled. I personally consider installing software some sort of configuration, but I understand others might understand it differently. Yet I think it was clear to @eylenburg that I wasn't suggesting GrapheneOS comes preinstalled with Play Services.
It certainly is a unique feature of GrapheneOS that you can install Play Services. Are you trying to reason that the ability to "configure" GrapheneOS to have sandboxed Play Services is not a GrapheneOS feature? Which would imply that GrapheneOS also doesn't "support" any of the features that rely on it that I listed above.
That's about running the Android Auto app with full functionality.
I was under the assumption that this is what the row is about, but if it's not it should be adjusted to explain that.
CalyxOS always has microG installed and having it installed has an impact even when it's disabled.
In how far are uninstalled apps different to disabled apps, if disabled via system settings? I don't know what CalyxOS does, this is more out of curiosity. The only thing I am aware of that a disabled app does that an uninstalled app does not, is that it blocks installation of another app with the same package name.
I also heard that Google claimed in front of the EU commission that disabling an app is essentially the same as uninstalling (as they're required to allow uninstallation of Play Store in EU through DMA, but to date they only allow to disable it), so if you have a different opinion, I bet EU commission would love to hear from you at their email EC-DMA@ec.europa.eu.
Using Magisk and spoofing things to temporarily bypass the checks can be detected and risks getting your account banned.
I'm not arguing it's a good idea, I'm just saying it's possible and not even uncommon to do.
I think you wanted to have your second message in another issue? Because this one doesn't talk about location at all
Network-based location on GrapheneOS is implemented via GNSS + A-GNSS by default.
GNSS by definition is not network-based location. What you mean is that GrapheneOS provides a "network" location provider to the system, so that apps that requesting a location from the "network" location provider (expecting to get a network-based location) will receive a GNSS location instead (or none if you are indoors and GNSS is not available).
The table already makes that clear.
The table has two different rows, one for the feature of actually having network-based location (= not GNSS) and one for providing a network location provider. GrapheneOS does the latter, but not the former.
thestinger
commented
1 month ago I didn't say it comes with it preinstalled. I personally consider installing software some sort of configuration, but I understand others might understand it differently. Yet I think it was clear to @eylenburg that I wasn't suggesting GrapheneOS comes preinstalled with Play Services.
It doesn't come with Google Play services and the Play Store, but it also doesn't grant it any special access when it's installed which is the unusual part. Installing Google Play services and the Google Play Store is simply installing regular apps running in the standard app sandbox, which is NOT usually how it works at all including on other operating systems which support installing it dynamically. It receives no more access than the Google Play code inside apps like Signal, Discord, etc. receives when you install those apps. The apps using Google Play include Google Play SDK and libraries. Many of the Google libraries function just fine without Google Play services installed including Firebase Ads, Analytics, etc. Most of the Firebase libraries work without Google Play services. The Analytics library and the normal variant of the Ads library has full fallback code to provide 99% of the functionality without Play services. There's a Lite variant of the Ads library which cannot function without Google Play with the idea being that apps distributed through the Play Store can make it a hard dependency where they don't work without it, but when distributed outside the Play Store they can use the normal library and have Google Ads working fine without Google Play services required.
You use closed source Google Play code as part of the apps depending on Google Play with or without Google Play services. Not all of those libraries need Google Play services.
It certainly is a unique feature of GrapheneOS that you can install Play Services. Are you trying to reason that the ability to "configure" GrapheneOS to have sandboxed Play Services is not a GrapheneOS feature? Which would imply that GrapheneOS also doesn't "support" any of the features that rely on it that I listed above.
There's nothing unique about the ability to install Play services on GrapheneOS. The norm is for Play services to either already be installed as privileged apps or for support to exist for installing them as privileged apps. What's unique about GrapheneOS is that they can be installed as regular apps in the standard app sandbox rather than privileged apps, with no special access via the usual special SELinux policy, lack of MLS containment, extensive privileged permissions and extensive use as the backend for OS services including as a replacement for AOSP components. It is unique because it runs with no more privileges than other user installed apps and does not need any standard permissions granted for nearly all functionality to work.
When a user installs and runs apps which use Google Play on an OS without Google Play, they're using a much less complete form of sandboxed Google Play for the Google Play SDK and libraries included in those apps. For example, Signal uses Google Play and therefore includes the Google Play SDK and several Google Play libraries including FCM and location libraries. If you run Signal on GrapheneOS without sandboxed Google Play, you are still running Google Play in the app sandbox. Users who want to avoid that can use the FOSS Molly instead, but it really doesn't matter. That Google Play code is not untrustworthy and is not malware. It's not a real problem that Signal includes the Google Play SDK and libraries. It's Java code so it's not hard to decompile and review what it does. The same can be done with Google Play services but it's much larger. Google Play services is largely Java which makes reviewing it much easier than closed source C and C++ code. It does have some of that but it's still possible to review. The part that's hardest to review is the part that's downloaded and run by microG as part of supporting those features...
I was under the assumption that this is what the row is about, but if it's not it should be adjusted to explain that.
The row appears to be about the Android Auto app, not supporting alternatives to it. The current row appears fine and is accurate. There's a major difference between GrapheneOS running Android Auto as a regular sandboxed untrusted app with only what users grant it and /e/OS running it as a privileged app without a lot of the standard app sandbox and with a bunch of privileged permissions it requests granted to it. On GrapheneOS, wired Android Auto can be used without any privacy invasive access granted to it by toggling on only the USB access it needs, not the much more invasive permissions it needs for wireless Android Auto. GrapheneOS greatly reduces the privileged permissions needed for any of the Android Auto functionality rather than simply making the privileged permissions it requests into toggles. We eliminate most of the privileged access it requests because it works without it. We also don't grant the privileged permissions it does actually need even with our compatibility layer reducing what it needs but rather make stripped down variants of them giving minimal access instead of everything they usually do. For USB Android Auto, it can be used on GrapheneOS without giving it more than just special USB access. Few users are going to care that it needs special USB access. Many would care about giving it broad access to Wi-Fi, Bluetooth and a whole bunch of hardware identifiers, etc. as it usually requests.
In how far are uninstalled apps different to disabled apps, if disabled via system settings? I don't know what CalyxOS does, this is more out of curiosity. The only thing I am aware of that a disabled app does that an uninstalled app does not, is that it blocks installation of another app with the same package name.
Disabled apps can't run but they still show up to other apps and therefore change how apps behave and impact app compatibility. Apps which would work without Google services no longer work without Google services and instead require enabling it. It would have to be hidden as we do for some of our features to change how things behave. Disabled is not hidden from other apps.
I also heard that Google claimed in front of the EU commission that disabling an app is essentially the same as uninstalling (as they're required to allow uninstallation of Play Store in EU through DMA, but to date they only allow to disable it), so if you have a different opinion, I bet EU commission would love to hear from you at their email EC-DMA@ec.europa.eu.
It prevents the code running but other apps can still see it's there and can read what the APK provides such as a library or permissions it defines. Apps will behave differently when Play services appears to be present even if it's disabled.
I'm not arguing it's a good idea, I'm just saying it's possible and not even uncommon to do.
There are people using Magisk with this spoofing with their own derivative of GrapheneOS. It has nothing to do with LineageOS specifically. It is no longer the same OS when the core OS is replaced with something else. An entry for Magisk + some modules + LineageOS is not LineageOS.
GNSS by definition is not network-based location. What you mean is that GrapheneOS provides a "network" location provider to the system, so that apps that requesting a location from the "network" location provider (expecting to get a network-based location) will receive a GNSS location instead (or none if you are indoors and GNSS is not available).
SUPL is network-based location based on cell towers, and it's a major part of the A-GNSS support used on GrapheneOS. We do not provide a toggle to use SUPL to fully determine location without GNSS, but we could. It's more privacy invasive in the full mode than it usually would be. GrapheneOS therefore does use a form of network-based location via SUPL and emulating what they call network location with GNSS + A-GNSS is not entirely avoiding using the same concept. SUPL retrieves a kind of database of cell towers by default.
The table has two different rows, one for the feature of actually having network-based location (= not GNSS) and one for providing a network location provider. GrapheneOS does the latter, but not the former.
The table has a row for a network-based location provider, which can be provided in 2 different ways on GrapheneOS. It also has a row as part of the section on whether connections to Google services are made about whether the OS uses Google's network location provider. They are not separate in the sense you're describing.
SUPL is not normally used as a network location service. but it is on GrapheneOS as part of GNSS + A-GNSS provided emulated network location. We could provide a toggle to make SUPL give a location estimate without GNSS... we just don't plan on doing it because we plan on hosting our own network location service based on regional databases downloaded to the device.
Some OS can be configured/adjusted to some degree in a way that significantly affects available features:
How those configuration affect the features and degoogling is not reflected in the table. E.g. Android Auto support in GrapheneOS requires Sandboxed Play Services, same for network-based location. LineageOS with Play Services can even be made compatible with Google Pay (at least on some devices). At the same time using/enabling microG and/or (sandboxed) Play Services also obviously has its downsides.
I'm not sure what's the best way to accurately display this in the table, maybe the column for OS where such significant change can be done should be split (and then merged via colspan when it doesn't make a difference).