I have never understood why people using MicroG can use apps like SNCF-Connect, while I cannot.
SNCF-connect is the largest online marchant in France. Since june, I cannot click the "pay" button anymore. It coincides with the new feature of Pay with Google.
So : is it because MicroG allows calls to Google services on e/OS devices, while my LineageOS refuses ? Or because MicroG implemented a try catch around this call, without any call to Google's servers ?
If it connects to Play Store, then isn't that the same as Aurora? Can people's accounts be banned? That would really suck to pay for something and lose it because Google banned you haha!
Some Play Services calls are stubbed out as no-ops and others are reimplemented either with fully free replacements (e.g. navigation) or else by calling proprietary Google remote endpoints (e.g. firebase)
Graphene generally seems to feel that running official signed Google adware is more secure than using open source alternatives that might require signature spoofing or having root on your own device.
GrapheneOS's approach is Sandboxed Google Play so the apps don't get special permissions. Without privileged access, Google apps get access to nothing more than what other apps can get access to on Android. So, for example, even if a device has microG installed, an app with a Google library would have virtually the same access as if Sandboxed Google Play was installed. And why would anyone need microG if not to provide compatibility for apps that rely on Play Services, aka apps with Google libraries?
Also, for some reason some people think that microG means deGoogling. That's not at all the case. microG still communicates with Google servers.
microG doesn't meet the project's requirements. If you look at the big picture, microG offers worse app compatibility and is less secure. The cons outweigh the pros by a lot. "Google bad" isn't an argument that works for us. App compatibility is very important.
"Sandboxed" Google Play still gets everything that the other apps in the same profile offer up to it / to Google. I don't understand how you're gaining any privacy as a practical matter. The issue isn't GApps' privileged access to the system, it's that other apps send your data to Google via Google Play Services.
To take some examples, MicroG stubs out the analytics and ads APIs. Your "sandboxed" Play would send that data to the mothership and return with ads.
> I don't understand how you're gaining any privacy as a practical matter.
Exactly.
Being too focused on "Google bad" means you're not seeing the bigger picture. microG is only a thing to provide app compatibility for apps that rely on Google Play Services. Which apps do you think do that? Apps with Google libraries that often have fallback implementations and can operate without Google Play Services.
So, given those facts, if someone has microG installed, Google still effectively has the same access as a device with Sandboxed Google Play, except microG users are stuck with worse app compatibility and because of signature spoofing it's less secure and code runs in that privileged context.
GrapheneOS focuses on privacy, security, and app compatibility. microG fails at security and app compatibility. Also, there are apparently leaks (that I admit I don't know the details of) regarding location that make it worse for privacy too. There could be more leaks that I don't know about.
microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.
Each app using Google Play still has the closed source Google Play SDK and libraries built into it in practice. It's extraordinarily rare to replace those libraries with the incomplete and buggy reimplementations from microG. Very close to zero otherwise open source apps are using those. The closed source Google Play SDK and libraries are therefore still part of the loop and have access to what the app can access. Many of the code paths in the Google libraries directly use Google services without requiring Play services including the full versions of the Ads and Analytics libraries.
The vast majority of data obtained by Play services is via the OS integration and permissions. Apps using it for push messaging, logging into accounts and many other features will send the same data to Google services regardless of whether you use it via sandboxed Google Play or microG.
GrapheneOS stubs out and reimplements APIs on the client side. That includes providing a complete implementation of the Google Play services location API not using on Google Play. These features are being expanded over time. They'll also be made available without having Google Play.
The GrapheneOS approach avoids giving an additional global service access to sensitive data from the OS and apps. microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.
Unlike microG, sandboxed Google Play doesn't get privileged access. That includes the executables (droidguard) downloaded by microG not getting privileged access. GrapheneOS also doesn't give privileged access to other apps such as Android Auto when those are installed as all the main operating systems using microG are doing. That privileged access gives access to highly sensitive data and doesn't require apps explicitly sending data to Google services, which will nearly all still go to Google services with a partial replacement of the middleware on the device.
The apps that use Google analytics/ads don't need Google Services on the device. The libraries are embedded into the app, and have just as much fingerprinting capabilities as sandboxes Google services.
Running google code sandboxed is far more secure than running google code with privileged access. MicroG downloads and runs google code in a privileged context and has had many privacy and security issues like leaking location to apps that dont have the location permission.
By "they" I assume you mean GrapheneOS supporters? I can only speak for myself, but I only flag things when they clearly deserve to be flagged. Fair discussions are important. They help us grow as people and even in our case, GrapheneOS, but we encounter a crazy amount of misinformation here. Some members of our team are also targets for endless harassment. It's so unfortunate that people behave that way. There are also clear sockpuppets attacking GrapheneOS while promoting others. There was a brand new account participating in this thread that was clearly doing that.
Misinformation, harassment, and people who are using unfair methods to win arguments and damage the reputation of others is unacceptable. That's the kind of thing that I flag. What other people do with their permissions is up to them, but I would say that I wouldn't condone people flagging just because they disagree. I'd consider flagging genuine questions to be awful behavior as well.
microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.
Each app using Google Play still has the closed source Google Play SDK and libraries built into it in practice. It's extraordinarily rare to replace those libraries with the incomplete and buggy reimplementations from microG. Very close to zero otherwise open source apps are using those. The closed source Google Play SDK and libraries are therefore still part of the loop and have access to what the app can access. Many of the code paths in the Google libraries directly use Google services without requiring Play services including the full versions of the Ads and Analytics libraries.
The vast majority of data obtained by Play services is via the OS integration and permissions. Apps using it for push messaging, logging into accounts and many other features will send the same data to Google services regardless of whether you use it via sandboxed Google Play or microG.
GrapheneOS stubs out and reimplements APIs on the client side. That includes providing a complete implementation of the Google Play services location API not using on Google Play. These features are being expanded over time. They'll also be made available without having Google Play.
The GrapheneOS approach avoids giving an additional global service access to sensitive data from the OS and apps. microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.
Unlike microG, sandboxed Google Play doesn't get privileged access. That includes the executables (droidguard) downloaded by microG not getting privileged access. GrapheneOS also doesn't give privileged access to other apps such as Android Auto when those are installed as all the main operating systems using microG are doing. That privileged access gives access to highly sensitive data and doesn't require apps explicitly sending data to Google services, which will nearly all still go to Google services with a partial replacement of the middleware on the device.
This is why I always think emperor git wears no clothes. Hiding these kind of intermediate junk commits from history should not require rewriting and breaking the distributed history you all share. imho the correct solution would be a tag-like layer for annotating existing commits with metadata (additional signatures, hide-flags, retroactive comments, etc) or just a full 2nd dag, but whatever: git sucks at annotating history and annotating history is a core workflow in git.
It's too bad you have to rely on signature spoofing to be able to use this as an alternative (but obviously I understand why). The spoofing looks narrowly scoped on LineageOS, but in general I imagine it creates some risk.
Why can't they signature spoof for those fundamental apps and prevent installing or uninstalling them, similar to how you can't uninstall google stuff on stock android?
Signature spoofing violates the android security model. It means giving privileged access to microG, which means giving privileged access to google. For a privacy project, granting 3rd parties privileged access is unacceptable.
MicroG isn't a 3rd party: it's auditable FLOSS code running on my own device. If you consider microG unacceptable you should never "apt install" anything.
microG uses many of the same closed source Google services, downloads and runs closed source Google Play binaries with Google access and exists to provide compatibility with closed source Google libraries used by apps. Using microG doesn't change that you're using closed source Google code on the client side and also on the server side for many of the services. It also still uses closed source Google Play code itself, including downloading and running droidguard which is highly obfuscated and dynamically changes on a regular basis. That code gets access to all the permissions and privileged access being given to microG including the Location permission and all the special privileged app access which is doesn't get when a user installs sandboxed Google Play on GrapheneOS.
microG has a poor privacy and security track record. They've repeatedly had severe privacy and security issues which are publicly discovered and then go unfixed for years. One of those which involved leaking location data to apps which weren't supposed to have access to it was documented on their wiki but yet not addressed for years. There are still privacy holes in the location implementation, although the most severe issue was fixed.
GrapheneOS does provide open source reimplementations of Google Play APIs including location. It provides those as OS libraries running in the apps using them instead of an extra service. That means location data access is restricted by the standard sandbox and permission model rather than needing to reimplement it in a service. Reimplementing it in a service means mistakes or failure to keep up with the modern permission model can create privacy holes, which has happened with the microG location service repeatedly and taken years to address.
This about Play Services and not the Play Store. Play Services are a bunch of extra APIs/services that Google does not make available as part of AOSP. The non-nefarious reason is to make it possible to fix bugs and roll out features faster because the OEMs are terrible at rolling out new Android versions. The possible nefarious reason is to make more of Android closed-source.
At any rate, microG is a reimplementation of Play Services.
Note that MindTheGapps is distributed at https://github.com/MindTheGapps/. The dot-com domain looks like unaffiliated SEO squatting and could change download links to malware anytime.
There's also https[//]microg.cc and https[//]microg.net, both masquerading as homepages for MicroG, and Duckduckgo finds several more. I actually reported the latter to Namecheap a year ago, but got no response back.
Is there a good authority to report these to? Clearly registrars aren't interested in taking them down, and they're probably not serving malware right now, but fake download sites for software running with elevated privileges is a security incident waiting to happen.
I have never understood why people using MicroG can use apps like SNCF-Connect, while I cannot.
SNCF-connect is the largest online marchant in France. Since june, I cannot click the "pay" button anymore. It coincides with the new feature of Pay with Google.
So : is it because MicroG allows calls to Google services on e/OS devices, while my LineageOS refuses ? Or because MicroG implemented a try catch around this call, without any call to Google's servers ?
I think that's because /e/os also distributes App Lounge [1], which can connect to Google Store and handle payments (most of the time).
[1] https://doc.e.foundation/os/apps/app-lounge/
If it connects to Play Store, then isn't that the same as Aurora? Can people's accounts be banned? That would really suck to pay for something and lose it because Google banned you haha!
Some Play Services calls are stubbed out as no-ops and others are reimplemented either with fully free replacements (e.g. navigation) or else by calling proprietary Google remote endpoints (e.g. firebase)
I have no Google anything installed on GrapheneOS and SNCF Connect works fine.
MicroG is possible to run on GrapheneOS but isn't recommended since GOS has a sandboxing solution for running Google Play apps:
https://grapheneos.org/features#sandboxed-google-play
Graphene generally seems to feel that running official signed Google adware is more secure than using open source alternatives that might require signature spoofing or having root on your own device.
GrapheneOS's approach is Sandboxed Google Play so the apps don't get special permissions. Without privileged access, Google apps get access to nothing more than what other apps can get access to on Android. So, for example, even if a device has microG installed, an app with a Google library would have virtually the same access as if Sandboxed Google Play was installed. And why would anyone need microG if not to provide compatibility for apps that rely on Play Services, aka apps with Google libraries?
Also, for some reason some people think that microG means deGoogling. That's not at all the case. microG still communicates with Google servers.
microG doesn't meet the project's requirements. If you look at the big picture, microG offers worse app compatibility and is less secure. The cons outweigh the pros by a lot. "Google bad" isn't an argument that works for us. App compatibility is very important.
"Sandboxed" Google Play still gets everything that the other apps in the same profile offer up to it / to Google. I don't understand how you're gaining any privacy as a practical matter. The issue isn't GApps' privileged access to the system, it's that other apps send your data to Google via Google Play Services.
To take some examples, MicroG stubs out the analytics and ads APIs. Your "sandboxed" Play would send that data to the mothership and return with ads.
https://github.com/microg/GmsCore/wiki/Implementation-Status
https://github.com/microg/GmsCore/blob/32bc8954ff872d0e1a05d...
> I don't understand how you're gaining any privacy as a practical matter.
Exactly.
Being too focused on "Google bad" means you're not seeing the bigger picture. microG is only a thing to provide app compatibility for apps that rely on Google Play Services. Which apps do you think do that? Apps with Google libraries that often have fallback implementations and can operate without Google Play Services.
So, given those facts, if someone has microG installed, Google still effectively has the same access as a device with Sandboxed Google Play, except microG users are stuck with worse app compatibility and because of signature spoofing it's less secure and code runs in that privileged context.
GrapheneOS focuses on privacy, security, and app compatibility. microG fails at security and app compatibility. Also, there are apparently leaks (that I admit I don't know the details of) regarding location that make it worse for privacy too. There could be more leaks that I don't know about.
microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.
Each app using Google Play still has the closed source Google Play SDK and libraries built into it in practice. It's extraordinarily rare to replace those libraries with the incomplete and buggy reimplementations from microG. Very close to zero otherwise open source apps are using those. The closed source Google Play SDK and libraries are therefore still part of the loop and have access to what the app can access. Many of the code paths in the Google libraries directly use Google services without requiring Play services including the full versions of the Ads and Analytics libraries.
The vast majority of data obtained by Play services is via the OS integration and permissions. Apps using it for push messaging, logging into accounts and many other features will send the same data to Google services regardless of whether you use it via sandboxed Google Play or microG.
GrapheneOS stubs out and reimplements APIs on the client side. That includes providing a complete implementation of the Google Play services location API not using on Google Play. These features are being expanded over time. They'll also be made available without having Google Play.
The GrapheneOS approach avoids giving an additional global service access to sensitive data from the OS and apps. microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.
Unlike microG, sandboxed Google Play doesn't get privileged access. That includes the executables (droidguard) downloaded by microG not getting privileged access. GrapheneOS also doesn't give privileged access to other apps such as Android Auto when those are installed as all the main operating systems using microG are doing. That privileged access gives access to highly sensitive data and doesn't require apps explicitly sending data to Google services, which will nearly all still go to Google services with a partial replacement of the middleware on the device.
The apps that use Google analytics/ads don't need Google Services on the device. The libraries are embedded into the app, and have just as much fingerprinting capabilities as sandboxes Google services.
Running google code sandboxed is far more secure than running google code with privileged access. MicroG downloads and runs google code in a privileged context and has had many privacy and security issues like leaking location to apps that dont have the location permission.
> MicroG downloads and runs google code in a privileged context
> many privacy and security issues
> leaking location to apps that dont have the location permission.
Could you share some details on these three points?
They'll just flag you for asking.
By "they" I assume you mean GrapheneOS supporters? I can only speak for myself, but I only flag things when they clearly deserve to be flagged. Fair discussions are important. They help us grow as people and even in our case, GrapheneOS, but we encounter a crazy amount of misinformation here. Some members of our team are also targets for endless harassment. It's so unfortunate that people behave that way. There are also clear sockpuppets attacking GrapheneOS while promoting others. There was a brand new account participating in this thread that was clearly doing that.
Misinformation, harassment, and people who are using unfair methods to win arguments and damage the reputation of others is unacceptable. That's the kind of thing that I flag. What other people do with their permissions is up to them, but I would say that I wouldn't condone people flagging just because they disagree. I'd consider flagging genuine questions to be awful behavior as well.
microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.
Each app using Google Play still has the closed source Google Play SDK and libraries built into it in practice. It's extraordinarily rare to replace those libraries with the incomplete and buggy reimplementations from microG. Very close to zero otherwise open source apps are using those. The closed source Google Play SDK and libraries are therefore still part of the loop and have access to what the app can access. Many of the code paths in the Google libraries directly use Google services without requiring Play services including the full versions of the Ads and Analytics libraries.
The vast majority of data obtained by Play services is via the OS integration and permissions. Apps using it for push messaging, logging into accounts and many other features will send the same data to Google services regardless of whether you use it via sandboxed Google Play or microG.
GrapheneOS stubs out and reimplements APIs on the client side. That includes providing a complete implementation of the Google Play services location API not using on Google Play. These features are being expanded over time. They'll also be made available without having Google Play.
The GrapheneOS approach avoids giving an additional global service access to sensitive data from the OS and apps. microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.
Unlike microG, sandboxed Google Play doesn't get privileged access. That includes the executables (droidguard) downloaded by microG not getting privileged access. GrapheneOS also doesn't give privileged access to other apps such as Android Auto when those are installed as all the main operating systems using microG are doing. That privileged access gives access to highly sensitive data and doesn't require apps explicitly sending data to Google services, which will nearly all still go to Google services with a partial replacement of the middleware on the device.
I guess this is submitted because of https://news.ycombinator.com/item?id=50154624 ?
Why do the most recent commits all say "Merge commit from fork" without any description of what the changes do or what the fork is?
Lazy merge commits. The descriptions of the changes are in the commits from the merged branches.
This is why I always think emperor git wears no clothes. Hiding these kind of intermediate junk commits from history should not require rewriting and breaking the distributed history you all share. imho the correct solution would be a tag-like layer for annotating existing commits with metadata (additional signatures, hide-flags, retroactive comments, etc) or just a full 2nd dag, but whatever: git sucks at annotating history and annotating history is a core workflow in git.
It's too bad you have to rely on signature spoofing to be able to use this as an alternative (but obviously I understand why). The spoofing looks narrowly scoped on LineageOS, but in general I imagine it creates some risk.
Why can't they signature spoof for those fundamental apps and prevent installing or uninstalling them, similar to how you can't uninstall google stuff on stock android?
Signature spoofing violates the android security model. It means giving privileged access to microG, which means giving privileged access to google. For a privacy project, granting 3rd parties privileged access is unacceptable.
MicroG isn't a 3rd party: it's auditable FLOSS code running on my own device. If you consider microG unacceptable you should never "apt install" anything.
microG uses many of the same closed source Google services, downloads and runs closed source Google Play binaries with Google access and exists to provide compatibility with closed source Google libraries used by apps. Using microG doesn't change that you're using closed source Google code on the client side and also on the server side for many of the services. It also still uses closed source Google Play code itself, including downloading and running droidguard which is highly obfuscated and dynamically changes on a regular basis. That code gets access to all the permissions and privileged access being given to microG including the Location permission and all the special privileged app access which is doesn't get when a user installs sandboxed Google Play on GrapheneOS.
microG has a poor privacy and security track record. They've repeatedly had severe privacy and security issues which are publicly discovered and then go unfixed for years. One of those which involved leaking location data to apps which weren't supposed to have access to it was documented on their wiki but yet not addressed for years. There are still privacy holes in the location implementation, although the most severe issue was fixed.
GrapheneOS does provide open source reimplementations of Google Play APIs including location. It provides those as OS libraries running in the apps using them instead of an extra service. That means location data access is restricted by the standard sandbox and permission model rather than needing to reimplement it in a service. Reimplementing it in a service means mistakes or failure to keep up with the modern permission model can create privacy holes, which has happened with the microG location service repeatedly and taken years to address.
I heard about this, but don't understand the risks?
I use it on LineageOS, works a charm
I dont get why some apps depend on Google Play functionality. Why can't I download Telegram on /e/OS
you can't download telegram from telegram.org?
This about Play Services and not the Play Store. Play Services are a bunch of extra APIs/services that Google does not make available as part of AOSP. The non-nefarious reason is to make it possible to fix bugs and roll out features faster because the OEMs are terrible at rolling out new Android versions. The possible nefarious reason is to make more of Android closed-source.
At any rate, microG is a reimplementation of Play Services.
You can directly download the Telegram APK from: https://telegram.org/android
(Or using the app store that is part of /e/OS and serves as a front for both the Play Store and F-Droid.)
They could also have it decoupled from the OS with an open-source version, these are two different subjects.
The real reason to me is that they want to avoid Android forks outside of their control.
Yes, which is why I also mentioned the more nefarious reading of it. Making a large API surface use closed-source code gives them control.
Telegram is a Russian spy app, it needs remote attestation you are not a bot because collecting bot data is not valuable.
Is it too late to rename to "MindTheGapp"?
Considering that MindTheGapps is a distribution of the real Google Apps packages, yes, it's too late.
https://mindthegapps.com/
Note that MindTheGapps is distributed at https://github.com/MindTheGapps/. The dot-com domain looks like unaffiliated SEO squatting and could change download links to malware anytime.
There's also https[//]microg.cc and https[//]microg.net, both masquerading as homepages for MicroG, and Duckduckgo finds several more. I actually reported the latter to Namecheap a year ago, but got no response back.
Is there a good authority to report these to? Clearly registrars aren't interested in taking them down, and they're probably not serving malware right now, but fake download sites for software running with elevated privileges is a security incident waiting to happen.
Ah no! Oh well.
Go home! Goober!...
I mean Google!