TikTok su iOS: il browser in-app traccia gli input dell'utente

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/sicure...te_109449.html

Dopo le app di Meta, anche TikTok fa uso di un codice JavaScript con il proprio browser in-app per tracciare gli input e le interazioni dell'utente

Click sul link per visualizzare la notizia.

[lollo9]

se quello che fa drizzare le antenne è appunto la JS injection, la soluzione sarebbe abbastanza semplice per Apple, come per Google.
il fatto è che non si tratta affatto di JS injection. Felix Krause non è un cretino, e lo so che le keywords come injection, keylogger etc. fanno un bell'effetto, ma da parte sua dovrebbe davvero aggiustare la terminologia.

TikTok, come ogni in-app browser di ogni altro social, ti fa passare da una rotta dedicata dalla quale ti servono JS con varie strategie, ma tendenzialmente due: o import-maps/microfrontend/affini, o un index specifico che referenzia del JS sempre residente su quel server.
questa NON è JS injection per definizione, è tutto first-party serving. l'esatto opposto.
che cosa sarebbe sentry.io allora? o logrocket?? od i vari tool di telemetria realtime che un qualsiasi framework web cabla di suo nelle build di produzione?
già oggi non puoi referenziare del JS esterno utilizzando JS stesso. e non puoi nemmeno lasciare che sia il bundle ad andare a recuperare JS per vie traverse da iniettarti nella webview, un po' per tutte le policy di cross-* che ci sono, un po' perché quello sì che Apple te lo casserebbe.

altra questione è interrogarsi su COSA possa fare il JS di una webview in-app, in particolare quali eventi possa ascoltare. e questa è materia per i vendor Apple e Google su tutti, ma poi pure MS, Mozilla e via giù fino al W3C.

ma come fai a bloccare selettivamente l'event queue di JS? non funzionerebbe niente. od ad aggiungiere un sistema di autorizzazioni sui listener? se ne riparlerebbe tra almeno 10 anni... il fatto è che il contenuto di una webview è dinamico per definizione, e visto che non puoi sapere cosa sarà servito in anticipo, l'unica strada è lavorare su un runtime "light" che per ora non esiste.
si è ormai creata questa prassi di buttare di tutto dentro una webview, puntare un revrese proxy da qualche parte e "decorare" al volo i contenuti. brutta gatta da pelare