Google beperkt permissies voor gesprekken en sms tot standaardapps

Google heeft een nieuw Play Store-beleid geïntroduceerd, waarmee het toegang tot de gespreksgeschiedenis en sms-berichten door Android-apps aan banden legt. In de toekomst kunnen alleen nog standaardapps toegang tot deze gegevens verkrijgen.

In zijn aankondiging legt Google uit dat het daarmee doelt op apps die gebruikers zelf als standaardapp hebben ingesteld, bijvoorbeeld voor het voeren van telefoongesprekken of het sturen van sms-berichten. Tot nu toe was het mogelijk dat verschillende apps om deze permissies vroegen. Ontwikkelaars hebben negentig dagen de tijd om hun apps aan de beleidswijziging aan te passen. Google kondigt aan dat het in de komende maanden met 'aanvullende controls' zal komen.

In een apart document meldt de zoekgigant dat ontwikkelaars alleen van de sms- en 'call log'-permissies gebruik moeten maken als dit nodig is voor de hoofdfunctionaliteit van hun app. Dat betekent dat de app zonder deze permissie niet zou werken. Er zijn wel uitzonderingen, bijvoorbeeld als er geen andere mogelijkheden bestaan om aan de gewenste gegevens te komen. Zo mag een synchronisatieapp bijvoorbeeld wel sms-berichten lezen en ontvangen.

In andere gevallen is het niet toegestaan, zoals bij accountverificatie, het sturen van uitnodigingen of het delen van materiaal. Op de eerdergenoemde pagina vermeldt Google ook alternatieve methodes die ontwikkelaars kunnen gebruiken.

Reacties (72)

[LightPhoenix]

Aan de ene kant natuurlijk een goede zaak, maar dit vind ik toch wel weer jammer:

In andere gevallen is het niet toegestaan, zoals bij accountverificatie, het sturen van uitnodigingen of het delen van materiaal.

Weer zelf sms codes overtypen in plaats van dat de apps die zelf kunnen lezen. Klein dingetje natuurlijk in vergelijking met de privacy die je wint, maar toch.

[P1nGu1n]

Dat is al mogelijk op manieren die privacy meer waarborgen, en die blijven gewoon mogelijk:

• Een Android functie voor telefoonnummervalidatie die de app een token geeft van 11 karakters, als Android die code in een SMS ontdekt krijg de app daar een seintje van. Meer info: XDA
• Met de SMS verification API van Google Play Services

Voor beide manieren heeft een app géén SMS permissie nodig, het framework (Android of Play Services) handelt dit af.

[Reactie gewijzigd door P1nGu1n op 25 juli 2024 22:44]

[LightPhoenix]

Dat is erg nuttige info die wellicht ook in het artikel zelf genoemd zou kunnen worden
Op die manier zijn er inderdaad voor devs genoeg opties voor alternatieve methoden. Wel hoop ik dan weer dat het niet direct door de GPS hoeft te worden afgehandeld, aangezien niet iedereen die op zijn telefoon wil hebben.

[84hannes]

9 oktober 2018 10:29
Dat is erg nuttige info die wellicht ook in het artikel zelf genoemd zou kunnen worden

@duqu

[duqu]

Heb een zinnetje aan het einde toegevoegd voor de duidelijkheid.

[GertMenkel]

Die eerste functie werkt alleen op Android 8 en hoger (API 26), die tweede maakt je app weer afhankelijk van de Google Play services.

Voor nieuwe devices en oude devices met play services is dit heel leuk, maar als je een app hebt die je zowel in Europa als China wilt verspreiden moet je speciale Google Play code hiervoor gaan maken.

Daarnaast is de constante afhankelijkheid van Google Play Services zwaar irritant aangezien zo meer apps niet gaan werken op een ont-Googlede telefoon.

[trenjeska]

maar ik wil juist dat mijn app werkt ZONDER afhankelijkheid van google play services.

[Wildfire]

Hmmm was toch wel erg handig bij bv. WhatsApp. Plus mijn werkgever is door veel werknemers gevraagd om een dagelijks door ons gebruikte app ook SMS verificatie te laten doen zoals WhatsApp, maar als dit er aan komt dan heeft het geen zin meer om daar tijd in te steken...

[Eagle Creek]

Beetje kind met badwater dit of niet? Ik denk dat die SMS verificatie nog steeds veel waarde heeft, ondanks dat je er iets meer werk aan hebt.

[unglaublich]

Het enige verschil is dat je zelf vanuit je alert de code moet overtikken.
Het zou fijn zijn als verificatiediensten hun berichten niet zouden beginnen met:
"Hallo, dit is een verificatiebericht gestuurd om 09:05, de code is 24 uur geldig en is: ...."
Waarna het bericht in de notificatiebalk wordt afgekapt.

[deadlock2k]

Het lijkt me dat dat de enige goede manier is omdat anders de verificatiecode voor iedereen te lezen is. Dat is zeg maar zo'n beetje de hele reden dat digid ook afstapt van sms. Het is onveilig.

[CivLord]

SMS verificatie is alleen onveilig wanneer ze gericht toegang hebben tot meerdere diensten en/of devices tegelijk en die real-time kunnen misbruiken. Wanneer dat het geval is heb je een veel groter probleem dan alleen verificatie SMS-jes.

[deadlock2k]

Nee, sorry. SMS is altijd onveilig, het SMS-protocol zelf (onversleuteld) en daarnaast de manier waarop mensen met hun toestel omgaan, waardoor diefstal van een toestel genoeg is. MFA met SMS als extra factor is wat mij betreft geen functionele MFA meer, hooguit in combinatie met een extra pincode zoals bij ouderwetse hardtokens ook verplicht was.

[CivLord]

Maar dan moeten ze zich al specifiek op jou gericht hebben. Enkel toevallig je inloggegevens van een site of dienst te hebben gevonden is niet voldoende. Ze moeten gericht je SMS kunnen onderscheppen of op een gestolen telefoon (die in de meeste gevallen beveiligd is) kunnen ontvangen. Dat zijn flinke drempels, die te hoog zijn voor een hacker die een lijst met gebruikersnamen en wachtwoorden bemachtigd heeft.

[deadlock2k]

Waarom maakt het uit of iets gericht is of niet? Daar wordt een inherente bad practice niet opeens good of zelfs maar acceptable practice door.

Ik ken scholen die toegang van docenten tot de leerlingvolgsystemen toestaan met SMS als tweede factor zonder pincode. Enig idee hoe slordig mensen met hun telefoonscherm omgaan? Hoe makkelijk het is om wachtwoorden en gebruikersnamen te ontfutselen aangezien nog steeds maar een marginaal deel van de bevolking zich houdt aan daadwerkelijk willekeurige wachtwoorden voor alles waar ze in kunnen loggen?

Kortom; het is gewoon een niet verwaarloosbaar risico, het blijven gebruiken zorgt ervoor dat het ook niet echt landt dat het geen veilige techniek meer is. Voor meer informatie: https://www.allthingsauth...-least-secure-2fa-method/

[CivLord]

Waarom maakt het uit of iets gericht is of niet? Daar wordt een inherente bad practice niet opeens good of zelfs maar acceptable practice door.

Met gericht bedoel ik dat een crimineel het bewust op jou gemunt moet hebben wil hij SMS verificatie überhaupt kunnen misbruiken.

Wanneer jij hier je gebruikersnaam en wachtwoord voor digID post, dan kan ik daar helemaal niets mee wanneer je SMS verificatie hebt aangezet. Wil ik er wel wat mee kunnen, dan moet ik eerst achter je telefoonnummer komen en een manier vinden om jouw SMS-verkeer te onderscheppen. Of ik moet je fysiek weten te vinden om je telefoon te kunnen jatten (en hopen dat je die niet beveiligd hebt). Dat maakt het uitermate onwaarschijnlijk dat je een willekeurig slachtoffer wordt wanneer je SMS verificatie gebruikt.
Pas wanneer ik weet wie jij bent en ik me specifiek op jou richt, kan ik én achter je gebruikersgegevens komen én je SMS-verkeer onderscheppen. Op het moment dat ik me zo specifiek op jou richt, laat ik me door het wel of niet gebruiken van SMS als verificatie niet tegenhouden en zal ik andere manieren vinden om van jou te krijgen wat ik wil.

[deadlock2k]

Met gericht bedoel ik dat een crimineel het bewust op jou gemunt moet hebben wil hij SMS verificatie überhaupt kunnen misbruiken.

Maar dat doen ze op het moment aan de lopende band. En daarnaast is het eenvoudig andersom redeneren; "We hebben een kwetsbaar apparaat gevonden, laten we daar de user eens van in de gaten gaan houden."

Again: SMS verificatie is bad practice, evenals het geheel of gedeeltelijk weergeven van de inhoud van berichten van praktisch wat voor applicatie dan ook op het lockscreen van je smartphone. Je kan een heleboel blijven roepen over dat het wel heel erg moeilijk wordt allemaal zo, maar dat maakt het niet opeens wel veilig.

[Reactie gewijzigd door deadlock2k op 25 juli 2024 22:44]

[Ed Vertijsment]

Goeie

[2green]

In het artikel staan al wat uitzonderingen, in het document van google nog iets uitgebreider. Mogelijk kun je daar gebruik van maken?

Zou je bijvoorbeeld in jullie app synchronisatie functionaliteit bouwen, dan lijkt het wel te mogen (heb het document alleen doorgeskimmed, zou het wel zelf even verifieren).

Daarnaast zou verificatie ook via de standaard sms app kunnen lopen met een eigen interface of app permissies om sms te lezen voor een bepaalde tijd of doorzetten van sms verificatie berichten naar shared lokatie, etc.

[air2]

Dat kan ook anders opgelost worden. Eindelijk is dit geintroduceert in iOS 12, waar het gewoon in het OS ingebakken zit. Als je een verificatie SMS krijgt kun je direct de waarde plakken (Ik vermoed dat het ergens in de toetsenbord afhandeling zit, maar google zou hiervoor natuurlijk best een apart API kunnen introduceren. Daar zou je niet het recht voor nodig moeten hebben ALLE smsjes te lezen, plus als google hier een nette API voor bied, hoeft het niet per APP gemaakt te worden.

[Veneficus]

Overtypen hoeft niet helemaal. De Google SMS app herkent dit soort codes en geeft meteen een shortcut voor het kopiëren van de code vanuit de notificatiebalk. Plakken en klaar. Natuurlijk wel twee handelingen in plaats van geen, maar je hoeft niet veel handmatig te doen.

[LightPhoenix]

Dan moet je wel weer de Google SMS app installeren. Niet alle ROMs hebben die standaard geinstalleerd staan, vaak juist omdat mensen geen Google alternatieven willen voor AOSP zaken. Daarnaast is het zoals je aangeeft wel degelijk een extra handeling plus dat ik hieronder lees dat het nog lang niet altijd goed gaat met het automatisch herkennen en kopiëren van de codes.

[Martinspire]

Van mij mag dit inderdaad gewoon een aparte permissie zijn. Inkomende berichten lezen voor de komende minuut of iets dergelijks.

[lasharor]

Mogen apps na deze verandering ook geen notificaties meer uitlezen? Ik dacht dat dit vrij recent nog een stuk makkelijker is geworden. Het lijkt mij voldoende voor apps als Whatsapp etc om hiervan gebruik te maken.

[DropjesLover]

Beetje rijkelijk laat in mijn ogen, dat soort fratsen hadden toch gewoon van dag 1 niet toegestaan hoeven te zijn? Of is het zo makkelijk toegankelijk maken van gebruikersdata waardoor Android zo groot/populair is geworden voor telefoonmakers?

Absoluut van de zotte dat ik geen filmpjes in mn standaard gallery-app (genomen foto's en filmpjes) kan afspelen wanneer ik de gallery geen toegang geef tot het maken van telefoontjes
Huawei Honor telefoon...

[Reactie gewijzigd door DropjesLover op 25 juli 2024 22:44]

[MenN]

De reden dat het zo successful geworden is, is natuurlijk het prijskaartje dat Google voor Android vraagt. Waardoor 3e partijen makkelijk met lage marges toestellen kunnen uitbrengen voor een zeer lage prijs.

Met gratis valt moeilijk te concurreren, vraag maar aan Microsoft

[Blokker_1999]

AOSP mag dan wel open en gratis zijn, niemand wil gewoon AOSP in het westen. Iedereen wil die Google apps. En dan ga je als bedrijf al zeer snel aankloppen bij Google om direct ook de nodige support contracten af te sluiten om te helpen bij de integratie.

[prutsger]

Iedereen wil die Google apps.

Ik niet. Bijna alles wat ik nodig heb haal ik wel uit F-Droid, maar een aantal zaken werken gewoon niet zonder de Play Services (push notificaties bijv.).

Met deze wijziging verwacht ik dat straks mijn Pebble via Gadgetbridge geen Phone en SMS permissie meer heeft die wel nodig is voor het weergeven op mijn Pebble. Terwijl dat niet de standaard app is voor SMS want die lees ik met Signal. Niet wenselijk.

[Reactie gewijzigd door prutsger op 25 juli 2024 22:44]

[Luinwethion]

Hopelijk tot dan Google de telefoon permissie, want READ_PHONE_STATE worden door veel apps gebruikt om je telefoon te herkennen via de unieke ID, maar ook om te weten zodra je gebeld wordt dat de app moet dus in pauze gaan.

[Ubartu]

Voor audio gaat dat zeker via een andere methode? Aangezien mijn muziek bijvoorbeeld stopt op het moment dat ik een video start. Zo niet, dan gaat dit nog een irritant gemis worden.

[Luinwethion]

Voor audio wordt dat via een andere manier gedaan, ik weet de ins en outs ook niet exact, maar blijkbaar zou READ_PHONE_STATE wel een belangrijk rol spelen in de afhandeling van telefoon gesprekken als je een app open heb staan die naar een andere status moet (idle, pause, etc).

Maar ik neem het aan dat Google dit allemaal onder controle hebt... Voor gebruikers is het alleen maar beter dat permissies beter geraffineerd worden, het is dan niet de bedoeling om goed om te gaan met het ondergebroken worden door een telefoon gesprek dat een app ook kan telefoneren of weten wie er allemaal gebeld heeft.

[WillySis]

De controle van de playstore op allerhande rechten die helemaal niet nodig zijn voor de werking van een app is slecht (lees afwezig). Daar zou men eigenlijk veel meer op moeten insteken. Bij elke plaatsing van een app de playstore even aangeven welke rechten noodzakelijk en waarom. Een geautomatiseerde controle met een handmatige steekproef is voldoende om de apps een stuk betrouwbaarder te maken.

Het afsluiten van het recht tot de gesprekken en sms heeft ook nadelen. De apps die de inkomende berichten tijdens het rijden automatisch voorlezen, of je in staat stellen om via voicecommando's iemand te bellen of een sms te sturen worden met deze actie flink benadeeld. Voor de verkeersveiligheid is dit dus een zeer slechte zaak.

[Ed Vertijsment]

Steekproef gaat niet werken, de kans dat je gepakt wordt is gewoon te klein en dan dien je hem gewoon opnieuw in.

[WillySis]

Als elk softwarehuis de eerste keer wordt gecontroleerd en softwarehuizen die een keer in de fout zijn gegaan vaker gecontroleerd worden, dan wordt de pakkans groter. Je hoeft ook niet alle rechten even streng te controleren, Toegang tot het geheugen is vrij standaard. voor navigatie-apps is toegang tot de locatie logisch enz.
Opnieuw indienen van een geweigerde app moet altijd leiden tot een controle. Bij herhaaldelijk de mist ingaan kan je de ontwikkelaar eventueel helemaal uitsluiten van de playstore. 100% waterdicht krijg je het niet, maar wel een stuk beter. Apple werkt ook op deze manier en daar zijn toch veel minder problemen door onnodige rechten.

Het alternatief van Google is eigenlijk een soort machtsmisbruik. Zij maken immers de standaard-apps die wel toegang kunnen krijgen.

[monojack]

Toch kan je je ook afvragen of Google hier geen misbruik van haar monopolie maakt. Als grootste advertentiebedrijf sluit het nu andere advertentiebedrijven buiten om data over gebruikers te verzamelen. Google heeft met Android een zeer bizarre situatie gecreëerd.

[Anoniem: 457607]

Eens! Je ziet het wel vaker, eerst zet men in op maximale groei door alles toe te staan. Pas als de groei er is, heeft men ineens last van "principes". Maar op dat moment komen die principes vooral de monopolist goed uit.

Daarom ben ik meer voor het iOS security model: een app mag in principe bijna niets, tenzij je expliciete toestemming verleend.

[ace6717]

Daarom ben ik meer voor het iOS security model: een app mag in principe bijna niets, tenzij je expliciete toestemming verleend.

En bij Android mag een app alles doen zonder toestemming te vragen? Security modellen van Android en iOS zijn gelijkwaardig, maar bij Android zijn er meer beschikbare API's waar je gebruik van kunt maken, dat is het grote verschil. iOS is gewoon veel te gesloten waardoor o.a. innovatie geremd wordt.

[Euronitwit]

Waarom beperkt tot gespreksgeschiedenis en sms-berichten.
Waarom gaat dit ook niet op voor.
Camera
Contacten /Contactpersonen
Agenda
Locatie
etc. maak het zelf maar af.

De toestemming zou per onderdeel voor een bepaald app te regelen moeten zijn.
(Hé Windows 10 mobiel heeft dit al jaren.)

[Luinwethion]

1- je wilt toch meerdere apps toegang geven aan je camera of niet? Bericht gaat over dat alleen de standaard app toegang hebt tot de phone en messages permissies.

2- je kunt gewoon per app permissies aan en uit zetten sinds 6.0.

[Euronitwit]

Helaas moet je het eerst allemaal toestaan om de app te kunnen installeren en kun je het pas later uitzetten.

[Luinwethion]

Nee, zodra de app het nodig heeft krijg je pas een pop-up met de vraag allow of deny.

WhatsApp voert de SMS permissie check bij opstarten, maar de camera en microfoon pas als je een foto of audio bericht wilt sturen.

[Euronitwit]

Kreeg anders op m'n vrouw haar Android telefoon sommige apps niet (goed) geïnstalleerd, zonder eerst alles goed te keuren.

[Luinwethion]

Oké, er is een verschil tussen tijdens installatie en tijdens opstarten.

Tijdens installatie wordt niks met permissies gedaan.

Sommige apps vragen de permissies zodra de app het nodig heeft, zoals Whatsapp. Andere doen toch alles tijdens opstarten.

En dan zijn er apps die niet verder werken als ze bepaalde permissies missen, dan moet je kijken als dat logisch is of niet.

Dat Snapchat niet werkt zonder de camera permissie, lijkt me best wel logisch.

Dat een game niet werkt zonder SMS permissies, dan zou je af kunnen vragen als je deze app echt geïnstalleerd wilt hebben.

Maar sinds 6.0 werkt dus Android net als iOS kwa permission management.

Enige kritiek die ik heb is notificatie, die staat standaard aan in Android voor elke app, dat zou ik graag aangepast zien.

[FreshMaker]

(Hé Windows 10 mobiel heeft dit al jaren.)

Da's ook niet zo moeilijk, als de laatste versie al 2.5 jaar oud is ...
https://nl.wikipedia.org/wiki/Windows_10_Mobile

Komen er nog wel security-patches voor ?

[Euronitwit]

Moet je nagaan hoe vooruitstrevend MS toen al was.

Vorige week nog een grote update binnen gekregen met niet alleen security patches.

[eric.1]

De toestemming zou per onderdeel voor een bepaald app te regelen moeten zijn.

Dat kan ook gewoon?

Je hebt gewoon een lijst met App-permissions waarin je per permissie een app toestemming kan geven of juist niet (of andersom, per app door de gevraagde permissies heenlopen).

[Kiswum]

Als ik een telefoon heb ingesteld, dan controleer ik regelmatig de rechten van alle apps. Je kunt per categorie aangeven of bepaalde apps wel, geen of toestemming krijgen na goedkeuring.

Ik vraag me af of smartwatch apps, straks wel toestemming krijgen om te laten zien wie er belt en welk SMS bericht je binnen krijgt. Dat zijn namelijk apps waarbij ik het wel wil toestaan zodat ik direct op mijn horloge kan zien wie er belt of wat voor bericht ik binnen heb gekregen.
Hetzelfde geldt voor andere BT verbonden producten, zoals mijn autoradio, met toegang tot mijn telefoonboek.

[DigitalExorcist]

Die syncen op een ander niveau toch? Dwz. als ik kijk naar m'n voormalige Garmin Vivofit, dan krijgt die gewoon alle notificaties die ik m'n toestel ontvang binnen, ongeacht het programma/app/soort melding.

M'n Apple Watch krijgt ook gewoon Instagram, Twitter en Snapchat binnen terwijl die apps er niet op staan. Gewoon omdat m'n iPhone die meldingen wel krijgt en deze 1-op-1 doorzet.

Je foon 'pusht' die meldingen, in het geval van een autoradio weet ik het niet zeker. Maar voor notificaties 'pusht' je telefoon de meldingen en 'pulled' je horloge niks.

[Reactie gewijzigd door DigitalExorcist op 25 juli 2024 22:44]

[Kiswum]

Het zou inderdaad kunnen dat zoiets met andere rechten gebeurd, dus via het BT protocol. Dergelijke meldingen moet je (vaak) vooraf activeren, zodat je die notificaties binnen kan krijgen. Mocht je smartwatch de mogelijkheid hebben om te bellen of berichten te versturen, dan zullen dat denk ik extra rechten zijn.

[DigitalExorcist]

Geen idee, maar ik gá er gemakshalve even van uit dat je alleen via de standaard-apps op een smartwatch kunt bellen. Geen idee hoe het met Android Wear, Tizen etc. zit en ik ken niet alle apps van watchOS maar je kunt niet alles 'zomaar' gebruiken.

[Coolstart]

We zitten duidelijk niet in een data privacy tijdperk. Wie kan met het hand op het hart zeggen dat al de data (betaalgeschiedenis, foto, locatie, wifi, auto, watch, alexa..) op uw telefoon niet gebruikt wordt? Door een derde partij, mallware of Google zelf. Ze verdienen op advertenties, niet door hun software. Wat het aannemelijker maakt dat ze op zijn minst ‘iets’ doen.

Dat uw data gedeeld wordt is zeker. Maar ik denk dat niemand echt weet op welke schaal dat juist gebeurd en of die gegevens annoniem zijn of niet. Wat denken jullie, betalen we Google en ‘Free’ apps met onze privacy of niet?

[DigitalExorcist]

Deels. We betalen Google met metadata. Als ik een lijstje moet maken met partijen die ik daarin vertrouw:

1) Apple
2) Microsoft
3) Google
4) Amazon
...
999) Facebook

Vooral omdat Apple verdiend aan zijn diensten (iCloud, iTunes), iAds niet meer als zodanig bestaat behalve in de App Store, en ze privacy nogal hoog in het vaandel hebben staan vaak ten koste van functionaliteit (daarom is Siri ook niet de allerslimste...). Microsoft moet verdienen aan z'n licenties (Office 365, Azure, Windows, Server, etc). maar heeft wel een advertentienetwerk rondom Bing. Google vertrouw ik in die zin wel dat ze metadata verkopen maar niet persoonlijk herleidbare zaken verhandelen.

Dat is meer een gevoel dan wat anders. Amazon moet gewoon spullen verkopen. Dat bedrijf mag ik sowieso niet echt vanwege hoe ze hun werknemers behandelen als grof vuil en elke mogelijke concurrentie zo hard mogelijk uit de business proberen te werken, ook als je verkoopt op Amazon zelf (waarbij Amazon de prijzen monitort en als zij het op basis van populariteit goedkoper kunnen doen door grootschalige inkoop, je als individuele handelaar kansloos bent).

Facebook vertrouw ik daar niet echt meer in. Ja, het basisprincipe klinkt leuk en aardig maar gezien alle miskleunen hoef ik dat niet zo nodig. Ja ik gebruik Facebook zelf ook en ben wel gecharmeerd van het principe zelf maar ik ben terughoudend wat ik erop zet en hóe ik het gebruik.

[StefanJanssen]

Hmm Signal werkt nog zonder de permissions. Maar een gezamenlijke inbox is wel fijn. Valt dit dan buiten de uitzonderingen?

En ze gebruiken ook de SMS ter verificatie. Als ze de inbox mogen gebruiken voor A mag het dan wel voor verificatie?

Erg jammer dit allemaal.

[J-A-J]

Google kondigt aan dat het in de komende maanden met 'aanvullende controls' zal komen.

[NullCrayfish]

En toch is het altijd jammer dat mogelijkheden worden ingeperkt.
Ik had misschien meer gezien in een beter waarschuwingsscherm bij de installatie, mogelijk met motivatie van developer, of strengere toelatingscontroles voor apps.

Neemt niet weg dat deze maatregel een hoop goed zal doen.

[Ed Vertijsment]

Helaas kijkt de gemiddelde gebruiker daar niet naar...

[Luinwethion]

Als Google de.READ_SMS permissie ook blokkeert dan kunnen apps zoals Whatsapp geen auto-login doen zodra je de de bevestiging of 2fa code via sms krijgt.
Sinds Pie heb je met de standaard Android SMS app een optie in de notificatie die een 2fa code herkent en laat je snel alleen die code kopiëren, maar dat werkt soms niet en soms kun je in de app zelf niks plakken.

Ook met de eigen codes van Google werkt het niet, de sms app kopieert ook de G- voor de nummers, en bij login wilt Google alleen de nummers hebben.

[Kiswum]

Dan is het slechts een copy and paste dingetje. Voor Whatsapp hoe je wellicht maar 1x per jaar de code in te voeren omdat je dan een ander toestel in gebruik neemt. Die 6 karakters kun je zelfs handmatig invoeren. Dus daarvoor hoeft die luxe niet te blijven bestaan.

[Chuk]

Goede evolutie, de meeste dubieuze apps die hier toegang tot 'nodig' hebben hebben er meestal geen zaken mee.

[AmigaWolf]

Goede evolutie, de meeste dubieuze apps die hier toegang tot 'nodig' hebben hebben er meestal geen zaken mee.

Nou niet helemaal een goede evolutie, aangezien er ook veel mensen gebruik maakt van gesprek opname App, hoop telefoons hebben dat niet ingebakken, en dat zal dan niet meer werken, en zo zijn er nog meer voorbeelden.

[Unveiled]

[...] waarmee het toegang tot de gespreksgeschiedenis en sms-berichten door Android-apps aan banden legt.

Titel lijkt onvolledig. Als ik dit zo lees, gaat het slechts om de logs.

[AmigaWolf]

Ok, ben benieuwt.

[J-A-J]

Dit lijkt me een hele goede ontwikkeling.

Als je namelijk een korte scan uitvoerd met audit apps of apps met audit mogelijkheden (Malwarebytes als voorbeeld), dan zal je verbaast opkijken van hoeveel apps permissies hebben waarbij je vraagtekens kunt plaatsen of deze apps de betreffende permissies wel nodig hebben.

Met deze doorvoering weer een stap in de goede richting in het oogpunt van cyber security.

[wica]

Waarom zouden een aantal functies aan banden gelegd zijn?
Zou het te maken hebben met dit verhaal? Beetje zoals FB en cambridge.
https://www.wsj.com/artic...sing-to-public-1539017194

[Reactie gewijzigd door wica op 25 juli 2024 22:44]