ession-recording legt je scherm-interactie vast, en maskering moet je bewijzen
Session-replay-tools nemen je tik-, scroll- en invoergedrag op alsof iemand meekijkt. De maskering van gevoelige velden is meestal view-gebaseerd: ze werkt alleen als de juiste velden als gevoelig zijn gemarkeerd. Of het echt maskeert kun je niet aannemen; dat moet frame voor frame op de opname zelf worden geverifieerd. Een claim 'wij maskeren' zonder die verificatie is onbewezen.
Wat session-recording vastlegt¶
Session-recording legt vast hoe je een pagina gebruikt. Je muisbewegingen, je kliks, wat je typt, hoe ver je scrolt. Bij elkaar is dat een reconstructie van je gedrag op het scherm, soms tot een bijna letterlijke opname van wat er te zien was. De tools die dit doen heten session-replay: producten van het type Hotjar, FullStory, Microsoft Clarity, of een eigen implementatie op basis van de open-source recorder rrweb.
Technisch werken die tools niet met video. Ze nemen de DOM op, dat is de structuur van de pagina zoals de browser die opbouwt, plus een stroom gebeurtenissen: op tijdstip t bewoog de muis hierheen, hier werd getikt, hier veranderde een invoerveld. Bij de eerste opname wordt de volledige pagina als momentopname vastgelegd, en daarna alleen nog de veranderingen. Die opzet is efficiënt en het maakt de heropvoering nauwkeurig, want elke muisbeweging en elke toetsaanslag zit erin. Precies die nauwkeurigheid is de reden dat gevoelige invoer mee kan komen als de maskering een veld overslaat. Bij het afspelen bouwt de speler de pagina opnieuw op uit die opnames. Het resultaat oogt als een video, maar het is een heropvoering van jouw sessie in de browser van de analist. Precies omdat het de DOM meeneemt, kan de inhoud van invoervelden in beeld komen.
Maskering is een belofte tot ze bewezen is¶
Aanbieders zeggen dat gevoelige velden worden gemaskeerd. Een wachtwoord, een burgerservicenummer of een medische invoer zou dan niet meekomen in de opname. Dat klinkt geruststellend, en het is een instelling die goed moet staan om te werken.
De maskering is meestal view-gebaseerd. Ze werkt alleen als de juiste velden als gevoelig zijn gemarkeerd. In de praktijk gebeurt dat met een CSS-klasse of een attribuut op het element. Bij Hotjar is dat data-hj-suppress, bij FullStory fs-exclude of fs-mask, bij rrweb-achtige opzetten een klasse als rr-block of rr-mask. Ontbreekt die markering op een veld, dan wordt de inhoud gewoon opgenomen. De maskering vergeet niets uit zichzelf. Ze maskeert precies wat iemand vooraf heeft aangewezen, en niets daarbuiten.
Daarom behandel ik maskering als een claim die bewezen moet worden. Zolang niet is aangetoond dat ze werkt, is het een belofte. Een uitspraak "wij maskeren" zonder verificatie is onbewezen. Dat is geen wantrouwen tegen de aanbieder, het volgt uit hoe de techniek in elkaar zit.
Waarom je het frame voor frame moet controleren¶
Of maskering echt maskeert kun je niet aannemen. Het moet op de opname zelf worden geverifieerd, want daar staat wat er werkelijk is vastgelegd. Een instelling in een dashboard zegt wat de bedoeling was. De opname zegt wat er gebeurde. Die twee kunnen uiteenlopen als één veld de markering mist.
De verificatie kan aan de kant van de vastlegging beginnen. Session-replay-tools sturen de opgenomen DOM en gebeurtenissen als een payload naar hun eigen server. Die payload is te onderscheppen. Een ruwe aanpak:
# vang de opname-payload en zoek naar wat er in de velden stond
jq -r '.log.entries[]
| select(.request.url | test("hotjar|fullstory|clarity|rrweb"; "i"))
| .request.postData.text' capture.har > replay-payload.txt
# staat een testwaarde die je in een gevoelig veld typte er letterlijk in?
grep -F 'TESTGEHEIM123' replay-payload.txtVul ik een herkenbare testwaarde in een gevoelig veld en vind ik die letterlijk terug in de payload, dan is de maskering aantoonbaar lek. Dat is dan gemeten. De payload is versleuteld op transport, dus het onderscheppen vraagt een proxy die het verkeer tussen browser en aanbieder openbreekt. Voor een eigen test op mijn eigen invoer is dat legitiem en voldoende. Ik werk met een vaste, onmiskenbare testreeks, zodat een treffer geen toeval kan zijn en een misser echt op afwezigheid wijst. Vind ik hem niet, dan is de maskering op dat veld in dat geval geslaagd, ook gemeten, maar alleen voor dat veld en die pagina. Eén schoon veld bewijst niet dat alle velden schoon zijn. De volledige controle vraagt dat je elk gevoelig veld nagaat, want de markering kan per veld ontbreken.
Waarom de context zwaar weegt¶
Op een gewone pagina is een schermopname al indringend. Iemand kijkt mee over je schouder terwijl je een winkel doorloopt. Op een pagina waar je persoonlijke of medische gegevens invult, wordt het risico veel groter. Daar raakt een verkeerd afgestelde maskering precies de gegevens die niemand hoort te zien.
De AVG verzwaart dat oordeel. Gezondheidsgegevens vallen onder de bijzondere categorieën van artikel 9, met een verwerkingsverbod behoudens beperkte uitzonderingen. Voor het plaatsen van de opname-scripts op je apparaat geldt bovendien artikel 11.7a van de Telecommunicatiewet, dat toestemming vraagt voor het lezen en schrijven van gegevens op randapparatuur. Een session-replay-tool die op een medisch formulier meekijkt, combineert dus twee zware verplichtingen: de toestemming voor de opname zelf en de bescherming van de gevoelige inhoud die erin terecht kan komen. Als de maskering daar faalt, faalt ze op het gevoeligste moment.
Wat het onderscheidt van gewone analytics¶
Gewone analytics telt gebeurtenissen. Een pagina bekeken, een knop ingedrukt, een formulier verzonden. Dat levert aantallen op. Session-recording levert een reconstructie op van één specifieke sessie, met de volgorde, de aarzeling, de terugklik en de inhoud van velden. Het verschil is de mate waarin een individu herkenbaar wordt.
Dat verschil telt voor de AVG. Een reconstructie van iemands scherm kan persoonsgegevens bevatten, ook als de tool geen naam kent, want het gedrag zelf is identificerend genoeg om een persoon te onderscheiden. Bij een medisch of persoonlijk formulier komt daar de inhoud van de velden bovenop. De verwerking verschuift daarmee van tellen naar het vastleggen van individueel, deels gevoelig gedrag. De grondslag onder artikel 6 moet passen bij die zwaardere verwerking, en bij gevoelige inhoud komt de drempel van artikel 9 in zicht. Dat is een afgeleide juridische weging, en ze verklaart waarom ik session-recording strenger toets dan een teller.
Wat dit voor mijn werk betekent¶
Ik neem "wij maskeren" nooit op gezag aan. Ik behandel het als iets dat je moet bewijzen op de opname zelf. In mijn scans noteer ik de aanwezigheid van een session-replay-tool als gemeten, en het al dan niet maskeren als open tot ik het frame voor frame heb gecontroleerd. Zolang die controle ontbreekt, is het risico reëel en de geruststelling leeg.
Dat sluit aan bij twee regels die ik breder aanhoud. Een weigering stopt zulke scripts niet vanzelf, want ze kunnen al vóór of buiten de toestemmingsvraag laden, zie Niet alles vuurt bij opstart, sommige trackers wachten op jou en Cookies weigeren scheelt echt, maar reken er niet blind op. En hoe gevoeliger de context, hoe hoger de lat, zie Hoe gevoeliger de context, hoe langer de identifier meegaat. Een schermopname op een medisch formulier verdient de zwaarste toets die ik heb.
Zie ook Cookies weigeren scheelt echt, maar reken er niet blind op, Niet alles vuurt bij opstart, sommige trackers wachten op jou en Hoe gevoeliger de context, hoe langer de identifier meegaat.
- Eigen bevinding: menzis triage zoekterm matomo, 2026-07-20session-recording in native modus, twaalf maskerende klassen, zoekveld niet gemaskeerd