TikTok injecteert code in in-app browser, 'gebruikt vermeende keylogger niet'

TikTok injecteert code in webpagina's van derden wanneer een gebruiker in de TikTok-app een browserpagina opent. Deze code zou onder meer kunnen dienen als een keylogger. Volgens het sociale medium wordt de betreffende code alleen voor ontwikkelingsdoeleinden gebruikt.

De omstreden code. Afbeelding via Felix Krause

Ontwikkelaar en beveiligingsonderzoeker Felix Krause ontdekte dat wanneer een gebruiker een link opent in de iOS-versie van TikTok, er zich een in-app browser opent waar het sociale medium JavaScript-code in kan injecteren. Hierdoor zouden met het toetsenbord ingevoerde gegevens, waaronder wachtwoorden, betalingsinformatie en andere gegevens, geregistreerd kunnen worden. Hij onderzocht niet of dit ook het geval is voor de Android-variant van de applicatie.

TikTok bevestigt tegenover Forbes dat de JavaScript-code inderdaad aanwezig is, maar dat de berichten over een vermeende keylogger misleidend zijn. Het omstreden stuk code zou een ongebruikt onderdeel van een sdk van een derde partij zijn. "Zoals andere platformen gebruiken wij ook een in-app browser om een optimale gebruikerservaring te bieden. De betreffende JavaScript-code wordt gebruikt voor debugging, troubleshooting en het monitoren van de prestaties van de applicatie, bijvoorbeeld voor het checken van de laadsnelheid van een pagina en of de pagina crasht."

Het keyloggergedeelte van de code van de sdk van een derde partij zou dus niet gebruikt worden. Het is niet duidelijk wie deze derde partij is en of zij daadwerkelijk een keylogger nodig zou hebben voor ontwikkelingsdoeleinden. TikTok suggereert verder dat bepaalde geregistreerde data alleen lokaal op het apparaat verwerkt wordt en niet doorgestuurd wordt naar servers van het sociale medium.

De onderzoeker zegt in zijn bevindingen, die overigens aansluiten bij de eerdere ontdekking van tracking door Instagram en Facebook in in-app browsers, dat het statement van TikTok eventueel zou kunnen kloppen. "Dat een app JavaScript in externe websites injecteert, betekent niet per definitie dat de app iets kwaadaardigs doet. Er is geen manier om te weten wat voor data een in-app browser precies verzamelt en of deze data doorgestuurd dan wel gebruikt wordt."

Het is dus geen gegeven dat TikTok inderdaad de toetsenbordinput van gebruikers registreert, laat staan naar zijn eigen servers stuurt of anderszins opslaat. Wel is het zo goed als zeker dat dit mogelijk zou zijn. Om die reden is het volgens Krause verstandig om browserlinks via TikTok, maar ook via Facebook en Instagram, te kopiëren en direct in een vertrouwde browser te plakken. Op deze manier kunnen de betreffende applicaties geen code injecteren om op deze manier gevoelige data te registreren.

Door Yannick Spinner

Redacteur

19-08-2022 • 18:05

124 Linkedin

Reacties (124)

124
116
54
6
0
25
Wijzig sortering
In app browsers zouden oprecht verboden moeten worden voor Play Store en iOS apps door Google en Apple. Er is geen goede reden om niet gewoon de default browser aan te roepen.

[Reactie gewijzigd door youridv1 op 19 augustus 2022 18:19]

Die reden is er voor app ontwikkelaars wel. Je houdt namelijk mensen binnen je eigen app, je kan o.a. code injecteren zoals hier genoemd etc. Het voordeel is voornamelijk niet voor jou als gebruiker.
Het voordeel kan er zeker wel voor jou als gebruiker zijn, omdat een in-app browser directe communicatie met de app heeft. Denk bijvoorbeeld aan makkelijk tekst/afbeeldingen delen tussen app en in-app browser, screenshots maken van delen van web pages, etc. Een in-app browser kan functionaliteit bieden waar normaal browserextensies en het wisselen van applicatie voor nodig zijn. Ook kan een in-app browser werken op een deel van het scherm, terwijl de app UI op andere delen aanwezig is. Voor authentication providers (inlog met Google/Facebook/etc) zijn in-app browsers ook heel nuttig, de app kan dan meteen verder gaan als authenticatie geslaagd is en je zit niet te wisselen.

Blokkeren van in-app browsers excludeert veel valide doelen. Enkel een paar kwaadaardige apps maken er ongepast gebruik van, waar een app store wel een policy op zou kunnen hebben en voor zou kunnen blokkeren. In theorie zou je wel een extra permissieniveau voor JS injection/keystroke detection in de in-app browser kunnen maken, maar dat zou mensen verwarren. Handmatige screening is dus ongeveer de enige optie.
Veel mensen kiezen bewust voor een bepaalde browser (vaak omdat men bepaalde extensies wilt gebruiken).
Een app die voor mij gaat besluiten dat ik een andere browser moet gebruiken omdat het hen goed uitkomt gaat er bij mij meteen vanaf.
Ik vindt het zelf altijd vervelend als apps mij een in-app inlogpagina voor Google geven. Hoe moet ik dan verifiëren dat ik werkelijk bij Google inlog?
De door @Niet Henk genoemde 'voordelen' vallen naar mijn overtuiging in het niet bij de risico's op ongewenst code-injectie.
Voeg daarbij dat bedrijven, en TikTok al helemaal, daarin geen schone reputatie hebben, dan heb je al snel het door @youridv1 gewenste verbod.
Ik ben het volledig met Niet Henk eens.
Ik heb aan een web applicatie gewerkt die zo werkt.
Dit was dan wel een windows app, maar het principe is exact het zelfde.
Inloggen ging via in-app browser, en daarna kon je producten selecteren en die kon je dan overnemen via meerdere routes. Derde partijen konden dus een bepaalde route configureren en dat wisselde tussen post naar een server, tot naar een specifieke url (waardoor de app die de browser bestuurde, wist welk product werd aangeklikt), tot protocol handlers.

Er zijn dus meerdere wegen naar Rome, maar via je app wat JavaScript injecteren, of gewoon kijken welke URL bezocht wordt, is veruit de eenvoudigste om te kunnen communiceren tussen app en browser.

EDIT: Overigens ben ik het NIET eens dat dit wordt gedaan voor analytics, tracking etc... Bijvoorbeeld een linkje openen via TikTok die naar een nieuwssite o.i.d. gaat & opent via die interne browser, vind ik dus niet oké.

[Reactie gewijzigd door joost00719 op 20 augustus 2022 21:07]

Eens, maar toch is dit op bepaalde hoogte zelfs voor gebruikers ook een voordeel. Inloggen/betalen etc waarvoor de browser opent - het is vaak echt een rotzooi en het werkt gewoon niet fijn. Daarbij is het in dezelfde app blijven ook gewoon een heel stuk "mooier" opzich, zeker als het kleinere acties of onderdelen zijn die je aanroept.
Het sloopt vaak integratie met bijvoorbeeld wachtwoordmanagers die in een normale browser het wel gewoon doen. Moet ik weer wachtwoorden over en weer kopiëren van de wachtwoordmanager, ook niet ideaal.

Verder, waarom zou je überhaupt willen dat <app-maker> met je meekijkt terwijl jij je PayPal/bank/gegevens o.i.d. invult? Er zijn gewoon privacy-vriendelijke manieren voor integratie, en daar moeten bedrijven vooral niet omheen werken.

Alle keren dát ik een link binnen een app open, zoek ik meteen de knop om dat in mijn echte browser te openen.
Is vooral vanuit de normale eindgebruiker bekeken die zich met je tweede punt niet bezighoudt, maar met het eerste deel van je reactie heb je ook dan zeker een punt. Ik gebruik die wachtwoordmanager niet, maar veel gebruikers doen dat wel en dat kan dat inderdaad een nadeel zijn.
Wat jij als voordeel noemt, zie ik als nadeel. Ik gebruik mijn eigen browser voor betalen, koekies en dergelijke. Een in-app browser is never nooit niet zo goed als de browser waar je zelf voor gekozen hebt.
Bedenk dat die browser er alleen maar is voor zaken die eigenlijk buiten de app vallen en daarmee buiten de controle van de app-leverancier. En die controle wil ik heel graag zelf houden.
Snap ik, maar ik bekijk dit soort dingen altijd vanuit het oog van de doorsnee eindgebruiker, niet vanuit de doelgroep die op Tweakers zit. Voor normale eindgebruikers maken die zaken doorgaans helemaal niets uit en komt het gewoon veel netter en minder ingewikkeld/slordig over als je (een soort van) in de app blijft.
De gewone gebruiker begrijpt het ook niet dat als ze naar een website gaan dat de ene keer zaken gewoon werken en de andere keer gaat het heel anders. Ze beseffen niet dat ze de ene keer hun standaard browser gebruiken met daarin gebruikersnamen en wachtwoorden (bijvoorbeeld) automatisch ingevuld en als ze via de in-appp browser werken dan zijn die wachtwoorden er opeens niet en moeten ze het nog een keer invullen.... Als tweaker snap ik dat en erger ik mij er aan. De Jan-met-de-Pet begrijpt dat niet altijd en ergert zich ook.
De ervaring van onze klanten is in ieder geval anders, die vinden het weldegelijk netter en een bepaalde doelgroep raakt je eigen app zelfs kwijt naderhand. Ook niet alle gevallen van het aanroepen van een in-app browser gaat om zaken die ingevuld moeten worden en/of al opgeslagen staan, overigens.

Ding is gewoon dat je met een in-app browser een webpagina kan laten aanvoelen alsof het bij je app hoort, en je houdt iemand min of meer binnen je app. Als de browser opent zal het in de meeste gevallen ook wel goedkomen, maar voelt iedereen duidelijk dat je buiten de app zit en dat er webpagina's worden geopend. Een deel van de gebruikers drukt een openende browser zelfs weg, wanneer het niet gaat om verplichte zaken.

Voor alles is iets te zeggen. En ja, natuurlijk is het het beste om alles native in je app te hebben voor bepaalde doelen die ik noem. Maar een in-app browser kan best uitkomsten bieden en dat vermijden is niet altijd persé beter.
Er is geen goede reden om niet gewoon de default browser aan te roepen
Dit is gewoon niet waar. Dat je zo snel geen reden kan verzinnen betekent dit dat er niet één is. Sowieso in combinatie met een eigen website, ter integratie, zijn er allerlei toepassingen. Inloggen, functionaliteit bieden die nog niet in de app zit (maar wel de website), handleidingen, en meer.

Een betere oplossing zou zijn om de in-app browser te beperken tot bepaalde aangegeven domeinen die de app-bouwer zelf ook bezit.
De eigen website via de eigen in-app browser.... Nergens voor nodig, je bent eigenaar van de app dus je kan je hele website in je app zetten.

De enige reden voor een in-app browser is het afvangen en verwerken van via die app doorgegeven links en zo. Er is geen enkele reden voor een in-app browser anders van voor de browser zelf.
je bent eigenaar van de app dus je kan je hele website in je app zetten
En dat doen veel app developers dus via een webview. Niet elke webview heeft een window er om heen waarmee je kan zien dat het een webview is, maar dat maakt het niet minder een webview.
De achterliggende pagina daarvan updaten is ook nog eens een stuk sneller dan je app helemaal opnieuw laten reviewen door Google/Apple. En het scheelt ook enorm in tijd/kosten om veel van dit soort views niet opnieuw te hoeven maken, en te kunnen focussen op onderdelen die wél performant moeten zijn.

Frameworks als Cordova en dergelijke geven op zich al aan hoe breed een webview wel niet kan worden opgezet. Het is echt veel meer dan alleen "een hyperlink uit een (socialmedia) app".

[Reactie gewijzigd door Luminair op 19 augustus 2022 21:51]

Zo'n webview is andersom: Dat is een app die de webview-deel van de browser gebruikt om zo de website te laten zien alsof het een app is. Daar is niets mis mee, als je daarin een website opent, dan open je dus niet de in-app-browser maar de browser-waar-de-app-ook-al-in-zit.
Geef een goede usecase dan? Dat heb je tot nog toe niet gedaan.

Functionaliteit buiten de app bieden kan ook in een browser agnostische mobiele site

Inloggen heb je ab so luut geen eigen browser voor nodig

Handleidingen? Maak een HTML handleiding en open die in de default browser net als de rest van de planeet.

[Reactie gewijzigd door youridv1 op 19 augustus 2022 20:09]

Ik denk dat het een afweging is, als je niet anders zou kunnen, kan je het allemaal oplossen in je eigen app, dat is het probleem niet.

Stel je hebt een bedrijf waar userengagement alleen op het web gebeurd, vervolgens ga je over naar apps. Ipv dat je een grotere smak met geld in 1keer uitgeeft, kan je stapsgewijs items native maken (alles dat nog niet native is open je de innappbrowser voor en laad je je online website).

Puur omdat het allemaal zou kunnen in een app betekend niet dat er "Geen use cases zijn" die zijn er wel. Dat inappbrowsers door minder security savvy developers worden geimplementeerd met alle gevolgen van dien, daar ben ik het met je eens dat het een slippery slope is waar je eigenlijk vandaan wilt blijven.
Inloggen kan prima met de gewone browser, en OAuth of iets dergelijk. Zo werkt het ook voor desktop apps.

De login gebeurt dan gewoon in de browser, en op het einde redirect de login site naar een link die je opent in de toepassing die probeert in te loggen, die URL bevat dan ondermeer de juiste sessiesleutels voor de app toegang te geven tot de API van de service.
In app browsers zouden oprecht verboden moeten worden voor Play Store en iOS apps door Google en Apple. Er is geen goede reden om niet gewoon de default browser aan te roepen.
In iOS zijn ze in ieder geval verplicht de API van safari te gebruiken omdat een volledig eigen engine niet toegestaan in, wat wel op Android mag.

iOS gebruikers mogen dan nog blij zijn op de strenge controle.
Op Android gebruiken de meeste in-appbrowsers toch gewoon Android System WebView?
Kan, maar is zeker niet verplicht.
Ze willen niet dat je hun platform verlaat, als jij weg gaat naar een Browser dan ben je uit hun applicatie waar ze advertenties verkopen. Alle gratis platformen werken op deze manier, maar ook bijvoorbeeld een Netflix blijft maar afspelen zodat jij niet naar een Disney of Prime weg klikt.
Wat bedoel je precies / wat is dan het beste? Moet ik de standaard telefoon browser gebruiken of een externe? (Wie wil niet dat je welk platform verlaat... en weggaat naar welke browser... Ik mis namen, daarom volg ik het niet echt :P)

Edit: Waarom downmod? Het was een serieuze vraag want ik snapte het echt niet... Sorry hoor.

[Reactie gewijzigd door Armselig op 20 augustus 2022 21:24]

Het platform in dit voorbeeld is Tiktok, zij willen dat jij in hun applicatie blijft. Daar kunnen ze je tracken en content laten zien (bijvoorbeeld pro-China content, advertenties). Dus hebben ze in hun applicatie ook een browser, als je die browser gebruikt om een externe link te openen en je sluit hem weer dan ben je nog steeds in Tiktok.
Ah, nu is het duidelijk, waarvoor dank.
Maar een groot aandeel van de apps zijn tegenwoordig niet heel veel meer dan een wrapper voor de website, en dat gaat lastig zonder in-app browser. Ook bijv. Electron is uiteindelijk niet veel meer dan dat.
Chrome's in-app-browser kan dit soort onzin niet zomaar; ik heb zelf bijvoorbeeld Firefox ingesteld en de "in-app" browsers openen normaal dan ook daarin. Aan de andere kant weerhoudt niets Facebook en vrienden er natuurlijk van om hun eigen browser mee te leveren als alternatief.

Als je een app niet vertrouwt, waarom vertrouw je hun browser dan wel? Het probleem is niet dat de browser API te veel toestaat, het probleem is dat de appontwikkelaar niet te vertrouwen is. Zelfs als Apple en Google dit repareren, kun je alsnog niet vertrouwen dat deze ontwikkelaars je telefoon niet op andere manieren misbruiken.

Wil je enigszins veilig zijn, gebruik dan gewoon de webinterface van dit soort diensten in een browser die je wel vertrouwt.
We kunnen het ook omdraaien. Meer PWAs gebruiken in je eigen default browser. Helaas heeft Firefox alleen nog geen geweldige PWA support.

Ander voordeel, geen Play/App store dependency meer. Maakt het switchen naar alternatieven makkelijker.
In-app browsers op zich zijn niet verkeerd noch ongewild. Specifiek gebruik ervan is. Kijk alleen al naar hoe populair als als Hermit (de light app browser, niet de malware), Native Alpha, etc zijn. Misschien niet de grootste apps ooit, maar ook niet zo minuscuul dat je in-app webview maar weg moet doen.

Wat ik liever zie is de optie om je webview aan te passen zonder je telefoon te moeten rooten, zoals nu wel het geval is. En dan apps forceren om de geïnstalleerde webview te gebruiken, en geen eigen, zodat alle limitaties en blokkades van de webview daar ook gelden. Apps developers kunnen dan altijd zeggen "wij raden X webview aan", en jij kan kiezen een meer privacy focused webviewer te gebruiken met mogelijk minder optimalisatie voor de apps die je gebruikt. Net zoals met je normale browser vs websites.

En sowieso dat app stores apps apps met keyloggers niet accepteren, ongeacht of ze gebruikt worden of niet. Gooi je development spul uberhoubt niet je release built. En een tool met verplichte keylogger (gebruikt of niet) is niet geschikt voor release imho.
Apple heeft juist meerdere keren mijn apps afgekeurd juist omdat ik op sommige momenten de gebruiker doorverwijs naar een externe browser. Toen ik het verving door een in-app webview vond Apple het pas prima...
Ingebouwde browsers waren oorspronkelijk een reactie van social media platforms op een van de meest verwarrende ux-problemen van de iPhone: de iPhone kent geen universele back-button.
Op het moment dat je dan een link opende in Safari zat je in een andere app. Vervolgens kon je voor je sessie geen eenvoudig kruimelpad terug volgen naar waar je begon. Dit was oorspronkelijk (+10 jaar geleden) reden voor het ux-team van Twitter om in app browsers te gebruiken. Safari kon daarvoor toen nog niet worden toegepast. Gelukkig heeft Apple niet stilgezeten en is het tegenwoordig prima mogelijk om ook in iOS de standaard browser als inapp browser toe te passen.
Waarom Apple dit niet verplicht is mij ook een raadsel, gegeven de suggestie van Krause dat Instagram de eigen inapp browser gebruikt om trackingcode te injecteren.
Ik wilde net gaan zeggen. Vroeger kon dat dan niet maar tegenwoordig verschijnt er als je een linkje opent vanuit een app altijd een knop bovenin naar de app waar je vandaan komt.
"...Er is geen manier om te weten wat voor data een in-app browser precies verzamelt en of deze data doorgestuurd dan wel gebruikt wordt."

dat kan toch met wireshark..., mits de data niet eerst geëncrypt wordt?
Ik verwacht dat de server communicatie wel encrypted is. (HTTPS) Dat is wel het minste wat ik verwacht van een app waarmee ik kan inloggen.

YT gaat zich trouwens de ballen uit de broek lachen wanneer tik-tok wordt geblokkeerd in het westen.
Als ik wel ergens een schurfthekel aan heb dan zijn het in app-browsers. Dit heeft voornamelijk te maken met het privacy aspect, het feit dat er nooit wordt gevraagd of ik het in de in-app browser wil openen of me “eigen” en dat je nooit, of in ieder geval, zeer zelden de cookies en andere “temp” files kan verwijderen.
Google doet helaas net zo hard mee. Als je o.a. een link opent in de youtube app dan gaat hij via de ingebouwde browser ipv je default browser. Gruwelijk iritant en het is ook niet uit te schakelen.

Bedankt voor het verbeteren van mijn injuiste info. Inderdaad als je kijkt naar de browser is het inderdaad een variant van je default browser. Hier was ik niet van op de hoogte.

[Reactie gewijzigd door Sp3ci3s8472 op 21 augustus 2022 15:25]

Dat voorbeeld is toevallig een ander geval omdat de "Chrome Custom Tabs" Android API wordt gebruikt. https://developer.chrome..../custom-tabs/#whatarethey

Dit houdt dus in dat er geen code geïnjecteerd kan worden, geen informatie van de site uitgelezen kan worden en dat de browser van de telefoon zelf wordt gebruikt. Dus praktisch gezien is het een visuele optie die ervoor zorgt dat je makkelijker terug kan naar de app.
Ik had verwacht dat iets vergelijkbaars van krscht zou zijn met de webkit-views bij in-app-browsers.
Maarja, soms ‘moet’ je ook wel wat kunnen uitwisselen…
De webkit views binnen apps kan je inderdaad wel code injecteren. Maar anderzijds is dit geïsoleerd van de browser en ben je dus niet ingelogd op sites en dergelijke.

De webkit view is overigens sterk af te raden voor bijvoorbeeld een browser scherm met een koppeling bij een derde partij. De gebruiker moet nu namelijk eerst handmatig inloggen voordat hij zijn account kan koppelen.
Ha, dat Google nog eens een privacyvriendelijkere optie dan Apple zou aanbieden. Hier komt namelijk bovenop dat andere browsers de Custom Tabs kunnen vervangen. Firefox doet dat o.a.
Bij mij niet het geval (Android), hij opent een overlay van mijn standaard browser, Brave.
Screenshot
Ik zie het inderdaad ook bij mij. Mijn post hierboven heb ik bij deze aangepast.
Om die reden heb ik Facebook en Instagram apps verwijderd, en gebruik ik ze nu in Firefox op Android.
De mobiele websites daarvan werken inderdaad prima. En als je gewoon een snelkoppeling op je startscherm plaatst, dan kun je de websites daarvan gewoon meteen openen zodat je het verschil niet eens echt merkt.
Wel ontdekt dat een filmpje uploaden niet lukt in Instagram via de browser (FF) maar wel via de app.
Om die reden gebruik ik nooit apps als je de functionaliteit ervan ook gewoon in he browser kan bekomen.
Dus hoe hard Bol, Amazon en consorten ook vragen om hun app te installeren als je op hun site surft, je hebt ze niet nodig en je bent veiliger in je betrouwde browser dan geen enkele zeggenschap te hebben over wat je wil delen of niet bij het gebruik van hun apps.
Precies, gewoon de eigen browser gebruiken en de app links laten liggen
Wat een stuk malware is die hele app. Dit kan er ook nog wel bij.
De volledige jeugd zit daarop en china incasseert alle gegevens.
De volledige jeugd zit daarop en china incasseert alle gegevens.
Ik begrijp niet dat mensen ineens experts zijn geworden en een mening hebben terwijl facebook en google al meer dan een decennia soortgelijke praktijken uithaalt en erger,


en nog steeds door kan gaan.


Laat staan derden die via truukjes soortgelijke gegevens vissen, koppelen, en verkopen en die bedrijven maken nog leuk miljarden omzetten.


Misschien een ideetje,
als de norm 5 jaar geleden een keer strakker werd vastgelegd na oa brexit. De “arabische lente” was al een mislukt experiment en daarvoor had je ook nog eens allerlei (semi-islamitische) organisaties die de zwakheden van social media makkelijk konden uitbuiten.
Google is geen onderdeel van een totalitair communistisch regime dat actief genocide pleegt, miljoenen mensen in concentratiekampen stopt, mensen om politieke/maatschappelijke redenen “laat verdwijnen”, mensen 24/7 surveilleert, van elk individu een sociale credit score bijhoudt en zo kan ik nog wel even doorgaan,
Ik begrijp je punt, maar definieer dan wel wat jij verstaat onder 'surveilleert'. Want Google ziet wel toe en noteert. De trails die van gewone mensen worden bijgehouden zijn lang en deze mensen zijn er lang niet altijd van bewust, noch hebben zij hiervoor bewust en expliciet toestemming voor gegeven (ondanks dat zij ooit een scroll van 2 minuten hebben gezet en toen ok hebben geklikt). Een redelijk recent voorbeeld van surveillance: hier
Wat klets je nu voor een onzin? De meeste propaganda komt precies uit die landen waarvoor jij het opneemt, waarschijnlijk ben je er al door beïnvloed.

China is niet te vertrouwen. Punt. Laten we aub niet wéér in dezelfde valkuil trappen als we met Rusland hebben gedaan. We zijn blijkbaar verwend en dus naïef geworden.

Tiktok is leuk maar moet blijkbaar maximaal worden gecontained. Leuk Paard van Troje dit.
vind ik ook en zeker van het hele verre westen. Er is en wordt niet ingegrepen omdat er nog geen afzetmarkt is. Het risico is nog veel te groot.
in WW2 was dat het risico waard t.o.v. de afzetmarkt. De oorlogsindustrie floreert nog steeds dankzij.
Sterker nog het zal binnenkort weer wat zaken moeten aanwakkeren want dat land verdient te weinig vandaar de hoge inflaties wereldwijd.
Ik werk op een wetenschappelijk instituut. De Chinese wetenschappers hadden vertaal software die ze geïnstalleerd hadden. Er kwam een nieuw hoofd van de IT die de firewall ging upgraden en wat meer zaken. De 500 gig. Die er per minuut uitging (was een beetje veel :P ) was einde verhaal vertaalsoftware. Nu beklagen ze zich, dat ze de boel niet goed kunnen vertalen :X

Dus als je Manderijns wil leren. Ik raad de pakketten van de ANWB aan :Y) :P

[Reactie gewijzigd door rob12424 op 19 augustus 2022 22:42]

Landerijen moet zijn Mandarijns?
Over taal gesproken…
Thanks, ik denk dat mijn phone wat meer autocorrect gegevens moet gaan versturen 8)7
Juist vanwege dit ben ik bang dat de westerse wereld straks ook de digitale ID gaat hanteren om zo makkelijk een ID aan alle data te kunnen koppelen. Want als ze dit niet gaan doen dan lopen we straks heel ver achter in the technologie etc.
Ik ben geïnteresseerd in wat je stelt. Wat is die digitale ID precies, en waar zit de dreiging van achterstand? Dat kunnen we uiteraard niet hebben.
DigiD. Is er al.
Een app waar al je ID's aan worden gekoppeld tot zelfs je Co2 budget die ze later omtoveren tot een sociale krediet systeem.
Ik hoop toch echt van harte dat Apple hier nu hard op in gaat grijpen...
En Android + de Europese commissie. Verbied anders gewoon die app .
De apps van Meta dan ook? Die injecteren ook allemaal code. Enige verschil is dat je er voor kan kiezen om de website direct in safari te openen.

Bron: https://pbs.twimg.com/media/FaeOQX-WYAEBTGe?format=jpg

[Reactie gewijzigd door tom.cx op 19 augustus 2022 19:42]

Alle websites die dat doen. Er moet een basis veiligheid wettelijk komen . Indien dit niet zo is na 2 waarschuwingen ze verbieden.
En regel ook ineens iets van handhaving anders heb je zo weinig aan dat verbod.
Absoluut, elke app die code injecteert in websites van derden moet geblokkeerd worden. TikTok, Facebook, Instragram. Allemaal.
Ik grijp zelf in !!!
Dat zou Apple volgens hun eigen Guidelines https://developer.apple.com/app-store/review/guidelines/ moeten doen.

Artikel 5.1.1 verbiedt dit namelijk:
(vii) SafariViewController must be used to visibly present information to users; the controller may not be hidden or obscured by other views or layers. Additionally, an app may not use SafariViewController to track users without their knowledge and consent.
Als je al javascript kunt injecteren is een keylogger triviaal, die hoeft niet eens in een SDK te zitten.
Als je al javascript kunt injecteren is een keylogger triviaal, die hoeft niet eens in een SDK te zitten.
Als je van een webview gebruik maakt heb je niet eens een keylogger nodig, want je kunt gewoon zaken als cookies; local storage; etc. uitlezen vanuit de app. Je hebt toegang tot alle persistence mechanismes waar in bijv. OAuth tokens opgeslagen kunnen staan.

Waarom nog een password jatten als je gewoon de bestaande sessie kunt hijacken?
Omdat een sessie op andere websites minder waard is (evt op oauth sites, maar ook daar werkt je sessie niet als domain verif goed is opgezet), en wachtwoorden mogelijk wel op andere sites gebruikt word (username lijsten die gebruikt worden op websites zijn wild, wie weet heb je wel een nieuw wachtwoord te pakken!
"Het keyloggergedeelte van de code van de sdk van een derde partij zou dus niet gebruikt worden"
En de SDK is van? Facebook? 8)7

Erg bijzonder dat de onderzoeker dit niet benoemd... en het hier een "keylogger" wordt genoemd terwijl er bij Facebook sprake was van een (tracking) "feature".
Tuurlijk werd dat wel gebruikt. Ik geloof er in ieder geval niets van dat ze toevallig die keylogger niet gebruiken.

Gewoon doen waar je zin in hebt tot je betrapt wordt en alsnog doen alsof je neus bloed.
Als ik de screenshot bekijk is dit inderdaad een SDK van Facebook.
Kaspersky deed dit overigens ook vroeger (geen idee of ze het nog steeds doen) maar dan in je normale browser. Ze injecteerden JavaScript in elk pagina, welke continue op de achtergrond verbinden maakten met de Kaspersky servers. Er werd o.a. gekeken naar Google zoektermen, en het bleef op de andergrond doorwerken indien je het uitschakelde in de instellingen.
Interessant artikel. Erg zorgelijk!

Ik wist niet eens dat je in de IOS app-integrated browser JavaScript kan injecten. Betekent dit dat Safari de “content-security-policy” negeert bijvoorbeeld? Dat zou gewoon een security breach genoemd mogen worden.

Dan open ik dus maar geen links meer in de app browser van welke app dan ook vanaf nu.
Waarom zetten jullie alleen TikTok in de titel, en niet ook Facebook? Zij doen namelijk precies hetzelfde.

In fact, Facebook betaalde bedrijven voor smear campaigns tegen TikTok. Door Facebook niet ook in de titel te noemen, ondersteunen jullie actief Facebook's poging om te doen alsof TikTok veel erger is: https://www.engadget.com/...r-campaign-133139892.html

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee