Alliantie van webontwikkelaars roept EU op om in-appbrowsers te verbieden

De Open Web Advocacy, een alliantie van webontwikkelaars, heeft de Europese Commissie opgeroepen om in-appbrowsers te verbieden. Apps moeten de door gebruikers gemaakte keuze voor een standaardbrowser respecteren, vinden zij.

Sommige apps openen links in een in-appbrowser die ze zelf hebben gemaakt en daarin injecteren ze JavaScript om data bij te houden, meldt de OWA. Onder meer van TikTok is dat al een paar jaar bekend, net als van Instagram en Facebook. Het is onbekend welke apps allemaal JavaScript injecteren in een in-appbrowser.

Apps moeten de keuze voor een standaardbrowser van gebruikers respecteren, vindt de organisatie van webontwikkelaars. Door links te openen in een in-appbrowser, gaan apps in tegen de DMA-regels om die keuze bij gebruikers te leggen, vinden ze. De Europese Commissie heeft nog niet gereageerd op het verzoek.

Er zijn oplossingen voorhanden. Zo heeft Android een functie die Custom Browser Tabs heet en die links in de app opent, maar dat kan met de browserengine van de standaardbrowser die de gebruiker gekozen heeft. Appontwikkelaars kunnen er nu nog voor kiezen om daarvoor een eigen browser te gebruiken, maar de EU zou Google ertoe kunnen dwingen om die keuze weg te halen. Dat maakt ook het injecteren van JavaScript onmogelijk. Onder de DMA heeft onder meer Apple Safari in iOS verwijderbaar gemaakt en het besturingssysteem een keuzescherm gegeven.

Door Arnoud Wokke

Redacteur

28-03-2024 • 10:27

72 Linkedin Whatsapp

Reacties (72)

72
72
31
1
0
36
Wijzig sortering
Als ontwikkelaar: Wij gebruiken af en toe third-party functionaliteit in een in-app browser, maar dan wel met Custom Tabs (op Android) welke de default browser opent. Bijvoorbeeld, voor de deel-auto app gebruiken we een thirdparty die alleen een webapp heeft voor de upload en validatie van een rijbewijs, hetzelfde voor schade rapporteren aan de auto. Dus om het nu allemaal af te schaffen is wel heel erg sterk, zeker omdat wij juist die functionaliteit nodig hebben voor een specifiek doel (en de service verlener ervoor betalen).
MAAR: Als gebruiker van andere apps, als Facebook (messenger) of Google search vind ik het bloedirritant dat alles maar inapp wordt geopened binnen in de app en inderdaad je wordt gecontroleerd wat je gebruikt. Dit moet je handmatig uitzetten en ik zie mensen om mij heen het natuurlijk niet uitzetten (want die snappen minder van tehcniek/vinden het niet interessant). Natuurlijk wel altijd dat ze dingen niet meer terug kunnen vinden nadat ze de inapp browser afsluiten... Ik kan mij voorstellen dat je als maker van websites dit niet wilt hebben en het is ook niet gebruiksvriendelijk of goed voor je privacy, dus het zou mooi zijn als hier iets aan gedaan kan worden (zonder de goede usecases te saboteren natuurlijk)
Staat een beetje los van de discussie om wel of niet in-app browsers te gebruiken maar voor het lezen van een rijbewijs, ID kaart of paspoort kan toch tegenwoordig makkelijk de NFC reader gebruiken en heb je toch helemaal geen derde partij meer voor nodig?
Tegenwoordig zijn er regels omtrent deze soort identificatie. KYC is in dit geval een must en daarvoor wordt vaak een derde partij gebruikt.
En die kun je dan toch netjes proxy-en via je eigen servers. Hou je daar ook nog zicht op.
De laatste keer dat ik keek (en dat is een jaartje geleden). Was ondersteuning voor NFC nog steeds heel wisselend in telefoons.

Zelfs als de meeste telefoons de hardware hadden, dan hadden ze lang niet allemaal de drivers om elk type tag te herkennen en gebruiken. En er zijn nog al wat verschillende types.
Er zijn echter ook genoeg "apps" die eigenlijk niets anders dan een wrapper rond een browser zijn, je kunt dus volgens mij niet zomaar in-app browsers verbieden, dat zou teveel problemen veroorzaken. Beste is als OS maintainers (zoals Google voor Android/AOSP en Apple voor iOS) gewoon in-app browsers niet meer gaan ondersteunen. Waarom dat per se via een Europese Wet zou moeten ontgaat mij even. Pak het probleem bij de kiem aan en forceer daarmee dat ontwikkelaars goede native apps bouwen.

[Reactie gewijzigd door CH4OS op 28 maart 2024 10:33]

Ik heb zo'n hekel aan wrappers!
Toon iets een de browser of bouw een app.

Maar wat er nu gebeurt is rete irritant. Je denkt een offline app te hebben, maar als je internet weg is dan werkt niks meer.

Ik zie er ook het nut echt niet van in. Als je wil ver-SaaS-en, bouw dan gewoon een website voor de browser en basta. Iedereen blij én het is duidelijk.

Bijkomend voordeel is dat ík de keuze van browser heb, met bijbehorende extensions/plugins en (gebrek aan) tracking.
Nou ja, met een dergelijke wrapper app kun je wel weer veel sneller een app ontwikkelen. Anders moet je wellicht een complete API eerst nog gaan optuigen voor de backend. ;)
De vraag is dan, is dat een probleem van de gebruiker/afnemer?

Ik denk dat het te snel willen ontwikkelen nu parte gaat spelen voor de gebruikerservaring. En dat is geen goede ontwikkeling.
Kosten baten analyse. De (in de meeste gevallen beperkte) performance hit waar de gebruiker amper iets van merkt is een kleine prijs als je maanden van je development traject af kunt halen, maakt de ontwikkeling van de software een stuk goedkoper + je kunt een breder scala ana developers aantrekken, aangezien het minder specialistisch is.

Klinkt als 'ja maar gebruiker', maar ook de gebruiker is niet heilig, als 90% van de gebruikers een app in een bepaalde staat accepteert, dan is het goed genoeg. (en goed genoeg is goed genoeg).

OT. Ik wist trouwens niet dat zo veel apps een eigen interne browser implementatie hadden, dat is echt wel een dingetje. Ze kunnen heel je hebben en houden jatten, alle account gegevens en wat nog meer. Ben het er wel mee eens dat dat verboden moet worden (gaat verder dan JS injectie, want met een eigen implementatie kun je overal bij, je hoeft je niet te beperken tot de toegang van JS).

[Reactie gewijzigd door jhaan1979 op 28 maart 2024 11:33]

Dat kan wel degelijk een veiligheidsissue zijn voor de gebruiker. Als bijvoorbeeld een oudere versie van een browser gebruikt wordt waar een lek in zit dat actief misbruikt wordt, kan dat wel degelijk de gebruiker in de problemen brengen, zonder dat die dat weet of doorheeft.
En de gebruikte engine kan dit niet hebben?

Beetje lood om oud ijzer.
Wat ook handig is: stukje bij beetje je app uitbreiden met "echte" functionaliteit, maar al de gehele functionaliteit kunnen aanbieden met een in-app-browser / webview die op de achtergrond al de authenticatie regelt.
Als je die route bewandelt is het zonde van de tijd om eerst de wrapper op te tuigen. Een app uitrollen moet geen doel op zich zijn, ook een app kan wat mij betreft beter voor kwaliteit dan snelheid gaan.
In het specifieke geval waar ik hier mee te maken had, is de website prima bruikbaar maar was er een grote wens om snel ook via de appstore vindbaar te zijn.
Alle onderdelen werkten perfect via een webview maar worden niet allemaal even veel gebruikt. Daarom eerst de meestgebruikte opgezet als "echte" app en per tab bepaald of het via een webview of echte app code weergegeven wordt.

Betreft een website met 101 opties waarvan er 10 veel gebruikt worden. Prima zo.

[Reactie gewijzigd door TotallyJorden op 28 maart 2024 17:53]

Daar hebben we toch gewoon PWA voor?
Die API heb je waarschijnlijk toch al gemaakt voor je website...
Nee, ik vind dat een app ook echt een app zou moeten zijn; anders verwijs je de mensen maar naar een mooi url. Dat scheelt je meteen weer het werk van een "nep app" ontwikkelen.

Los van dat ik ook geen voorstander van wrappers ben, vind ik vooral het injecteren van javascript nogal kwalijk; dat is nogal een potentieel privacy- en veiligheidsrisico.
tijdje onder een steen gelegen? PWA's hebben gewoon support voor offline. Daarnaast heeft een goede webapp ook nog native functionaliteiten zoals push notificaties, authenticatie en nog wat meer. Het is vooral de UI die in een browser gerenderd wordt in de plaats van native.
Er zijn ontzettend veel PWA's die niet van native te onderscheiden zijn. Geen gebruiker die dat kan vaststellen. Spotify, Uber zijn bijvoorbeeld hybride apps. Durf te wedden dat je niet kan zeggen welke onderdelen native zijn en welke web.
Hybride is geen pwa. Ik weet zeker dat spotify niet goedkoop was om te maken. Hun hele unique sellingpoint is een gebruiksvriendelijke app, daar komen investeringen bij kijken waar je u tegen zegt. De app loopt soepel, doet wat het moet en houdt zich redelijk aan wat ik van een android app verwacht.

Ik heb net even uber geïnstalleerd om te kijken, wat een gedrocht is dat. Ik kan prima zeggen welk deel native is: geen deel is native. De registratie loopt in een browser als ik het zie, en de rest is zeer zeker niet native aan de slechte transities en oppoppende onderdelen te zien. Dus die hebben steken laten vallen.
Spotify... Tja. Na de eerste login wordt ik meteen doodgegooid met cookie acceptatie schermen.

Het zou kunnen dat ik onwetend pwa's gebruik.

In dat geval kan je mijn commentaar lezen met betrekking op de pwa's waar ik amper gebruik van kan maken door broddelwerk.
Ze bedoelen hier dan ook in-app browsers en niet gewoon iedere webview. Aka. verbied dat apps links mogen openen in zichzelf. Niet dat die apps geen gebruik meer mogen maken van een webview.
Dat snap ik, maar ook de wrapper apps kunnen dus die JavaScript code injecteren, dat moet je dus ook niet willen. Dan is het beter om het OS breed de support voor dat soort zaken te staken, omdat het gewoon potentieel onveilig is.
De grap van js code is natuurlijk wel het gemaakt is om een sandbox te draaien, de browser. Daar kan je verder niks mee behalve iets op die pagina, je kan niet eens bij andere tabbladen van een browser.
Maar gelukkig zijn browsers (ook embedded browsers) vrij van veiligheidslekken. Het zou zeker niet de eerste keer zijn dat een sandbox gewoon lekt naar de browser of zelfs het OS.
Maar juist door het feit dat het zo ontzettend gewild target is, ook het beste en snelste gefixt :)
Ik zou niet eens een app willen dat voor zoiets überhaupt vatbaar kan zijn. ;) Maar ja, door genoeg partijen dat dan inderdaad gedacht wordt 'not my problem, it's not my phone'... ;) Dat laat wel een stuk van de (imo slechte) mentaliteit van app ontwikkeling anno 2024 zien.
Wij zijn juist blij om volledig hybride te zijn. Praktisch geen native apps meer. Alles is nu SPA/PWA. Performance is nagenoeg gelijk. Users merken er niks van. En ontwikkeltijd is enorm verbeterd. Web, ios en android in 1. Natuurlijk zijn er aantal zaken die native blijven. Notificaties, inlog, bepaalde menus etc.
En dan heeft de gebruikte embedded versie van de browser een veiligheidslek. Ik zou er echt geen voorstander van zijn. Het is wat mij betreft echt een smerige manier om snel maar een app neer te kunnen zetten. Dat mag nooit het doel zijn. Zou je een andere opzet hebben, bijvoorbeeld dat de backend alleen een API is waarmee je vervolgens gaat praten, kan je prima ook een boel devtijd besparen. Echter kost dat aanzienlijk meer tijd en geld, terwijl altijd alles maar met haast en snel, snel moet. Haastige spoed is zelden goed, maar toch gaat men door.
Omschrijf veiligheidslek?. Waarom zou de embedded versie van de browser een lek hebben.
Als je doelt op remote code uitvoeren. Dat kan ook gewoon in native Java/Kotlin of Objective C.
Webapps is geen smerige manier om een app neer te zetten. Wij hebben meer dan 10m gebruikers in onze apps die al sinds begin an apps bestaan. We zijn er van overtuigt als bedrijf dat native apps (Afgezien van spellen en andere intensieve apps) goed vervangen kan worden door PWA's.
Ik denk dat je geen kennis hebt van software ontwikkelen, want de opzet van een PWA is precies gelijk aan een native app. Backend hetzelfde.
Ik heb genoeg strepen in software engineering zitten mag ik hopen, dat ik in elk geval een goede mening kan vormen. Jullie hebben dan wellicht een andere mening, dat is verder prima. Maar dat betekend niet automatisch dat iemand dan maar geen kennis heeft, je hoeft jouw mening dus ook niet als feit te verkondigen, dat is althans wel hoe jouw reactie nu op mij overkomt.
Niet meer ondersteunen als OS is wel tricky. Het is gewoon code die de leverancier van de app meelevert en draait. Een OS bevat niet zomaar en mogelijkheid om selectief code wel of niet uit te voeren, en dus ook niet de optie om het niet meer te ondersteunen.

Wat wel kan is dit weren met regels van app-stores, zoals die van apple en google play. Of een virus-scanner achtige constructie die het probeert te detecteren, maar dat is best complex en niet 100% accuraat.
Daar zat ik ook aan te denken. Mijn Home Assistant app is ook eigenlijk een in-app browser. Dat moet wel op die manier door alle customisation die mogelijk is. Anders moet je in de app ondersteuning voor elke obscure addon bouwen.

Maar de app gooit wel wat custom dingen in die web interface, zodat je de app kan instellen en de communicatie met je Home Assistant. Zo kan de app doorgeven waar je telefoon is (zodat als je naar huis gaat bijvoorbeeld de thermostaat alvast aan gaat) of hoe laat je wekker afgaat. En dat moet ook weer terugkoppelen naar de telefoon.

Ik weet zo nog niet of dat met een vrije keuze van browser engine nog wel nog kan.
Er zou onderscheid moeten worden gemaakt tussen de doelstelling van de in-app browser.

De Instagram app gebruikt 't nu om binnen de Instagram app te blijven als je op een url klikt. Dat vind ik persoonlijk irritant en zou misschien een keuze moeten zijn. M'n YouTube-login wordt dan b.v. niet opgepakt.

Er zijn ook in-app browser toepassingen dat een toevoeging heeft. B.v. het inloggen/authentiseren middels OAuth bij een platform. Als je dan in de app zelf blijft is dat imho prima
Die 'apps' die al dan niet stiekum een wrapper rond de standaard browser zijn zouden hier het probleem niet zijn. Die gebruiken de standaard browser. Tot je ze toevallig een keer via facebook of tiktok opent, dan komen ze in die broweser uit.....

Het probleem hier is juist de apps die met een eigen browser komen en daar de pagina's in laden die je via die apps tot je krijgt.
En ja, de app die al dan niet stiekum een wrapper rond een eigen browser zijn, die zijn hier wel onderdeel van het probleem.
De titel van het artikel is op dit punt verwarrend. Wat (mogelijk - het is maar 'n oproep) verboden wordt is niet het gebruik van een browser door / in een app, maar het gebruik van een eigen browser, die daarmee de browserkeuze en privacy instellingen van de gebruiker negeert.

(Ik vind juist veel te zeggen voor 'wrapper rond een browser' apps, zeker rond de default browser die de gebruiker al gewend is. Makkelijke combinatie van weinig (onderhouds)werk en een behoorlijk 'native' ervaring.)
Een app in een webview/browser is iets anders dan een app die een website opent in een browser van de app zelf. Het is heel goed mogelijk om dat onderscheid te maken. Is de website die wordt geopend van dezelfde service als de app, dan mag je doen wat je wilt, is de website van een andere service, respecteer dan de keuze van de gebruiker.
Dit gaat wel specifiek over externe links die in-app geopend worden, dat is prima op te lossen.

Er is ook altijd de optie "Open in xx" dus deze wrapper weet wel degelijk om welke context het gaat.

Het vreselijkste is nog wel dat je het voor elke app individueel uit moet zetten. Ik wil alles gewoon in mn daadwerkelijke browser zodat het ook fatsoenlijk in de historie komt te staan.
Stel, jij gebruikt de Duck-Duck-Go browser op je Android. Via de in-app browser worden jouw privacy instellingen in de Duck-Duck-Go omzeilt en worden alsnog allerlei gegevens van jou geharvest. En daar gaan Google (zelf één van de grootste overtreders met GMail) en Apple niks aan doen. Dus EU Commissie, een onderzoek asap.
Dus geen tweakers meer als 'app' ;)
Er zijn echter ook genoeg "apps" die eigenlijk niets anders dan een wrapper rond een browser zijn
De BePark app is zo'n draak van een app. Het is dat ze een service voor een best goede prijs leveren en daar in Brussel zo'n beetje monopolist in zijn, ander was ik al lang overgestapt.

Ik heb ze half voor de grap wel eens voorgesteld om het opnieuw voor hen te maken, maar dan met een fatsoenlijke user-experience. Het was half voor de grap, maar het zou niet bepaald moeilijk zijn om een betere app te ontwikkelen, dus ik zou het gedaan hebben wanneer ze hadden gereageerd. Voor de juiste prijs, natuurlijk. Maar ja, niks gehoord.

Als de app beter zou werken, zou het hun imago verbeteren. En een verbeterd imago levert doorgaans toch inkomsten op. Alleen al omdat het je de mogelijkheid geeft de prijzen te verhogen zonder dat half je klantenbestand in protest gaat en je bedrijf op TV gaat afzeiken. :D

Maar gezien hoe veel protesten er telkens weer in België zijn, denk ik niet dat Belgen erg goed zijn in het inschatten van de waarde van een goed imago. Het volk heeft nogal wat tegenstrijdigheden. Het zijn bijvoorbeeld hele lieve mensen als je ze op straat tegenkomt. Behalve als ze in een auto zitten... Dan veranderen ze in de grootste narcisten op Aarde.
Los van het injecteren vindt ik het bloed irritant want je kan niet terug naar waar je vandaan kwam zonder die 'browser' te sluiten. Gelukkig kan ik het in alle apps die ik op Android gebruik uitzetten (en dan wordt de default gebruikt).

Ik zou het prima als het dmv wetgeving wordt afgedwongen dat het niet mag/kan (als het niet nodig is). Voor inloggen oid via een website in een app kan ik me voorstellen dat het een nettere ervaring geeft dan dat je naar een andere app gestuurd wordt maar daar houdt het wel op...

[Reactie gewijzigd door watercoolertje op 28 maart 2024 10:33]

Wat ik dus begrijp gaat het hier niet om het wel of niet gebruiken van een webview waarbij je wel of niet in je app blijft, maar een eigen browser implementatie, dus eigen render engine en wat nog meer. Kortom, een eigen stuk code die volledige controle heeft over alle websites die je in die engine bezoekt.
Wat ik dus begrijp gaat het hier niet om het wel of niet gebruiken van een webview waarbij je wel of niet in je app blijft, maar een eigen browser implementatie
Dat is hun motivatie voor de klacht iunderdaad. De gewenste aanpassing slaat echter wel op alle in-app browsers, want ze willen dat die allemaal vervangen worden met een browser die de gebruiker zelf heeft gekozen...
Hoe en waar kan je t uitzetten in Android? Wil ik ook wel doen
Ik vind het vooral altijd zo vervelend dat je dan niet ingelogd bent.
De Outlook app heeft een tijdje een ingebouwde browser gehad die je niet kon uitschakelen dat was voor mij de reden om over te gaan op de gmail app.
Gmail op iOS opent standaard ook links in de app zelf (kun je wel wijzigen). Het is nog steeds safari natuurlijk, maar als je bijvoorbeeld begint met inloggen in Gmail en je moet autoriseren met digid of je bank app dan kom je daarna in de gewone browser en wordt je sessie niet herkend.

Toch laat ik het wel aan staan want vind het vaak wel handig om even naar een gelinkte pagina te kijken die daarna ook gelijk weg is ipv dat ik er aan moet denken de tab weer te sluiten.
Maarja, op iOS heb je niet echt de keuze voor je eigen browser, want dat zijn/waren voornamelijk maar skins over de iOS browser van Apple omdat die dat forceerden.
Sinds iOS 17.4 (en iPadOS 17.4) mogen browsers wel met eigen engine worden uitgebracht in de EU. De vraag is allen of en wanneer browsers dat gaan doen, want dan moeten de ontwikkelaars twee apps bijhouden. De EU versie en de versie voor de rest van de wereld.
Kan dat nu nu wel uitgeschakeld worden?
Geen idee ben nooit terug gegaan
Ah, dat zou echt een zegen zijn. In-app browsers zijn benauwend. Je kunt weinig, de gebruikelijke knopjes en zo zijn er niet en als het echt custom is, dan werkt het vaak nog ongelooflijk traag ook. Dat Android het met de standaard browser oplost is leuk, maar nog steeds is je interface beperkt. Het eerste wat ik doe is menu > openen in ...
Binnen iOS is dit erg fijn en handig. Doorgaans is het kort nodig en je hebt altijd de escape om het item in je browser te openen. Ik vind een in-app browser veel fijner, al dat heen en weer tussen apps vind ik erg irritant.
Ik kan me wel voorstellen dat als je normaal browser X gebruikt, dat de in-app weergave vanuit Safari is, en je dus cookies/account/etc niet in dat venster kunt gebruiken.
Hoe ingewikkeld zou het voor (in dit geval) Apple zijn om browser X zijn eigen in-app browser te gebruiken?
Misschien dan ook Microsoft tot de orde roepen.
Office desktop apps kunnen niet middels group policy of intune worden ingesteld om de standaard browser te respecteren. Alleen wanneer je Enterprise licenties afneemt.
Heb ook echt nooit begrepen hoe bijvoorbeeld Apple dit een prachtig idee vond terwijl ze overal hameren op gebruikersvriendelijkheid.

Hoe vaak je dan door zo’n in-app browser naar een login scherm gestuurd wordt en vervolgens nog keer moet inloggen. Echt hilarisch hoe je als ontwikkelaar dat kan opleveren en dan denken dat je lekker bezig bent.
Mooi ja, maar dat betekent eigenlijk wel het deprecaten van de standaard Android webview wat een heleboel oudere apps stuk zal maken.

Ik vind het zelf altijd wel fijn als een app de door mij gekozen browser gebruikt, want dat is firefox en dan krijg ik dus meteen alle addons mee zoals uBlock Origin en Dark Reader <3
Ik snap dat men 'vervangende' browser oplossingen weg wil hebben, maar bijv een oauth login voor een app is wel handiger met een in app browser. Of een stukje service paginas als webview ipv native.

Men zou de eis voor de gekozen browser moeten respecteren en evt dat soort tracking js moeten verbieden.

[Reactie gewijzigd door - peter - op 28 maart 2024 10:41]

Ik wilde gisteren mijn prepaid opladen bij mijn provider. Dan gaat er in de app een browser open (Chrome) waarop de PayPal website verschijnt. Je kunt kiezen voor aanmelden of kaartgegevens invullen. Ik klik op aanmelden en vul mijn emailadres in. Als ik dan op volgende klik om mijn wachtwoord in te vullen kom ik weer terug bij de eerste pagina met aanmelden of kaartgegevens invullen. Dit is vervolgens een infinite loop. De andere betaalmethodes werkte ook allemaal voor geen meter. Uiteindelijk heb ik het maar via de PC gedaan waar het meteen in 1x lukte. 8)7
Ja herkenbaar. Of een mail van de provider met een inloglink.
Klik je op, kom je op website die naast inlog nog een code naar je mailadres stuurt.
Maar je mail is reeds geopend in de website.. dus teruggaan zorgt hoor herhaling van stappen. Irritant.

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