Android limiteert inzien welke apps geïnstalleerd zijn door andere apps

Google voert in mei een restrictie voor Android in die maakt dat apps beperkt worden in de mogelijkheden om te detecteren welke andere apps een gebruiker op zijn smartphone geïnstalleerd heeft.

Google beperkt het gebruik van query_all_packages voor Android-apps per 5 mei, zo meldt het bedrijf. In de praktijk betekent de stap dat Android-apps alleen nog kunnen opvragen welke andere apps op een toestel van een gebruiker zijn geïnstalleerd als dit noodzakelijk is voor de kernfunctionaliteit van die app.

Apps die hier niet aan voldoen, maar wel gebruikmaken van query_all_packages, moeten hun manifest aanpassen om aan het gewijzigde Google Play-beleid te voldoen. Anders riskeren ontwikkelaars dat de app verwijderd wordt. Alleen Android-apps op basis van api-niveau 30 of hoger, gericht op apparaten met Android 11 of hoger, kunnen toestemming krijgen om query_all_packages te gebruiken. Vanaf november 2021 moeten nieuwe apps voor Google Play zich op Android 11 richten om toegelaten te worden in de downloadwinkel.

Google voert de wijziging door, omdat het de geïnstalleerde apps als persoonlijke en gevoelige informatie beschouwt en de privacy van gebruikers op dit vlak beter wil beschermen.

Reacties (62)

[dasiro]

qua security zal dit enkel maar verbeteringen brengen, uiteindelijk zouden apps volledig geïsoleerd moeten kunnen werken en inter-app content via een API-handoff doorsturen die door de andere app dan weer wordt geaccepteerd.
Ideaal voorbeeld zou voor password-managers zijn dat een app een request stuurt naar de API. Is er een manager? zo ja, dit is de hash van de site of app die authenticatie vraagt, waarbij de manager dan zelfs niet kan zien wélke app of site dit vraagt en antwoord met een hash van de opgeslagen credentials die worden teruggestuurd en je paswoorden zelf nooit meer heen en weer gaan. De enige weak-link is dan de encryptie, maar die kan je dan onafhankelijk van de apps verhogen als er nieuwe technieken worden geïmplementeerd (als de oude achterhaald/gecompromitteerd zijn bvb)

[DataGhost]

Het voorbeeld wat je nu noemt is er volgens mij allang in de vorm van Autofill. Als ik op een veld van een inlogformulier tik krijg ik de optie om het met Autofill dmv mijn password manager (Keepass2Android) in te vullen als die optie niet direct al zichtbaar was. Kies ik daar vervolgens voor, krijgt mijn password manager een query voor de package-naam (com.bedrijf.app) of een URL en die kan daar vervolgens op zoeken. Kies ik een entry, wordt dat via de Autofill-API ingevuld in het inlogscherm.

Neemt niet weg dat het inderdaad een goed idee is dat apps op een "app-onafhankelijke manier" zouden kunnen communiceren op veel gebieden.

[dasiro]

dat is het nu net: in mijn idee weet keepass zelfs niet dat jij in com.gay.matchfinder wil inloggen, dan zou het enkel weten dat het het de credentials-hash van applicatie-hash moet sturen. Moest het volledig E2E-encrypted zijn, dan weet zelfs de android-API dit niet.

[DataGhost]

Ja logisch, maar je begeeft je nu over de grens tussen usability en security/privacy. Natuurlijk moet keepass gewoon weten dat ik in com.gay.matchfinder wil inloggen, anders kan de bijbehorende entry helemaal niet opgezocht worden. Er is niet echt een manier om dit verder te automatiseren zonder deze zoek-info. Als ik dat niet wil is het simpel, niet gebruik maken van Autofill, handmatig opzoeken welke entry ik wil gebruiken en via het Keepass-toetsenbord (zodat je niet hoeft te copy/pasten) invullen in de app. Zo blijft de app zelf voor Keepass onbekend.

[dasiro]

daar komt de applicatie-hash bij kijken.

com.gay.matchfinder = ERZERZER65
jouw credentials = LKJLKJKL118
als je je credentials wil opslagen stuurt ERZERZER65 naar de authentication-API STORE ERZERZER65 LKJLKJKL118
Deze geeft dan een lijst van password-managers en jij kiest je keepass.
de authentication-API stuurt dit commando dan door en in keepass staan dan zelfs geen paswoorden.
een password request volgt dan de omgedraaide weg:
ERZERZER65 stuurt naar de authentication-API GET ERZERZER65 en je kiest in je lijstje keepass.
keepass antwoord dan met SEND ERZERZER65 LKJLKJKL118. De API geeft dit dan als antwoord terug en je bent ingelogd.

[David Mulder]

Dit zou het wel ongelovelijk veel moeilijker maken om wachtwoorden te managen. Stel je nu voor dat je je manager opent en je com.facebook.orca aan messenger.com wilt linken (want is beide facebook login), de gebruiker zou dan op de één of andere manier beide hashes moeten weten te herkennen.

En het grootste probleem is dat het voor de veiligheid compleet nutteloos is, want het aantal populaire apps is relatief klein en de hash zou unsalted moeten zijn, want verschillende devices moeten dezelfde hash berekenen en de salt zou deel van het OS moeten zijn en niet van de password manager, want als het deel was van de password manager dan zou je sowieso door de lijst van populaire apps kunnen bruteforcen in no time.

Mogelijk dat er een oplossing bestaat (master password dat je aan het OS moet geven dat gebruikt zou worden als salt misschien en dan misschien het OS zelf alle management tools aanbieden...?), maar ik heb grote twijfel dat er een oplossing bestaat die niet een grote impact heeft op usability.

[Reactie gewijzigd door David Mulder op 30 juli 2024 21:59]

[frankkie12345]

Hopelijk breekt dit niet het deel-systeem.
Heel veel apps laten je content delen naar andere apps;
(Denk aan je Galerij-app die een foto wilt delen naar Facebook)
Die moeten op kunnen vragen welke apps die content kunnen ontvangen lijkt me.
Anders kunnen ze geen mooie lijst met opties tonen (in de eigen look and feel).
Als ze dit niet kunnen, moeten ze de content delen en hopen dat het ergens aan komt.
Ben benieuwd.

[Wolfos]

Nee, dat is een ander systeem. Je geeft dan aan welke content je wilt delen, maar de rest word door het OS geregeld. De app hoeft hiervoor niks te weten over de andere apps. Het is zelfs niet mogelijk om te zien welke app dit bericht oppakt.

Zie:
https://developer.android...components/intents-common

[Reactie gewijzigd door Wolfos op 30 juli 2024 21:59]

[reneflo]

Punt is wel dat veel (vooral Google) apps niet gewoon een intent afvuren, maar hun eigen share sheet knutselen. Hier is bijvoorbeeld een artikel over de share sheet van Chrome: https://www.androidpolice...et-and-more-apk-download/

Je kan dit maken door op te vragen welke activities een intent afvangen:

List<ResolveInfo> infos = manager.queryIntentActivities (intent,
PackageManager.GET_RESOLVED_FILTER);

Ik vraag me af of dit dan wel blijft werken, want dan kan je ook nog aardig wat beschikbare apps scannen op je telefoon. Kan je alleen geen apps vinden die niet te openen zijn via een share intent actie. Volgens het artikel wordt alleen query_all_packages geblokkeerd.

[Cerberus_tm]

Met Xprivacy (Luo) blokkeer ik al sinds Android 4 welke apps andere apps kunnen zijn. Dat is bijna nooit nodig. En delen werkt meestal los daarvan.

[GertMenkel]

Er is een standaard-API voor het delen van inhoud die zal blijven werken, alhoewel sommige apps (en dan vooral van de grote spelers) er de neiging op nahouden om vaag, proprietary gedrag daaraan toe te voegen. Google is daar voor zover ik weet geen fan van, en ik eigenlijk ook niet.

Sommige app-ontwikkelaars detecteren om die reden welke apps er allemaal geïnstalleerd zijn. Dat gebruik mag niet meer:

Below is a list of use cases that won't be permitted to request the QUERY_ALL_PACKAGES permission:

• Where use of the permission is not directly related to the core purpose of the app.
  • This includes Peer-to-Peer (P2P) sharing. P2P must be the core purpose of the app in order to qualify as a permitted use.
• When the data is acquired for the purpose of sale.
• When the required task can be done with a less broad app visibility method.

Note: This list is not exhaustive. For in depth guidance on alternative options and best practices, please refer to the Managing Package Visibility guidance for developers

Ontwikkelaars zullen dus specifiekere API calls moeten doen om te checken of je Facebook, Twitter of Tiktok geïnstalleerd hebt als je dat soort trucs willen uithalen.

Eigen share-schermen zullen verdwijnen. Die zijn ook nergens voor nodig, overigens; er zijn drie of vier verschillende API's om zo'n share uit te voeren, die allemaal op zijn minst de UI van de telefoon volgen. Ik heb echt een pesthekel aan die momenten dat ik op share druk en de app me behulpzaam vraagt of ik mijn plaatje wil delen met de SMS daemon, ADB bugreport server of met de Qualcom Network Driver.

[hoeksmarp]

Werkt dat niet via een standaard van de api van android? Hoeft toch niets voor worden opgevraagd?

[Aiii]

Volgens mij heeft Android gewoon een API die dat soort zaken regelt. Daar hoef je als App verder niet veel aan te doen, je geeft slechts de te delen content door aan de API, en die toont dan de apps die deze content accepteren.

[satya]

Het is in Android 11 zowieso al een drama geworden als je een app voor foto's of camera wil gebruiken die niet de standaard op je device is

[frankkie12345]

Praat me er niet van...
Heb deze library gemaakt, als een wanhopige poging dit weer mogelijk te maken.
https://github.com/frankkienl/camera11
Maar als die packages niet meer kunnen worden worden gequeried via de PackageManager, dan zal dit ook niet meer werken.

[satya]

Best gaaf, het valt te hopen dat default apps instelbaar worden.

[reneflo]

Ik heb me altijd al verbaasd dat het zo makkelijk is als app om te kijken welke andere apps geïnstalleerd zijn. Al kan het nuttig zijn om battery saver apps te vinden die mogelijk app functionaliteit schaden vind ik het heel goed dat dit gelimiteerd wordt.

[TuxDePinguïn]

Voor alles is wel een interessante use case te vinden. Gelukkig heeft Google hier ook aan gedacht:

Alleen Android-apps op basis van api-niveau 30 of hoger, gericht op apparaten met Android 11 of hoger, kunnen toestemming krijgen om query_all_packages te gebruiken.

[dakathefox]

Inderdaad. Denk aan het gebruik van Shazam, waarbij jij je net ontdekte muzieknummer direct kunt afspelen in je Spotify App of Youtube Music App.

[Tassadar32]

Daarvoor heb je geen query_all nodig. Je kan ook opvragen of specifieke apps geinstalleerd zijn.

[Aiii]

Ook dat lijkt mij volstrekt overbodig. Als je een app maakt, dan kun je je website zo configureren dat je weblink de gebruiker automatisch doorstuurt naar je app. Bij Apple gaat dit automatisch als je de configuratie goed doet, bij Android meen ik dat de gebruiker zelf mag aangeven of hij website of app wil openen bij een volgende klik (of de keuze wilt blijven krijgen). Ook Spotify en Apple Music kunnen gewoon met een URL worden aangeroepen. Waarom zou een app dan moeten kunnen opvragen wat jij zoal op je telefoon geïnstalleerd hebt? Dat soort functionaliteit kan alleen maar misbruikt worden om data te verzamelen over de gebruiker en voegt maar weinig extra's toe.

Dat er use cases waarbij je een App wellicht een specifieke toestemming zou kunnen geven om dit te willen, zoals het use case hierboven voor een eventuele batterij-app, snap ik wel. Maar waarom dit voor het gestelde use case van linken naar muziekservices nodig zou zijn? Nee, laat dat w.m.b. maar lekker achterwege.

[Reactie gewijzigd door Aiii op 30 juli 2024 21:59]

[Tassadar32]

Voorbeeld: om door te verwijzen naar een app, maar alleen als deze geinstalleerd is (en de UI daarop aanpassen). Minder probleem met PWA en partial apps maar nog steeds een valide use case.

[Zwatelaar]

In jouw usecase zou het voldoende moeten zijn om alleen op te vragen of die ene benodigde app geïnstalleerd is.

Het probleem is dat veel apps je gehele lijst met geïnstalleerde apps opvragen (en vaak ook doorsturen naar de app-bouwer).

Het eerste valt onder functioneel, het laatste valt onder dataverzameling.

[Teutates]

Volgens mij gebruikte onder andere Pokemon GO deze functie om tekijken of bepaalde "cheat" apps geïnstalleerd waren.

Maar inderdaad lijkt me niet iets wat de meeste apps nodig hebben. en lijkt me een goede aanpassing om dit beter te beperken.

[Farcrada]

Dit werkt dan ook twee kanten op. Alhoewel je niks kan beginnen tegen een Android installatie op een rooted apparaat. Zou je op een "normale" installatie nu dus ook niet meer vanuit de cheat applicatie andere applicaties kunnen benaderen.

Aan het eind van de race komt het niet neer op hoe veilig je de applicatie kan maken op het apparaat van de gebruiker maar komt het erop aan dat ze de gebruiker vertrouwen. En dat is juist iets dat je niet moet doen als je met invoer verificaties werkt. Dit is bijvoorbeeld waarom bank applicaties gewoon blijven werken ondanks je wellicht niet eens meer op een telefoon bezig bent. Geen enkele cheat gaat ervoor zorgen dat jij ineens 6 miljoen op je rekening krijgt.

Nu ben ik niet helemaal helder over wat voor manier(en) er dan vals gespeeld wordt, en snap ik ook dat sommige input nu eenmaal afhangen van desbetreffende gebruiker informatie (locatie, bijvoorbeeld), maar dat houdt niet in dat het principe van Don't Trust The Client dan ineens weg valt.

[Sandwalker]

Dat zijn natuurlijk twee kanten van de medaille. Android’s privacy wordt iets beter door deze aanpassing. Mogelijk ook iets veiliger, de prijs daarvoor is dat packages die buiten de store om geïnstalleerd zijn ongehinderd hun ding kunnen doen, dan worden online spellen minder leuk. Ik denk nog steeds dat voor cheat detectie het niet nodig is om naar andere apps te kijken. Op basis van het gedrag kun je heel goed zien of een speler menselijk of augmented is.

[unreal0]

Use case: automatisch account koppelen van bijvoorbeeld Spotify aan een account in een andere app

[blinchik]

Als je kan opvragen of er specifieke apps geïnstalleerd zijn, dan kan je toch een grote lijst van package namen inbouwen en die een voor een query'en?

Ik snap de usecase wel, ik heb zo een een app die een apart licentie pakketje installeert, die zullen waarschijnlijk daar op checken.

[Verwijderd]

Je moest eens weten wat een desktop applicatie allemaal kan zien en doen

Het sandbox model is echt heel gaaf, ik denk dat het al lang standaard geweest zou zijn als Microsoft en Apple het niet keihard als walled garden misbruikt zouden hebben.

[reneflo]

Ja het sandbox model is zeker heel mooi. Ik denk dat het vooral nog niet de standaard is omdat het lastig backwards compatibel later te introduceren. De OS'en die het hebben hebben het direct vanaf het begin. Als je app ontwikkelaars laat kiezen of ze sandboxed draaien of niet gaan toch veel voor niet waarschijnlijk. Als je al ziet hoe lang mensen Internet Explorer zijn blijven gebruiken omdat applicaties anders niet meer werkten zal het lang duren voordat alle apps sandboxed zijn als je dit introduceert in update.

[Verwijderd]

Als je gebruikers kan laten kiezen tussen sandbox en non-sandbox op de zelfde manier als dat met http en https gegaan is komt dat wel goed. Zolang je de waarschuwings popups maar rood en eng genoeg maakt

[swtimmer]

Eindelijk. Altijd zot gevonden dat praktisch iedere app kan zien welke bank of investerings app ik gebruik.

[kamerplant]

Inderdaad, het is krankzinnig dat dit überhaupt kon. Ik zou dat beschouwen als een major privacy lek eigenlijk.

[GertMenkel]

Ik vind het wel komisch hoe we in tien jaar tijd van "waarom moet alles gesandboxed" naar "waarom kunnen apps elkaar zien" gegaan zijn. Je Skype, Discord, VLC en Chrome kunnen elkaar op de computer ook allemaal zien, ik zie niet waarom je je hierover zou verbazen. Het gesandboxte, gesegmenteerde, door-Google-en-Apple-beheerde ecosysteem van applicaties is nog zeer nieuw.

Ik hoop wel dat ik handmatig deze beperkingen kan uitzetten, het liefst zonder update aan de kant van de ontwikkelaar; AccuBattery heeft die statistieken echt nodig om nuttige informatie te kunnen verstrekken. Diverse time-tracking apps en alternatieven voor Google's Digitaal Welzijn ook. Het zou niet de eerste keer zijn dat API's als deze verdwijnen achter de handtekeningen van de fabrikant en/of Google waardoor het niet meer mogelijk is te concurreren met de grote spelers.

[kodak]

Al in de vorige eeuw was duidelijk dat je bij meerdere gebruikers (of dat nu mensen of criminelen zijn) maar beter kan werken met rechten en minst noodzakelijke rechten. Zelfs de meest gebruikte besturingssystemen hadden dit 15 jaar geleden al.
De we waar je het over hebt lijkt vooral Android/Google te zijn die perse een eigen interpretatie toepaste zonder daar heel duidelijk over te zijn naar de gebruikers. Gebruikers hebben voor zover ik weet nooit massaal gevraagd om weinig rechten of veel rechten voor Google en app ontwikkelaars. Er lijkt ze zelfs nooit gevraagd wat voor controle ze over hun en andermans persoonsgegevens willen of uitgelegd wat ze werkelijk maar beperkt aan controle hadden.

[bigbadbull]

Eindelijk. Altijd zot gevonden dat praktisch iedere app kan zien welke bank of investerings app ik gebruik.
....
Inderdaad, het is krankzinnig dat dit überhaupt kon. Ik zou dat beschouwen als een major privacy lek eigenlijk.

hoe wil je dat een site/app dan anders je bank app voor jou opent als je een betaling wil uitvoeren ?
Als die geen lijst mag geven met apps zodat je je banking app kan openen .

[Splorky]

Dat is natuurlijk om een verbeterde gebruikers ervaring te kunnen creëren.

Wacht nog steeds op een standaard firewall in Android om dat soort informatie binnen te kunnen houden zonder persé root te hoeven hebben

[Koen Hendriks]

Wordt nu ook veel gebruikt voor root detectie ( 1 van de manieren). Kijken of Magisk Manager of SuperUser is geinstalleerd

[GertMenkel]

Dat zal waarschijnlijk zo blijven, volgens Google's uitleg:

Apps that have a verifiable core purpose involving financial transaction functionality (e.g. dedicated banking, dedicated digital wallet) may obtain broad visibility into installed apps solely for security based purposes.

[Koen Hendriks]

Nou dan moeten we toch de hide functie actief blijven gebruiken van Magisk

[MoonRaven]

Oké, dat kan een probleem worden voor apps die een license key app gebruiken lijkt mij. Ik heb nog redelijk wat apps die dat gebruikten omdat in-app purchases toen nog niet bestonden. Ook nieuwere apps doen dat, al weet ik niet precies waarom.

Zo heb ik Podcast Addict toen ook gekocht, ik heb er geen probleem mee om een app nogmaals te ondersteunen na zo'n lange tijd, ik vraag mij alleen af wat de impact gaat zijn.

[michaelkamen]

Hoe wordt het in dit scenario precies een probleem? Het is nog altijd mogelijk om te checken of specifieke apps geïnstalleerd zijn (op naam). Is dat niet voldoende?

[MoonRaven]

Ah oke, dat was mij niet duidelijk of er een mogelijkheid was om 1 app op te zoeken.

[michaelkamen]

Ja, dat kan nog. Maar er zitten wel wat haken en ogen aan. Als je app info opvraagt via de PackageManager API worden de resultaten vanaf API 30 wel standaard gefilterd. Als de opgevraagde app daar niet in staat krijg je dus de melding dat hij niet is geïnstalleerd.
Het is ook mogelijk om specifieke apps op te nemen in je manifest om daarmee contact te maken.
Maar dat moet dus hardcoded gebeuren, tijdens ontwikkeling.
Sommige apps zijn wel altijd zichtbaar en opvraagbaar:

The following types of apps are always visible to your app, even when your app targets Android 11 (API level 30) or higher:

Your own app.
Certain system packages, such as the media provider, that implement core Android functionality.
The app that installed your app.
Any app that launches an activity in your app using the startActivityForResult() method, as described in the guide about how to get a result from an activity.
Any app that starts or binds to a service in your app.
Any app that accesses a content provider in your app.
Any app that has a content provider, where your app has been granted URI permissions to access that content provider.
Any app that receives input from your app. This case applies only when your app provides input as an input method editor.
In addition, you can start another app's activity using either an implicit or explicit intent, regardless of whether that other app is visible to your app.

[keranoz]

Mooi dit!

Ook voor de root community. Voorbeeld: de mcdonalds doet het om de 1 of andere reden niet als root gedeteceerd is. Er zit zelfs een check in om te kijken of je Magisk Manager geïnstalleerd hebt. Je moet dus Magisk Manager hiden anders doet McDonalds het niet.

Dit scheelt een stuk werk.

[WhatsappHack]

Ik gok dat die een of andere reden is, dat er een app is die klooit met de coupons.

[IThom]

De titel gaf mij het idee dat er apps geïnstalleerd worden door andere apps, en dat de gebruiker dat straks niet kan in zien.

Misschien zoiets: Nieuwe restricties Android voorkomen dat apps alle geinstalleerde apps kunnen zien ?
Of: Android limiteert apps lijst alle geinstalleerde apps te kunnen uitlezen ?

[Reactie gewijzigd door IThom op 30 juli 2024 21:59]

[Captain_Code]

Ik had hetzelfde, heel verwarrend maar gelukkig lijkt dit beter nieuws

[RoestVrijStaal]

Het lijkt erop dat de permissie "QUERY_ALL_PACKAGES" dan enkel gegeven kan worden voor systeem tool apps die geïnstalleerd zijn via Google Play, en niet via F-Droid of gesideloaded zijn.

De gelinkte pagina van Google in het artikel geeft daar geen duidelijkheid over, maar zegt expliciet "Google Play" en "Google Play". Het zal een slechte zaak zijn als het waar is.

[Maduropa]

Ik was eigenlijk benieuwd sinds wanneer dit mogelijk was en waarom ze er nu pas op reageerden. Schijnt pas mogelijk te zijn sinds Android 11 (R). Dus op oudere versies bestaat dit niet.
https://stackoverflow.com...ll-packages-permission-do
en dan https://developer.android.com/training/package-visibility

Begrijp hier er verder uit dat het query_all eigenlijk bedoeld is als normale queries niet werken. Dus dan kan een app nog altijd een reeks queries loslaten om bijvoorbeeld te kijken of bepaalde andere apps wel of niet geinstalleerd staan.
Maar ze hebben het dus gecreeerd, zagen dat het niet veilig was en daarom beperken ze het nu meteen weer.