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)
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.
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.
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.
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.
GmsCompat is a layer that runs the official google play services and store in the app sandbox which also strips it of all privileges and teaches it to function with only the bare minimum.
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.
Telegram is practically a spy app for both Russian and Western agencies now. While Durov tried to claim total neutrality in his interview with Tucker Carlson, his stance completely flipped after France detained him. Telegram is now proactively cooperating with EU and USA agencies and sharing user data, normal chat logs (everything that is not "Secret Chats"), IP addresses and phone numbers with law enforcement.
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.
The founder and leader of /e/ and Murena has repeatedly claimed highly private and secure devices primarily benefit criminals and pedophiles. He has also falsely claimed that GrapheneOS is mainly used by criminals. /e/ and Murena heavily mislead users about what they provide. In reality, they lag incredibly far behind on standard privacy/security patches and protections. They set a fake Android security patch level despite having many patches missing. They even miss a large subset of the AOSP patches. Drivers and firmware are rarely updated and lag far behind the official releases. Linux kernel updates are barely provided.
/e/ adds many privacy invasive services to the OS including tracking users with random identifiers for updates. They sent user speech data to OpenAI for years without obtaining consent beyond it being hidden in a massive terms of service but have finally moved away from doing that in newer versions. They still have a bunch of other privacy invasive services and still add many more Google services compared to AOSP by default along with giving those privileged access. microG on /e/ downloads and runs Google Play executables with highly privileged access by default and they give highly privileged to Android Auto and other components as their way of getting those running.
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!
1 reply →
I have no Google anything installed on GrapheneOS and SNCF Connect works fine.
Are you sure? Login doesn't work on mine, and language is stuck to English idk why
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 guess this is submitted because of https://news.ycombinator.com/item?id=50154624 ?
Note even if you use MicroG, there is no Android device on the market that will function without piles of proprietary, and often privileged, software.
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?
These are merge commits generated by merging a PR from a private security fork created for GitHub Security Advisories.
These commits match the advisories published 3 weeks ago:
https://github.com/microg/GmsCore/security
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.
2 replies →
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.
17 replies →
I heard about this, but don't understand the risks?
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.
16 replies →
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.
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.
12 replies →
Okay, so lemme break this down real simple
(Correction from prior statement)
GmsCompat is a layer that runs the official google play services and store in the app sandbox which also strips it of all privileges and teaches it to function with only the bare minimum.
The app itself is sandboxed
But it is taught to run without the app panicking
The app sandbox is an OS feature: https://source.android.com/docs/security/app-sandbox.
de-Googleling is unfortunately not a priority for GrapheneOS.
4 replies →
GrapheneOS is incredibly focused on security. Privacy is clearly a second thought to them.
10 replies →
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
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.
1 reply →
you can't download telegram from telegram.org?
Telegram is a Russian spy app, it needs remote attestation you are not a bot because collecting bot data is not valuable.
Telegram is practically a spy app for both Russian and Western agencies now. While Durov tried to claim total neutrality in his interview with Tucker Carlson, his stance completely flipped after France detained him. Telegram is now proactively cooperating with EU and USA agencies and sharing user data, normal chat logs (everything that is not "Secret Chats"), IP addresses and phone numbers with law enforcement.
Telegram works on my /e/OS device. I am using Obtainium to download it, but you can also download it from the website: https://telegram.org/android
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.
1 reply →
Ah no! Oh well.
Go home! Goober!...
I mean Google!
My main device uses MicroG with LineageOS. It works really well, and I recommend it. It is a Murena phone from here: https://murena.com/
Murena? Didn't their CEO say that security is only for pedophiles lol. Can't trust that guy with our data.
Murena also sent data to Open AI, right? Didn't tell their users.
Also mixed up sessions on their service and users got other users' data downloaded on their devices.
We can't trust your judgement.
The founder and leader of /e/ and Murena has repeatedly claimed highly private and secure devices primarily benefit criminals and pedophiles. He has also falsely claimed that GrapheneOS is mainly used by criminals. /e/ and Murena heavily mislead users about what they provide. In reality, they lag incredibly far behind on standard privacy/security patches and protections. They set a fake Android security patch level despite having many patches missing. They even miss a large subset of the AOSP patches. Drivers and firmware are rarely updated and lag far behind the official releases. Linux kernel updates are barely provided.
/e/ adds many privacy invasive services to the OS including tracking users with random identifiers for updates. They sent user speech data to OpenAI for years without obtaining consent beyond it being hidden in a massive terms of service but have finally moved away from doing that in newer versions. They still have a bunch of other privacy invasive services and still add many more Google services compared to AOSP by default along with giving those privileged access. microG on /e/ downloads and runs Google Play executables with highly privileged access by default and they give highly privileged to Android Auto and other components as their way of getting those running.
https://clubic.com/actualite-604786-murena-e-os-interview.ht...
https://grapheneos.social/@GrapheneOS/116353973732143171
5 replies →
Murena doesn't produce their phones, they just flash modified /e/OS to devices from Fairphone, Gigaset, Hiroh, SHIFT and Google.
It's better to buy one of these directly and flash a preferred ROM yourself.