Permisos d'aplicacions per a Android: com funciona Google correctament ...

Darrerament hi ha hagut moltes notícies sobre un lapse de seguretat o de judici (tant, realment) a Apple que permet a les aplicacions iOS prendre prestat les vostres dades de contacte i enviar-les a parts desconegudes sense el vostre consentiment. Apple ha dirigit aquest problema als membres del Congrés dels Estats Units i prendrà les mesures necessàries per mantenir un control més estricte en una futura actualització d'iOS. Aquesta és una bona notícia i ens alegra veure que succeeix.

Però què passa amb Android? Durant tot aquest enfocament en les aplicacions que fan coses sense permís explícit de l’usuari, veieu persones que es refereixen al model de permisos d’Android. Ho anirem desglossant tot per vosaltres. No és perfecte, però funciona força bé i, certament, és millor que no hi hagi cap sistema de permís.

Anem a través de permisos a Android i de quina manera heu d'assegurar-vos.

Per disseny, cap aplicació d'Android té permís per realitzar cap operació que "afecti negativament altres aplicacions, el sistema operatiu o l'usuari". Perquè una aplicació tingui accés a coses com les dades de contacte privades, les dades d’una altra aplicació, l’accés a la xarxa o fins i tot una cosa tan banal com escriure les seves pròpies dades a l’emmagatzematge del dispositiu, l’aplicació ha de declarar que tindrà permisos per fer-ho i, a continuació, heu d'acceptar aquest permís abans de poder instal·lar l'aplicació. Quan instal·leu una aplicació, se us ofereix una llista de permisos que l'aplicació declara.

I tingueu en compte que diem que les aplicacions estan "declarant" permisos i no necessàriament "les sol·liciten". Suposem que Semàntica, però no hi ha cap quadre que digui "Hola, Jerry! Sóc una aplicació i m'agradaria que em deixessis fer una ullada a la informació de contacte. Està bé?" En canvi, les aplicacions d'Android són més directes, dient "Jo, Jerry. Sóc una aplicació. Aquí teniu una llista del que puc fer, només ho sabeu. Agafeu-lo o deixeu-ho."

Les aplicacions d'Android declaren a quins permisos tenen accés i, per tant, a quines caixes de sorra poden jugar-hi. Podeu optar per acceptar-les i instal·lar l'aplicació o no. Té sentit?

Permisos: personal i personalitzat a l'Android Market

A continuació, es mostra com sembla si instal·leu, per exemple, Path. Obteniu la llista de macro de permisos que declara el camí d'accés. Toqueu una i us expliqueu aquest permís amb una mica més detall.

Així sembla si instal·leu alguna aplicació des d’Android Market. Haureu de desplaçar-vos per la llista per veure-les totes. Una mica més avall és el que té Path (i altres) amb tot tipus de problemes a iOS. En el seu formulari Android, podeu veure clarament que Path declara el permís per a "Les vostres dades personals: llegiu les dades de contacte". Toqueu aquest permís i obteniu més detalls:

"Permet a una aplicació llegir totes les dades de contacte (adreça) emmagatzemades al vostre telèfon. Les aplicacions malicioses poden utilitzar-ho per enviar les vostres dades a altres persones."

Així, Path us ha dit que té accés a les vostres dades de contacte. No necessàriament t’explica què hi farà (si no ho acabéssim de fer, voldríeu saber-ho?), Però sí que us diu que podeu llegir-lo.

Aplicacions fora de Android Market

Però, i si en seleccioneu una aplicació? O utilitzar la botiga d'Amazon Amazon? Se suposa que les aplicacions declaren els permisos que utilitzen, i veureu aquesta llista de permisos quan instal·leu l'aplicació. (Recordeu que Amazon Appstore torna a aparèixer les aplicacions, de manera que el que veieu és exactament el mateix que si hagueu instal·lat una aplicació des d’un correu electrònic o una descàrrega.)

A continuació, es mostra el aspecte de publicació posterior de Gmail. L'única diferència real entre la publicació directa i la instal·lació des d'Android Market, en la mesura que es van produir els permisos, és que quan engegueu la publicació inicial, no obteniu descripcions de permisos més detallades.

Per què tot això? Les aplicacions d'Android són "sandboxed": es reprodueixen al seu propi espai i tenen fitxers de dades dins d'aquesta caixa de sorra. Només poden compartir el joc a la caixa de sorra d’una altra persona després d’haver sol·licitat explícitament permís i això es fa a través de les pantalles que veieu més amunt. Quan accepteu aquests permisos i instal·leu l'aplicació, esteu autoritzant aquesta aplicació per reproduir-se als boxs de sorra que l'aplicació diu que vol jugar.

Pel que fa als desenvolupadors … i com han de fer els seus consumidors

Darrere de les escena, els desenvolupadors d'aplicacions declaren aquests permisos al fitxer AndroidManifest.xml, que és una part necessària del codi font d'una aplicació per a Android. Aquestes declaracions són estàtiques, i cadascuna d’elles es presenta a l’usuari tal com hem vist anteriorment. Android no té forma d’atorgar permisos dinàmicament en temps d’execució, perquè segons els desenvolupadors del sistema operatiu Android “complica l’experiència de l’usuari en detriment de la seguretat”. Obligar que una aplicació us indiqui què vol fer, per endavant i que mai no pugui canviar, és el màxim model de seguretat.

El costat flip? També és el més fàcil que els usuaris ignorin.

Sabem tot el que ha passat amb Path a iOS. Com moltes altres aplicacions d’iOS, va utilitzar el contacte sense permís. No amb propòsits nefastos, però, sense cap permís anticipat i sense demanar-ho després. Path for Android va enviar tota mena de dades als seus servidors, tal com va fer a iOS. Però, com hem mostrat en aquesta publicació, a Android, Path ha de declarar el permís primer. O, més precisament, declara permís i l’accepteu o el rebutgeu.

El problema és quan instal·leu una aplicació, molt probablement anireu fent brisa més enllà de la secció de permisos. En realitat no ho hauria de fer, però tots ho fem. El fet que els permisos no estiguin escrits en un llenguatge normal és part del problema. Però, fins i tot si ho fossin, la majoria de nosaltres faria clic en qualsevol moment. Això és com és, a cada plataforma. D'altra banda, hi ha qui solta els permisos perquè no els entén. Un cop més, ajudaria un llenguatge més fàcil d'utilitzar.

Una de les alternatives a això és que l’aplicació sol·liciti permisos en temps d’execució, quan vol fer una cosa que no pot fer normalment. Ja hem llegit que l’equip d’Android creu que això és inconvenient i insegur, per la qual cosa no és probable que passi.

Una altra alternativa és permetre permisos seleccionats, de la mateixa manera que RIM ho fa amb BlackBerry. Acabeu amb aplicacions que només funcionen a la meitat perquè us heu denegat els permisos, com BlackBerry. No hi ha un mètode real que no sigui contundent, a part de llegir-ho tot quan instal·leu aquesta aplicació i intentar entendre què demana fer i per què ho demaneu.

Aquí és on arribem tots. Alguns de nosaltres entenem els permisos d’aplicacions més que d’altres, i quan una aplicació fa alguna cosa que no hauria de fer, se sent el crit. Llegiu els permisos. Llegiu els comentaris del mercat. Llegiu Android Central. Quan alguna cosa us faci malament, en podreu sentir.

I una última cosa …

Una nota especial ha d’anar aquí sobre les vulnerabilitats de seguretat. Tots els programes informàtics, i això vol dir que tots els sistemes operatius mòbils també són plens. Quan es trobi una vulnerabilitat que permeti a una aplicació obviar el model de seguretat, Google l’abordarà ràpidament. Això passa i sempre passarà. La rapidesa amb què es produeix aquesta actualització depèn de les persones que facin el vostre telèfon. Es mereixen el crèdit quan ho fan de la manera correcta i el menyspreu quan triguen massa i ho fan malament. Això no serà una cosa que desapareixerà aviat i estem aquí amb vosaltres per trucar a un OEM que no mantingui les coses tan segures i segures com haurien de ser.

Si voleu aprofundir encara més en els permisos d'Android, consulteu la pàgina de desenvolupador de Google que hi apareixen.