Weggeknipte info uit Windows-screenshots is terug te halen door bug

Weggeknipte info uit screenshots gemaakt met Knipprogramma uit Windows is terug te halen door een bug. Dat zegt een onderzoeker. Hij publiceerde recent over dezelfde bug die werkt op Pixel-telefoons.

Onderzoeker David Buchanan bevestigt bevindingen van software-engineer Chris Blume dat de bug aCropalypse ook werkt op Windows. Door de bug zijn delen die zijn weggeknipt of geblurd in de originele afbeelding deels of helemaal te reconstrueren. Dat komt doordat de software de bytes van de originele afbeelding niet verwijdert, maar alleen overschrijft en delen die niet zijn overschreven dus nog in het bestand achterblijven.

Dezelfde exploit werkt met minimale aanpassingen, zo zegt Buchanan. De pixelindeling is anders, want Knipprogramma, in het Engels Snipping Tool, gebruikt een RGBA-indeling, rood-groen-blauw-alpha, tegenover de RGB-indeling van de Pixel-telefoons.

Microsoft heeft nog niet gereageerd op de bevinding, waardoor mogelijk privégegevens van screenshots achterhaald kunnen worden. Google heeft al wel gereageerd: het bedrijf heeft de bug gefikst in de maart-update voor veel van zijn Pixel-telefoons. De bug zit sinds Android 10 in het systeem en komt door een fout die al een paar jaar bekend was. Het is onbekend of er misbruik is gemaakt van het lek.

Knipprogramma Windows 11 aCropalypse
Knipprogramma Windows 11 aCropalypse: weggeknipte informatie is te reconstrueren

Door Arnoud Wokke

Redacteur

22-03-2023 • 08:38

91 Linkedin Whatsapp

Reacties (91)

91
90
41
9
0
19
Wijzig sortering
Belangrijke sidenote is dit alleen gebeurt als je een screenshot opslaat -> bijknipt -> weer opslaat.
Hoewel dit natuurlijk wel voorkomt is dit volgens mij niet de gebruikelijke werkwijze van de meeste mensen die het gebruiken, dus dat scheelt nog in de impact.
Alsnog een kwalijke zaak :(
Je zou toch verwachten dat de afbeelding volledig opnieuw uitgerenderd wordt wanneer je opnieuw opslaat. Microsoft doet dit waarschijnlijk niet zodat je achteraf gemaakte aanpassingen (deels) kan terug draaien? Hoe dan ook kunnen ze dit toch verhelpen met een prompt: "Wil je volledig opnieuw opslaan, aanpassingen kunnen niet terug gedraaid worden, ja of nee."
Het is een bug, als ze daar vanaf hadden geweten dan zouden ze het gewoon hebben opgelost, geen prompt hebben ingebouwd.
Op het blog van de vinder staat een uitleg over hoe de bug bij de Pixel telefoons werkt. Tldr; als je een afbeelding cropt dan wordt de nieuwe afbeelding een kleiner bestand. Google heeft vanaf Android 10 een API gewijzigd waardoor bij het opslaan van een kleinere versie van een bestaand bestand, niet eerst de oude data wordt verwijderd. Dat betekend dat alleen het eerste deel van het oude bestand wordt overschreven. De rest van de blog gaat over hoe je de gecomprimeerde incomplete data uit de rest van het bestand kunt uitlezen.

Een bug die op te lossen is door Google met 1 karakter; open het bestand in 'wt' (write truncate) modus in plaats van 'w' (write) modus.
De echte bug is juist dat Google die API zonder duidelijk te communiceren aanpast. Voorheen was 'w' gewoon met truncate.

Wat ook de UNIX standaard is sinds mensenheugenis. 'wa' om te appenden
Zoiets zal het bij windows ook zijn. Ergens OF_CREATE toevoegen ofzo.
Zou betekenen dat als je Save As gebruikt het probleem zich niet voordoet. Geen idee of dat ook daadwerkelijk zo is…
Als je in een nieuw bestand opslaat, heb je hier inderdaad geen last van.
En als ik dat doorstuur, of post op social media etc, waar post processing gebeurd, dit dus ook geen issue is? Dus vooral van toepassing op files die ik direct bewerk via mijn eigen systeem, het origineel en die kopieer naar een cloud share of netwerk share etc.
Ja, is een BUG of op z'n minst unexpected behaviour. Maar er is nu wél een feature van te maken.
Gewoon een sloppy programmer. Er is nooit over nagedacht. Dan is het geen bug. Een bug is als iets fout gaat. Als je niet nadenkt en gewoon maar iets doet zodat het werkt, is het een soort undocumented feature. Unexpected behaviour impliceert min of meer dat je erover nagedacht hebt, maar vooruit, we keuren 'm goed.

Als je ziet hoe lang het ook in Android zat zonder dat het iemand opgevallen is, betekent ook dat niemand hier over nadenkt. Behalve dan die gast die het ontdekte, en ook dat was vast toeval.
Zo kun je elke bug wel wegredeneren want de computer doet het nooit fout, gewoon sloppy geprogrammeerd :z
Ja, maak er maar een karikatuur van. Onzin natuurlijk.
Dit is toch gewoon slordig geprogrammeerd? Het is niet alsof het programma fout loopt of niet werkt zoals bedacht. Je cropt en houdt een gecropt plaatje over. Works as designed. Dat als bij-effect het originele plaatje is te herleiden, is geen bug. Het stond waarschijnlijk niet in de eisen, anders was erop getest. En de programmeur heeft zelf ook niet bedacht dat het zo zou werken. Dus eigenlijk een ontwerpfout. Er is denk ik nooit bedacht dat het zo werkt en dat dit het resultaat is. Dan kun je toch niet spreken van een bug?
Een bug is een fout in een computerprogramma of een website, waardoor het zijn functie niet (geheel) volgens specificaties vervult.
Dus om te achterhalen of het echt een bug is, zouden we de specs moeten bekijken. Ik wed dat daar niet in staat dat je het afgeknipte deel expliciet moet overschrijven of op een andere manier niet meer terug te halen moet zijn.
Kan je niet volgen "unexpected behaviour" lijkt voor mij juist dat je er niet over hebt nagedacht, en dat je programma iets anders doet dan wat je verwacht hebt en ook wat anders dan wat je wilde doen...
Google maakt het zichtbaar, maar als Microsoft het origineel weggehaald had, had google dit nooit kunnen tonen. Het blijkt dus dat soms, ondanks geblur, toch het wachtwoord wat er achter de blur staat te achterhalen is.
Alleen jammer dat google en microsoft met DIK betaalde engineers niet in staat zijn dit te regelen voordat shit hits the fan.
De put dempen nadat het kalf verdronken is, telt niet als afdoende maatregel IMHO. Shareholder value is wat de klok slaat, blijkbaar niet multi billion user experience. Treurig hoor, google en microsoft!
Volledig opnieuw renderen (en daarmee coderen) is niet zo'n goed idee bij een jpg bestand, want dan gaat de beeldkwaliteit achteruit.
Daarom is er nu een short-cut genomen waarbij dát niet gedaan wordt en daar bovenop de weggeknipte, of met een blokje bedekte, content niet daadwerkelijk uit het bestand verwijderd wordt.
Dat laatste vind ik toch wel kwalijk, want privacy- en secrecy- concerns zijn niet van dit jaar, maar al sinds vera crypt met die "secret containers" aan de slag ging (en dat is al behoorlijk wat jaartjes geleden).
Je kunt een JPEG niet in place aanpassen. Je zult dus wel opnieuw moeten comprimeren. Zonder dingen als de originele DCT is het ook erg lastig om de extra pixels aan het einde van het bestand terug te halen.

Hier gaat het echter om PNG-bestanden. Die zijn (vaak) lossless opgeslagen, dus daarom kun je wel data terughalen. Zodra je de offset van de afbeeldingdata weet kun je de blokken pixels redelijk accuraat op hun oude plek neerzetten.

Dit is het resultaat van een write naar een bestand zonder eerste de oude data te verwijderen. De oude gegevens worden niet genuld en het bestand wordt niet getruncate, waardoor een gedeeltelijke write (wat logisch is als je nieuwe bestand kleiner is dan het origineel) oude gegevens achterlaat.
Kan wel degelijk, met beperkingen. Als je naar Irfan View kijkt, dan kun je een lossless rotate en crop uitvoeren. Maar je kunt inderdaad niet een stukje blurren oid tenzij het onderaan de afbeelding staat en progressive jpg gebruikt, dan zou je de laatste detailslag af kunnen kappen.

Daarnaast is er vaak ook nog een of meerdere thumbnails met verschillende resoluties embedded in een jpeg bestand opgeslagen, als je die niet verwijderd of aanpast dan heb je ook een probleem. Ik heb wel eens een file recovery gedaan met zo'n thumbnail om een foto te herstellen die op een floppy met bad sectors was opgeslagen. Het was niet perfect maar beter dan niets.
Hier kwam ik pas achter toen ik met AI aan de slag ging, zelfs van PNG plaatjes gepost om bepaalde websites kan je de AI prompt nog weer achterhalen met PNG info in Stable Diffusion.

Als je ze eenmaal door Photoshop haalt en opnieuw opslaat is het wel weg.
Je kunt JPG wel degelijk in-place aanpassen, alleen beperkt tot roteren en croppen.
Het gaat erom dat je data alleen kunt terughalen wanneer je het niet fatsoenlijk weghaalt en dat gebeurt dus niet terwijl dat wel zou moeten.
Dat truncaten van het einde van het bestand gebeurde eerder automatisch, maar door een foutje in de nieuwe versie van de library werkte de parameter voor het truncaten niet meer.
Nou, dat zou ik niet helemaal verwachten, want dat levert dubbele compressie-artifacten op. In ieder geval langs de knipranden. Nou is dat misschien alsnog beter dan stiekem informatie behouden die de gebruiker denkt weg te knippen, maar het is een afweging.

Dan nog wordt compressie meestal in kleine blokjes gedaan, en om compressie-artifacten tegen te gaan is het dus voldoende om enkel de blokjes die doormidden worden geknipt te behouden. Waardoor je een klein stukje weggeknipte data rond de randen zou kunnen reconstrueren maar niet het hele bestand.
Screenshot maken, weg knippen en daar een screenshot van maken , opslaan
Belangrijke sidenote is dit alleen gebeurt als je een screenshot opslaat -> bijknipt -> weer opslaat.
Volgens mij gebeurd dat maar al te vaak, zeker als je een "echte" screenshot neemt en dus je hele scherm (of meerdere schermen) als plaatje opslaat
Dat is lastig te voorspellen denk ik. Ik kan me voorstellen dat er mensen zijn die het zo gebruiken, maar er zijn ook hele volksstammen die gewoon [win]+[shift]+[s] gebruiken en dan krijg je het niet-geselecteerde deel van het screenshot nooit in een bestand en dus kan deze bug niet voorkomen. Die mensen zijn dus iig niet kwetsbaar.
Persoonlijk denk ik dat de gemiddelde Windows gebruiker niet eens afweet van Win+shift+s combinatie.

Moet zeggen gebruik die zelf ook nooit, moet ik maar eens gaan aanleren want ik gebruik altijd gewoon de snipping took

Printscreen op je toetsenbord is denk ik meer bekend bij de meeste mensen, en die maakt gewoon een plaatje van je hele scherm
Dat hangt overigens ook nog van je Windows-versie af denk ik, want op mijn Windows 11 doet die gewoon exact hetzelfde als [win]+[shift]+[s].

Overigens de snipping tool gebruiken op zich niet genoeg volgens mij, je moet het bestand opslaan en dan met de snipping tool overschrijven. Dus ook als je een fullscreen screenshot maakt met de snipping tool en die dan in de tool cropt en dán pas opslaat, dan bevat de afbeelding dus ook niet meer informatie dan de crop.
Kan je instellen wat printscreen doet, hele printscreen of snippingtool openen.

Overigens gebruik ik ook vaak alt+printscreen om 1 venster te forwarden.
Dit gebruik ik ook echt 50 keer per dag sinds ik dat weet haha.
Win + Shift + S, kadertje slepen om hetgeen wat je wil versturen en gelijk plakken vanuit clipboard. Ik sla bijna nooit wat op, laat staan dat ik het opnieuw ga croppen en weer opslaan.
Ik schrok even. Ik las croppen, maar dacht ook dat het impact had op het tekengedeelte, waarbij je je afbeelding kan maskeren door eroverheen te tekenen. Dat scheelt.
In theorie zou dat ook effect kunnen hebben. Je maakt een afbeelding beter comprimeerbaar door een complex deel van de afbeelding te vervangen door een blank vlak. Als het resulterende bestand kleiner is dan het originele bestand dan heb je kans dat het laatste stuk van het originele bestand nog deels terug te halen is. Dat zal dan wel om een kleiner stuk gaan dan bij (flink) croppen. En de kans dat het precies jouw uitgevlakte deel betreft is heel klein.

Probeer het eens uit!

[Reactie gewijzigd door Joolee op 22 maart 2023 09:20]

Helaas kan ik geen C++, maar als je zelf wil spelen: https://github.com/unrealwill/jpguncrop :)
Dat klopt inderdaad. De 'bug' zit hem in de manier waarop de Snipping Tool omgaat met het overschrijven van een PNG bestand. Er loopt dus helemaal niets mis wanneer je een screenshot neemt en die bewerkt om vervolgens te kopiëren en versturen. @arnoudwokke Mogelijks het artikel hier op aanpassen?

[Reactie gewijzigd door Skyline GT-R op 22 maart 2023 10:33]

Dus, niet met snippingtool.exe en daarin met gummetje erasen en plakken in bvb document of mail? (Of was het cuttingtool.exe..?)
Nee, niet met snipping tool over een al bestaand bestand heen schrijven.
Daarbij doet de bug zich ook alleen voor bij PNG-bestanden: https://twitter.com/wdormann/status/1638235267919233024

Klopt niet na wat verder onderzoek en een oplettende gebruiker.

[Reactie gewijzigd door Anonymoussaurus op 22 maart 2023 12:04]

Hoezo is dit niet de gebruikelijke werkwijze? Dit is juist wat hier ook vaak wordt gebruikt.

Bijzonder dat Microsoft dit nog steeds niet heeft gepatched wanneer dit al een paar jaar bekend is en Google er al een fix voor heeft uitgebracht.

De onderzoeker gooit het blijkbaar nu naar buiten om beweging te krijgen bij Microsoft.
Hoezo is dit niet de gebruikelijke werkwijze? Dit is juist wat hier ook vaak wordt gebruikt.
Serieus? Dus je slaat een plaatje eerst op, dan crop je hem en save je hem opnieuw?
Precies! Gewoon de welbekende knipprogramma gebruiken.
Hoe zit dat met GIMP?. Die gebruik ik veel. Om schermafbeelding of plaatje dingen te blurren. Daarna sla ik 'm weer op.
Er zijn een aantal tools beschikbaar om te detecteren of jouw afbeeldingen hiervoor kwetsbaar zijn, en om dit automatisch te verwijderen op Discord:David Buchanan heeft ook uitgelegd hoe je dit kan mitigeren op je server: https://twitter.com/David...?cxt=HHwWgoC2sY61sbwtAAAA

Trouwens, de bug doet zich alleen voor bij PNG-bestanden: https://twitter.com/wdormann/status/1638235267919233024 Blijkt niet te kloppen (andere website gaf foutieve informatie I guess).

[Reactie gewijzigd door Anonymoussaurus op 22 maart 2023 10:24]

Trouwens, de bug doet zich alleen voor bij PNG-bestanden: https://twitter.com/wdormann/status/1638235267919233024
In één van zijn Tweets geeft hij juist een voorbeeld van deze bug bij JPEG's, of begrijp ik iets verkeerd?
Ah, ik had die informatie van een andere site. Daar zeiden ze dat het alleen PNG's betreft. :/
Beetje onduidelijk uit het artikel in hoeverre dit nu opgaat voor Windows 10 maar dit lek is niet te gebruiken op afbeeldingen die zijn bewerkt met de Windows 10 Snipping Tool. Het lek is wél te gebruiken op afbeeldingen die zijn bewerkt met Windows 10 Snip & Sketch.
Wow dit is best wel kwalijke zaak, stuur je snapshot waar je gevoelige gegevens uit wegknipt, staan ze er gewoon nog in! Ik vraag mij af, als je de marker gebruikt om te doorstrepen van url oid, kan dat ook ongedaan worden?
Enige nuance hier is dat dit alleen werkt als je een screenshot maakt, opslaat, vervolgens in Snipping Tool zelf nog cropt en dan vervolgens het originele bestand overschrijft. Gewoon een screenshot maken en vervolgens croppen zonder eerst op te slaan werkt gewoon zoals het hoort.

Dat zijn toch iets meer, en voornamelijk veel minder voorkomende stappen dan een screenshot maken op je Android toestel en dat doorsturen waar het gewoon altijd gebeurd voor zover ik die bug heb begrepen.
Ik verwerk voor me werk regelmatig paspoorten, dan krijg je mensen die op een PDF een zwart vlak zetten over bv hun foto of BSN nummer in de onderste regel.

Niet beseffende dat ik gewoon dat zwarte vlak weer kan verplaatsen als ik de PDF open.. 8)7
Anoniem: 685461
22 maart 2023 08:46
De hamvraag is dan: Is het een bug of is het een (secret) feature? :)
Juist, lijkt mij eerder iets dat bewust is gedaan, want een screenshot waar je iets uit wegknipt zou normaal opnieuw geencodeerd worden als een losse image, en dus niet de betreffende info bevatten. Het is geen layered image.
Het heeft niets met herencoderen te maken, maar met de manier waarop de file voor schrijven geopend wordt. Dit is hetzelfde als bij de Pixel/Android bug een paar dagen geleden.

Je kan een file op een aantal manieren openen voor schrijven. Eentje opent de file voor schrijven en behoudt de content (typisch gebruikt voor een append), terwijl een andere de file opent en de filesize op 0 zet (dus de inhoud weggooit). Deze laatste wordt truncate genoemd. Beide manieren van openen gebruiken typisch dezelfde functie, maar verwachten een extra of andere flag als parameter (bij android was het bvb "w" vs "wt").

Voor een nieuwe file gedragen beide variaties zich hetzelfde: de file bestaat immers nog niet, en is dus 0 bytes groot.

Als een file die reeds bestaat geopend wordt is er wel een verschil. Zonder een seek operatie (bvb naar einde file voor een append) zal de versie zonder truncate enkel het begin overschrijven en de rest als onderdeel van de file behouden: oude data blijft dus bestaan. Die data kan je dan gebruiken om de file te herstellen. Bij een truncate is de inhoud van de file hetzelfde als de weggeschreven data en blijft er dus geen oude data achter.

Alles lijkt eerder te wijzen op een slordigheid, bvb "w" ipv "wt" meegegeven (afhankelijk van de api) dan dat dit bewust gedaan is. Bij de Pixel/Android versie kwam het door een ongedocumenteerde verandering in de File-io API: waar vroeger "w" impliciet een truncate deed, was dat in een nieuwe versie plots niet meer het geval.
Oh, en wat als je een undo functie hebt? Dan heb je toch tussenliggend layers nodig. Het lijkt mij veel waarschijnlijker dat het een bug is.
Zolang je de image in het programma open hebt, kun he undo doen, daarna moet het gewoon pleite, bij formaten als jpeg en png.
Behalve een deja-vu roept dit de vraag op: Als dit bij bijgeknipte screenshots gebeurt, gebeurt het dan ook bij allerlei andere bestanden?
Ja. Waarschijnlijk wel. Word-bestanden deden dat bijvoorbeeld zodat je tekst die was verwijderd of aangepast terug kon zien. En er zullen vast wel meer bestandstypes zijn waar dat nog steeds gebeurt, bewust (om de edit-history te bewaren) of door een bug.

Ik bedenk net dat er ook image-formaten zijn waar je meerdere afbeeldingen in één bestand kunt opslaan maar waarbij die feature zo weinig gebruikt wordt dat sommige applicaties alleen iets doen met de eerste afbeelding in de file. Kan ook leuke verrassingen opleveren als je denkt gevoelige informatie weg te halen en dan later blijkt dat er meerdere afbeeldingen in dat bestand stonden die jij in jouw editor niet hebt gezien.

[Reactie gewijzigd door downtime op 22 maart 2023 10:15]

Dit zou ook een verklaring kunnen zijn van op het eerste gezicht onverklaarbare verschillen in bestandsgrootte (wat ik wel eens heb meegemaakt) tussen een bestand wat je ooit hebt bewaard, later aangepast en opnieuw bewaard enerzijds, en een bestand wat is gemaakt met puur een kopie / plak-actie daarvan door de gebruiker.

Beiden zien er precies hetzelfde uit, bevatten vanuit het oogpunt en ervaring van de gebruiker precies dezelfde informatie, maar achter de schermen dus niet.
Gebruik zelf al jaren nu Greenshot voor alle screenshots welke nodig zijn, vind het ook een stuk fijner werken dan de native van Windows. Hopelijk verhelpen ze het wel snel, veel collega's gebruiken het wel namelijk.
Klopt , sinds een paar maanden ook hier de default sniping tool geworden. Simpel met handige features. Zelfs noobs hier snappen het en vinden het een vooruitgang.
Wat is er niet te snappen aan de standaard sniping tool van windows? toetscombinatie, selecteren wat je wilt en je hebt je screenshot..... Je moet toch wel heel erg braindead zijn als je dat niet begrijpt.
Dat bedoel ik ook niet, ik zeg alleen dat Greenshot meer functies te bieden heeft en vaak zijn tools met meer functies niet goed te begrijpen door noobs, vandaar mijn opmerking.
Dus hetgeen m'n collega's doen, een screenshot maken van een screenshot waarin zaken zijn weggeknipt, is helemaal zo gek nog niet.
Dan nog even met je telefoon een foto van je beeldscherm maken, uitprinten en met een stift erover :+
Handig hoor! Die technologie! Maakt alles zo makkelijk :+
daarna wel even kopiëren natuurlijk anders kan je het gewoon tegen het licht houden :o

[Reactie gewijzigd door pennywiser op 22 maart 2023 10:33]

Kan nog gekker.
Screenshot in Word bestand geplakt, en dáár weer een screenshot van gemaakt.

I kid you not, sommige mensen excelleren in het vinden van de meest on-intuitieve manieren om een foutmelding te delen.
Als ik een foto of iets dergelijks ergens deel dan maak ik altijd een screenshot (gecropped met behulp van bijvoorbeeld Greenshot), niet alleen om zeker te weten dat geblokkeerde stukken niet perongeluk als layer meekomen (en de data erachter dus vrij simpel is te achterhalen door die layer uit te zetten, of in dit geval een bug die de data niet correct overschrijft en afkapt), dat maar ook om alle metadata eruit te trekken. Bij de meeste sites worden de plaatjes hergecomprimeerd en word het server-side eruit gehaald dus is meestal geen probleem, maar bijvoorbeeld Discord doet niets met het bestand behalve het op hun CDN zetten.

Dan heb ik liever niet dat als ik perongeluk de GPS op mijn telefoon aan heb staan dat de locatiedata in de foto ge-embed worden en daarna het halve internet over gaat. Ik heb vaak genoeg een foto die ik op het internet heb gevonden door een EXIF reader gehaald en ben toen verrassend veel data tegengekomen.

Een screenshot is gewoon puur de foto data zoals die op mijn scherm werd getoond maar verder bevat het niets.
Dit doet mij direct terug denken aan de The Underhanded C Contest van 2008. Een wedstrijd om een C-programma te schrijven voor een bepaalde taak die op het oog perfect zijn werk doet, maar ook een listig verborgen fout bevat die de taak ondermijnt. Opdracht voor 2008: Schrijf een programma dat een regio van een plaatje masked/zwart maakt.

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