Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google pakt apps aan die 'onterecht' gebruikmaken van toegankelijkheidsdiensten

Google heeft e-mails aan ontwikkelaars gestuurd die apps bouwen en daarbij gebruikmaken van Androids toegankelijkheidsdiensten. Volgens het bedrijf is die toegang alleen bedoeld voor apps die gebruikers met beperkingen helpen. Ook malware gebruikt deze toegang.

In een e-mail, waarvan de tekst onder meer door Android Police is gepubliceerd, roept Google de ontwikkelaar van een 'battery saver'-app op om aan zijn gebruikers uit te leggen waarom hij van accessibility services gebruikmaakt. Doet hij dit niet binnen een periode van 30 dagen, dan wordt zijn app verwijderd. Een andere mogelijkheid is het stoppen van het gebruik van de toegankelijkheidsdienst, waarmee bijvoorbeeld de inhoud van een actief scherm afgeroepen kan worden.

Door de bewoordingen blijft in het midden of het voldoende is om uit te leggen waarom die toegang nodig is of dat Google desondanks tot verwijdering over kan gaan, omdat het kan concluderen dat er sprake is van oneigenlijk gebruik van de toegang. Volgens de e-mail moeten ontwikkelaars in de Play Store aangeven of hun app de dienst gebruikt. Volgens Android Police maken legitieme apps, waaronder wachtwoordmanager LastPass, gebruik van deze api en zijn ze ervan afhankelijk.

In analyses van beveiligingsbedrijven kwam de toegankelijkheidsdienst geregeld terug als het ging om Android-malware, bijvoorbeeld bij SpyDealer en clickjacking-malware. De api speelt ook een belangrijke rol in de zogenaamde Cloak and Dagger-aanvallen. Malware gebruikt de api bijvoorbeeld om toegang te krijgen tot gevoelige informatie.

Door Sander van Voorst

Nieuwsredacteur

13-11-2017 • 14:27

69 Linkedin Google+

Reacties (69)

Wijzig sortering
Of ze kunnen misschien iets opzetten waarbij je alleen deze 'elevated' rechten krijgt als je je app door Google laat onderzoeken zoals Apple doet voordat ze in de Play Store komen? Het is toch raar dat er überhaupt malware in de play store staat.

Dat je malafide apps als .apk bestanden kan downloaden snap ik nog, maar via de Play Store mag je verwachten dat er een check op zit, zeker als apps dit soort speciale rechten gebruiken.

Daarnaast hoop ik niet dat ze LastPass dit ontnemen, die gebruikt deze rechten om wachtwoorden in te vullen. Ik weet dat er in Android 8 een speciaal framework hiervoor is, maar voordat 10% van de mensen Android 8 heeft zitten we in 2019.
Er wordt niet gezegd dat er malware in de Play Store staat. Er wordt gezegd dat malware van dezelfde functionaliteit gebruik kan maken. Hier 2 voorbeelden:

[Reactie gewijzigd door AnonymousWP op 13 november 2017 14:39]

Er wordt niet gezegd dat er malware in de Play Store staat. Er wordt gezegd dat malware van dezelfde functionaliteit gebruik kan maken. Hier een voorbeeld: nieuws: Android-malware steelt data uit populaire apps als WhatsApp en Facebook
Dat klopt, hier niet inderaad. Maar er zijn legio voorbeelden dat de 'vrijheid' die Google toestaat op het Android platform ervoor zorgt dat er veel malafide apps via de Play Store vaak aan miljoenen mensen worden verspreid. Hier een artikel van WIRED erover: klik

En dit bericht haakt in op die vrijheid: Google laat alle apps zonder enkele vorm van controle de Toegankelijkheidsopties aanspreken, en vervolgens zijn ze dan verbaasd dat apps deze niet gebruiken waarvoor Google ze ooit bedoeld heeft. Ja, dat had ik je ook kunnen vertellen.

De houding van Google hier is een beetje als een 'Ben jij 18+' melding op een website: totaal nutteloos.

Enkel de laatste maanden begint Google eindelijk de touwtjes wat aan te trekken om gebruikers te beschermen.

Op Android kom je apps tegen die...
... je lockscreen vervangen en reclame toevoegen...
... Whatsapp en FB data uitlezen...
... continu je locatie in de gaten houden...
... je batterij 'saven' door met memory management te kutten...
... met één druk op de knop je geheugen 'opschonen' en allemaal gebruikersbestanden weggooien

De vraag is niet: Waarom installeren mensen dit? Nee, de vraag is: Waarom staat Google in godsnaam toe dat apps hier rechten voor hebben?

Ik kan geen enkele reden verzinnen waarom een app toegang tot RAM management moet hebben. Dat is een taak van het OS, niet van apps.

Je kan niet onder het mom van vrijheid jezelf geen verantwoordelijkheid opleggen.

[Reactie gewijzigd door ApexAlpha op 13 november 2017 14:47]

Ik kan geen enkele reden verzinnen waarom een app toegang tot RAM management moet hebben. Dat is een taak van het OS, niet van apps.
Ik heb extreem beperkte ervaring met daadwerkelijke ontwikkeling met accessibility services (ik ben niet eens een java ontwikkelaar, maar moest wat aanpassingen maken aan een tool voor client in het verleden) en ben aardig zeker dat er geen ram management mogelijkheden zijn. Wat er echter wel is is een API waarmee je de open applicaties kunt uitlezen en afsluiten. Natuurlijk een heel logische API voor accessibility services, want die geven vaak compleet andere interfaces (bijv. braille bar) om met je mobiel om te gaan. En ja, een dergelijke app moet ook het recht hebben om je scherm uit te lezen natuurlijk, en als je dan Whatsapp of FB opent kun je die data uitlezen inderdaad. Niks mis mee. Google maakt het lastig genoeg om accessibility services aan te zetten voor een app dat het toch echt wel duidelijk is dat je iets vreemds aan het doen bent.

En dat is het ding, ik ben erg blij dat de API's in accessibility services, ze maken Android een simpelweg meer open platform en staan me toe dingen te doen die op Apple niet kunnen. Desalniettemin zou ik liever zien dat Google een groter aantal meer specifieke permissies zou maken die 'wat enger dan de rest' zouden zijn. Het is jammer dat apps zoals Cornerfly of Twilight om accessibility services moeten vragen.

[Reactie gewijzigd door David Mulder op 13 november 2017 15:06]

Wat er echter wel is is een API waarmee je de open applicaties kunt uitlezen en afsluiten.
Een groot deel van RAM management is het bepalen wanneer apps afgesloten worden en zo uit het geheugen gegooid worden. Ik snap oprecht niet waarom app A app B moet kunnen afsluiten. Zo iets doet het OS toch?

Het uitlezen voor bijvoorbeeld braille kan ik me voorstellen. Maar dan wel nadat gecontroleerd is door Google of dat ook echt is wat de app doet. En niet zomaar de opties openstellen voor elke app die erom vraagt.

Bij veel apps krijg je een simpele instructie: 'als ik op Volgende klikt opent er een scherm. Druk daar even op het vinkje naast <AppNaam>'. Alsof een gemiddelde consument dat weet wat er goedgekeurd wordt.
Een groot deel van RAM management is het bepalen wanneer apps afgesloten worden en zo uit het geheugen gegooid worden. Ik snap oprecht niet waarom app A app B moet kunnen afsluiten. Zo iets doet het OS toch?
Waarom? Omdat je dus dan een app kunt afsluiten via een andere interface dan het scherm. Of omdat je bijvoorbeeld een scherm hebt wat je open applicaties op een manier toont zodat je het kunt gebruiken zonder dat je fysiek kunt vegen over het scherm.
Het uitlezen voor bijvoorbeeld braille kan ik me voorstellen. Maar dan wel nadat gecontroleerd is door Google of dat ook echt is wat de app doet. En niet zomaar de opties openstellen voor elke app die erom vraagt.
En dat is dan ook nou net het ding. Google heeft het duidelijk een stuk lastiger gemaakt om accessibility services aan te zetten dan normale permissies. De optie dat de gebruiker echt te dom zou zijn om te bedenken dat die app dan bijna alles kan, dat ligt echt bij de gebruiker. Google waarschuwt gewoon expliciet dat een app dan je wachtwoorden kan uitlezen etc.
Waarom? Omdat je dus dan een app kunt afsluiten via een andere interface dan het scherm. Of omdat je bijvoorbeeld een scherm hebt wat je open applicaties op een manier toont zodat je het kunt gebruiken zonder dat je fysiek kunt vegen over het scherm.
Je noemt hier niks dat niet via het OS zou kunnen worden afgehandeld.
'Vegen' is een inputmodule die vervangen kan worden, mits het OS daarin faciliteert.

Jij lijkt je neer te leggen bij wat google nu heeft als oplossing en je gooit vervolgens je handen in de lucht van "Zie je wel, het kan gewoon niet anders!".
Wacht, wat? Hoeveel mensen zijn er die en scherm kunnen gebruiken, maar niet kunnen vegen over een sherm? Een kleine groep mensen die geen precieze fysieke controle hebben over hun armen (bijv. door een spier aandoening). Jij bent dus van mening dat Google en Apple voor iedere specifieke fysieke beperking aparte interfaces zou moeten maken? Het hele idee van accessibility services is dat je een generieke API hebt die extreem veel rechten heeft zodat je bijv. je hele mobiel netjes kunt bedienen via een braille bar.

Alles wat ik met zekerheid kan zeggen is dat de meeste mensen die ik heb gezien met (niet standaard) fysieke beperkingen gebruik maakten van windows en android devices. Want dat is een beetje het ding, Apple heeft VoiceOver en verwacht dat dat alles voor iedereen oplost. Prima product, en ja, je kunt daar braille bars (of hoe die dingen ook officieel heten) op aansluiten, maar ik vermoed dat die integratie met Android simpelweg beter is. Enkel vermoeden omdat ik altijd let op dit soort zaken, maar het nooit zelf heb gebruikt (buiten trainingen om die helpen m'n applicaties meer toegankelijk te maken).

[Reactie gewijzigd door David Mulder op 14 november 2017 15:42]

Ik denk dat je me verkeerd snapt. Ze hoeven niet in alles te voorzien, ze moeten die api alleen dieper integreren. Dus niet een losse app die 'van buitenaf' alles mag doen. Het zou een apparte extentie op het UI subsysteem moeten zijn.
Hierbij hebben individuele apps geen weet van hoe hun informatie weergegeven wordt. Ze doen hun ding en de UI (die door het os wordt afgehandelt) koppelt die calls aan de juiste interfaces, zoals bv de code/driver die het braileapparaat aanstuurt.

De beperking die jij ziet wordt enkel veroorzaakt door de keuzes in het ontwerp van het os.
En dat is het ding, ik ben erg blij dat de API's in accessibility services, ze maken Android een simpelweg meer open platform en staan me toe dingen te doen die op Apple niet kunnen.

iOS heeft natuurlijk ook een toegankelijkheids API. Daar kun je ook dingen mee. Je kunt er misschien niet alles mee, maar dat betekent ook dat misbruik zoals in het artikel word voorkomen.
Wat ik me dan afvraag is waar jij blij mee bent wat op iOS niet kan en op Android wel.
Tasker en pushbullet (notification syncing) zou het standaard voorbeeld zijn die accessibility services gebruiken. En natuurlijk LastPass indien je een oude versie van Android gebruikt (op nieuwe versie heeft Google een complete API gemaakt om dit specifiek te supporten)
En ja, een dergelijke app moet ook het recht hebben om je scherm uit te lezen natuurlijk,
Vind ik een drogredenering. Of en hoe dit gebeurt is compleet afhankelijk van hoe het systeem is ontworpen.
Accesibility services zouden zodanig ontworpen kunnen worden dat een app helemaal geen informatie krijgt over de afhandeling van UI events.
Sterker nog, zoiets als accesibility services zou een systeemservice moeten zijn. Als jij die services nodig hebt dan heb je dat meestal voor het hele systeem nodig, niet voor een enkele app. De app zou helemaal niks hoeven te weten over hoe de interface wordt weergegeven.
Blijkbaar is dit 'by design' wel zo bedacht. En dat is een slechte keuze waar dit soort problemen bijna gegarandeert uit voort gaan komen.

Google doet hier aan symptoombestrijding van hun eigen brakke design.
De vraag is waarom ze het eigenlijke probleem niet aanpakken.
Om te beginnen zou ook het recht van een app om internet op te mogen uitgezet moeten kunnen worden.
Elke app die je installeert, zou eenmalig moeten vragen (tenzij je het achteraf weer terugtrekt) of die internet op mag. Net als voor alle andere permissies, zoals camera, microfoon, locatie, enz.
Het past niet meer in een tijd dat alles vol staat van 'veiligheid' hebben dat alle apps klakkeloos internet op gaan zonder de gebruiker toestemming te vragen. Een firewall is een noodzaak voor een modern OS.
En dat was hoe Android inderdaad begon... en toen besloten ze dat alle apps om die permissie vroegen en dat ze het gewoon standaard zouden toestaan :( . Ben het compleet met je eens dat dat super jammer is, maar ik begrijp het ook ergens echt wel. Het mooie is wel dat je nog steeds om de permissie moet vragen, dus alternatieve roms kunnen wel degelijk heel makkelijk apps onderscheiden die het internet op willen.
Dat gaat niet gebeuren omdat dit invloed kan hebben op de advertentie inkomsten van Google.

Ik zag wel dat je bepaalde permissies voor een app achteraf kan uitschakelen, maar alles wat potentieel invloed heeft op de 'bottom line' van Google kan je niet blokkeren.

Er is ooit een beta versie geweest van Android die dit wel kon, maar Google realiseerde zich dat mensen hiermee ook advertenties konden blokkeren. Dat is er toen vliegensvlug uitgehaald.

[Reactie gewijzigd door ArtGod op 13 november 2017 20:46]

De houding van Google hier is een beetje als een 'Ben jij 18+' melding op een website: totaal nutteloos.
Maar dat is niet nutteloos. Het is een vrijwaring voor de uitbater, niet een drempel voor de bezoeker.
Vandaar ook de zin: "Je kan niet onder het mom van vrijheid jezelf geen verantwoordelijkheid opleggen. "
Google is al langere tijd bezig om de apps op een hoger niveau te krijgen.
Waarom staat Google in godsnaam toe dat apps hier rechten voor hebben?
Dat doet Google niet, dat doet de gebruiker, die gaat akkoord met de rechten die een app wil. Google zorgt er alleen voor dat er om bepaalde rechten gevraagd kan worden door een app, logisch, want er zijn zat legitieme redenen voor te bedenken dat een app verregaande rechten nodig heeft.
Dat doet Google niet, dat doet de gebruiker, die gaat akkoord met de rechten die een app wil.
Met alle respect, jij denkt nu als een techneut. Denk eens aan iemand in je omgeving (je moeder, je oma) die géén ICT kennis hebben en een Android telefoon of tablet gebruiken. Keuren die, bewust, weloverwogen rechten goed waar apps om vragen?

Nee, hè. De gemiddelde gebruiker drukt gewoon op 'Ja'. Je kan deze verantwoordelijkheid niet bij de (gemiddelde!) gebruiker leggen. Dat is gewoon vragen om problemen.

Ik zal je even vertellen welke ervaring mijn Oma had met een Samsung tablet dat ze ergens gratis bij kreeg.

Ze vond het ding prachtig. Binnen een paar dagen zocht ze zelf Youtube filmpjes op, recepten via Allerhande en kon ze e-mails sturen. Dit is iemand die nog nooit een PC heeft gehad.

Binnen 2 maanden had ze een ander Lockscreen op. Eentje met reclame. Er stonden permanent 3 notificaties vast en als ze daar één keer op drukte dan werd het geheugen leeggegooid of de SD kaart 'opgeruimd'. Ook stonden er apps op die continu op de achtergrond draaiden. Hierdoor was de tablet iedere leeg als mijn oma die uit de kast pakte. AVG gaf om te dag een melding dat er mogelijk virussen op aanwezig waren. Ze schrok zich rot en durfde het niet meer te gebruiken tot ze mij belde.

Ze. Had. Geen. Idee.

Geen idee waarom die dingen er waren, hoe ze erop kwamen of wat ze doen. Als mijn oma een pop-up krijgt met de tekst: U moet nu op Ja klikken!'. Dan doet ze dat.

Na een paar keer terug te gaan en geprobeerd uit te leggen dat ze niet zomaar ergens op moet klikken heb ik het opgegeven. Mijn oma was erg teleurgesteld want ze vond het erg leuk.

Samen met de familie hebben wij een iPad aangeschaft.

Dit ding werkt nu al een jaar perfect. Nog nooit reclame op lockscreen, nog nooit meldingen van virussen, nog nooit apps die geheugen gingen 'opschonen', nog nooit een lege batterij na 3 dagen in de kast.

Google klaagt dat apps de rechten misbruiken. Apple geeft ze de rechten niet.

Welke is nou beter voor de gemiddelde consument?
Als de gemiddelde consument te lui is om 2 regels text te lezen voor ze ergens op klikken, dan is dat wat mij betreft hun probleem.

Laat ze een paar keer tegen die muur lopen. Op den duur leert men
wel bij.

Oh, en een oma valt bij mij niet onder "de gemiddelde consument"

"If you make a program fool-proof, someone will just invent a better fool."
Als oma de app zou weigeren dan had ze niet met haar kleinkinderen kunnen appen.
Wat denk je dat oma doet?
De gemiddelde consument leest de tekst van een gemiddelde advertentie die zogenaamd waarschuwt voor het één of andere probleem. Dat probleem zou op te lossen zijn door op de knop te drukken, dus doen ze dat.
En geen enkele app waarschuwt dat het je lockscreen, geheugen of opslag verneukt. Dat ze kunnen doen doordat ze om onnodige permissies vragen is iets dat de gemiddelde gebruiker niet kan beoordelen (en wat zijn onnodige permissies voor een virusscanner?).

Voor iemand zonder meer dan gemiddelde kennis s het onderscheid tussen een valide systeemmelding en een malafide pop-up nauwelijks te maken. Zolang ontwikkelaars arrogant alle schuld aan 'domme' gebruikers geven zal er nooit iets verbeteren.
Jij lijkt je quote te zien als een excuus om iets niet foolproof te hoeven maken omdat er altijd wel iemand is die iets stoms doet wat je niet hebt voorzien. Je hoeft iets niet foolproof te maken voor de 'best fool' maar wel voor de 'average fool'.
Met alle respect, jij denkt nu als een techneut.
Ik snap wat je bedoeld, maar zo is het nu eenmaal (dat de gebruiker de rechten toestaat en niet Google, dat is wat jij beweerde). Wat moet Google dan, die rechten niet beschikbaar stellen voor apps zodat er geen apps worden gemaakt die die rechten simpelweg nodig hebben?

Je veel te lange verhaal is er 1 van onkunde met apparatuur, je oma doet er beter aan zich enigszins te verdiepen in de materie. Je haalt toch ook eerst je rijbewijs en dan pas een auto. Als we van het niveau van je oma uit moeten gaan dan mogen apps dus niks meer kunnen...
Wat moet Google dan, die rechten niet beschikbaar stellen voor apps zodat er geen apps worden gemaakt die die rechten simpelweg nodig hebben?
Bijvoorbeeld ja. Zoals iOS dit doet. Op iOS kun je inderdaad niet je lockscreen vervangen, andere apps uitlezen, apps uit memory gooien, bestanden verwijderen (buiten je eigen app). Gaat prima voor 99% van de mensen.

Het zou beter zijn als Google dit ook zou doen om misbruik te voorkomen en dan voor de andere 1% mensen die wel bewust hiermee omgaan een "power-user" mode beschikbaar stellen die via ADB gestart kan worden (om een drempel op te werpen).
Je veel te lange verhaal is er 1 van onkunde met apparatuur, je oma doet er beter aan zich enigszins te verdiepen in de materie. Je haalt toch ook eerst je rijbewijs en dan pas een auto. Als we van het niveau van je oma uit moeten gaan dan mogen apps dus niks meer kunnen...
Het niveau van gebruik van de tablet door de oma is op het niveau van een rijbewijs: Ze weet de apps te vinden en ze weet de apps te gebruiken. Wat jij van de oma verlangt is dat ze kennis heeft op het niveau van een automonteur: dat ze alle specs van de benzine checkt voordat ze tankt en dat ze alle specs van de motorolie, remolie, etc. weet en een gedetailleerde werkorder kan geven wanneer de auto voor een onderhoudsbeurt naar de garage moet.
Jaa leuk, laten we een algemeen voorbeeld op detailniveau gaan ontleden. Heeft oma wel de verkeersregels geleerd dan? Of de regels omtrent uitstekende lading en vervoer chemische stoffen en het gebruik van rubbermatten onder lading die zelf te weinig wrijving heeft? Heeft ze ervaring met een caravan of alleen met een aanhangertje of uberhaupt nooit een trekhaak gezien?

Wat ik verlang is dat ze de verkeersborden leest en begrijpt voordat ze een straat inrijdt. Meer niet. Althans verlang... ze moet het zelf weten, maar dan ook niet klagen als de boel niet goed werkt. Ze kan gelukkig geen slachtoffers maken zoals met een auto.

[Reactie gewijzigd door Aikon op 14 november 2017 09:15]

Wat ik verlang is dat ze de verkeersborden leest en begrijpt voordat ze een straat inrijdt. Meer niet. Althans verlang... ze moet het zelf weten, maar dan ook niet klagen als de boel niet goed werkt. Ze kan gelukkig geen slachtoffers maken zoals met een auto.
Juist! En op dat niveau kan ze uitstekend met de tablet overweg.
En zodra iemand gaat beginnen met nep-verkeersborden die mensen die de snelweg op willen naar de McDonalds sturen, zal ze samen met de rest van Nederland veel vaker langs McDonalds rijden.
Tja door Apple’s iOS is het nu minor meer normaal dat apps eerst toegang moeten vragen. Maar toch vreemd hoe anders de pc wereld eruit ziet. Installeer een programma en dat kan gelijk overal bij! En blijkbaar apps ook op Android.
Ehh, sinds Android 6 vragen applicaties ook aan de gebruiker of de desbetreffende applicatie toegang mag hebben tot functie x, y en z. Dit werkt voor zowel buiten de Play Store om als via de Play Store: reviews: Android 6.0 Marshmallow: langere accuduur en meer controle
Windows doet al jaren niet anders en dat is nooit een probleem geweest. Ik vind beide systemen (Android, iOS) redelijk gesloten voor de gebruiker. PC's zijn vergeleken met smartphones een grote zandbak waarin je kunt doen en laten wat je wil. Biedt gewoon de keuze zou ik zeggen. Biedt een optie voor jan met de foon en laat de geavanceerde gebruiker de beperkingen opheffen indien nodig. Wel met de kanttekening "als je het verneukt, los het lekker op". Beste van alle werelden toch?
Op Android kom je apps tegen die...
... je lockscreen vervangen en reclame toevoegen...
... Whatsapp en FB data uitlezen...
... continu je locatie in de gaten houden...
... je batterij 'saven' door met memory management te kutten...
... met één druk op de knop je geheugen 'opschonen' en allemaal gebruikersbestanden weggooien
Dat is deels ook de schuld van de gebruikers: daar zijn er nu eenmaal genoeg van die niet kunnen slapen tot dat alle achtergrond apps afgesloten zijn, of die heilig geloven dat een app hun smartphone weer snel kan maken, terwijl het eigenlijk komt door te weinig ram. Daar spelen malafide app programmeurs vervolgens weer handig op in.

Google zou inderdaad wel wat strenger op mogen treden, maar tegen stupiditeit valt nu eenmaal niks te doen.
Google zou inderdaad wel wat strenger op mogen treden, maar tegen stupiditeit valt nu eenmaal niks te doen.
Tegen de arrogantie van mensen die iedereen die niet hun specialistische kennis hebben stupide vinden helaas ook niet. Het probleem zal dus nog wel even blijven bestaan.
Er is wel Mallware die er gebruik van maakt: Tostamigo, die zat in enkele apps zoals Smart AppLocker. 1 van die apps was meer dan 500.000 keer gedownload.

Zie http://blog.trendmicro.co...ware-single-attack-chain/
sinds de aller eerste telefoon (g1) heb ik android telefoons in gebruik, maar nu, 10jr verder ... ga ik de swithc maken; beetje moe van het eindeloos flashen/rom/patchen zoeken etc. Krijg sterk de indruk dat apple hun zaken op gebied van stabiliteit en support toch wel beter geregeld heeft. Dat ROM-frotten was leuk ~5jr terug - heden dag spendeer tijd liever aan iets anders :+ ... wordt ik nu een luie tweaker:? (nofi)
Dat is ook veel minder nodig, zoals anderen zeggen, kun je nu zelf rechten aan en uitzetten vanaf Android 6 en ook andere zaken (zoals VPN firewall) werken nu goed zonder dat je moet rooten.
Het is niet eenvoudig om malware automatisch te herkennen. Een fotobewerkings app zal bijvoorbeeld toegang hebben tot je Gallery, bestanden kunnen lezen en wegschrijven. Als er een inlog functie zit om een account aan te maken zal de app ook internet toegang willen hebben, en een device identifier willen lezen.

Met deze set acties kun je ook prima een een app maken die je foto's doorzoekt naar foto's van credit cards en deze informatie naar een server uploadt. Deze app kun je zelfs verbergen in een foto editor.

Het is dus niet mogelijk om enkel naar de API calls van een app te kijken, om te zien wat deze doet moet je de app echt uit elkaar trekken en de code goed analyseren. Een computer is daar over het algemeen vrij slecht in, omdat je door de low-level instructies een groter geheel moet kunnen zien.

Voor een mens kost het analyseren van een relatief simpele app al snel een volle werkweek. Wil je een snelle update uitrollen voor je app, dan kun je niet zomaar 7 dagen wachten tot je update eindelijk live gaat. Daarnaast staan er zo veel apps in de Play Store dat menselijke controle voor al deze apps niet realistisch is.
Google zou rond deze tijd miljoenen apps verwijderen die geen privacy policy hadden en toch toegang vroegen tot gebruikers gegevens. Ik heb er nog niets van gemerkt.

Dus ik vraag mij af of ze wel daadwerkelijk tot verwijderen over gaan.

Ook vind ik het vreemd dat app ontwikkelaars die nepversies of misleidende versies maken die lijken op die van grote merken überhaupt hun account niet gewoon verwijderd wordt. Alleen hun app wordt verwijderd, maar ze kunnen gewoon weer nieuwe apps uitbrengen.

[Reactie gewijzigd door ArtGod op 13 november 2017 20:41]

Hoop niet dat dit invoed heeft op apps zoals Button Remapper , die de API gebruiken voor hmm, nou ja, button remapping.

Ik vond m'n Galaxy S7 redelijk onwerkbaar totdat dingen zoals de back knop op een wat toegankelijkere plaats zitten.

Valt dit dan ook onder 'onterecht' gebruik ?
Kort gezegd: ja. Als het niet gebruikt wordt om gehandicapten betere toegang te geven dan is het in principe illegaal.
De toegankelijkheidsopties worden ook flink gebruikt om te cheaten in spelletjes, bijvoorbeeld door het maken/draaien van macro's.
Ik hoop dat taskmanagers worden ontzien. Ik ben al jarenlang gebruiker van Android en weet dat een taskmanager niet noodzakelijk is. Indien een app crashed vind ik het toch wel makkelijk om met ES Taskmanager direct alle apps te kunnen killen en weer opnieuw te kunnen beginnen. Het gaat in deze toch om gebruikers gemak?

Daarnaast zou Google bij het toelaten in de store al gelijk een dergelijke scan moeten uitvoeren. Google scant inmiddels al dagelijks al mijn apps, en als er iets wordt geconstateerd, dan mogen ze mij informeren.
Eeh, dus in plaats van het fixen van de brakke API's gaat google nu een paar misbruikers aanspreken.
Mag ik dan aannemen dat als je het gewoon niet al te gek maakt dat je de API's mag blijven misbruiken voor eigen gewin?
Dank je wel Google! De onderwereld houdt van jullie!
Wat is er brak aan?
Nou, dat een Accesibility API misbruikt kan worden om rechten op het systeem te verkrijgen waarmee privacygevoellige informatie kan worden ingewonnen.
Lijkt me in de basis al brak.

Heb je het laatste paragraaf van dit artiekel niet gelezen dan?

Zo lees ik voor de cloak&dagger aanval het volgende:
Attacks that abuse “accessibility service” permission:
  • Unconstrained keystroke recording, including passwords. According to the documentation, this should not be possible (See "security note" here)
  • Security PIN stealing
  • Device unlock through PIN injection + perform arbitrary actions while keeping the screen off!
  • Stealing two-factor authentication tokens (SMS-based, Google Authenticator, and other app-based tokens)
  • Ad hijacking
  • Web exploration
Lijkt me dus evident dat die API brak is als het zulke aanvallen mogelijk maakt.

[Reactie gewijzigd door koelpasta op 13 november 2017 15:51]

... Hoe verwacht jij dat echte accessibility services werken zonder de inhoud van je scherm te kunnen zien? Misschien eerst een keertje wat research doen voor je zo'n opmerkingen maakt.
Hoe kan een GUI werken zonder te weten wat er gerenderd wordt?
Dat probleem is dus niet uniek aan accesibility services.

De accesibility service is in feite een stukje UI.
Deze problemen betekenen gewoon dat die API verkeerd is uitgedacht (waarschijnlijk als een achterafje dat niet echt goed integreert met de GUI o.i.d.)
Als je deze aanvallen niet kunt uitvoeren op de gewone GUI maar wel via deze extentie op de GUI dan is er iets misgegaan in het ontwerp.

Een ander diepgeworteld probleem met android is dat je als gebruiker geen macht hebt om apps de toegang tot services te blokkeren. Daardoor krijg je veel gebruikers die er niet naar kijken en daarom is het bijvoorbeeld de gewoonste zaak van de wereld geworden dat elke app je contactlijst leegtrekt.

Hier lijkt google de problemen niet bij de bron aan te pakken (de API fixen zodat het niet misbruikt kan worden) en in plaats daarvan symtoombestrijding toe te passen. Daarbij bepaalt google zelf wat ze als symptoom zien en ze laten dus een hoop andere inherente privacyproblemen links liggen (omdat het in hun voordeel is, neem ik aan).
Onder de meeste omstandigheden hoort een app geen toegang te hebben tot vensters van andere apps, dus dat wordt niet toegestaan. Dat lijkt me gewoon goede beveiliging voor mobile apps. Toegankelijkheidsservices kunnen echter niet werken zonder dat soort toegang. Ze hadden natuurlijk kunnen zeggen "service x heeft toegang tot inputvelden met type wachtwoord" enzo, maar op deze manier is het extensible en kunnen mensen dus zelf nieuwe dingen verzinnen om eventueel het leven van mensen met een handicap makkelijker te maken.

En wat je zegt over permissies is al 2 jaar niet meer het geval.
Toegankelijkheidsservices kunnen echter niet werken zonder dat soort toegang.
Snap het nog steeds niet. Waarom moeten toegankelijkheidsservices meer rechten hebben? Hoezo moeten ze de UI van andere apps kunnen benaderen? Kan toch allemaal door een UI manager worden gedaan ofzo? Dat ding dus dat normaalgesproken de UI renderd die dan gewoon een aangepaste UI doet, bijvoorbeeld door text via een tts te laten lopen. Daar heb je volgens mij allemaal geen enge cross-memory zooi voor nodig.

[Reactie gewijzigd door koelpasta op 14 november 2017 14:45]

"Die dan gewoon een aangepaste UI doet"...? Ik denk echt dat je het niet snapt ofzo...
Natuurlijk heeft een TTS app, password manager of voice control app toegang nodig tot wat er op het scherm staat. En natuurlijk heeft een hulpmiddel om mensen het scherm op eenvoudigere wijze te laten ontgrendelen toegang nodig om, je raadt het, het scherm te ontgrendelen. Die apps kunnen gewoon niet functioneren zonder dat soort rechten.
Het is ook niet cross-memory trouwens.

[Reactie gewijzigd door RobinJ1995 op 14 november 2017 15:00]

En natuurlijk heeft een hulpmiddel om mensen het scherm op eenvoudigere wijze te laten ontgrendelen toegang nodig om, je raadt het, het scherm te ontgrendelen.
Zo'n app is echt niet anders dan de normale UI die je laat unlocken. Gezien vanuit het systeem dan. Het is dan gewoon een variant op het normale ontgrendelscherm.

Jij lijkt steeds te denken dat die accesibility services 'over' je systeem moeten liggen. Ik ben sterk van mening dat het in het systeem geintegreerd hoort te worden waarbij gelijk alle hierboven genoemde securityproblemen niet meer bestaan.
Het is ook niet cross-memory trouwens.
Dan zou er, zoals ik het lees, ook geen probleem zijn geweest. De accesibility service biedt blijkbaar de mogelijkheid om de content van diverse apps uit te lezen en dat terwijl die apps in een eigen afgeschermd geheugengebied draaien.
Snap het dan... het enige verschil is dat in plaats van het enkel "intern" te houden de accessibility API net er voor zorgt zodat derde partijen ook gewoon gebruik kunnen maken van die speciale functionaliteiten en toegankelijkheidsservices dus niet beperkt zijn tot wat het OS out of the box ondersteund.

En de inhoud van het scherm kunnen lezen heeft helemaal nikms te maken met "cross-memory"... Het enige waar het hier om lijkt te gaan is dat jij vindt dat zo'n API enkel intern mag zijn, en niet toegankelijk voor derde partijen. Daar ben ik het geheel mee oneens.
het enige verschil is dat in plaats van het enkel "intern" te houden de accessibility API net er voor zorgt zodat derde partijen ook gewoon gebruik kunnen maken van die speciale functionaliteiten en toegankelijkheidsservices dus niet beperkt zijn tot wat het OS out of the box ondersteund.
Nee, dat stukje API kan gewoon geexposed worden voor 3rd party developers. Aleen wordt het dan moeilijker te misbruiken omdat het os de boel kan reguleren.
Je krijgt dan geen apps die altijd alles kunnen en mogen, je krijgt dat die app dat netjes via het OS doet.
En de inhoud van het scherm kunnen lezen heeft helemaal nikms te maken met "cross-memory"...
Wel als je een app toestaat over processen heen informatie in te winnen.
Het enige waar het hier om lijkt te gaan is dat jij vindt dat zo'n API enkel intern mag zijn, en niet toegankelijk voor derde partijen. Daar ben ik het geheel mee oneens.
Ik zeg dus helemaal niet dat het niet toegankelijk mag zijn voor andere partijen.
Dit gaat alleen over hoe die services geimplementeerd worden.
Nu gaat het als het ware 'buitenom'. Dit maakt het noodzakelijk dat de app die de speciale interface mogelijk maakt vanuit app-land toegang krijgt tot stukjes van andere apps. Die toegang hoeft helemaal niet op dat nivo plaats te vinden.

Verder hoef je ook niet direct toegang te hebben tot het scherm. Het os heeft dat hele scherm in abstracte vorm in geheugen staan. Je kunt volgens mij alle accesibility regelen via die abstracte hierarchie in het os zelf. Daar kan je direct een textbox omruilen voor een weergave voor een brailleapparaat (dat door een 3e partij wordt geleverd).

Door deze scheiding te maken zullen apps niet meer zomaar accesibility services tussen neus en lippen door kunnen aanzetten. De beperkte gebruiker zal dan een speciaal soort systeemextentie los moeten installeren in plaats van de gewoonlijke app. Dat is verder niet anders dan een gewone app alleen staat het wel los van alle normale apps. Gewone gebruikes zullen deze specifieke software niet hoeven te installeren en dat kan vervolgens dus ook geblokkeerd worden in normale apps.

Deze speciale systeemextentie heeft vervolgens het voordeel dat het via het os precies kan zien wat het os te renderen krijgt en daar de nodige acties op kunnen ondernemen. Er is op dat nivo geen noodzaak meer om van bovenaf 'in te breken' op de UI van andere apps. Het OS heeft die informatie al.
Ik zie wat je bedoelt, maar niet hoe dat nou helemaal anders is... Het is sowieso al "langs het OS", dus sorry maar wat je daar over zegt is dikke onzin. Als een toegankelijkheidsapp een tekstveld kan "vervangen", hoe is dat dan beter? Op elke OS ooit werken toegankelijkheidsservicest trouwens ook gewoon op deze manier hoor, het is enkel omdat het mobile apps zijn dat er uberhaupt een speciale API voor nodig is.

Visuele toestanden kunnen al via instellingen "in het OS", maar als een toegankelijkheids-app plots componenten in andere apps gehaal kan vervangen, dan hebben we pas een probleem (zowel voor de developers van andere apps die dat nooit allemaal kan voorzien, als voor de beveiliging van het systeem).

Wat je beschrijft over "losse systeemextensie"... dat *is* de app. De gebruiker moet nog steeds de teogankelijkheids-API manueel aanzetten voor een app alvorens deze iets met deze APIs kan doen. Het heeft echt geen zin om een speciaal soort "app" hiervoor te verzinnen, dit is namelijk waarom we uberhaupt een systeem met permissies hebben.
Visuele toestanden kunnen al via instellingen "in het OS", maar als een toegankelijkheids-app plots componenten in andere apps gehaal kan vervangen, hoe is dat dan beter?
Het ging me niet persee om vervangen. Het scherm en een braile-apparaat kunnen prima tegelijk worden aangestuurt door de UI. En tekst input kan prima naast een voice recognition engine draaien.
Het door mij bedoelde systeemcomponent ziet er voor het systeem precies zo uit als elk ander UI component, alleen wordt er dan bijvoorbeeld niet naar het scherm gerenderd maar naar een ander apparaat (of mischien wel scherm maar in ander font, of whatever). Daarmee hoeft er geen rare weg buitenom meer te worden gefaciliteerd door het os. De usability extention is dan werkelijk een stukje OS geworden. Je voorkomt daarmee o.a. dat een normale app zich rechten toe kan eigenen die het nooit zou mogen hebben. Ook vergemakkelijk je de werking van de systeemextentie omdat deze nauwer met het OS is verbonden.

Maar dit is slechts een voorbeeld van hoe het mogelijk anders zou kunnen worden opgelost.
Waar het mij vooral om gaat is dat een app niet zomaar actief de andere apps zou mogen afstruinen op zoek naar UI elementen waar het zich aan kan binden.
Het zou het OS moeten zijn die (in het geval van weergave) de usability extentie zou moeten aanroepen als er iets te laten zien valt. In dat geval is er een gerichte informatiestroom die beter te beheersen valt.
Wat je beschrijft over "losse systeemextensie"... dat *is* de app.
Nee, die app is een hack bovenop het systeem. Het systeem wordt niet echt ge-extend. Een app krijgt vanuit user context rechten om met het OS te klooien.
Het heeft echt geen zin om een speciaal soort "app" hiervoor te verzinnen, dit is namelijk waarom we uberhaupt een systeem met permissies hebben.
Dat is nogal kort door de bocht.
Een OS bestaat uit vele stukjes 'speciale' software. Denk alleen al aan drivers. Maar er zit een heel zwikje aan subsystemen in je OS die werkelijk niks met wat we 'apps' noemen te maken heeft.
Apps draaien in een heel specifieke context waarbij je eigenlijk wilt voorkomen dat ze vanuit die context veel rechten krijgen op diepere OS lagen.
En dat gaat er dus mis met het usability spul van google. Een dergelijke app moet vergaande rechten hebben om vanuit die usercontext toch de dingen te kunnen doen die het moet doen. En vervolgens kan daar dus ook vanuit userland misbruik van worden gemaakt.
Het zou het OS moeten zijn die (in het geval van weergave) de usability extentie zou moeten aanroepen als er iets te laten zien valt. In dat geval is er een gerichte informatiestroom die beter te beheersen valt.
Je bedoelt hooks. En klopt, is een potentieel mooie extra, maar is lang niet krachtig genoeg volgens mij om alle functionaliteit aan te kunnen bieden die de huidige accessibility API biedt. Ik zeg niet dat ik het niet met je eens ben dat het een mooiere oplossing zou kunnen zijn, maar het zou zeker niet genoeg zijn.
Nee, die app is een hack bovenop het systeem. Het systeem wordt niet echt ge-extend. Een app krijgt vanuit user context rechten om met het OS te klooien.
Het systeem wordt ge-extend door apps. Of je apps nou wilt zien als aparte programma's of als plugins voor Android, dat maakt allemaal niet uit. Het heeft echt geen zin om hier een heel apart soort app/plugin/whatever voor te verzinnen. Het huidige permissie-systeem doet dat net al heel goed. Die hooks zouden mogelijk een mooie uitbreiding zijn, maar lijkt me nog steeds dat het veel logischer is om "apps" (waar je niet per definitie aan moet denken als dingen met een heel eigen UI enzo, dat kunenn dus ook gewoon dingen zijn die hooks/intents ontvangen en daar op reageren) van de juiste permissies gebruik te laten maken.
En vervolgens kan daar dus ook vanuit userland misbruik van worden gemaakt.
Nou kijk, je kan verzinnen wat je wilt om de gebruiker te beschermen, maar dat is het zelfde verhaal als User Account Control in Windows, waar de meeste gebruikers ook gewoon gaan van "wat waarom vraagt dat ding om toestemming... ik zal maar op ja klikken..?" Alles kan misbruikt worden, en als de gebruiker niet iet of wat doorheeft waar die mee bezig is en alle waarschuwingen van "dit is gevaarlijk doe dit niet als je niet zeker bent wat het doet" routinematig wegklikt dan maakt het helemaal niets uit of we voor jouw systeem gaan of hetgene wat er nu is, het zou nog steeds even "onveilig" zijn, maar wel minder krachtig voor mensen die effectief een disability hebben.

Begrijp me niet verkeerd, het huidige accessibility framework is zeker niet perfect! O.a. dat de implementatie van sommige functionaliteit inderdaad letterlijk vereist dat een app over een andere app zijn venster heen gaat tekenen (hoewel daar zeker ook goede legitieme use cases voor zijn, wat waarschijnlijk ook de reden is dat deze permissie niet is beperkt tot accessibility apps), of dat bijvoorbeeld apps als LastPass (wat ook gewoon een legitieme accessibility app is als je het mij vraagt) dingen moet doen als "ik zie dat op dit scherm ergens wachtwoord geschreven staat en ik zie een invoerveld... laat ik mijn kadertje maar tonen." in plaats van te kunnen inhaken op tekstvelden (pre-Android 8 op zijn minst). Maar of het nu architectureel gezien zo slecht is als jij het uitmaakt? Persoonlijk denk ik van niet. Maar waar ik het zeker mee eens kan zijn is dat er nog wel wat werk aan de boeg is.
Dus er is niks brak aan, maar het wordt misbruikt. Ok, zoveel stond al in het artiekel (sic). Dat misbruik willen ze nu iets aan gaan doen. Die rechten hebben sommige apps nu eenmaal nodig, uiteindelijk keuren gebruikers het gebruik v/d rechten goed.
Dus er is niks brak aan, maar het wordt misbruikt.
Als de API niet brak ontworpen was dan had dit misbruik niet kunnen plaatsvinden.
Er kan toch ook geen misbruik worden gemaakt van de normale rendering engine? Waarom wel op deze speciale 'rendering' engine?

Het gaat uiteindelijk gewoon om een stukje User Interface.
Die rechten hebben sommige apps nu eenmaal nodig,
Leg eens uit in welke specifieke gevallen deze functionaliteit niet door het systeem kan worden afgehandelt en het noodzakelijk is dat de app de gevoellige informatie zelf gaat lopen afhandelen?
Misschien dat je je even moet inlezen in waar de accesibility services voor nodig zijn.
Het is bedoeld voor personen met een bepaalde beperking die het ze onmogelijk of erg lastig maakt om met smartphones/ tablets te werken. Er zijn zoveel verschillende soorten beperkingen dat die onmogelijk allemaal binnen de standaard installatie van een OS zijn te ondervangen. In plaats daarvan zijn er dus de accesibility services, die het voor derden mogelijk maken om voor elke beperking een eigen hulpmiddel te maken. Zo'n hulpmiddel kan verschillen van een extra tweak tot een volledige launcher die via een speciale interface (braille, volledig spraakgestuurd, volledig bediend met een blaasrietje voor mensen met een hoge dwarslaesie, etc.) alle functies van het OS moet kunnen bedienen.
Ik snap wel waar het voor nodig is. Het systeem kan daar alsnog een nette interface voor bieden. Maar het zou niet nodig hoeven te zijn dat een app direct toegang heeft tot bv de UI van andere apps. Kan allemaal transparant via het systeem gebeuren zodat de app zelf zich niet bewust is van dat het middels accesibility services wordt 'gerenderd' (met renderen bedoel ik natuurlijk whatever er nodig is, dus TTS, braile, ander contrast, spraak input).
Dan kan je een bepaald hulpmiddel, inclusief eventuele systeemdriver, zelf toevoegen aan het systeem en dan kan het niet meer op deze manier worden misbruikt.
Wanneer je bv. WhatsApp via een andere interface wilt kunnen gebruiken, zal je die interface (in de vorm van een app) toch inzicht moeten geven in wat er in WhatsApp weergegeven wordt en dan moet je die interface ook de mogelijkheid geven om WhatsApp te bedienen.
Zodra je het isoleert, wordt het onbruikbaar, want je hebt geen input en je kunt geen output geven.
Wanneer je bv. WhatsApp via een andere interface wilt kunnen gebruiken, zal je die interface (in de vorm van een app) toch inzicht moeten geven in wat er in WhatsApp weergegeven wordt en dan moet je die interface ook de mogelijkheid geven om WhatsApp te bedienen.
Nope.
Het systeem is zich al bewust van wat er getekent moet worden. Daar kun je een stukje code hebben dat dan (ook) andere acties onderneemt.
Hoe dan ook hoeft whatsapp geen toegang te hebben tot de accesibility service. Het systeem handelt dat af op de achtergrond en doet dan de dingen die gewenst zijn, zoals TTS, etc.
Zodra je het isoleert, wordt het onbruikbaar, want je hebt geen input en je kunt geen output geven.
Nogmaals, het OS kan dit allemaal al, alleen is zo ingesteld dat de normale UI wordt 'weergegeven'. En die UI engine is gewoon te vervangen door whatever je maar wilt. Het zijn allemaal abstracties waar je een input veld gewoon kunt vervangen door een voice recognition call.
Er hoeft dus helemaal geen apparte app met enge rechten aan te pas komen als je dit via het OS extend.

Nogmaals, wat jij denkt dat er moet gebeuren is enkel het gevolg van hoe het nu door google is ontworpen. Er zijn mijns inziens betere manieren om usability services te implementeren.
Hoe zie je het dan?
Stel ik wil de berichten van WhatsApp op een brailleregel weergegeven krijgen. Dan gebruik ik een app om via de usability services WhatsApp uit te lezen en de tekst naar de brailleregel te schrijven. Met een braille toetsenbordje kan ik dan tekst typen, die door de app in WhatsApp wordt ingevoerd en verzonden. Dat kun je doen in de vorm van een app, een driver of een UI engine, maar je hebt altijd iets van een anderen partij waar in- en output doorheen gaat en wat bepaalde acties uit moet kunnen voeren.
Je input en output wordt al afgehandelt door het systeem. En dat stukje kan worden aangevuld met zoiets als braile i/o .
De app heeft niks door en voor het systeem is het een normaal stukje UI, net als andere stukjes UI zoals een tekstveld.

Het hele punt is dat als het OS een textbox kan tekenen dat het dan ook een braile-apparaat kan aansturen.
En als het text van een inputbox kan accepteren dat het ook tekst via spraak kan accepteren.
En dat zonder een app die enge dingen doet.
Ik zie niet in hoe dat mogelijk is wanneer het systeem niet op voorhand bekend is met elke mogelijke vorm van in- en output. Maar ik ben dan ook geen specialist op het gebied van OS engineering.
Het os hoeft dat niet te weten. Het os heeft een regeltje tekst (van de app gekregen) en hoeft alleen te weten waar het de die tekst heen moet sturen (bv braileapparaat ipv naar de tekst-renderer).
Jij kunt dat stukje dan uitbreiden met eigen hulpmiddelen.

En dat geldt ook voor input.

Usability services grijpen inderdaad diep in op deUI.
En daarom moet die koppeling dieper in het systeem plaatsvinden en niet via een (vanuit security gezien) gevaarlijke omweg.

Nogmaals, dit is een designkeuze geweest bij google.
Ik zie het verschil niet.
De output gaat nog steeds via een door derden gemaakt stukje software naar het outputapparaat, want het OS heeft geen standaard drivers voor alle verschillende soorten output devices.
Het probleem blijft dat een kwaadwillig stukje software zich bij het OS voor kan doen als een bonafide app die als driver voor een output device dient, terwijl het de output voor andere zaken gebeurt. Op dezelfde manier kan de app zich voordoen als driver van een input device en input aan het OS doorgeven waar de gebruiker geen weet van heeft.
En of je dat nu linksom of rechtsom mogelijk maakt, zodra je het mogelijk maakt om mensen met een beperking via oplossingen van derden gebruik te laten maken van je OS, blijf je het probleem houden dat mal-ware zich voor doet als een dergelijke 'oplossing' en dingen buiten het zicht van de gebruiker doet. Een mogelijke oplossing daarvoor zou kunnen zijn door aanbieders van dergelijke oplossingen te certificeren en accesibility services, in wat voor form dan ook, alleen beschikbaar te stellen voor apps met een dergelijk certificaat. Maar dan moet de app afdeling van Google overuren draaien.
Het probleem blijft dat een kwaadwillig stukje software zich bij het OS voor kan doen als een bonafide app die als driver voor een output device dient,
Dat probleem had je al, alleen klotst het probleem over naar gewone apps. Het hier beschreven probleem is dat normale apps die niks met usability te maken hebben toch zomaar vanuit userland bij accesibility faciliteiten kunnen komen (middels misleiding, domme gebruikers, etc).
Een mogelijke oplossing daarvoor zou kunnen zijn door aanbieders van dergelijke oplossingen te certificeren en accesibility services, in wat voor form dan ook, alleen beschikbaar te stellen voor apps met een dergelijk certificaat.
Ja, zoiets inderdaad. En daarbij kun je dus ook toestaan dat die apps meer in het systeem geintegreerd zitten zodat ze geen rare fratsen uit hoeven te halen vanuit userland.
Maar dan moet de app afdeling van Google overuren draaien.
Ik denk dat dat wel meevalt.Hoeveel zinnige nieuwe programma's die accesibility services bieden komen er per maand uit? Hoe vaak hebben mensen met een beperking behoefte aan een nieuw systeem dat weer totaal anders werkt?
Dit is volgens mij een markt die niet gebaat is bij een eindeloze worst aan bijna niet te onderschieden apps, zoals dat in de app wereld gebruikelijk is.
Ik neem aan dat er een relatief beperkte hoeveelheid echt goede usability apps bestaan en dat is denk ik nog best te overzien qua controle.
Grote Broer kijkt naar je!

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True