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.
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 ?
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?
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.
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/
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 is incredibly focused on security. Privacy is clearly a second thought to them.
de-Googleling is unfortunately not a priority for GrapheneOS.
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.
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/
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 ?
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?
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.
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.
Ah no! Oh well.
Go home! Goober!...
I mean Google!