Ich habe mal ein wenig gestöbert und bin auf ein paar Ideen gekommen. Erstmal ein paar Fragen zu deiner Situation:
-
Hast du in den Einstellungen bei den Berechtigungen noch mal überprüft, ob die betreffenden Apps auch wirklich keine Netzwerk-Berechtigung haben? Nur zur Sicherheit.
-
Hast du im betroffenen Benutzerprofil Sandboxed Google Play installiert?
-
Könnten die betroffenen Apps mit einer anderen App mit Netzwerk-Berechtigung zu kommunizieren versucht haben?
-
Sind die aufgerufenen Verbindungen die Links, die die betroffenen Apps automatisch öffnen dürfen?
IPC
Wenn sich das Problem nicht wider Erwartens schon nach Schritt 1 löst, könnte es an IPC mit Google Play Services oder anderen Apps liegen. Inter-process communication, oder zu deutsch Interprozesskommunikation, ist der Weg auf dem auf Android verschiedene Apps miteinander kommunizieren können. Das ist auch gut so, denn nur so kann Android trotz des app sandboxings überhaupt funktionieren.
Aus einem Thread zu IPC aus dem GrapheneOS Forum:
IPC has restrictions. It’s mostly used to send „messages“ not „data“ between apps. Like a valid IPC would be „hey, Vanadium, open www.youtube.com“. Invalid IPC would be „hey, Google Play Services, here’s this person’s entire photos collection“.
For IPC to work, it has to be mutual. Google Play won’t randomly make up some IPC call to a random app to get data from it, but even if it were to do that, that app would have to have that receiver set up, otherwise the IPC will be blocked by the OS.
Das bedeutet, dass es für Apps ohne Netzwerk-Berechtigung möglich sein könnte, über andere Apps Daten zu senden. Das allerdings nur sehr limitiert und sofern eine andere App vorhanden ist, die damit explizit kompatibel ist. Die Google Play Services sind auf GrapheneOS zwar Sandboxed und haben daher nur die Berechtigungen einer normalen App, statt Systemzugriff. Da IPC auch normale Apps können und Google das eigene Ecosystem natürlich aufeinander abgestimmt hat, kann so etwas beispielsweise passieren, wenn man Google Apps in einem Benutzerprofil mit Google Play Services benutzt.
Mehr Links
Hier mal eine Sammlung von nützlichen Threads und auszugsweise Zitaten:
Thread zur Nutzung von GBoard
the most private way to use Gboard is with Network permission OFF and without sandboxed Play Services as the two could communicate
Thread zur Isolation durch entzogene Netzwerk-Berechtigung
Just keep in mind apps in the same user profile can communicate with one another with mutual consent which is also transparent via their manifest… So an evil app you don’t trust can tell shit about you to the good app you trust if they are in conspiracy
Thread mit Daniel Micay über Lecks und allgemein zum Vertrauen in Apps
When you give an app a permission or another form of access, you trust it to be secure against being exploited by an attacker to gain access to what that permission […] provides.
For example, if you give an app Contacts access, you trust it not to leak access to that data. You trust it not to provide an API for other apps in the same profile to read or write contacts without either requiring explicit consent from you on a case-by-case basis or guarding it with the Contacts read/write permissions. […] The same thing applies to every permission and other form of access you can grant to apps.
Anmerkung: Contact Scopes dürften mittlerweile in der beschriebenen Situation mehr Schutz bieten.
Thread zum Umgehen der fehlenden Netzwerk-Berechtigung durch Google Play Services
- Is it theoretically and technically possible that data or metadata could be intentionally or unintentionally sent to Google by way of sandboxed play services?
- Do we have the technical means to know for sure whether this is or is not happening?
- If Sandboxed Play Services has Network permission then yes, it can receive some data from other apps via IPC and potentially send it to Google. Some data needs to be sent to Google if apps are using Google APIs.
- One could MITM at the router level or VPN level and inspect the traffic to see what exactly is being sent to where.
Contra IPC
Vielleicht liegt es aber doch an etwas anderem. Im GrapheneOS Feature Overview steht zum Network Permissions Toggle nämlich Folgendes:
GrapheneOS adds a Network permission toggle for disallowing both direct and indirect access to any of the available networks. The device-local network (localhost) is also guarded by this permission, which is important for preventing apps from using it to communicate between profiles. Unlike a firewall-based implementation, the Network permission toggle prevents apps from using the network via APIs provided by the OS or other apps in the same profile as long as they’re marked appropriately.
Da würde ich grundsätzlich schon davon ausgehen, dass trotz IPC keine direkten Verbindungen ins Internet hergestellt werden. Und da es keine Firewall ist, kann auch eine Lücke in ebenjener nicht das Problem sein. Was sonst könnte es sein?
(Weil wir bisher so wenige hatten) hier ein Thread zu vermeintlichen Datenlecks durch App Link Verification, in dem OP ein ähnliches Problem zu haben scheint:
I have been revoking network access from apps which I do not believe need it. […] I was looking at my NextDNS logs and noticed that the app was making DNS connections to its servers, while I had blocked it in permissions.
Erklärt wird das auch hier im GrapheneOS Usage Guide unter dem Punkt App Link Verification:
Android apps can declare associations with domains in order to handle those URLs in the app automatically. […] The OS will securely confirm that the domain authorizes the app to handle the domain’s URLs. […] Verification of app links by the OS is done by the Intent Filter Verification Service system app. It will use an HTTPS GET request to fetch https://example.com/.well-known/assetlinks.json in order to process a request to verify that an app can handle example.com links.
These network requests by the Intent Filter Verification Service to verify app associations with domains are commonly confused for network requests made by the apps. It’s simply an HTTPS GET request without identifying information and doesn’t offer a communication channel with the app.
Und hier noch ein Thread, mit ein bisschen unkomplizierterer Erklärung:
Any app can claim it can open any address. An app can claim hundreds of addresses if it wants, and Android will check all of them. […] [It] does this to protect people from apps that want to steal our information.
Für mich wirkt es am plausibelsten, dass die Verbindungen durch die App Link Verification zustande kommen. Scheinbar passiert es ja des Öfteren, dass dadurch jemand falsche Eindrücke bekommt. In dem Fall wäre es recht harmlos. Und wenn man es unbedingt ganz ausschalten möchte, kann man dank GrapheneOS der Intent Filter Verification Service Systemapp einfach die Netzwerk-Berechtigung entziehen. Dann sollte Ruhe sein.
Fazit
Das war für mich ein wilder, aber interessanter Ritt. Ich kann aus der Ferne schwer sagen, ob es bei dir konkret wirklich an IRC bzw. App Link Verification liegt, oder nicht doch an etwas anderem. Ich würde dir dazu raten, einfach mal die theoretisch vorstellbaren Lösungen durchzuprobieren. Wenn eine funktioniert, hast du auch wahrscheinlich das zugehörige Problem identifiziert – sofern es sich wirklich um ein Problem handelt.
Sollte gar nichts helfen, kann ich dir empfehlen, (idealerweise mit Bildern) im GrapheneOS Discussion Forum oder im GrapheneOS Matrix Raum nachzufragen. Es würde mich sehr wundern, wenn es dafür keine gute Erklärung gibt.
Viel Erfolg und sag gerne mal Bescheid, wenn du mehr weißt!