💻 computer science

Is Your Private Information Logged? An Empirical Study on Android App Logs

Deze empirische studie analyseert de prevalentie en oorzaken van privacylekken in Android-applicatielogs, waarbij wordt vastgesteld dat de meeste lekken voortkomen uit onwetendheid van ontwikkelaars, en biedt vervolgens richtlijnen om deze risico's te mitigeren.

Oorspronkelijke auteurs: Zhiyuan Chen, Soham Sanjay Deo, Poorna Chander Reddy Puttaparthi, Vanessa Nava-Camal, Yiming Tang, Xueling Zhang, Weiyi Shang

Gepubliceerd 2026-02-18

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zhiyuan Chen, Soham Sanjay Deo, Poorna Chander Reddy Puttaparthi, Vanessa Nava-Camal, Yiming Tang, Xueling Zhang, Weiyi Shang

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Titel: De Digitale Dagboeken van Je Telefoon: Waarom Je Gegevens (Onbedoeld) Lekken

Stel je voor dat elke app op je Android-telefoon een dagboekschrijver is. Deze schrijvers (de ontwikkelaars) schrijven continu notities op om te zien of hun app goed werkt. Ze noemen dit "logs". Het is alsof ze een zwartboek bijhouden waarin ze elke stap, elke klik en elke fout die de app maakt, opschrijven. Dit helpt hen om problemen op te lossen, net zoals een monteur die een auto repareert en noteert wat er misging.

Het probleem? Soms schrijven deze schrijvers per ongeluk gevoelige informatie in hun dagboek. Denk aan je naam, e-mailadres, telefoonnummer of zelfs je wachtwoord. En het ergste is: dit dagboek is vaak niet goed afgesloten. Iedereen die erbij kan, kan het lezen.

De onderzoekers van dit papier (Zhiyuan Chen en zijn team) hebben een groot onderzoek gedaan om te zien hoe vaak dit gebeurt en waarom. Hier is wat ze hebben ontdekt, vertaald naar begrijpelijke taal:

1. Wat vinden ontwikkelaars zelf? (De "Wat is er mis?" fase)

De onderzoekers keken naar vragen die ontwikkelaars online stellen aan elkaar. Ze ontdekten vijf soorten zorgen:

De "Veilige Schrijver": De meeste ontwikkelaars willen hun dagboeken veilig houden. Ze vragen: "Hoe kan ik mijn dagboek zo schrijven dat ik geen wachtwoorden of namen vermeld?"
De "Detective": Sommigen gebruiken de dagboeken juist om privacyproblemen op te lossen. Ze kijken in het dagboek om te zien waar een fout zit.
De "Bezorgde Burger": Sommigen zijn bang dat hun dagboek te veel lekt en vragen om hulp.
De "Boze Vrijheidsstrijder" (Zeldzaam): Een klein groepje wil juist geen privacy beschermen. Ze willen bijvoorbeeld een app maken die de bel- en sms-lijsten van anderen leest. Dit is natuurlijk gevaarlijk.
De "Bewaker": Sommigen denken dat als ze het dagboek maar goed opslaan (bijvoorbeeld in een gesloten kast), het veilig is.

De les: De meeste ontwikkelaars willen goed doen, maar weten niet altijd hoe.

2. Wat vonden ze in de dagboeken? (De "Bewijslast")

De onderzoekers hebben 83 populaire Android-apps (zoals Amazon, Tinder, en spelletjes) op hun telefoon geïnstalleerd en laten draaien. Ze hebben vervolgens de dagboeken (logs) van deze apps onder de loep genomen.

Het resultaat was schokkend:

Het is overal: Ze vonden 610 tot 651 plekken waar privé-informatie in de dagboeken stond.
Het is niet alleen de app: Soms is het de app zelf die fouten maakt, maar vaak is het een hulpje (een bibliotheek van derden) dat de app gebruikt. Denk aan een app die een reclamebureau gebruikt om advertenties te tonen. Die reclamebureaus schrijven soms ook hun eigen dagboeken, en daar staan jouw gegevens in.
De "Grote Lekken": De meest gevonden informatie was het merk van je telefoon (bijv. "Motorola" of "Samsung"). Dat klinkt niet erg, maar hackers kunnen hiermee je prijs op websites aanpassen of je volgen. Maar ze vonden ook echte privé-gegevens: e-mailadressen, namen en unieke telefoon-ID's.
De "Nieuwe Trend": In de nieuwste versies van apps was er minder van je telefoon-ID te vinden (goed nieuws!), maar er stonden plotseling veel meer namen in de dagboeken (slecht nieuws!).

3. Waarom gebeurt dit? (De "Oorzaken")

Waarom schrijven ontwikkelaars dit op?

De "Te Luide Schreeuw": Veel van deze dagboeken staan op een instelling die zegt: "Schrijf dit altijd op, zelfs als het niet nodig is." Alsof iemand in een drukke kamer blijft schreeuwen over zijn wachtwoord, terwijl hij alleen fluisterend had moeten praten.
De "Vage Schets": Vaak schrijven ontwikkelaars niet één woord op, maar een heel complex pakketje (zoals een JSON-structuur). Stel je voor dat je een envelop opent met daarin een brief, een foto en een bankafschrift, en je schrijft gewoon "Hier is de envelop" in je dagboek. Je vergeet dat er een bankafschrift in zit. Ontwikkelaars zien vaak niet dat er gevoelige data in die complexe pakketjes zit.
De "Foutmelding": Als iets misgaat (bijvoorbeeld een inlogfout), schrijft de app soms de hele foutmelding op, inclusief je e-mailadres. De ontwikkelaar dacht: "Ik moet weten waarom het misging," maar vergeten dat je e-mailadres nu in het dagboek staat.
Onwetendheid: De grootste oorzaak is simpelweg: Ze weten het niet. Ze denken dat het veilig is, of ze zijn te druk met het maken van de app om na te denken over privacy.

Wat betekent dit voor jou?

Stel je voor dat je telefoon een glazen huis is. De ontwikkelaars bouwen het huis, maar soms laten ze de ramen open staan en hangen ze je paspoort en bankpas op de vensterbank.

De belangrijkste lessen uit dit onderzoek:

Geen "Wazige" Codes: Het is niet genoeg om je wachtwoord te versleutelen met een simpele code (zoals MD5 of SHA-1). Dat is alsof je je sleutel in een doorzichtig plastic hoesje stopt; hackers kunnen het nog steeds zien.
Kijk naar de "Hulpjes": Als je een app gebruikt, is het niet alleen de maker die je gegevens ziet, maar ook de reclamebureaus en tools die de app gebruikt.
Ontwikkelaars moeten wakker worden: Ze moeten leren om niet zomaar alles op te schrijven. Ze moeten "veilig schrijven" als een normaal onderdeel van hun werk, net als het sluiten van de voordeur.

Conclusie:
De onderzoekers zeggen: "Het is niet dat ontwikkelaars kwaadwillig zijn; ze zijn vaak gewoon onwetend." Ze hebben een lijstje gemaakt met tips om dit te voorkomen. Als ontwikkelaars hier beter op letten, wordt je digitale dagboek weer een veilig dagboek, in plaats van een open boek voor iedereen.

Kortom: Je telefoon houdt een dagboek bij, en tot nu toe schreef de schrijver er vaak te veel in. Het is tijd om die schrijver een lesje te geven in privacy.

Probleemstelling

Met de snelle groei van mobiele apps is de privacy van gebruikers een steeds dringender issue geworden. Hoewel er veel onderzoek is gedaan naar privacylekken in Android-apps via netwerkanalyse en statische/dynamische code-analyse, is er weinig aandacht voor software logs.

Context: Android-apps genereren uitgebreide logs voor debugging en monitoring. Deze logs bevatten vaak runtime-informatie die per ongeluk of onbewust gevoelige gebruikersgegevens (PII - Personally Identifiable Information) kan bevatten.
Risico: Omdat Android-apps vaak verbinding maken met externe servers en logs niet altijd strikt worden beschermd of vernietigd na uitvoering, kunnen deze logs leiden tot langdurige privacylekken. Officiële Android-documentatie waarschuwt ontwikkelaars expliciet om geen PII (zoals e-mails, telefoonnummers, namen) in logs te plaatsen, maar de naleving hiervan is onbekend.
Gat in onderzoek: Bestaand onderzoek mist een empirische studie die specifiek kijkt naar de aard, oorsprong en kenmerken van privacylekken binnen Android-app logs, evenals de perceptie van ontwikkelaars hierover.

Methodologie

De auteurs hebben een empirische studie uitgevoerd met drie onderzoeksvragen (RQ's) en een gestructureerde aanpak:

Dataverzameling (Dataset Constructie):
- Apps: Er zijn 83 populaire Android-apps geselecteerd via PlayDrone (metadata van de Google Play Store).
- Generatie: Logs zijn gegenereerd door UI-tests uit te voeren met de tool Monkey (een onderdeel van het Android SDK) op een testapparaat met een gedefinieerd gebruikersprofiel (inclusief device ID, e-mail, naam, etc.).
- Versies: Er zijn twee datasets verzameld: een "oude" dataset (bestaande APK's) en een "nieuwe" dataset (de nieuwste versies van dezelfde apps).
- Resultaat: In totaal 83 apps (78 met succesvolle logs in de nieuwe dataset), resulterend in bijna 9 miljoen logregels.
Onderzoeksvraag 1 (RQ1): Ontwikkelaarsperceptie:
- Analyse van Q&A-forums (Stack Exchange/Stack Overflow) om te begrijpen welke zorgen ontwikkelaars hebben over privacy in logs.
- Methode: Zoeken met trefwoorden zoals "log" en "privacy", gevolgd door handmatige classificatie door twee onderzoekers.
Onderzoeksvraag 2 (RQ2): Detectie van Privacylekken:
- Detectie: Zoeken in de gegenereerde logs naar specifieke trefwoorden die corresponderen met het testprofiel (e-mail, naam, IMEI, Android ID, serial number, fabrikant) en zwakke hash-waarden (MD5, SHA-1).
- Bronanalyse: Identificeren of de logs afkomstig zijn van de app zelf of van third-party libraries (via log tags).
- Noot: De detectie is 100% accuraat omdat de auteurs precies weten welke data ze hebben ingevoerd en zoeken.
Onderzoeksvraag 3 (RQ3): Kenmerken van Lekken:
- Logging Level: Analyse van de ernst van de log (ERROR, WARN, INFO, DEBUG, VERBOSE). Logs met niveau $\ge$ INFO worden tijdens runtime altijd afgedrukt.
- Locatie/Structuur: Handmatige classificatie van waar de privacy-informatie staat (bijv. in JSON, URLs, enkele tokens, arrays, of hybride structuren).

Belangrijkste Bijdragen

Dataset: Constructie van een uniek, open-source dataset van Android-app logs (83 apps), wat een gat vult in de beschikbare open-source bronnen.
Empirisch Bewijs: Eerste studie die privacylekken in Android logs kwantificeert en analyseert vanuit een "logging research" perspectief, in plaats van alleen netwerk- of code-analyse.
Ontwikkelaarsinzicht: Koppeling tussen de zorgen van ontwikkelaars op forums en de daadwerkelijke lekken in de code.
Open Science: Publicatie van code en data voor de gemeenschap.

Resultaten

1. Ontwikkelaarszorgen (RQ1):
Uit 59 relevante forumposts werden vijf categorieën afgeleid:

Vervanging van gevoelige data (35,6%).
Gebruik van logs om privacyproblemen op te lossen (27,1%).
Zorgen over potentiële lekken en hulpvragen (27,1%).
Ontwikkelaars die privacy niet willen beschermen (6,8%): Dit is een verrassende bevinding waarbij ontwikkelaars actief zoeken naar manieren om gevoelige data uit logs te halen of te printen.
Opslag en toegangsbeheer (3,4%).

2. Voorkomen van Privacylekken (RQ2):

Frequentie: Privacylekken zijn wijdverbreid. In de oude dataset werden 610 lekken gevonden in 83 apps; in de nieuwe dataset 651 lekken in 78 apps.
Bron: De meeste lekken (95,9%) komen uit interne app-aanroepen, maar 4,1% (25 gevallen) komt uit third-party libraries (zoals Localytics, Unity Ads, MoPub). Dit betekent dat gebruikersdata soms naar externe partijen wordt gestuurd via logs.
Type Data:
- Fabrikant (Manufacturer): Meest voorkomend (54% in oude dataset), vaak over het hoofd gezien maar toch gevoelig.
- Android ID: Komt veel voor in oude versies, maar is verdwenen in nieuwe versies (ontwikkelaars zijn hier voorzichtig mee geworden).
- Gebruikersnaam: Een toename van lekken (van 3 naar 82 gevallen) in de nieuwe dataset, wat een toenemend risico aangeeft.
- E-mail: Nog steeds aanwezig, maar afgenomen.

3. Kenmerken van de Lekken (RQ3):

Logging Level: Een groot deel van de lekken (59,67% in oude dataset) zit in logs met niveau INFO of hoger. Dit betekent dat deze gegevens altijd tijdens runtime worden afgedrukt en niet kunnen worden uitgeschakeld zonder de functionaliteit van de app te beïnvloeden.
Data Structuur:
- Complexe structuren: De meeste lekken zitten in complexe datastructuren zoals JSON (28,20%) en URLs. Ontwikkelaars zijn zich vaak niet bewust van de inhoud van deze structuren wanneer ze variabelen loggen.
- Enkele tokens: Lekken in simpele tekst (19,84%) komen vaak voor door het gebruik van log-templates die per ongeluk gevoelige parameters meenemen.
- Hybride structuren: In de nieuwe dataset is een sterke toename van hybride structuren (50,54%) te zien.
Oorzaak: De meeste lekken zijn onbedoeld. Ontwikkelaars zijn zich vaak niet bewust dat ze gevoelige data loggen, vooral bij het gebruik van complexe templates of het loggen van foutberichten (error messages) die authenticatie-informatie bevatten.

Betekenis en Conclusie

De studie concludeert dat privacylekken in Android-app logs een ernstig en onderbelicht probleem zijn.

Onbewustheid: De belangrijkste oorzaak is dat ontwikkelaars zich niet bewust zijn van wat er precies in hun logs terechtkomt, vooral bij complexe datastructuren zoals JSON.
Naleving: Ondanks officiële richtlijnen van Google, volgen ontwikkelaars deze niet strikt.
Aanbevelingen:
1. Ontwikkelaars moeten gevoelige data actief filteren of vervangen voordat ze worden gelogd.
2. Wees voorzichtig met het loggen van complexe objecten (JSON, arrays) en gebruik geen zwakke hashes (MD5/SHA-1) als bescherming.
3. Controleer third-party libraries zorgvuldig, aangezien deze ook data kunnen lekken.
4. Er is behoefte aan betere tools voor het detecteren van privacylekken in complexe datastructuren binnen logs.

De auteurs plannen toekomstig onderzoek naar de "privacy paradox" bij ontwikkelaars (waarbij hun gedrag niet overeenkomt met hun beweringen) en willen de studie uitbreiden naar malware.