Android 13 verhelpt 'loophole' waar veel bestandmanagers op berusten

Bestandsmanagers die gebruikmaken van een loophole om toegang tot eigenlijk afgeschermde bestanden te verkrijgen moeten vanaf Android 13 een andere manier bedenken om dit te doen.

Praktisch alle applicaties die geheel toegang hebben tot de opslagruimte van een Android-toestel, kunnen vanwege een restrictie toch niet bij de map /Android en de daaronder vallende mappen /Android/obb en Android/data. Deze maatregel werd met Android 11 ingevoerd en weerhoudt applicaties ervan om toegang te krijgen tot informatie die opgeslagen is door andere apps.

Er is daarentegen een veelgebruikte loophole in Googles besturingssysteem in omloop waardoor gebruikers toch bij mappen onder /Android konden komen, zo legt Esper uit. De loophole maakt gebruik van het Storage Access Framework, waarvoor Google expliciet toegang tot de /Android-hoofdmap ontzegde. Maar toegangsverzoeken voor subdirectories als /Android/obb en Android/data werden niet geblokkeerd. Kortom, vooralsnog kunnen bestandsmanagers geen toegang krijgen tot /Android als geheel, maar wel tot specifieke mappen binnen dit afgeschermde stuk van Androids opslagruimte.

Met Android 13 voegt Google een nieuwe limitatie toe aan het SAF; wanneer het framework een map probeert te openen controleert Android of het om een bestandslocatie gaat die eigenlijk afgeschermd zou moeten worden. Zo ja, dan kan de betreffende bestandsmanager geen toegang tot de map krijgen, waardoor de opslaglocaties van uiteenlopende apps voortaan beter afgeschermd worden.

Er blijven overigens nog wel manieren om deze afgeschermde bestandslocaties te vinden. Googles maatregelen treffen vooral derden, terwijl bijvoorbeeld de AOSP Files-app nog steeds bij /Android en daaronder geplaatste mappen kan komen. Ook via de pc moet het volgens Esper geen probleem zijn om anderszins afgeschermde mappen te openen.

Reacties (122)

[RoestVrijStaal]

Maar waarom, Google? Waarom moet dit? Waarom wil je Android-gebruikers zo graag pesten?

Laat mij nou gewoon met een bestandmanager naar keuze mijn bestanden op mijn smartphone beheren.

Maak nou eens een fatsoenlijke API als alternatief van die loophole. En nee, Google Drive en andere Cloud-services zijn dat niet.

[GertMenkel]

Zodat je zaklamp-app niet met een reeks popups gebruikers kan misleiden om toegang te geven tot de WhatsApp backupmap, bijvoorbeeld. Mensen klikken veel te vaak domweg op OK bij vreemde popups en ook die mensen moeten hun telefoon veilig kunnen gebruiken.

Het hele idee van de Android-map is dat de data daarin alleen beschikbaar is voor de applicatie zelf, zodat ontwikkelaars externe opslag veilig kunnen gebruiken. Dat is cruciaal als je bijvoorbeeld een SD-kaartje in je telefoon stopt.

Wil je die bestanden alsnog inzien, dan kan dat altijd nog met de ingebouwde bestandsverkenner en door je apparaat aan een PC te hangen. Als je je telefoon root (wat sowieso nodig is wil je bij je eigen data komen) kom je ook om deze beperking heen. Ik weet zeker dat een Magisk/Zygisk module deze beperkingen kan uitzetten als je dat zou willen. Waar een wil is, is een weg.

[fapkonijntje]

Precies dit dus. Je ziet hele volksstammen een beetje zielig doen over een beveiligingsmaatregel als dit, zonder dat ze even drie seconden nadenken over het waarom. Klagen is tenslotte veel makkelijker dan even nadenken of navragen.

Men vergeet te snel dat 99,98% van de gebruikers van Android gewoon normale mensen zijn zonder enig verstand van zaken en voor hun is dit een risico, geen gunst. Moeten we dan voor die 0,02% ineens allemaal potentiële risico's voor de 99,98% in leven houden? Hoe egocentrisch kun je zijn hè.

Ik ben technisch genoeg en zodoende kom ik wel bij de Android folder, ook in 13. Dat het wat lastiger is, ach, het is voor een goed doel, want op deze manier is de overgrote meerderheid beter beschermd met als enige prijs een marginaal mindere ervaring voor mij.

Ik vind de houding van mensen die dit soort 'fixes' zo blind afbranden toch wel behoorlijk lomp. Alsof ze de enige gebruiker van Android zijn.

[GertMenkel]

Sommige beveiligingsmaatregelen zijn wel bijzonder irritant. Het verwijderen van klembordtoegang op de achtergrond zonder mogelijkheid om dat weer werkend te maken voor power users heeft mij tot het rooten van mijn telefoon gepusht om KDE Connect weer werkend te krijgen.

Maar inderdaad, de meeste veranderingen waar men zo bang voor is, is goed. Kijk naar het gedoe rond de SD-kaart bij Android 4.4, waar Google hard pushte om gedeelde opslag flink te minderen. De pushback die daarop volgde maakt tot de dag van vandaag dingen als tracking en zelfs het achterhalen van locatiegeschiedenis via GPS tags in foto's mogelijk. Als ik mijn interne opslag open lijken er iedere update nieuwe tracking identifiers op de opslag te verschijnen en ik kan niet wachten tot ik eindelijk apps kan dwingen binnen hun eigen map te blijven als ik niet wil dat ze overal spul dumpen.

[wankel]

(...) om KDE Connect weer werkend te krijgen.

Off-topic, maar vanaf welke Android versie speelt dat?

[GertMenkel]

Android 10. Deze module lost dat probleem voor mij op.

[Bert1993]

Heel erg bedankt, ik lees zo even mee en heb dit probleem ook, hoop het hier mee op te lossen!

[wankel]

Bedankt, snel gebookmarked!

[Recklezz]

Ik ben het in grote lijnen eens, maar volgens deze redenatie hadden ze best een switch in de developer settings kunnen zetten die de toegang weer openzet.

[sympa]

Dit is toch geen relevante optie voor developer settings? Dan liever een aparte permissie voor file managers.
Waarbij die file managers op een bepaalde manier ook weer beperkt moeten worden in hun gedrag. Misschien net zoals bij accessibility.

[dimdek]

Ik blijf het altijd grappig vinden dat we accepteren dat ontwikkelaars van apps niet vertrouwd mogen worden terwijl de 'gebruikers zonder enig verstand van zaken' hun hele hebben en houwen delen met Google zonder enige beperking. Daar bestaat zelfs geen andere knop voor dan de uit knop op je toestel.

[fapkonijntje]

Datzelfde gaat natuurlijk ook op voor Apple. Bij Google heb je wel meer mogelijkheden om het datadelen te beperken.

[dimdek]

Je hebt helemaal gelijk. Zowel Apple als Google gebruiken hun marketing en OS functies om ons te vertellen dat andere partijen onveilig zijn. Ondertussen gaan ze zelf lekker hun gang om zoveel mogelijk van onze data te vergaren zonder dat de overgrote meerderheid van de gebruikers dit doorheeft.

[Tozz]

Maar nu krijg je het tegenovergestelde. Ik heb een Fitness-App die continue een verbinding wil houden met 't fitness bandje. Werkt niet. Verliest verbinding, kan geen GPS fix krijgen, etc, etc. Waardoor komt dat? Door permissie restricties door "batterijmanagers", etc, etc.

Wat is mijn oplossing? Als het niet werkt geef ik die App toegang tot alles, geef ik 'm uitzonderingen op alle batterijmanagement oplossingen, etc.

Security is goed, maar het moet niet te vervelend worden. Dan krijg je hetzelfde als de cookie banners. Die zijn ook dusdanig vervelend dat iedereen maar gewoon op OK klikt

[Mellow Jack]

Je kan ook geiriteerd zijn tov de fabrikant van je dingetje. Nextcloud, als voorbeeld, geeft bij het aanzetten van het syncen van bijv je foto's een popup met de vraag of je de battery settings voor die specifieke app wilt aanpassen. Ik ken het hele fitnessapp niet maar o.b.v. van jou verhaal krijg ik het gevoel alsof ze die app al veel langer niet meer onderhouden

[Tozz]

Deze App geeft dat ook aan, incl. instructies per merk. Maar op mijn Samsung is het toch weer anders dan de instructies. En dat begrijp ik wel, want het wisselt ook wel ongeveer elke Android release waar 't precies zit.

Het maakt ook niet uit verder. Mijn punt is dat teveel restricties zorgt voor klakkeloos openzetten van permissies. Het maakt dan niet zoveel uit of het goed is uitgelegd, ik wil dat als ik een App installeer dat 't gewoon werkt zoals het behoort te werken. Ik wil niet nog allerlei permissies en uitzonderingen moeten toevoegen in de krochten van een settings menu om een eenvoudig bluetooth fitness trackertje te laten functioneren.

[GertMenkel]

Juist omdat iedereen zomaar op OK klikt worden er beperkingen opgegooid als deze. Een popup die je geen OK kan geven, kun je ook niet per ongeluk accepteren.

Samsung's app killer is specifiek voor Samsung-toestellen. De agressieve manier waarop die daarmee omgaat is mij ook een doorn in het oog. Je mag al deze stappen door en nog worden er apps op de achtergrond afgesloten. Daar heeft Google natuurlijk niet zoveel over te zeggen. Overigens doen sommige apps het beter dan andere in dit opzicht, over het algemeen worden beter geschreven apps doe minder energie gebruiken minder snel afgesloten, en fitnessapps lijken in mijn ervaring niet bepaald efficiëntie als doel te hebben.

Extra permissies geven lost je app-en OS-probleem niet op. Je zult hooguit de locatiepermissie op "altijd" moeten zetten voor Bluetooth-toegang (omdat de app je kan volgen met Bluetooth beacons als je altijd Bluetooth-toegang geeft), de rest is telefoonspecifiek en toegang tot je adresboek gaat daar echt niet bij helpen. Apps die permissies nodig hebben om goed te werken, moeten daar zelf de nodige informatie over beschikbaar stellen in de app en erom vragen, zelf willekeurige permissies aanzetten heeft weinig nut.

[fastedje]

Als ik een bedtandsmanager app (bijvoorbeeld Total Commander) zelf de toegang geef, waarbij duidelijk is vermeld dat de app toegang tot alle bedtanden van alle apps krijgt, dan zie ik geen probleem qua security.

[GertMenkel]

Mensen begrijpen niet helemaal wat "alle bestanden" betekent. Ze willen wel dat ze bijlages kunnen toevoegen voor de email maar niet dat een app op de achtergrond alle foto's naar de cloud stuurt. Foto-apps mogen alle foto's bewerken en verwerken maar men verwacht niet dat dat ding door je WhatsApp-backups gaat pluizen. Het permissiemodel van mobiele telefoons laat mensen denken dat ze beschermd worden, maar de "toegang tot je bestanden en media" popup neemt veel meer bescherming weg dan mensen zich realiseren.

Er zijn onderhand diverse televisieprogramma's geweest waar men een paar euro werd betaald (of zelfs helemaal niks) om een apk te "testen" die ze vervolgens vergaten te verwijderen achteraf en als proof of concept allerlei nare dingen deed.

Duidelijk voor power users is iets anders dan duidelijk voor het gros van de mensen. Google moet vooral de onwetende mensen bedienen hier. Wellicht komt er, net als bij de vorige permissieverwijdering, een menu dat je zelf moet aanklikken (en dat apps niet naar de voorgrond kunnen forceren) om de nodige permissies te geven, maar realistisch gezien gaat dat waarschijnlijk niet gebeuren. Persoonlijk vind ik dat voor power users deze mogelijkheden moeten blijven bestaan, maar dat ze dit soort bugs oplossen is meer dan normaal. Ik had zelf eigenlijk verwacht dat dit een bug is die met een beveiligingsupdate van bestaande Android-versies zou worden opgelost, want het is duidelijk ongewenst gedrag vanuit het perspectief van de API.

De reden dat Google zulke beperkingen opgooit is omdat ze al lange tijd willen dat ontwikkelaars stoppen de gedeelde bestandsruimte te gebruiken voor het uitwisselen van bestanden. Storage providers in combinatie met een file picker werken uitstekend voor het pakken van bestanden uit een bepaalde app of service, alles op de interne opslag dumpen is te simpel en heeft te weinig manieren om permissies te regelen.

[CivLord]

Maar leuk wanneer WhatsApp alle foto's in de Android map plaatst en ik deze naar een locatie op mijn SD-kaart wil verplaatsen.
Nu staan die foto's wel onder de map \Android\Media en niet onder één van de twee in het artikel genoemde mappen, dus ik hoop dat mijn foto's gewoon met Total Commander beschikbaar en verplaatsbaar blijven.

[Patriot]

Zodat je zaklamp-app niet met een reeks popups gebruikers kan misleiden om toegang te geven tot de WhatsApp backupmap, bijvoorbeeld. Mensen klikken veel te vaak domweg op OK bij vreemde popups en ook die mensen moeten hun telefoon veilig kunnen gebruiken.

Maar het is geen redelijke, proportionele, oplossing voor het probleem. Het probleem van gebruikers die niet weten wat ze doen die heel makkelijk aan dit soort kwaadwillende apps kunnen komen kun je op andere en betere manieren oplossen.

[RoestVrijStaal]

Al werp je duizend technische muren op. De gebruiker is en blijft de zwakste schakel. Waarom laat Google de beslissing voor deze technische muur niet over aan fabrikanten?

En nee, rooten is tegenwoordig geen praktische optie meer sinds apps checken of je telefoon geroot is of niet. En MagiskHide is niet meer.

[GertMenkel]

Fabrikanten passen Android aan op verschillende manieren, er is weinig dat ze tegenhoudt om de patch uit te commenten als ze het ermee oneens zijn. Google is natuurlijk zelf ook een fabrikant en zodra ze dit soort dingen alleen voor Pixels gaan inbouwen krijg je alleen maar meer gezeik.

Ik heb mijn telefoon geroot en mijn twee bankapps en al mijn media-apps doen het prima, al is Netflix wat zielig en moet ik die updaten via apkmirror (werkt wel gewoon, ook met HD). MagiskHide heeft bij mij eigenlijk nooit goed gewerkt, ik heb altijd al via externe modules dingen als SafetyNet-onzin moeten omzeilen en patchen, maar dat was na het rooten zelf vijf minuten werk. Het zal er aan liggen welke apps je gebruikt.

[Z80]

Dit is ook de schuld van google. Om de led als zaklamp te gebruiken moet je de api van de camera mis/gebruiken. Met de daarbij behorende rechten. Iets dat je eigenlijk niet wil.
Zo ook de wifi of bluetooth scanner. Die kan alleen werken als ook de gps aan staat. Waarom? Omdat google dit in hun api aan elkaar geknoopt heeft. Is het voor de veiligheid? Nee. Het is voor data verzamelen.

Dat er nu restricties op een filemanagers gezet gaan worden die de veiligheid niet verbeterd, eerder verslechterd, maar gebruikers gaat pesten. Dat zou onderzoek moeten worden van machtsmisbruik.
Moet ik eerst een android toestel rooten om bijvoorbeeld kaartmateriaal in een offline navigatie te kunnen zetten vanuit de download map.

[GertMenkel]

Nee. WiFi en Bluetooth kun je scannen zonder GPS. Je moet echter wel locatiepermissies hebben. Waarom? Omdat we geen leuke dingen kunnen hebben zonder dat datagraaiers proberen geld aan je te verdienen. De locatiepermissie die bij scannen hoort, heeft te maken met technieken als WiFi-beacons en geopositionering door middel van WiFi-(B)SSID's. Je moet daarvoor wel locatietoegang aan hebben staan, maar die kan ook op "energiebesparend" staan (of hoe ze het ook noemen tegenwoordig) waarbij GPS gewoon uit blijft.

Het zou kunnen dat het allemaal achter dezelfde toggle staat bij sommige fabrikanten, maar technisch gezien kan het op Android niveau compleet gesplitst.

[sprankel]

Bij gebruik van Bluetooth vraagt de telefoon niet of de app gebruik mag maken van GPS, het vraagt of de app je locatie mag bepalen.

De reden daarvoor is dat je met Bluetooth alleen ook locatie tracking kunt doen door bijvoorbeeld Enhancing Bluetooth Location Services. Of neem die airtags van Apple, het enigste wat die doen is een Bluetooth signaal uitzenden maar toch kan je die dingen tracken over heel de wereld.

Dus als jij een App Bluetooth permissies geeft kan die app perfect met enkel Bluetooth jou locatie achterhalen, dat is waarom je automatisch ook locatiepermissies moet geven zodat het duidelijk is voor iedereen dat de app je locatie kan achterhalen, iets wat nogal onduidelijk zou zijn als de app enkel om Bluetooth permissies vraagt.

Zelfde verhaal met Wifi.

[--Andre--]

En andersom natuurlijk. App will bluetooth aanzetten, ik moet permissie locatie geven.

Dit feit geeft al aan, dat wat de app wil doen, en de permissie die daarbij hoort, nogal van naam kunnen verschillen. Ja, je kan via bluetooth locatie bepalen, maar de app wil met een bluetooth apparaat verbinden, dus permissie locatie lijkt irrilevant voor de actie.

Om nu terug te komen op die zaklamp-app, als die om een niet relevant lijkende permissie vraagt, denk je, om bluetooth aan te zetten vraagt hij om locatie. Android vraagt nou eenmaal om rare dingen, het zal wel kloppen.

[Z80]

Maar ik wil helemaal niet dat de locatie bepaald wordt bij het zoeken naar een Bluetooth apparaat.
Waarom moet een toestel weten waar een smartwatch, sportband, sensoren op een fiets en dergelijke exact is op deze wereld?
Dat er tags Bluetooth gebruiken om zicht te melden is niet mijn probleem.

Zelfde als jij een wifi scan. Welke netwerken op welk kanaal zitten zodat mijn AP op een minst gebruikt kanaal kan zetten. Ook hier moet de locatie aan staan. Waarom? Waarom moet je hiervoor de locatie delen. Totaal nergens goed voor. En was bij de oude versies van Android ook niet nodig. Het lijkt heel erg op data graaien en SSID's op een map kunnen plotten door de OS maker.

[sprankel]

Stel ik breng een app uit waarbij ik in de achtergrond informatie heb wat de fysieke locatie van Wifi hotspots is via MAC adress, dan heb ik aan de informatie met welke hotspot jij verbonden bent genoeg om jou locatie te bepalen. Zelfs zonder verdere achtergrond informatie, met welke hotspot jij doorgaans in de nacht verbonden bent en welke overdag kan ik al bepalen of jij thuis bent of op school/werk of wanneer jij op vakantie bent.

Zelfde probleem met Bluetooth, het enigste wat ik moet doen is een Bluetooth signaal uitzenden dat gebruik maakt van het Airtag netwerk en ik pin je exacte locatie vast. https://github.com/seemoo-lab/openhaystack

Van het moment jij mijn app toegang geeft tot Bluetooth of Wifi kan ik je locatie beginnen bepalen zonder dat het OS dat kan blokkeren. En dat maakt het OS je vrij duidelijk door meteen ook locatiepermissies te vragen.

[Z80]

Het OS maakt dit totaal niet duidelijk.
WIFI kan zo aan. Een AP uit de lijst aanklikken en verbinden ook. Zelfde voor Bluetooth.
Maar zodra je een scan wil gaan doen moet je ineens je locatie delen. Iets dat enkel voor data graaien nodig is.
Mocht de locatie bepaling via een SSID plaatsvinden uit een app die dit niet mag, en hier geen rechten toe verkregen heeft met een toestemingsvraag. Dan hoop ik dat de store beheerder de app op de blacklist zet.

En een android telefoon zit niet in het Airtag netwerk. Gelukkig niet. Dus die ga je niet op locatie exacte locatie pinnen.
Om een Bluetooth device op een locatie te pinnen moet je het echte mac adres weten, en dit registreren\scannen. Want net als de andere OS bakker is het Bluetooth mac dat uitgezonden wordt random. Dit om tracking tegen te gaan.
Daarbij het device dat de Bluetooth ziet kan dan zijn eigen locatie doorgeven. En mogelijk de signaal sterkte.

PS
lees je eigen github link nog eens goed na. Want je bent dingen door elkaar aan het halen.
Namelijk dat je een eigen Bluetooth device dat aan de gestelde voorwaarden voldoet kunt toevoegen aan het Airtag netwerk buiten Apple om. Maar dan moet je wel volledig beheer hebben over dit device, en moet er voor geschikt zijn.
Wat jij uitzend aan netwerk maakt niet uit. Het gaat om ontvangst om locatie bepaling te doen.

[Ablaze]

Ik ben het wel eens met RoestVrijStaal.

De app folder heeft standaard al dusdanige permissies dat apps elkaars data niet zomaar kunnen lezen en de ingebouwde bestandsverkenner is zwaar ruk. Ik wil Total Commander of vergelijkbaar kunnen blijven gebruiken.

Dat sommige mensen nergens bij nadenken en malafide apps toegang geven tot hun hele bestandssysteem hoeft mijn eigen functionaliteit niet te limiteren. Ik koop een Android in plaats van een iPhone vanwege de veelzijdigheid, niet om mij te laten beperken.

[Flagg]

Waarom wil je een handjevol gebruikers "pesten", bedoel je?

Een klein gedeelte die daar überhaupt gebruik van maakt en een nog kleiner gedeelte die het weer zonodig moet zien als "pesten".

Die laatste groep is toch chronisch ontevreden over alles dus geen zin om rekening mee te houden.

[adje123]

Het is jouw smartphone, maar niet jouw software.

[THETCR]

De wijziging zit in AOSP en niet in proprietary software van Google.

Je bent dus ook vrij om een eigen build te maken zonder deze wijziging.

[Hayland]

Daar heb je in de praktijk niks aan, want 99.9% van de telefoons draaien een Google fork van AOSP.
Je hebt dan meestal geen drivers/firmware met AOSP, want die zijn meestal proprietair. Daarnaast moet de telefoon ook nog te flashen zijn, wat ook niet altijd kan (bootloader unlocken e.d.).

[THETCR]

een Google fork van AOSP

Het is geen fork, GMS (Google Media Services) zijn packages die los te installeren zijn.

Je hebt dan meestal geen drivers/firmware met AOSP, want die zijn meestal proprietair.

Alle drivers kan je gewoon krijgen. Het probleem is altijd geweest dat je voor sommige hardware BLOBS krijgt in plaats van source, maar voor het builden van AOSP is dat geen probleem.

Je argument over de bootloader is wel correct, helaas zijn er tegenwoordig fabrikanten die dit volledig dichthouden.

[Hayland]

Het is geen fork, GMS (Google Media Services) zijn packages die los te installeren zijn.

In bijna alle gevallen hebben de fabrikanten hun eigen repo met aanpassingen. Dat komt dus op een fork neer, gezien ze hun builds uit hun eigen repos bouwen.
(het kan ook een git submodule zijn, maar ook dat komt uiteindelijk op hetzelfde neer: je hebt geen toegang en kan niet makkelijk even een build maken)

Die fork kan enerzijds features hebben (die niet in AOSP zitten) tot fixes om bepaalde drivers goed werkend te krijgen op je apparaat.

Alle drivers kan je gewoon krijgen. Het probleem is altijd geweest dat je voor sommige hardware BLOBS krijgt in plaats van source, maar voor het builden van AOSP is dat geen probleem.

Binaire blobs zijn dan wel vaak beschikbaar, maar dat geeft ook heel vaak problemen. Kijk maar op het XDA Developer forum. Ik denk bijvoorbeeld aan WiFi of BlueTooth dat onbetrouwbaar is, of beperkingen op het gebruik van je camera (bvb slechts 1 van de 4 camera's beschikbaar op de nieuwere OnePlus devices sinds de 8T ofzo).

Binaire blobs leunen vaak op aanpassingen en/of services die alleen in de proprietaire ROM van de fabrikant zitten. Services zijn soms manueel in te bouwen, maar dan moet je dus een custom ROM bouwen, want die kan je als gebruiker niet altijd zomaar installeren. (die zitten op de systeempartitie/folders waar je niet zomaar bij kan)

Met veel hackwerk kan je dus iets redelijk werkend krijgen vanuit AOSP, maar in de praktijk is dat niet gewoon even een AOSP build starten.

Daarnaast is het niet legaal om die binaire blobs te delen met anderen.

Je bent dus ook vrij om een eigen build te maken zonder deze wijziging.

Mijn punt was vooral dat dit technisch correct was, maar praktisch niet uitvoerbaar. Zeker niet voor de gemiddelde gebruiker, en dat het daarnaast vaak een niet-stabiele en incomplete gebruikerservaring biedt (qua hardware-ondersteuning vooral).

[THETCR]

Er zit een cruciaal verschil tussen je beide statements:

In bijna alle gevallen hebben de fabrikanten hun eigen repo met aanpassingen.

want 99.9% van de telefoons draaien een Google fork van AOSP.

Wat betreft het gebruik van BLOBS, dat levert inderdaad regelmatig problemen op. Je krijgt vaak problemen met eventuele breaking changes. Shims zijn nou ook niet echt wenselijk.

Daarnaast is het niet legaal om die binaire blobs te delen met anderen.

Dat is zeer discutabel. Zo mogen partijen zoals LineageOS die prima delen.
Het probleem zit 'm meestal in dat je het niet voor commerciële doeleinden mag doen en in een selectief aantal gevallen niet in een publiekelijk toegankelijke repo mag plaatsen. Echter mag je voor die laatste groep het wel via adb van je eigen telefoon halen.

Binaire blobs

Volgens mij is de definitie van BLOB al dat het binair is.

Je hebt echter zeker gelijk dat het niet "even" is om een fatsoenlijke build te maken van AOSP, voornamelijk ook omdat de code op dit moment broken is.

Echter kan je natuurlijk altijd nog de wijziging toepassen op een code base van bijvoorbeeld LineageOS.

[Alex3]

Het zijn wel je eigen bestanden. Zo vind ik nog bestanden van apps die ik al lang verwijderd heb.

[blorf]

Individueel heb je daar niks mee te maken. Je mag met alle bestanden op je apparaat doen wat je wil. Het wordt een probleem als je een brouwsel gaat distribueren, al dan niet tegen betaling. Om even een illusie van tafel te vegen: software kan wel meer vertellen. De eigenaar van de hardware is de baas.

[sympa]

Het is ook jouw privacy. En als elke random app bij alle bestanden kan is dat niet goed.

[blorf]

Dat is om te voorkomen dat je lokaal je eigen software- en media-verzameling kan bijhouden.
Een smartphone mag geen PC zijn, want die kunnen teveel zonder dat er wat aan wordt verdiend.

[DataGhost]

Huh? Die verzamelingen kan je prima bijhouden. Dat kon, dat kan nu, en dat kan straks nog steeds. Bestandsmanagers blijven gewoon werken, ze kunnen alleen bepaalde mappen met systeembestanden of data van andere apps niet zomaar in.

[Martinspire]

Het gaat om andere data maar in principe heb je wel gelijk. Er zit geen winst in die toegang vrij geven.
Kanttekening, hij kan ook misbruikt worden zonder dat dat duidelijk is. En we weten allemal hoe debiel sommige gebruikers zijn...

[blorf]

De werkelijkheid is veel complexer maar dat valt gewoon niet simpel uit te leggen. Een rode vlag die van ver te zien is is feit dat er in wat door het OS wordt aangeboden als zijnde een directory of map geen hardware-executables kunnen bestaan.

[Omnicron1]

Helemaal mee eens !

[supersnathan94]

Om heel eerlijk te zijn was dat natuurlijk ook best wel een lek. Top level privileges niet honoreren is best wel een probleem.

Dat zou onder windows het equivalent zijn van “users/Supersnathan94” niet goedkeuren, maar “users/Supersnathan94/documents” wel.

[RoestVrijStaal]

Het gaat hier om het zelfde soort data dat in Windows in %APPDATA% gaat en bij Linux (doorgaans) in $XDG_CONFIG_HOME.

Gebruikersdata gegenereerd door applicaties. Vaak configuratiebestanden. Hoewel sommige applicaties voor wat voor reden dan ook een eigen (dot-hidden) mapje in %USERPROFILE% en $HOME zet.

Waarom zou je op Android die gebruikersdata niet mogen benaderen?

[DataGhost]

Die data mag je prima benaderen. Echter is Android opgezet alsof elke applicatie in een sandbox draait. Hoe de situatie nu op Windows en Linux (doorgaans) is, is dat applicaties slechts onder een bepaalde gebruikersaccount draaien, en inderdaad toegang hebben tot de volledige mappen %APPDATA% en aanverwanten. Daarom is het voor een of andere onschuldig uitziende, grappige app (weet ik veel, noem hem even BonziBuddy ofzo) triviaal om de data van de browser of e-mailclient te openen en daar alle opgeslagen gebruikersnamen, wachtwoorden en bijbehorende websites of servers uit te trekken en door te sturen naar de schrijver van die grappige app. Door alle apps in hun eigen sandbox te draaien (volgens mij redelijk zoals Qubes OS dat ook doet) zorg je ervoor dat de browser niet bij de data van de e-mailclient kan, maar die BonziBuddy ook niet! Alleen heeft dat dus als bijkomend nadeel dat een file manager, als die gewoon als app uitgevoerd wordt, deze zelfde restricties krijgt opgelegd. In principe is dit zeer wenselijk, het enige nadeel hieraan is dat je dus op de een of andere manier toestemming moet geven aan die app om toegang te krijgen tot data van andere apps. Dat kan dus bijvoorbeeld prima met een elevation prompt (*sudo / UAC) om tijdelijk de sandbox-restricties op te heffen, alleen is die prompt/mogelijkheid nou precies het deel wat in veel Android-situaties ontbreekt.

[svenk91]

Gebruikers moeten er wel bij kunnen, maar niet elke willekeurige app.

[SinergyX]

Als ik Supersnathan94 ben, dan hoor ik gewoon toegang te hebben tot al die mappen. Of dit nu een eigen usermap, systeemfolder of installatiefolder is, dat is juist het hele probleem met Android, je wordt steeds verder afgeschermt van je eigen OS.

[DataGhost]

Ik snap het sentiment op het moment dat je niet zomaar root kan worden op je eigen toestel, maar hier is root voor uitgevonden. Er zijn voldoende situaties te bedenken waarin je wel zelf toegang wilt hebben tot een map als jij dat echt wilt, maar jouw "account" (hier: app) niet standaard toegang wilt geven zonder bevestigingsvraag. Als we naar accounts kijken is het op *nix behoorlijk gangbaar om verschillende services onder verschillende accounts te draaien met elk hun eigen beperkte rechtenset. Zo kan een of ander programma bijvoorbeeld niet zomaar bij al jouw foto's, of wat user-level malware die je per ongeluk op je hoofdaccount binnenhaalt niet bij de account die je hebt ingericht voor bijvoorbeeld je eigen bedrijfje ofzo. Tegelijkertijd wil jij wel vanuit de ene in de andere kunnen komen en daar gebruik je dus roottoegang (of andere vorm van elevation) voor. Zo kan jij het alsnog maar een random app niet zomaar. Deze structuur vertaalt dus losjes naar apps omdat die allemaal zoveel mogelijk in hun eigen omgeving draaien. Dat is maar goed ook want het is niet fijn als elke app zomaar bij je Whatsapp-database of de data van een authenticator-app kan zonder dat jij daar toestemming voor hoeft te geven. Blijft dus inderdaad het usability-dingetje over dat die toestemming normaal op Android niet heel makkelijk te geven is, hoewel dat voor 99% van de gebruikers eigenlijk maar beter is.

[Vampyre]

maar hier is root voor uitgevonden

Nou... uitgevonden?
Volgens mij is Google (of in ieder geval de meeste vendors) juist niet zo heel blij dat de mogelijkheid rooten door sommige regeringen verplicht mogelijk moet zijn.

Unlocking en rooting (en jailbreaks) worden juist (ook nog is) bemoeilijkt. Dus niet uitgevonden hiervoor en al helemaal niet ondersteund.
Jouw telefoon wordt niet geheel als jouw bezit gezien door de makers. Geld nog meer voor de data er op.

Uiteraard dus een slechte zaak.

[DataGhost]

Ik bedoel daar niet "het rooten" mee, maar "de account" of het concept "root". Wat ik daarmee bedoel is dat een zekere vorm van elevation, liefst expliciet, de manier is om als gebruiker toch "volledige" controle over een machine te hebben zonder dat de account die op dat moment in gebruik is 24/7 al die rechten impliciet moet bezitten. De situatie die SinergyX schetst is met Windows XP toch redelijk uitgestorven zonder dat de gebruikers daar echt veel mogelijkheden mee ontnomen zijn. Terug willen naar die situatie omdat een telefoonfabrikant niet af-fabriek een zeer makkelijke elevation-mogelijkheid meelevert vind ik behoorlijk overtrokken.

Verder weet ik niet hoe het met AOSP zit als je dat zelf installeert, maar ik kan me niet voorstellen dat dat dan direct zo dichtgetimmerd is. Ook custom ROMs hebben doorgaans gewoon root-mogelijkheden. Het zijn de telefoonfabrikanten die het moeilijk maken, deels ingegeven door het gemiddelde niveau van technische kunde van de gebruikers, deels vanwege andere redenen (geld etc). Dat is voor Tweakers inderdaad lastig maar zeker niet onoverkomelijk. Bovendien is het vaak al voor aankoop al mogelijk om erachter te komen of een apparaat makkelijk geroot kan worden. En dat is dus nog los van de andere mogelijkheden die er nog steeds gewoon zijn door een telefoon met een PC te verbinden, al dan niet in debugging-mode, om zo bij die afgeschermde bestanden te komen.

[Vampyre]

De situatie die SinergyX schetst is met Windows XP toch redelijk uitgestorven zonder dat de gebruikers daar echt veel mogelijkheden mee ontnomen zijn.

Als een voorbeeld, als ik een driver of beter een hypervisor wil toevoegen op windows (die volledig toegang heeft tot alles), dan kan ik dat zelfs nog zonder problemen op windows 11.
Wil ik dit doen op mijn Samsung a52s dan houd Knox mij tegen, zelfs met custom roms (knox is de onvervangbare hypervisor).
Daardoor kan ik niet, op de hardware die ik aangeschaft heb, niet alle mogelijkheden aanspreken en gebruiken die de hardware bied, in tegenstelling tot die Windows PC.

(Daarnaast het 7 maanden na launch geduurd voordat de community een werkende root oplossing vond waarbij de ook de camera's bleven werken. Knox schakeld die ook heel fijn uit bij rooten...)

Waarom is dit wenselijk volgens jou?

Terug willen naar die situatie omdat een telefoonfabrikant niet af-fabriek een zeer makkelijke elevation-mogelijkheid meelevert vind ik behoorlijk overtrokken.

Ik niet.

[Vampyre]

Ik snap vrij goed wat de android mappen doen en voor dienen, no worries.
Bijvoorbeeld, je 2FA codes worden daar niet in opgeslagen en Candy Crush heeft nooit bij deze codes gekund via deze weg (en anders zie ik graag de CVE die dat beweerd).

Mijn reactie op was op jouw root verhaal, daar is dan ook mijn voorbeeld op gestoeld.

En naast dat 162% van alle statestieken on the spot verzonnen wordt is jouw 0,1% op 2.5 miljard gebruikers (https://www.businessofapps.com/data/android-statistics/) nog steeds 2.5 miljoen mensen die het even moeilijker wordt gemaakt.

Dit terwijl je ook een permission flag kunt toevoegen voor filemanagers.
Of een call recorder flag voor call recorder apps (https://tweakers.net/nieu...eksopname-op-android.html)

Of gewoon een super user elevation. Zoals we al jaren hebben op bijna elk ander OS.

En om je zorgen over mijn telefoon keuze ook weg te nemen, ik wou inderdaad niet aan de Samsung vanwege Knox.
Altijd vanaf de Polaris met WinCE HTC gekozen vanwege de S-OFF mogelijkheden (security off voor alle delen van de telefoon, inc. radio firmware).
Maar helaas... HTC is een beetje dood.

Anyway, beetje offtopic, maar in ieder geval wel fijn dat je deze situatie toch wel een beetje als onwenselijk ziet.

[Vampyre]

Waar worden die dan opgeslagen?

/data/data/<packagename>/files

Kan jij mij zo'n usecase noemen dan?

Backups naar sdcard en rsync naar servers in eigen beheer.

Iemand anders noemde onder dit bericht al zaklamp-apps. Straks hebben tig zaklamp-apps een permission flag voor filemanagers. De meeste gebruikers klikken toch wel op okee, ja en amen

Ja? En? Dus de meeste gebruikers zijn idioten of zo? Is dat wat je zegt en is dat dan het werkelijke security probleem?
Ik denk eerlijk gezegd toch niet dat dat de kern van het probleem zou zijn hoor.

Google heeft vast wel de middelen om even een malware scan los te laten op alles wat zich voor doet als zaklamp app.
De Playstore en de inhoud is hun verantwoordelijkheid, daar kunnen ze allerlei beveiliging en checks in bouwen,

[DataGhost]

/data/data/<packagename>/files

Is deze locatie dan wel gewoon leesbaar voor alle apps? Zo ja, kan dus Candy Crush wel gewoon bij die 2FA-codes.

Backups naar sdcard en rsync naar servers in eigen beheer.

En zo nee, zal dit ook lastig zijn. Dan heb je immers onvolledige backups. Dat zal de reden zijn dat Titanium Backup al sinds jaar en daghier een beetje over is nagedacht root nodig heeft voor volledige backups. Ook hier moet je (op dit moment) een first-party oplossing hebben. Een elevation prompt zou hier zeker kunnen helpen maar voor dit soort toegang zie ik die ook te snel misbruikt worden. Dan zou ik die toestemming liever tethered willen geven, eenmalig, waarna die app daar wel bij kan. Maar ook dan sta je nog open voor rogue updates.

Ja? En? Dus de meeste gebruikers zijn idioten of zo? Is dat wat je zegt en is dat dan het werkelijke security probleem?
Ik denk eerlijk gezegd toch niet dat dat de kern van het probleem zou zijn hoor.

Dat ligt wel ten grondslag aan veel verbeteringen die op het gebied van security worden gedaan, en natuurlijk speelt het veranderende landschap wbt malware ook mee. Het gaat tegenwoordig veel minder om chaos maken en meer om datavergaring, waardoor malware ook een stuk onschuldiger lijkt want je merkt er niet zoveel van.

Google heeft vast wel de middelen om even een malware scan los te laten op alles wat zich voor doet als zaklamp app.
De Playstore en de inhoud is hun verantwoordelijkheid, daar kunnen ze allerlei beveiliging en checks in bouwen,

Die middelen hebben ze wellicht, maar er zijn ontelbaar veel manieren om malware te maken die niet gevonden wordt door malware-scans. Zolang de broncode niet geüpload hoeft te worden is dat niet of nauwelijks te detecteren, en zelfs dan is het moeilijk. Die scans werken immers ook alleen maar op basis van signatures en soms heuristiek waardoor ze volledig afhankelijk zijn van het gedrag wat de app vertoont op het moment van testen. Als ik malware zou willen maken die niet te detecteren is, zou ik een echt werkende filemanager-app in elkaar klussen die pas vanaf twee maanden na installatie gaan beginnen met het doorsturen van verzamelde data, terwijl er wel functionaliteit in zit die ervoor zorgt dat netwerkverkeer van de app niet als verdacht wordt gezien. Zo is dat ten tijde van het uploaden in de Play Store (eerste versie en elke update) volkomen ondetecteerbaar. En dan heb ik het nog niet eens gehad over sideloaden.

[Reactie gewijzigd door DataGhost op 24 juli 2024 01:06]

[Vampyre]

Is deze locatie dan wel gewoon leesbaar voor alle apps?

Nee. En sterker nog, als de app in kwestie een no-backup flag heeft gezet dan kan er dus helemaal niks bij zonder root. Zelfs niet USB tethered. Dus de gebruiker ook niet.

Die middelen hebben ze wellicht, maar er zijn ontelbaar veel manieren om malware te maken die niet gevonden wordt door malware-scans.

Ze hebben ook mensen of kunnen mensen in huren. Geld zat daar.
En daarbij, als een app rechten nodig heeft staat dat in het manifest. Die kan je niet zomaar even na installatie aanpassen.
Ook als je extra rechten in een update wil stoppen kan de playstore dat dus weer tegen houden als je een zaklamp app bent.

En dan heb ik het nog niet eens gehad over sideloaden.

Dan wil ik dat wel even doen .
Juist het side-loaden is opeens veel makkelijker geworden.
Vroeger, voor Android 8(?) moest je eerst het hidden developers menu in om dat toe te staan.
Tegenwoordig kan elke app deze permission vragen en apps installeren.
Hoe is dit dan wel consistent met het hele gebruikers verhaal?

[DataGhost]

Nee. En sterker nog, als de app in kwestie een no-backup flag heeft gezet dan kan er dus helemaal niks bij zonder root. Zelfs niet USB tethered. Dus de gebruiker ook niet.

Ook hier kan ik me usecases voor voorstellen, zal wel weer in de buurt liggen van de usecases voor Knox, hoewel het natuurlijk niet wenselijk is dat er helemaal geen toegang mogelijk is.

Ze hebben ook mensen of kunnen mensen in huren. Geld zat daar.
En daarbij, als een app rechten nodig heeft staat dat in het manifest. Die kan je niet zomaar even na installatie aanpassen.
Ook als je extra rechten in een update wil stoppen kan de playstore dat dus weer tegen houden als je een zaklamp app bent.

Daarom noem ik dus ook een file manager app als concreet voorbeeld. Niemand die vraagtekens gaat zetten bij de permissie voor bestandstoegang. Met wat simpele kleine features is ook netwerkverkeer niet raar, dus zelfs als je de bytecode van de app scant op netwerktoegang en domeinnamen is daar niks verdachts aan. Dan hoef je alleen nog maar timed functionaliteit in te bouwen, of C&C-style een flag te veranderen die periodiek online wordt gecontroleerd, en niemand die gaat kunnen testen of die app niet stiekem gebuikersdata wegsluist, ongeacht hoeveel mensen je ervoor inhuurt. Nou ja, of je moet alle apps en alle updates maandenlang blijven testen natuurlijk maar gezien de omvang van de play store kan ik redelijk veilig zeggen dat dat onmogelijk is, naast een gigantische geldverspilling.

Dan wil ik dat wel even doen .
Juist het side-loaden is opeens veel makkelijker geworden.
Vroeger, voor Android 8(?) moest je eerst het hidden developers menu in om dat toe te staan.
Tegenwoordig kan elke app deze permission vragen en apps installeren.
Hoe is dit dan wel consistent met het hele gebruikers verhaal?

Jij reageerde alsof de Play Store de enige manier is om apps op een Android-device te krijgen. Ik bedoelde hiermee dat er meerdere mogelijkheden zijn om dit te doen waarmee direct alle door jou voorgestelde controle buitenspel wordt gezet.
Maar goed, sideloaden kan prima consistent zijn met het hele gebruikersverhaal zolang de runtime environment "veilig" is. Dus dat betekent apps zoveel mogelijk sandboxen. Ook al heb je dan de allerergste spyware binnengehaald via een sideload zou deze alsnog niet zomaar bij data van andere apps moeten kunnen. Dat uitgangspunt is in principe veiliger dan testen of apps zich netjes aan de regels houden die jij hebt verzonnen, zonder daar runtime checks op te doen.

[sympa]

Hoe zit het dan met SMM en de TPM op je PC? En de Intel Management Engine?

[Vampyre]

TPM kan ik mijn eigen keys in zetten, SMM kan uit (coreboot) en AMD ;-).

[Heidistein]

Ik begrijp wel wat je zegt, maar er zijn wel degelijk usecases waar het mogelijk moet zijn om niet (uiteraard) in /home/heidistein te mogen, maar wel degelijk in /home/heidistein/public_html.
Of documents/gedeeld_met_anderen. Of iets.

[GertMenkel]

Voor die use cases kunnen apps providers registreren die andere apps toestemming geven tot relevante data. Deze providers kunnen zelfs in je bestandsverkenner verschijnen waardoor je bijvoorbeeld je favoriete cloudopslag met de ingebouwde verkenner kan doorbladeren zonder eerst alles te hoeven downloaden. Ook kunnen apps op die manier slim met bestanden om gaan (bijvoorbeeld een galerij-app die "mappen" maakt per locatie zodat je vanaf je bestandsverkenner je vakantiefoto's terug kunt zien).

Gedeelde mappen in privémappen zijn op sommige platformen de manier waarop men dit doet, maar ik vind de Android-aanpak een stuk beter passen eigenlijk.

[Jazco2nd]

En de map android/media dan? Die is vrij essentieel om wel toegankelijk te houden. Whatsapp media en database backup zit daarin.

[GertMenkel]

Als WhatsApp niet zo onhandig in elkaar was gezet had dit gewoon automatisch gewerkt. Het handmatig overkopiëren van de datamap is een hack die je bij een goed werkende messenger nooit nodig zou moeten hebben. WhatsApp heeft hier gek genoeg gekozen om backups op te slaan op een plek die expliciet niet voor andere apps beschikbaar zou moeten zijn en Google heeft daar nu een fout in opgelost. Dat is niet echt een Google-probleem, dat is een keuze die WhatsApp heeft gemaakt.

In theorie kunnen ze je gewoon vragen om een willekeurige map te kiezen op de SD-kaart om de backup naartoe te schrijven natuurlijk. Waarom ze dat niet doen is mij een raadsel.

[Jazco2nd]

Dat laatste is wat ik liefst heb, want ik heb gewoon m'n eigen cloud dus gebruik FolderSync (webDAV) om de belangrijkste dingen te backuppen.

Signal laat je wel de backup map kiezen, maar gooit alles in 1 mega file, inclusief alle media. Dus zit je zo elke nacht 25GB (*2 want er zijn altijd 2 backups) te uploaden

[GertMenkel]

Ik weet niet precies hoe Sifnal's veesleuteling werkt, maar als delen van het versleutelde bestand iedere keer hetzelfde zijn, zou je kunnen kijken naar Seafile. Seafile doet namelijk block level deduplication waardoor een "25GB" backup maar een paar MB kan zijn. Dat werkt natuurlijk niet als (voor goede veiligheidsredenen) het hele bestand iedere keer verandert. Als de backup niet versleuteld is, werkt dat natuurlijk wel weer, maar ik kan me niet voorstellen dat ze daar geen sleutel op zetten.

[Jazco2nd]

Het hele bestand veranderd en is versleuteld. Ik ken Seafile ja, maar dat gaat helaas niet werken. Het probleem moet door Signal worden opgelost.. het is eigenlijk te gek voor woorden.

[WhatsappHack]

Via USB sowieso te bereiken

[Martinspire]

Voor hoe lang nog?

[BGLAdmin]

Het framework zou ervoor moeten zorgen dat applicatie A niet bij de data van applicatie B kan, ofwel bescherming van gegevens van de gebruiker.
Je zou ook kunnen zeggen dat applicatie A niet mee bij je Whatsapp data kan. Via een applicatie zoals files van Google kun je er nog wel bij, of met een usb kabel.

[rjberg]

Dus je kunt nog wel bij downloads en zelfgemaakte mappen?

[cosmo_roel]

Mijn OS (instantie), mijn mappen, ik wil erbij kunnen. Punt.

[edwinjm]

Waarom moet app A bij de data kunnen van app B? Dat is voor zowel de beveiliging als de privacy een slechte zaak. Eigenlijk vreemd dat dit nu pas wordt opgelost.

[familyman]

Onzin.
Ik heb een app waarmee de gebruiker kan schrijven oo pdfs en afbeeldingen.
Die afbeeldingen en pdfs hoeven niet uit de app zelf te komen, maar zouden bv ook via een sync binnen kunnen komen. Of in die andere app gemaakt zijn.

[calvinturbo]

Dat zou nog steeds moeten kunnen, die data staat over het algemeen in mappen zoals Downloads

[Z80]

En nu een poi lijst of offline map downloaden en in de map van de desbetreffende navigator zetten.
Nu nog geen probleem. Als google zijn zin krijgt is dit niet meer mogelijk.
OsmAnd heeft de mogelijkheid om een paar kaarten vanuit de app te downloaden. Daarna moet je betalen. Maar de kaarten kun je gewoon gratis en legaal van een site downloaden.
https://osmand.net/list.php
Die komen dan wel in je download map. Zie hier een voorbeeld van het probleem.

[calvinturbo]

Dit kan je toch via de PC via USB gewoon regelen? Dat wordt niet geblokkeerd.

[Z80]

Waarom en extern apparaat gebruiken voor iets op je eigen android toestel van map verplaatsen?
Daarbij komt het nog al eens voor dat ik geen pc, of vertrouwde pc, bij de hand heb. Wel een data verbinding om de gegevens binnen te halen.

[sympa]

Daarom is er ook heel veel storage gedeeld op te toestel.
Maar apps kunnen dus ook een privé-stuk hebben. Wat privé moet blijven.
Of is het ook zo handig als "Brightest Flashlight Turbo Pro" ook je bankzaken gaat inzien en regelen?

[Bas170]

Als ie het dan maar wel goed doet, scheelt het mij weer werk

[CivLord]

Wanneer je het hebt over een flashlight app die niet bij mijn WhatsApp data hoeft te komen heb je absoluut gelijk. Maar ik wil wel met mijn bestandsbeheer app bij de foto's in de WhatsApp data kunnen om deze naar mijn SD-kaart te kunnen verplaatsten.

[Anoniem: 1099225]

Waarom moet app A bij de data kunnen van app B? Dat is voor zowel de beveiliging als de privacy een slechte zaak. Eigenlijk vreemd dat dit nu pas wordt opgelost.

Hier ben ik het helemaal mee eens echter kan er ook om toestemming gevraagd worden zodat ik zelf wel bij de mappen kan indien ik dit wens. Zo word het ook gedaan bij veel andere permissions, je hebt de keuze uit standaard blokkeren, elke keer vragen of altijd toestaan. In dit geval kun je de keuze geven uit de eerste twee.

[Reactie gewijzigd door Anoniem: 1099225 op 24 juli 2024 01:06]

[Vampyre]

App A hoeft niet bij de data van B te komen. IK wil bij de data van zowel A als B komen.
Het is namelijk MIJN data. Google heeft het recht niet om MIJ de toegang te ontzeggen.
Vrij simpel lijkt mij .

[jmvdkolk]

Omdat jij bij de data wil komen met jouw favoriete bestandsmanager (App A) moet App A bij de data van B komen. Wat @edwinjm zegt is dus zeker wel relevant en juist. Effectief heb jij ook gelijk, want jouw favoriete bestandsmanager kan jou dus niet meer bieden wat jij wilt.

Ik zie niet wat hier simpel aan is, want er zijn twee conflicterende belangen. Google moet hier een keuze maken om ofwel groep 1 tevreden te stellen ofwel groep 2. Het alternatief is dat Google iets helemaal nieuws bedenkt en alle app makers vraagt dit nieuwe te gebruiken zodat zowel groep 1 als groep 2 tevreden is.

Persoonlijk klinkt dit hele gebeuren als security through obscurity, dus denk ik dat dit helemaal niets oplost qua security.

[kodak]

Er staat in het artikel toch duidelijk dat je er nog bij kan? Op verschillende manieren zelfs.

[Vampyre]

Op 2 manieren. Beide door Google of de fabrikant gecontroleerd.
Dus zelf een app kiezen om er bij te kunnen mag niet meer.
Waarom mag dat niet meer zonder omwegen?

Security? Mag ik dan eens serieuze cijfers zien van hoe groot dit probleem werkelijk is tegenover de steeds grotere draconische maatregelen die genomen worden?

Privacy? We hebben het over de Data Mining Operation genaamd Google hier. Hoeveel 'telemerty' stuurt Android ook al weer terug?

DRM? Ja... Waarschijnlijk...

[Xfade]

Waarom wil je bij die mappen?

[Vampyre]

Waarom is er überhaupt iemand anders als ikzelf die de toegang tot die mappen mij kan ontzeggen op mijn eigen telefoon of device?

[Flagg]

Doe je dat bij en auto ook, ik heb de auto gekocht dus ik wil bij de data in mijn ECU komen?

Maar bij een telefoon word je ineens aangetast in je rechten?

[Vampyre]

Nou... Ja?

En dit is een goed voorbeeld.
Vroeger kon je met elke auto, als er wat aan mankeerde, bij elke garage terecht om hem te repareren.
Als je de technische kennis had kon je het zelf (pa heeft die kennis, vroeger vaak hem geholpen met reparaties).

En toen kwamen de computers er opeens in... Met daarbij de 'DRM praktijken'.
En tegenwoordig doet jouw eigen auto helemaal niks meer als deze niet met zijn eigen dure dealer garage kan praten.
Dit is vendor lock-in.

Maar we hebben het over Android, niet auto's. Offtopic dus.

[biteMark]

Nou, Android is toch open source? Er is vást wel iemand die een ROM gaat bakken waar deze restrictie uitgesloopt is, en met een beetje geluk ook voor jouw telefoon. Of misschien kan je wegkomen met een root.

[arjandijk162]

Er zijn weinig mensen meer met een (root) rom dus je schrijft voor een kleine marjt

[TheRacknker]

Dus MiXplorer zal niet meer werken zeker. Echt super fijn

[jimzz]

Waarom niet? Het gaat vaak om kritieke bestanden waar 99% vd gebruikers niks te zoeken heeft en de hele boel aan gort kan helpen als ie daar in gaat kloten.

Het zorgt er naar mijn idee dus voor dat App X niet zomaar in de bestanden van App Y mag snuffelen, waar dat nu dus via die loophole wel kan (en kwaadwillenden zullen hier dan ook gretig gebruik van maken in verschillende louche apps).

Ik vraag me vaak af wat de mensen (buiten principe) zo erg daar aan vinden dat zulke bestanden lastiger te bereiken zijn? (Is een oprechte vraag btw).

In Windows zijn de systeembestanden ook niet zomaar te wijzigen en daar hoor ik maar weinig over. Maar goed ik hoor graag tegenargumenten.

[MsG]

Ik vind het vooral lastig omdat ik niet lekker kan backuppen met Android. Android heeft standaard alleen het kreupel terugzetten van apps als je een telefoon herinstalleert ZONDER enige vorm van gebruikersdata. Bij Apple is dit vele malen beter geregeld. Veel spelletjes bewaren hun savegamedata in de data/data-map waar je zonder root ook niet bij kan. Hierdoor was ik bijvoorbeeld al m'n savegames van Rollercoaster Tycoon kwijt toen ik van tablet wisselde. Geen wereldprobleem maar wel vervelend.

[GertMenkel]

De Android SDK heeft een heel framework waarmee je data bij installatie van een nieuw apparaat wordt teruggezet. Deze werkt op apparaten met Android 2.2 of hoger voor dingen als instellingen, en sinds Android 6 zijn er een stuk meer features toegevoegd.

Dit is bedoeld voor instellingen en metadata en de versie die ontwikkelaars gratis van Google krijgen is beperkt tot 25MB. 25MB aan database is een behoorlijke hoeveelheid aan gebruikersdata voor een platte opslag vind ik zelf, helemaal aangezien het bedoeld is om alleen het broodnodige te syncen zodat je persoonlijke inhoud van de cloud kan worden getrokken. Voor mobiele game saves zou dit ook nog wel genoeg moeten zijn lijkt me zo. Er zijn natuurlijk opties om via de Google Drive API grotere bestanden te back-uppen of men kan hun eigen servers relatief eenvoudig inrichten als ze dat liever doen. Overigens is de API zo ontworpen dat Android-systemen zonder Play Store zelf hun backupsysteem kunnen bouwen, maar in de praktijk gaat alles natuurlijk naar Google.

Ik had zelf een optie gezien van Google om (betaald) meer data te kunnen back-uppen. Ontwikkelaars kunnen applicatiespecifieke mappen maken op Drive natuurlijk, maar een ingebouwd systeem zou net iets makkelijker zijn.

Als je al je data kwijt bent zodra je van telefoon wisselt, is dat meestal de schuld van de app-ontwikkelaars of heb je in het verleden backups zelf uitgezet. Backups van instellingen/account tokens/etc. zijn een kwestie van een regel XML toevoegen en het werkt bijna out of the box.

[MsG]

Backups van instellingen en wachtwoorden zijn vaak wel prima, maar daadwerkelijke speldata veelal niet. Het zal mij als eindgebruiker een zorg zijn bij wie dat ligt, effectief heb je deze ellende eigenlijk niet bij iOs met de volledige systeemkopie, terwijl ik, sinds ik 10 jaar geleden bij Android ben gekomen, dit probleem alleen niet had op mijn geroote toestellen. 25 MB is vrij middeleeuws als je het mij vraagt, zeker voor opslag-data voor de wat serieuzere spellen.

Ik ben niet per se alle data in z'n geheel kwijt, maar meestal eindig je toch met diverse apps die dan puur op het nieuwe toestel worden gezet, maar zonder enige userdata.

Ook al eens een topic over gestart (Werkende backup-software voor Android) maar blijkbaar leeft het niet echt, en vindt het merendeel van de Android-gebruikers het prima, om gebruikersdata van apps te verliezen bij overstap.

[GertMenkel]

Zo'n beetje elke telefoon die ik gekocht heb kwam met zijn eigen backupsoftware voorgeïnstalleerd, meestal zonder dat ik daar interesse in had. De beste backupsoftware lijkt me degene van de fabrikant die bij meer dan alleen de openbare data kan, al wordt het cross platform gebruik daarvan iets lastiger voor herstel (wallpaper/SMS/contacten/etc. herstellen kan natuurlijk wel gewoon).

Ik zou zelf niet precies weten wat een game in 25MB kwijt kan, maar ze zouden er op zijn minst de naam van een cloud bucket of een directory token voor Google Drive in kunnen opslaan om de saves mee te synchroniseren. Als je graag het Android-platform wil benutten, is er de Google Play Games API met save sync en meer. Daar heb je 800KiB gestructureerde data + 3MB aan cover image per save, dus als je 500 autosaves wil synchroniseren dan kan dat, aannemende dat de gebruiker genoeg GDrive-opslag heeft. Is 800KiB niet genoeg, dan kan zoals eerder genoemd de data altijd nog naar een "normale" applicatie-drive map en kan de "save game" bestaan uit de nodige metadata om die data uit te lezen/weg te schrijven.

Games die ervoor kiezen om niet te syncen zijn nogal ergerlijk, maar de API's liggen klaar. Ik heb bijvoorbeeld ook spellen op Steam die geen cloud sync doen voor saves, het is lichtelijk irritant dat de ontwikkelaars kozen om niet te integreren met het platform maar het zij zo.

[Vampyre]

Android heeft een zeer irritante per app security flag die voorkomt dat de normale backup service (zoals via ADB) de 'privacy gevoelige' data niet backupt.
Helaas staat die flag bij een hoop apps aan, zelfs bij bijvoorbeeld firefox (last time I checked in ieder geval nog steeds.
Bij firefox heb je dus eigenlijk alleen maar de keuze om mozilla sync of een andere sync plugin te gebruiken.

Beste backup op Android is dan ook nog steeds titanium backup (mi.) maar die vereist uiteraard root rechten.
En daar gaat dan ook meteen de hele farce van veiligheid bij Android, aangezien data protection juist een zeer belangrijk aspect is van veiligheid.
En dat kan dus alleen maar via omwegen en moeilijk doen...
Lekker handig

[Reactie gewijzigd door Vampyre op 24 juli 2024 01:06]

[jimzz]

Ik zet persoonlijk alleen de belangrijke data over bij een nieuwe installatie en installeer alles opnieuw. Is normaal gesproken maar eens per 2 jaar, maar ik heb gemerkt dat zowel op Android als op iOS dat ten goede komt van zowel performance als batterijduur in tegenstelling tot het volledig terugzetten van een backup.

Overigens heeft Samsung dit best goed geregeld tegenwoordig, weet niet hoe dat voor andere merken is.

[MsG]

Mijn punt is dus vooral dat je genoeg data niet eens kan backuppen zonder root omdat je geen rechten op die locaties hebt. Bij de iPhone schoof ik telkens door naar een bestaande reservekopie, waardoor je gewoon keurig de omgeving hield maar dan met nieuwe hardware. Dat zorgde ook totaal niet voor vertraging of slechtere werking.

Als Android nou eens het maken van een systeembrede reservekopie zou ondersteunen (wat Android bij Google zelf opslaat is lang niet alle data van de apps), zou er al een stuk minder noodzaak zijn voor root.

[jimzz]

Apple heeft dit zeker beter voor elkaar, maar slowdowns waren wel degelijk aanwezig op mijn iPhones. Vandaar dat ik liever als nieuw installeer.

Maar je punt is zeker valide, Google kan daar zeker nog op verbeteren.

[jaquesparblue]

Android gaat steeds meer de iOS kant in. Geen goed teken. Toegang tot externe media (USB, SD) hebben ze ook al aardig vernaggeld.

[willieverhoef]

klopt in de naam van veiligheid wordt de vrijheid opgegeven. Een extra recht met duidelijke waarschuwing zou ook genoeg moeten zijn. Maar helaas

[WhatsappHack]

“Een extra recht met duidelijke waarschuwing zou ook genoeg moeten zijn.”

Je overschat de gebruikers denk ik… Iets met een zaklamp app enzo.

[Nico Klus]

Nou, 'Files by Google' zegt over /Android/data "Hier is niets te zien" op Android 12.

[Rub3s]

Nou, dat is een filemanager van Google, daar gaat dit nieuwsbericht niet echt over.

[satya]

Dat hangt dan weer af van de als default ingestelde filemanager.

[Rub3s]

Nee, hij heeft het over 'Files by Google'. Dat is iets van Google zelf, dan kan Google die app zo beperken zoals ze zelf willen ongeacht de api van Android.

[satya]

halfomhalf, bij een xiaomi bijvoorbeeld is de standaard filemanager van xiaomi, geen enkele andere standaard applicatie heeft dan de volledige rechten. Je zult eerst een andere filemanager als standaard in moeten stellen wat sinds android 12 weer mogelijk is. De genomende map is dan nog steeds niet leesbaar.

De standaard en veilig geachte filemanager heeft meer rechten dan andere filemanagers of apps die je op je toestel kan zetten, daar gaat het bij het hele framework ook over. Nu nog de mogelijkheid om een paar andere apps zoals de camera als standaard in te kunnen stellen zodat gcam hier de standaard wordt.

[Olympus user]

Alles onder Android 13 zal dit niet krijgen dus mogelijk onveilig en moeten velen al nieuwe telefoon kopen.
Tja zo blijven we bezig met consumeren.