Android app-machtigingen - hoe Google het goed doet ...

Er is de laatste tijd veel nieuws geweest over een verval in beveiliging of oordeel - beide eigenlijk - bij Apple waarmee iOS-applicaties uw contactgegevens kunnen lenen en zonder uw toestemming naar onbekende onderdelen kunnen sturen. Apple heeft het probleem voorgelegd aan leden van het Amerikaanse congres en zal stappen ondernemen om de controle te houden in een toekomstige iOS-update. Dat is goed nieuws en we zijn blij het te zien gebeuren.

Maar hoe zit het met Android? Tijdens al deze focus op apps die dingen doen zonder expliciete gebruikerstoestemming, zie je mensen verwijzen naar het Android-machtigingsmodel. We gaan het allemaal voor je afbreken. Het is niet perfect, maar het werkt behoorlijk goed - en het is zeker beter dan helemaal geen permissiesysteem.

Laten we u door toestemmingen op Android leiden, en hoe u zeker moet zijn dat u deel uitmaakt.

Per ontwerp heeft geen enkele Android-applicatie toestemming om een ​​bewerking uit te voeren die "nadelige gevolgen zou hebben voor andere applicaties, het besturingssysteem of de gebruiker." Om een ​​app toegang te geven tot zaken als privécontactgegevens, de gegevens van een andere applicatie, netwerktoegang of zelfs zoiets alledaags als het schrijven van eigen gegevens naar de opslag van het apparaat, moet de app verklaren dat het toestemming heeft om dit te doen, en dan je moet die toestemming accepteren voordat je de app kunt installeren. Wanneer u een app installeert, krijgt u een lijst met machtigingen te zien die door de app worden aangegeven.

En merk op dat we zeggen dat applicaties "toestemmingen" verklaren en niet noodzakelijkerwijs "aanvragen". Wij veronderstellen semantiek, maar er is geen doos met de tekst: "Hé Jerry! Ik ben een app en ik zou het leuk vinden als je me je contactgegevens laat zien. Is dat goed?" In plaats daarvan zijn Android-apps directer en zeggen "Yo, Jerry. Ik ben een app. Hier is een lijst met wat ik kan doen, gewoon zodat je het weet. Neem het of laat het."

Android-apps geven aan tot welke machtigingen ze toegang hebben en dus tot welke sandboxen ze kunnen spelen. En u kunt ervoor kiezen om ze te accepteren en de app te installeren of niet. Zinvol?

Machtigingen - vooraf en persoonlijk in de Android Market

Zo ziet het eruit als u bijvoorbeeld Pad installeert. U krijgt de macrolijst met machtigingen die Path aangeeft. Tik op een, en het verklaart die toestemming iets gedetailleerder.

Zo ziet het eruit als u een applicatie van Android Market installeert. U moet door de lijst bladeren om ze allemaal te zien. Een beetje naar beneden is degene die Path (en anderen) in allerlei problemen op iOS heeft gekregen. In de Android-vorm kunt u duidelijk zien dat Path de toestemming geeft voor 'Uw persoonlijke gegevens - contactgegevens lezen'. Tik op die toestemming en je krijgt meer details:

"Hiermee kan een app alle contactgegevens (adresgegevens) lezen die op uw telefoon zijn opgeslagen. Schadelijke apps kunnen dit gebruiken om uw gegevens naar andere mensen te verzenden."

Dus Path heeft je verteld dat het toegang heeft tot je contactgegevens. Het vertelt je niet noodzakelijkerwijs wat het ermee gaat doen (als we het niet net ter sprake hadden gebracht, zou je het echt willen weten?), Maar het vertelt je wel dat het het kan lezen.

Apps buiten de Android Market

Maar wat als u een app sideloadt? Of gebruik je de Amazon Appstore? Applicaties moeten nog steeds aangeven welke machtigingen ze gebruiken en u ziet die lijst met machtigingen wanneer u de app installeert. (Onthoud dat de Amazon Appstore apps opzij laadt, dus wat je ziet is precies hetzelfde als wanneer je een app hebt geïnstalleerd via een e-mail of download.)

Zo ziet sideloaden van Gmail eruit. Het enige echte verschil tussen sideloading en installatie vanaf de Android Market, voor zover rechten gaan, is dat wanneer u sideload, u niet de meer gedetailleerde machtigingenbeschrijvingen krijgt.

Waarom dit allemaal? Android-applicaties zijn "sandboxed" - ze spelen in hun eigen ruimte en hebben hun eigen gegevensbestanden in die sandbox. Ze kunnen het spel alleen delen in de sandbox van iemand anders nadat ze expliciet om toestemming hebben gevraagd, en dat gebeurt via de schermen die je hierboven ziet. Wanneer u die machtigingen accepteert en de app installeert, geeft u die app toestemming om te spelen in de sandboxen waarvan de app zegt dat het wil spelen.

Aan de kant van de ontwikkelaar … en hoe consumenten hun steentje moeten bijdragen

Achter de schermen verklaren app-ontwikkelaars deze machtigingen in het bestand AndroidManifest.xml, dat een verplicht onderdeel is van de broncode voor een Android-app. Deze verklaringen zijn statisch en ze worden allemaal aan de gebruiker gepresenteerd zoals we hierboven hebben gezien. Android heeft geen manier om tijdens runtime dynamisch machtigingen te verlenen, omdat het volgens de Android OS-ontwikkelaars "de gebruikerservaring bemoeilijkt ten koste van de beveiliging." Een app dwingen om je te vertellen wat hij vooraf wil doen en nooit kan veranderen - dat is het ultieme beveiligingsmodel.

De keerzijde? Het is ook het gemakkelijkst voor gebruikers om te negeren.

We weten alles over wat er is gebeurd met Path op iOS. Net als veel andere iOS-apps gebruikte het de contactpersoon zonder toestemming. Niet voor snode doeleinden, maar desalniettemin zonder voorafgaande toestemming en zonder het later te vragen. Path voor Android stuurde allerlei gegevens naar zijn servers, net zoals op iOS. Maar zoals we in dit bericht hebben aangetoond, moet Path in Android eerst de toestemming geven. Of, preciezer gezegd, verklaart het toestemming en u accepteert het of wijst het af.

Het probleem is dat wanneer je een app installeert, je waarschijnlijk langs de sectie met rechten waait. Dat zou je echt niet moeten doen, maar we doen het allemaal. Het feit dat de machtigingen niet in gewone taal zijn geschreven, maakt deel uit van het probleem. Maar zelfs als ze dat waren, zouden de meesten van ons toch recht langs klikken. Dat is indrukwekkend, op elk platform. Aan de andere kant zijn er mensen die in paniek raken over machtigingen omdat ze ze niet begrijpen. Nogmaals, meer gebruiksvriendelijke taal zou hier helpen.

Een van de alternatieven hiervoor is om de toepassing tijdens de uitvoering toestemming te vragen, wanneer deze iets wil doen dat ze normaal niet kan doen. We hebben al gelezen dat het Android-team dit ongemakkelijk en onzeker vindt, dus het is niet waarschijnlijk dat dit gebeurt.

Een ander alternatief is om geselecteerde machtigingen toe te staan, net zoals RIM dat doet met BlackBerry. Je eindigt met applicaties die maar half werken omdat je machtigingen hebt geweigerd, net als BlackBerry. Er is geen echte waterdichte methode, behalve het allemaal lezen wanneer je die app installeert en probeert te begrijpen wat hij vraagt ​​te doen en waarom hij het vraagt.

Dat is waar we allemaal binnenkomen. Sommigen van ons begrijpen applicatie-machtigingen meer dan anderen, en als een app iets doet wat het niet zou moeten doen, hoor je het protest. Lees de rechten. Lees de opmerkingen over de markt. Lees Android Central. Als er iets misgaat, hoor je erover.

En nog een ding …

Hier moet een speciale opmerking worden gemaakt over beveiligingsproblemen. Elk computerprogramma - en dat betekent ook elk mobiel besturingssysteem - zit er boordevol van. Wanneer een kwetsbaarheid wordt gevonden waardoor een toepassing het beveiligingsmodel kan omzeilen, zal Google dit snel repareren. Dit gebeurt en het zal altijd gebeuren. Hoe snel deze update naar u wordt uitgerold, is afhankelijk van de mensen die uw telefoon maken. Ze verdienen de eer als ze het op de juiste manier doen, en de minachting als ze te lang duren en het verkeerd doen. Dat is niet iets dat binnenkort weg zal gaan, en we zijn hier bij u om een ​​OEM te roepen die de dingen niet zo veilig en beveiligd houdt als zou moeten.

Als je nog dieper in Android-machtigingen wilt duiken, bekijk dan de Google-ontwikkelaarspagina op deze.