Salta al contenuto principale


GrapheneOS: Einstellungen der Google Play Services im vertraulichen Profil

kuketz-blog.de/grapheneos-eins…

in reply to Kuketz-Blog 🛡

Neee, ich verzichte lieber komplett auf die Google Play Wanze und nutze die datenschutzfreundlichere Variante namens MicroG.
in reply to Chris

@Kubiac MicroG ist weniger datenschutzfreundlich, unsicherer und weniger nutzerfreundlich in der Bedienung als die von GrapheneOS bereitgestellte sandboxed Lösung. Also in quasi allen Belangen schlechter.
Questa voce è stata modificata (4 mesi fa)
in reply to David Culley

@davidculley @Kubiac
Sicherheit: ich verstehe wie du darauf kommst: microG wird häufig mit erhöhten Berechtigungen installiert. Das ist aber optional, bei einigen OS geht es auch ohne.
Nutzerfreundlich: das ist natürlich Geschmackssache, aber kann ich prinzipiell auch nachvollziehen. microG ist halt ein Open-Source-Projekt weniger Entwickler, Google steckt dagegen sicherlich viel mehr Ressourcen in ihre Spyware.
Datenschutzfreundlich: Verstehe ich nicht, kannst du das erklären?
in reply to pixelschubsi

@pixelschubsi @davidculley The whole point of the sandboxed Google Play compatibility layer is that we provide zero special access or privileges to Google apps and services. The only purpose of using sandboxed Google Play is to use apps which contain the Google Play SDK and libraries. You are running Google Play's code when you use those apps. It runs as part of the apps within their app sandbox. Many of those libraries including Ads and Analytics work without Google Play services.
in reply to GrapheneOS

@pixelschubsi @davidculley Sandboxed Google Play uses the same app sandbox for Google Play services and Google Play Store that's used for apps containing Google Play code. Therefore, it provides zero additional access or control to Google Play code compared to using the apps using Google Play code without the rest of Google Play.

Since GrapheneOS improves the app sandbox and permission model, less data is available to Google Play code with our approach than an OS without our privacy features.

in reply to GrapheneOS

@pixelschubsi @davidculley GrapheneOS has our own network location implementation not tied in any way to Google service compatibility. It has a more private and usable approach than fully online network location services with full offline support in progress.

Separately from that, we provide our own implementation of the Google Play location API not using Play services but rather the OS location service. It runs within the apps using it as a library and makes them use the OS service.

in reply to GrapheneOS

@pixelschubsi @davidculley Users can disable this redirection but there's very little reason to do it anymore beyond testing since we have our own OS network location.

We'll be reimplementing more Google Play functionality and redirecting to the OS implementations of functionality when it makes sense. Location was just the most important. Sensor APIs are likely next.

Our compatibility layer is open source, as are the standalone reimplementations of functionality like network location too.

in reply to GrapheneOS

@pixelschubsi @davidculley We made our own open source compatibility layer for running closed source Google Play code because the existing compatibility layer didn't meet our privacy, security and compatibility requirements. We wanted to start with near perfect compatibility while maintaining the standard security and not giving any more access to data than not using it. We're gradually improving it and will be reimplementation much more than the location API as part of it.
in reply to GrapheneOS

@pixelschubsi @davidculley It will become possible to use our compatibility layer without the sandboxed Play Store and sandboxed Play services. We do already make certain apps like Pixel Camera and Google Photos work without it. Many people have a significant misunderstanding of what we provide in this area and the roadmap for it. It's important to understand that the apps using Play services have closed source Google Play SDK and library code included and avoiding it is a different thing.
in reply to GrapheneOS

@pixelschubsi @davidculley If you want to avoid using closed source Google Play code, you need to avoid apps depending on Google Play services. For example, Molly is a fork of Signal with a variant without the Google Play libraries. It provides UnifiedPush support as an alternative to using either Firebase Cloud Messaging via Play services or the less efficient Signal background push. Signal with microG is still using closed Google Play code as part of Signal with a Google service via microG.
in reply to GrapheneOS

@GrapheneOS @davidculley Your comment misses the point. The above was to compare GrapheneOS with microG to GrapheneOS with sandboxed Play Services. MicroG is not a competitor to GrapheneOS (different layer) and also it's very clear the best would be if none of them were used and apps would just work without any proprietary code or SDK. Molly is a good example here.
in reply to pixelschubsi

@pixelschubsi @davidculley GrapheneOS with microG is mostly not an option. microG depends on spoofing signature checks for Play services which is not going to be integrated by GrapheneOS. microG does not preserve standard privacy and security checks so that won't be added.

You're still running Google Play code within the app sandbox if you use microG to provide compatibility with apps depending on Play services. Using microG does not avoid running Google Play code in general, only parts of it.

in reply to GrapheneOS

@pixelschubsi @davidculley GrapheneOS is fully capable of reimplementing Google Play services functionality without microG and it does do that. If you want more of that, you'll be happy to know that we'll be providing more. We will not be implementing it via microG. microG does not meet our code quality standards, particularly for privacy and security. The development team is untrustworthy particularly considering their attacks on our team. We make our own replacements for Play functionality.
in reply to GrapheneOS

@GrapheneOS @davidculley As soon as you run two apps in a profile, adding sandboxed play services means those apps can (and factually do) cross-talk and share user identifiers. A well-known case of this is the Advertising ID (which luckily can be turned off), but it also applies to others like push tokens or auth tokens. That's definitely not "zero additional access".
in reply to pixelschubsi

@pixelschubsi @davidculley There's absolutely no extra interprocess communication access for Google Play services on GrapheneOS. Apps don't need Google Play services to communicate with each other within the same profile. In general, apps do not communicate via Google Play services as that's not something it provides as an API. The advertising ID is optional and can be disabled. Push tokens and authentication are per-app, not shared across apps. The apps can certainly communicate without it.
in reply to GrapheneOS

@GrapheneOS I guess you might have not understood the post you're replying to, given it's written in German. For reference, @davidculley wrote that GrapheneOS sandboxed Play Services is more secure, user-friendly and privacy-friendly than microG. I replied that I understood how he concluded the first two, but not how it is more privacy-friendly than microG. Your multi-message reply does not tell me anything in that regard.
in reply to pixelschubsi

@pixelschubsi @davidculley GrapheneOS provides strictly less access to user data and other information to Google Play code than CalyxOS with microG. It objectively gives less data to the apps using Google Play and Google Play code. You are not avoiding Google Play code through using microG. Aside from that, the idea that something being open source makes it more private is false. microG has had major privacy issues such as leaking location data to apps which aren't meant to be given access.
in reply to GrapheneOS

@GrapheneOS @davidculley Nobody talked about CalyxOS here. Again, we want to compare the privacy GrapheneOS with sandboxed Play Services with a hypothetical GrapheneOS that uses current microG instead, which, while not official, is trivial to achieve given how little effort is needed to do the signature spoofing. I also heard microG developers have considered adding a feature that makes it work on unchanged GrapheneOS.
in reply to pixelschubsi

@pixelschubsi @davidculley @Kubiac@mastodontech.de microG does not work without privileged access. In DivestOS, it wasn't integrated as a privileged app but was still given the special ability to pretend to be Google Play services. Doing that bypasses security checks and then makes it a problem that microG does not implement the same privacy/security checks. That is still giving it a form of privileged access and it does have real consequences.
in reply to GrapheneOS

@pixelschubsi @davidculley microG has a lot of developers who have been involved on underhanded attacks on the GrapheneOS project, our team and our community. microG has a history of introducing privacy/security vulnerabilities including leaking location data to apps and downplaying that to the point of covering it up. What about that is trustworthy? They have clearly demonstrated a disregard for security and that their idea of privacy is limited to reducing use of Google code and services.