'Uber-app had toestemming voor schermopname in iOS'

De Uber-app had in iOS de mogelijkheid om schermopnames te maken, een functie waar geen enkele andere app van een derde partij bij zou kunnen. Uber zegt de api nooit gebruikt te hebben en deze te verwijderen.

De ongedocumenteerde functie maakt het mogelijk om schermopnames te maken, zelfs als de app gesloten is. De toestemming heeft betrekking op com.apple.private.allow-explicit-graphics-priority, waarmee ontwikkelaars de framebuffer van een iOS-apparaat kunnen uitlezen en beschrijven, die data over de weergave bevat.

Volgens beveiligingsonderzoeker Will Strafach, een van de ontdekkers van de code, is Uber voor zover bekend de enige partij naast Apple die toestemming heeft de schermopnamefunctie te benaderen. Uber reageert tegenover ZDNet met de melding dat de code gebruikt werd om de rendering op de Apple Watch-app te verbeteren, maar niet meer verbonden is met andere functies in de codebase.

De api zou het mogelijk maken plattegronden op de iPhone of iPad op de achtergrond te renderen en vervolgens te sturen naar de Apple Watch. Uber zou al samen met Apple bezig zijn om de code te verwijderen. Niet bekend is waarom Apple Uber toestemming verleend zou hebben; in het verleden tikte Apple Uber op de vingers wegens strijd met zijn privacyregels.

Reacties (67)

[Infor40]

Extra permissies geven aan een bedrijf dat het toch al vaak niet zo nauw neemt met de regeltjes... fraaie zet Apple...

[supersnathan94]

Als uber daadwerkelijk de code gebruikt voor wat het aangeeft dan zie ik het probleem niet zo. In dit geval lijkt het erop dat dit daadwerkelijk een foutje is aangezien Uber heel netjes een verklaring geeft waarom het die code gebruikt. Dat zal Apple dan ook geverifieerd hebben bij de initiele screening.

[Dutch_CroniC]

In de kop staat "Uber zegt de api nooit gebruikt te hebben en deze te verwijderen."

Maar dan wel een verklaring afgeven hoe ze het wel gebruikt hebben?

[supersnathan94]

Lees dan ook even de rest van het artikel door aangezien daar gewoon staat dat ze aangeven dat de API niet in productie wordt gebruikt.

Uber reageert tegenover ZDNet met de melding dat de code gebruikt werd om de rendering op de Apple Watch-app te verbeteren, maar niet meer verbonden is met andere functies in de codebase.

[Dutch_CroniC]

Ja dus hebben ze de api wel gebruikt...
Het maakt mij niet uit op welke manier.

[supersnathan94]

Dus klopt de kop niet en dan is dit niet de plaats om dat te melden. Dat de schrijver iets interpreteerd betekent niet dat het ook daadwerkelijk zo gezegd is. Dat blijkt ook maar weer als je het statement van Uber zelf bekijkt.

[Dutch_CroniC]

Ik deed geen melding dat de kop niet klopte.
Ik maakte een opmerking over de tegenstrijdigheid.

Maar je hebt gelijk, ik heb het artikel op zdnet.com gelezen en daar wordt het anders geplaatst.
Dus inderdaad, de kop klopt niet

[batjes]

Ik blijf het een bout excuus vinden.

Om op de watch te renderen, heb je toegang nodig tot de framebuffer van je smartphone? wut?

[Infor40]

Dan blijft toch staan dat je extra rechten toekent aan een bedrijf dat een voorgeschiedenis heeft met het schenden van privacyregels. En vervolgens neem je de verklaring van Uber zelf voor waar aan. Misschien is het ook wel waar, maar dat neemt niet weg dat het vreemd is dat er uitzonderingen worden gemaakt.

[supersnathan94]

Ja klopt het is wat vreemd. Echter weten wij niet of er ook getest is of de functionaliteit zo werkt. Als dat het geval is, dan is het een heel ander verhaal en hebben we ook de garantie van Apple dat het idd zo werkt. Dat Apple nu actief meewerkt geeft ook aan dat zij ook doorhebben dat het niet de beste oplossing was.

Aangezien Uber vziw geen extern updatemechanisme heeft zullen ze te allen tijde een nieuwe app in moeten dienen ter review. En dat betekent gelukkig dat er altijd een tweede partij is die er baat bij heeft dat deze functie daadwerkelijk doet wat hij zegt.

Apple werkt nauw samen met Uber en heeft bijvoorbeeld ingebouwde support in Maps zitten voor het bestellen van een Uber taxi. Derhalve is het voor Apple ontzettend belangrijk dat Uber zich aan de gemaakte afspraken houd. Anders kost dit ze veel geld.

[bbob]

Foutje, ik snap niet dan mensen in die sprookjes van een foutje geloven. Het is geen fout apple zal er gewoon toestemming voor hebben gegeven. Apple en dat controleren. Apart dat uber dan het enige bedrijf is van alle bedrijven die apps maken die toestemming gekregen heeft.

[drdelta]

Apart dat uber dan het enige bedrijf is van alle bedrijven die apps maken die toestemming gekregen heeft.

Zijn ze de enige?

[Jay-v]

Apple is juist zeer strikt net dat soort dingen en weigert apps die zich niet aan de regels houden. Kan me voorstellen dat Apple dat heeft toegestaan om Apple watch te promoten. Gaat wellicht samen met een strikte code review alvorens het de appstore in mag.

De eerste versie van watchos kon ook niet zonder iphone omdat er geen native applicaties mogelijk waren op de watch.

[Reactie gewijzigd door Jay-v op 22 juli 2024 15:58]

[Mic2000]

Zover ik weet reviewen ze geen code, alleen de werkende apps. Plaats je bv een gameboy emulator in je code die over twee maanden pas actief gaat dan zien ze dit niet.

[Reactie gewijzigd door Mic2000 op 22 juli 2024 15:58]

[supersnathan94]

Ze reviewen wel degelijk ook op lager niceau door te kijken welke calls je maakt en of er geen vage constructies zijn gebouwd voor dit soort grappen.

Pas als je externe update mechanismen gebruikt en dynamisch code bij kunt laden had Apple vroeger geen poot om op te staan en kon je alles doen na release. Volgens mij hebben ze dit echter wel aangepast ondertussen.

[Verwijderd]

Als ze maar niet te diep reviewen. Zo is een van hun regels dat een app zowel IPv4 als IPv6 moet ondersteunen (een goed idee), maar ook dat het IPv6 moet prefereren over IPv4 (iets waar wij grote problemen mee hebben omdat sommige antieke backends waar we indirect mee willen communiceren niet werken met IPv6). Dus wordt de Volkswagen oplossing voorgesteld: detecteren dat een app in de Apple tests loopt en dan IPv6 prefereren, als dat niet zo is liever IPv4.

[supersnathan94]

Als een backend niet werkt met IPv6 dan is het misschien tijd om dat te fixen in plaats van workarounds te gaan schrijven.

Met de huidige store grootte zullen jullie vast niet de enige zijn met deze problemen en is er misschien een betere oplossing te vinden die wel sustainable is en niet het risico met zich meebrengt dat je een permaban krijgt.

[Verwijderd]

Die backends staan niet onder onze controle, en aan clubs als de Duitse Telco's vragen om wat backends te vervangen omdat dat handiger is voor onze iOS app kun je echt wel vergeten.

[supersnathan94]

Tsja. Het risico lopen dat je gebanned wordt is ook niet echt sustainable. Iets meer latency introduceren en je eigen backend schrijven die als wrapper functioneerd geeft een betere oplossing en kan ook een betere veiligheid geven.

Maargoed zoals ik al zei zijn er vast meer mensen met dat probleem. Ik gok dat diezelfde duitse telco ook apps over die backends heeft lopen? Misschien daar eens vragen hoe zij het hebben gefixed? Just an idea.

[Xerxes249]

Dat klinkt als stuff waarvoor je je account gebanned kunt krijgen ^^

[Kevinp]

In dit geval lijkt het alsof apple Uber zelf de mogelijkheid heeft gegeven. Dus slordig van Apple.

Overigens voor test doeleinden wel logisch. Maar dan moet je de procedure bij een release wel op orde hebben.

[SoloH]

Alleen zie je de hele context niet met zo'n bericht. Je weet niet wat voor afspraken er zijn. Wellicht doet Apple wel een audit of zijn er harde afspraken gemaakt.

[SubSpace]

Twee strikes voor Apple, in evenzoveel dagen

[armageddon_2k1]

Ach ja, het mooie aan Apple is dat je die strikes daadwerkelijk ziet. Met die wirwar en chaos van al die Android prut ga je het nooit zien. Al die geroote en ongecontroleerde apps waar Jan en alleman gebruik van maakt. Als iets niet zichtbaar is bij anderen dan wil dat niet betekenen dat het niet gebeurt.

Maar inderdaad. Twee strikes voor Apple.

Met strike 2 bedoel je natuurlijk de MacOS bug. Die gedetecteerd werd, direct gefixt werd, en direct in elke update zit. Net zoals al die Android devices die altijd up to date zijn....

EDIT: Hihi, altijd zo grappig. Als je zo'n reactie plaatst weet je dat je -1 krijgt.

[Reactie gewijzigd door armageddon_2k1 op 22 juli 2024 15:58]

[Firecrash]

Ook de gaten in Android worden gewoon gedicht, snap je punt totaal niet.

Offtopic: Lekker ongefundeerd haten op een product. Leuk man die comment sectie van tweakers

[supersnathan94]

Dit is niet ongefundeerd haten op een product dit is terechte kritiek op een ecosysteem waarvan google ook weet dat het niet houdbaar is op lange termijn. Waarom denk je dat google met android O veel meer controle over kernel updates en patches naar zich toe trekt?

[Verwijderd]

Ze willen geen root en effectieve adblockers?

[supersnathan94]

Nee ze willen dat updates niet eerst door zes verschillende partijen hoeven worden getest omdat iets simpels als een UI laag te ver geïntegreerd is en omvalt doordat er malpractices worden gebruikt in de code.

[Verwijderd]

Maar aangezien stock Android geen root heeft wil ik bij voorkeur een kernelexploit om een toestel netjes te rooten zonder geklooi met bootloaders (was vaak weer ongewenste neveneffecten heeft, zeker op Sony telefoons).

[Neko Koneko]

Alleen bij Android ben je vervolgens weer afhankelijk van de fabrikant van je toestel en die nemen het niet altijd zo nauw met het updaten Maar dat terzijde.

OT: Ik vind het zelf een bedenkelijke praktijk, Uber is inderdaad nu niet bepaald een toonaangevend voorbeeld van een bedrijf dat zich netjes gedraagd dus om juist dit bedrijf dit soort rechten te geven is misschien niet de meest wijze zet van Apple geweest.

[mjz2cool]

is tegenwoordig met security updates wel beter geworden, je krijgt meestal een jaar updates, en bij de duurdere telefoons 2 jaar, met 1 of 2 upgrades. en met android 8 wordt het nog beter, waar google rechtstreeks het systeem zelf kan updaten zonder invloed te hebben op de ui van een fabrikant.

bovendien, als je een telefoon hebt vergelijkbaar met een iphone (van google zelf, of updates rechtstreeks van google), zoals de nexus lijn toen, en nu de pixel en android one lijn, krijg je nog betere ondersteuning.

met windows 10 is het nog beter geregeld, daar krijg je bij elke fabrikant gewoon updates en upgrades rechtstreeks van microsoft, los gezien van het feit dat microsoft meer moeite lijkt te stoppen in hun apps voor android en ios, dan in hun eigen os.

maar vind ios wel fijner, na windows mobile 6.1 en windows 10 mobile en android 2.3 tot 7.1 te hebben gehad. de enige die fijner was, is windows phone 8 en 8.1

[armageddon_2k1]

2 jaar updates? En dat vind je goed? Voor een telefoon van >600 euro? De acceptatiecriteria liggen wel heel erg laag dan. Dus ik ben verplicht elke 2 jaar een telefoon te kopen, een vlaggenschip, want anders is het elk jaar.... wauw.

[mjz2cool]

ik zeg niet dat ik dat goed vind, ik vind het zelfs slecht dat het zo gaat, maar het gaat wel steeds beter. eerder mocht je blij zijn met 1 update. ios doet dat wel beter, en windows 10 mobile doet het net zo goed

[Verwijderd]

Nee, je bent niet verplicht een nieuw toestel te kopen als je geen updates meer krijgt. Je hebt zeker een beheersachtergrond en bent in cursussen geconditioneerd op het zo snel mogelijk uitrollen van updates?

[armageddon_2k1]

Nee, ben gewoon een simpele consument die het nieuws leest over de vele veiligheidslekken en waarde hecht aan mijn privacy en data-veiligheid...

[Verwijderd]

Dan moet je sowieso rooten en Google zoveel mogelijk blokkeren.

Qua beveiliging valt het allemaal wel mee, ik heb hier nog nooit gelezen over grote virusuitbraken op Android, ontdanks alle theoretische gevaren waar men het steeds over heeft.

[i2Paq]

Zijn punt is dat vele Android apps. ook "gaten" hebben die pas later ontdekt worden. Dat is niet haten op een product maar gewoon zeggen hoe het is.
Daarbij, vele telefoons van amper twee jaar oud op Android zien nooit een update.

[rikoos]

EDIT: Hihi, altijd zo grappig. Als je zo'n reactie plaatst weet je dat je -1 krijgt.

Volledig Terecht toch? Eigenlijk is het zelfs een -2. Je gaat opeens volledig off topic door Android aan te halen terwijl het hier over de combi Uber en Apple gaat. Dus niets raars aan.

[Verwijderd]

Storm in een glas water, kennelijk heeft Uber wat debugging code in de binary niet verwijderd.

Oepsje, niet zo netjes maar als je even doordenkt zul je ook begrijpen dat een bedrijf als Uber niet echt belang heeft bij het screengrabben van iPhone screens, en als het al een businesscase hiervoor zou hebben en zo malafide zou zijn dit te implementeren, dan zou dit ook zeker uit komen en een groot lifethreatening schandaal veroorzaken. Nu heeft Uber al een slechte naam en een dergelijk schandaal zouden ze er echt niet bij kunnen hebben.

[Bigs]

Lees je maar eens in over hoe Uber de strijd aan gaat met concurrenten als Lyft. Daarbij worden echt vuile spelletjes gespeeld en het nemen van screenshots om te kijken of iemand de Lyft app gebruikt zou daar zeker in passen.

[Lapa]

Deze API kan zelfs screenshots maken als de app gesloten is. En dus niet alleen van de eigen app! Om screenshots binnen je eigen app te maken heb je ook echt geen bijzondere API's nodig. (bron: we hebben net een app gebouwd die exact dat doet).

Dat "hele lage niveau" waar je het over hebt, is nu net wat opengesteld wordt door deze API.

[Reactie gewijzigd door Lapa op 22 juli 2024 15:58]

[Zephyer]

En dit kan, indien gebruik gemaakt wordt van een EMM, (gelukkig) worden dichtgezet.

[z1rconium]

Het lijkt iets anders/ernstiger te zitten:

"com.apple.private.allow-explicit-graphics-priority," allows a developer to read or write to the iPhone's framebuffer, a part of the phone's memory that contains pixel and display data. "Writing is always possible from an app using normal rendering services, which draw to framebuffer on your behalf," he said. "Reading allows you to look at the device's screen."

"It's the equivalent of giving keylogging ability to apps," he said.

[Vexxon]

Dit is alleen niet het eerste zogenaamde 'oepsje' en wellicht is dit een echte, maar in het licht van al die andere 'oepsjes' ga je er toch anders naar kijken.

[marhalm]

Is het ook een oepsje dat Apple Uber en alleen Uber toegang tot deze schimmige API heeft gegeven denk je? Of wellicht dat er meer apps zijn met deze backdoorachtige API waar wij niets van weten?

Als dit Google was, dan had je hier moord en brand geschreeuwd. Nu het Apple is, stelt het niets voor

[Toettoetdaan]

Raar, maar blijkbaar had Apple veel over voor de adoptie van de watch.

[m4ikel]

Mooi voorbeeld van onheerlijke handelspraktijken. Partij X meer voordeel geven op het platform dan partij Y, niet de eerste keer dat Apple zo'n trucje uithaald.

Lijkt me een prima aankopingspunt voor Lyft om een zaak aanhandig te maken. Zeker gezien zowel Apple als Uber blijkbaar samenspelen om hun marktpositie verder af te schermen.

[Reactie gewijzigd door m4ikel op 22 juli 2024 15:58]

[gubyan]

Less is more, en dat geldt ook voor een app, en zeker voor de hoeveelheid zinloze apps die mensen meezeulen op hun phone.

[Verwijderd]

Totally offtopic:
Auteur lijkt verrekte veel op Mark Zuckerberg na een afterparty...

[mutley69]

Dit is de eerste keer dat de dubbele houding van Apple rond privacy tegen het licht gehouden wordt - het hek is van de dam - eindelijk!

[jip_86]

Het is op het moment eerder nieuws als Uber iets wél volgens de regeltjes doet. Keer op keer lees je dit soort berichten, vraag me af of dit ooit nog een keer gaat stoppen.

[sympa]

Echt innoveren doe je door je wel aan de wet te houden. Anders was Napster (wat echt een goede dienst was overigens, social music sharing) vandaag de dag een miljardenbusiness.

[Jerie]

Als je nou alleen had gezegd

De wet personenvervoer eist nu éénmaal dat je de opleiding doet tot taxichauffeur. Uiteindelijk ben je gastheer voor de klant en heb je best wat nodig. Voor 2000 euro ben je klaar incluis vergunning en opleiding.

Inclusief bron dan had je een punt gemaakt.