Is een tracker in je e-mail legaal?

| AE 9290 | E-mail | 56 reacties

Een lezer vroeg me:

Ik krijg de afgelopen tijd veel emails met een zogenaamde email tracker. Dit houdt in dat de verstuurder precies kan zien door wie en wanneer zijn email wordt geopend. Dit is een redelijk beangstigend gevoel omdat ik niet weet wat er allemaal wordt bijgehouden door de verzender. Mag dat zomaar?

Email trackers zijn op zich niet nieuw, maar ze stijgen snel in de belangstelling. En nee, ze zijn niet legaal.

Het basisidee van e-mailtracking is dat je iets opneemt in het mailbericht dat je op afstand kunt uitlezen. Een bekend voorbeeld is een doorzichtige pixel opnemen die op een externe website staat. Als die pixel wordt opgehaald, dan moet dat wel zijn omdat de ontvanger het mailbericht ging lezen en zijn mailprogramma die afbeelding meende nodig te hebben.

Steeds meer maildiensten werken met HTML, en je kunt dan zo ongeveer een complete webpagina met alles erop en eraan opnemen. Inclusief tracking scripts, cookies of wat je maar wil. Zo kun je dan bijvoorbeeld uitlezen wat voor mailprogramma iemand gebruikt, hoe lang hij de mail leest, of hij op links klikt en ga zo maar door.

Dit is dus waar de cookiewet tegen bedoeld is. E-mailtrackers vallen onder het wettelijke begrip “gegevens opslaan of uitlezen” van andermans computer of telefoon. Of je dat nu doet vanuit een website of via een mail doet er niet toe. Zodra je gegevens wilt opslaan of juist wilt ophalen van iemands computer, zegt de cookiewet dat er toestemming voor nodig is.

Op een website is dat simpel, althans in theorie: een popupscherm of kadertje waarin wordt uitgelegd wat cookies zijn, en een knop om wel/geen toestemming. In de mail is dat veel lastiger, want volgens mij kunnen mailprogramma’s niet zomaar die dingen laten zien. Dit nog afgezien van dat daar de cookies en tracking scripts al worden gezet voordat je op ‘ja’ zou kunnen klikken, wat sowieso niet mag van de cookiewet. Dus nee, die dingen zijn niet legaal.

Arnoud

Deel dit artikel

  1. Mijn mailprogramma staat zo ingesteld dat hij remote content pas na een click inlaad, dus dan geef ik toestemming. Of eigenlijk; dat is soms de enige manier om de mail uberhaubt te lezen, maar je weet ook dat zodra je die knop aanclicked je getracked word, dus per mail moet je bepalen of dat het waard is (hint: vrijwel nooit). Dat hoeft niet met een pixel te zijn, elk remote element kan dat al.

      • Ligt eraan om wat voor mail het gaat.

        Als een overheidsdienst zo’n systeem gebruikt is het niet vrijwillig. Als het gaat om een mail van een commerciele partij kan je die niet openenen en kiezen om geen zaken met deze partij te doen.

        Maar ook voor dit laatste kan het weer een probleem worden, indien alle partijen in een markt dit doen.

        Hoe dan ook, ik laad geen externe content in mijn mails. Als de mail dan niet leesbaar is, dan gaat hij de prullenbak in en maak ik een filter aan dat dit voortaan automatisch gebeurt.

    • Het is in ieder geval wel een makkelijke manier om berichten end-to-end encryptie te geven (met https op de website): PGP slaat nog niet echt aan (helaas terecht: wat is die software irritant zeg!). Het zou mooi zijn, voor de PGP-gebruikers onder ons, als je als alternatief je PGP-sleutel op hun website zou kunnen uploaden, waarna ze je PGP-encrypted e-mails sturen van het bericht zelf.

  2. Het lijkt mij dat een (gedwongen) ontvangstbevestiging een vrij normale functie is, een die wat mij betreft eigenlijk standaard ingebakken in het e-mail protocol had mogen zitten. Ik zie er dan ook niet zo’n probleem in dat dit wordt verkregen door middel van een pixel. Mijn inziens is dat ook niet verboden, omdat artikel 11.7a Tw verbied het “opslaan van of toegang verkrijgen tot informatie in de randapparatuur”. Een pixel die een leesbevestiging stuurt doet dat helemaal niet.

      • Ik ben met je eens dat het uitlezen van de browsercache valt onder het begrip, maar de pixel leest de browsercache helemaal niet uit. De pixel wordt opgehaald vanaf een webserver en de webserver stuurt onderneemt dan een actie, zoals het opslaan van het feit dat de mail is gelezen. Overigens ga ik er vanuit dat dit alles zich afspeelt binnen een e-mail cliënt.

          • Maar de pixel wordt helemaal niet opgeslagen in de cache door de persoon die deze opgenomen in de content. De computergebruiker is daar zelf verantwoordelijk voor, omdat hij er voor heeft gekozen voor een browser die de pixels opslaat in de cache. Artikel 11.7a Tw kan niet gebruikt worden om een ander te verbieden om bepaalde content opnemen. Ik merk overigens op dat jij op deze blog ook een plaatje hebt opgenomen, dat deze in mijn cache wordt opgeslagen en strikt gezien niet noodzakelijk is voor een goede werking van de blog. 😉

            • Ik leg de verantwoordelijkheid bij de website-eigenaar omdat deze het initiatief neemt door de pixel in de webpagina op te nemen. Daardoor komt die pixel langs bij de browser en de browser slaat deze dan op. De website-eigenaar doet de pixel opslaan bij de cache van de bezoeker.

              Als je zegt, dat valt buiten de cookiewet, waarom cookies dan niet? Ook die worden immers door de website gegenereerd en opgestuurd. Zeg je dan ook, ik kies er voor om cookies te ontvangen?

              En je hebt gelijk dat het logo linksboven op het randje van functioneel noodzakelijk is. Ik zie dat niet als een argument dat mijn stelling onjuist is.

              • De pixel valt er niet onder omdat de website-eigenaar geen techniek toepast waarmee die pixel op jouw computer wordt opgeslagen. Het veronderstelt oorzakelijk verband ontbreekt. Cookies vallen er wel onder omdat daarbij de website-eigenaar doelbewust een techniek toepast waarmee deze informatie wordt opgeslagen.

                Ik geloof dat ik een rechter jou nooit, op basis op basis van art. 11.7a Tw, zou verbieden om de plaatjes link en rechts bovenin, tussen de blog en de comments en rechts van de blog op te nemen.

                • Huh? Het opnemen van een <IMG> tag in een webpagina lijkt me toch een techniek om plaatjes op iemands computer te krijgen? Je weet donders goed dat iedere browser dat gaat cachen. Welk oorzakelijk verband zou je willen? Ik zie echt geen verschil tussen een image-tag en een cookie header.

                  En ik geloof dat ook niet maar meer omdat het noodzakelijkheidscriterium breed zal worden uitgelegd dan omdat er geen sprake is van opslag.

                  • Het opnemen van een image-tag is wel een techniek om een plaatje op iemand computer te krijgen, maar geen techniek om dat plaatje op iemands computer op te slaan. Je kunt het in alle redelijkheid niet toerekenen aan de website eigenaar dat het plaatje wordt opgenomen in de cache. En daar is de cookiewet ook helemaal niet voor bedoeld. Er zijn overigens wel browsers die plaatjes niet in de cache op slaan, zoals de Lynx-webbrowser. ,,^..^,,

                    Het criterium “strikt noodzakelijk” kan niet breed worden uitgelegd, omdat het dan niet meer strikt is. Strikt noodzakelijk betekent dat de een goede werking wordt gehinderd als het betreffende plaatje er niet meer is. En alle vier de plaatjes op deze pagina zijn strikt gezien niet noodzakelijk om van de blog kennis te nemen. Het plaatje rechts is slechts een illustratie. Het plaatje tussen de comments en de blog en rechts bovenin zijn reclame. En de banner links bovenin heeft niets met de content te maken. Strikt gezien zijn al die plaatjes dus niet noodzakelijk voor je blog.

                    Ik maak een vergelijking naar de vrijheid van meningsuiting. Die geeft een ieder het recht om te zeggen wat hij vindt, maar betekent ook niet dat men een ander kan verplichting om die mening te publiceren. De ratio achter art. 11.7a Tw is de bescherming van de persoonlijke levenssfeer en om mensen de macht te geven over wat er op de eigen computer gebeurt, maar dat gaat niet zover dat men anderen kan vertellen wat ze in hun content mogen opnemen. Zie TK, 2013/2014, 33903, nr. 3 voor de achtergrond.

            • Klopt. De cookiewet kent twee aspecten: 1) Wordt er informatie opgeslagen dan wel uitgelezen? Zo nee, dan is ie niet van toepassing. 2) Is die informatie (redelijkerwijs) noodzakelijk voor levering van de gevraagde dienst? Zo ja: dan mag het. Zo nee: dan is toestemming vereist.

              Die bijlage wordt opgeslagen (cache, mailbox op je laptop, etc) dus is bij vraag 1 het antwoord ‘ja’. Maar ik denk dan, die bijlage zal relevant zijn voor de ontvanger en dus deel van de gevraagde dienst.

              Ik heb al eens verdedigd volgens mij dat een reclamebanner in een webpagina een overtreding is van de cookiewet. Ik zie geen weerlegging daarvan in de tekst van de wet.

              • Als het plaatje in de e-mail voor elke ontvanger dezelfde naam heeft, dan ben ik het met Alex eens en zie ik het verschil niet met een plaatje in een browser, wat je immers ook kunt gebruiken om een bezoeker te tracken op basis van bijvoorbeeld zijn IP-nummer.

                Pas als je een persoon daadwerkelijk gaat tracken, heb je toestemming nodig. Misschien dat het probleem er een van intentie is; met een tracking pixel weet je als enigszins geïnformeerde gebruiker dat deze uitsluitend is geplaatst om je te tracken. Het logo op een webpagina daarentegen kan weliswaar worden gebruikt om je te tracken, maar is daar in eerste instantie niet voor bedoeld.

                Het gezwam over een techniek “waarmee die pixel [doelbewust] op jouw computer wordt opgeslagen” snap ik niet, want zoals Arnout al terecht opmerkt, dat geldt voor elk object dat door de webbrowser op de computer wordt opgeslagen. Je zou daarbij zelfs kunnen chargeren dat cookies privacyvriendelijker zijn, omdat de bezoeker daar doorgaans meer controle over heeft dan over de browsercache.

                • Als een plaatje, dat voor iedereen dezelfde naam heeft, niet via een elektronisch communicatienetwerk wordt opgeslagen in de randapparatuur van een gebruiker, waarom zou dit wel gelden voor een plaatje dat iedere keer een andere naam heeft? De wet luid:

                  Onverminderd de Wet bescherming persoonsgegevens is het via een elektronisch communicatienetwerk opslaan van of toegang verkrijgen tot informatie in de randapparatuur van een gebruiker, alleen toegestaan op voorwaarde dat de betrokken gebruiker: a) is voorzien van duidelijke en volledige informatie overeenkomstig de Wet bescherming persoonsgegevens , in ieder geval over de doeleinden waarvoor deze informatie wordt gebruikt, en b) daarvoor toestemming heeft verleend.

                  • Een plaatje (en een cookie) worden niet opgeslagen, de gebruiker slaat ze op. Je komt er denk ik op uit dat je naar intentie kijkt. Maar inderdaad, dan maakt de naam niet veel uit. Hooguit zou je bij een unieke naam meteen kunnen zeggen dat het een trackingplaatje is, terwijl je dat bij een algemene naam niet meteen kan concluderen.

                  • Onverminderd de Wet bescherming persoonsgegevens is het via een elektronisch communicatienetwerk opslaan van of toegang verkrijgen tot informatie in de randapparatuur van een gebruiker, alleen toegestaan op voorwaarde dat de betrokken gebruiker: a) is voorzien van duidelijke en volledige informatie overeenkomstig de Wet bescherming persoonsgegevens , in ieder geval over de doeleinden waarvoor deze informatie wordt gebruikt, en b) daarvoor toestemming heeft verleend.

                    En hier ga je dus mank. Je krijgt zonder toestemming van een gebruiker tot bepaalde informatie, namelijk de informatie dat de gebruiker de betreffende e-mail leest zonder dat deze daarvoor akkoord geeft dat deze informatie gestuurd dient te worden. Men kan stellen dat hier immers dat functionaliteit zonder leesbevestiging hetzelfde is als het sturen van een normale brief of kaart. Indien men zeker wilt weten dat een e-mail is gelezen, zal men dat expliciet aan de gebruiker dienen te vragen. Men heeft dan dezelfde werking als het versturen van een aangetekende brief met ontvangstbevestiging.

                      • De informatie ligt opgeslagen als zijnde een instructie in het RAM-geheugen van de gebruiker om informatie op afstand op te halen en.of te versturen. Indien juridisch een harde schijf tot randapparatuur is verklaard, is het ook juridisch verdedigbaar dat andere onderdelen (o.a. RAM-geheugen) in een computer tot randapparatuur horen.

                        • Het is juridisch volgens mij toch wel andersom. Ik bedoel: je kunt bijv. een Linux-distributie als Puppy Linux (maar eigenlijk de meeste distro’s wel tot op zekere hoogte) gewoon draaien vanaf een USB-stick en zo via het RAM-geheugen werken. Je hebt dan dus geen HDD of SSD nodig. Echter, als je alleen een HDD of SSD hebt maar geen RAM-geheugen, dan kun je geen enkel OS gebruiken. RAM is dus geen randapparatuur.

                          • Dat de meeste besturingssystemen zo zijn gemaakt dat ze RAM nodig hebben, is het echter niet noodzakelijk dat ze in theorie ook zonder zouden kunnen werken. Immers kan men alles naar een harde schijf dan wel USB-stick schrijven. Dit zorgt uiteraard wel voor een perfomance val. Maar daar gaat het nu niet om.

                            • Nee, ik denk dat dat technisch onmogelijk is; dat heeft te maken met de manier waarop computer-hardware ontworpen is. De machine-taal waarin instructies voor processoren geschreven zijn gaat uit van de aanwezigheid van RAM: veel instructies hebben rechtstreeks te maken met het laden van / opslaan naar RAM.

                              Voor randapparatuur zoals harde schijven bestaat zulke ingebouwde functionaliteit in processoren niet; daar zijn dus drivers voor nodig. Die drivers hebben RAM nodig voor de opslag van hun variabelen, gebufferde data en dergelijke. Om een voorbeeld te noemen: ik heb een projectje waarbij ik een Arduino computertje gebruik in combinatie met opslag op een SD-kaart. De Arduino UNO heeft slechts 2048 bytes RAM, dus je wordt je daar heel erg bewust van waar je RAM allemaal voor nodig hebt. Net zoals harde schijven geven SD-kaarten data in sectoren van 512 bytes, dus als je data byte-voor-byte leest moet je een 512-byte buffer in RAM hebben voor de rest van een sector. Dat kost je dus een kwart van je RAM op een Arduino UNO.

                              Op sommige platforms kan je misschien om het RAM heen werken als processor-registers, processor-cache en dergelijke voldoende geheugen bieden voor drivers. Dan vraag ik me wel af: waar begint/eindigt je definitie van RAM? Het zijn toch allemaal verschillende lagen van volatile memory? Wat bereik je er mee als je één laag niet gebruikt en de andere lagen wel?

                              • Op sommige platforms kan je misschien om het RAM heen werken als processor-registers, processor-cache en dergelijke voldoende geheugen bieden voor drivers. Dan vraag ik me wel af: waar begint/eindigt je definitie van RAM? Het zijn toch allemaal verschillende lagen van volatile memory? Wat bereik je er mee als je één laag niet gebruikt en de andere lagen wel?

                                Zo goed als alle computers werken in de basis volgens het Von Neumann-principe of de daarvan afgeleide Harvard-architectuur. De achterliggende technologie achter de ‘geheugen-unit’ is voor deze principes niet relevant. Processor registers worden in de regel vooral gebruikt om de data in te stoppen waar de verwerkings-unit (ALU) op dat moment mee werkt. Dat zijn zulke kleine hoeveelheden, dat ik niet denk dat dit voor mensen betekenis heeft en als informatie moet worden gezien. Hoogstens als uitkomst van een rekensom o.i.d misschien. We gebruiken de definitie RAM tegenwoordig vaak voor volatile geheugen, maar dat is niet de oorspronkelijke. Kenmerkend van RAM is vooral dat de toegangstijd voor elke byte gelijk is. Betrouwbare toevoer, op vast tempo, van vooral de instructies, maakt de opbouw van een ALU veel eenvoudiger.

                                Dat de meeste besturingssystemen zo zijn gemaakt dat ze RAM nodig hebben, is het echter niet noodzakelijk dat ze in theorie ook zonder zouden kunnen werken. Immers kan men alles naar een harde schijf dan wel USB-stick schrijven. Dit zorgt uiteraard wel voor een perfomance val. Maar daar gaat het nu niet om.
                                Dit heeft vooral met de hardware te maken. In theorie is dit mogelijk, er zijn eenvoudige micro’s die hun instructies direct uit flash uitvoeren. Het protocol voor communicatie met een USB-stick of een SSD zou je in theorie best in hardware kunnen implementeren en dan aan de RAM-bus van je micro kunnen hangen. Met een HDD wordt het wel complexer, maar goed die dingen hebben ook gewoon hun eigen cpu met ramgeheugen om constante toevoer te garanderen. Of iemand er brood in ziet om zo’n setup mogelijk te maken is een ander verhaal… Maar om terug te komen op de discussie: Bij zo’n systeem is je HDD of USB-stick geen randapparatuur meer, maar noodzakelijk voor de werking.

                  • Misschien denk ik te makkelijk, maar mag je ‘opslaan van informatie in de randapparatuur van de gebruiker’ niet gewoon opvatten als, krijgt de gebruiker enkel waar hij om vraagt? Als ik een blog lees, dan wil ik die website zien zoals de auteur hem heeft gemaakt. Dat opslaan doet mijn computer dan in opdracht van mij en niet die van de blogger. Wat mij betreft handelt de aanbieder van de blog niet eens. Die informatie staat daar en ik laat mijn device die downloaden en aan mij presenteren (of niet).

                    Wat voor tekst, plaatjes, filmpjes, etc.. een auteur op zijn site zet, is zijn keus. Het lijkt me niet aan de gebruiker om te bepalen welke informatie een auteur op zijn site plaatst, incl. reclamebanners. Als je een site opvraagt, dan weet je nou eenmaal van tevoren niet precies wat je krijgt. Alle informatie (HTML/CSS/scriptjes/etc.) die noodzakelijk is voor het zichtbare deel lijkt me dan automatisch noodzakelijk voor de gevraagde dienst.

                    De cookiewet lijkt me pas relevant voor dingen die de gebruiker niet automatisch te zien krijgt, omdat je een website opvraagt om hem te bekijken en niet om getrackt te worden o.i.d. Als de gebruiker er niet om vraagt en het gebeurt toch, dan handelt de aanbieder pas. Lijkt me redelijk om dit dan door te trekken naar e-mail en dat een onzichtbaar plaatje, of met steeds een andere naam, dan niet mag. De naam veranderen heeft nl. geen enkele invloed op hoe de gebruiker dat plaatje zien krijgt en is daarom niet noodzakelijk.

    • Er IS gewoon een ontvangstbevestiging in het protocol. zie https://en.wikipedia.org/wiki/Return_receipt en RFCs 3461 tot en met 3464 en 6522. Het is wel een vrijwillige standaaard en SMTP servers mogen dit gewon negeren. (wat helemaal past bij de Privacy gedachten achter de DONOTTRACK header.)

      Met een Pixel tracking doe je veel meer dan alleen kijken of de mail is ontvangen / gelezen. Je doet ook informatie verzamelen over met welk apparaat dit is gedaan en van welk IP adres er word gekeken (en mogenlijk meer, hangt van de gebruikte techniek af)

      Het willen weten dat een mail is aangekomen is legitiem om te vragen, maar ok dat ook te eisen gaat wat mij betreft te ver. Daar dan ook nog eens informatie bij verzamlen over mij die niets met het mailtje te maken hebben is helemaal uit den boze. Tracking pixels in mails is dus not done in mijn optiek. En is ook nergens voor nodig, want de functionaliteit is er al op vrijwillige basis.

      • Stel je voor dat je een abonnement hebt wat je wilt opzeggen. De houder van dat abonnement zal dan moeten bewijzen dat zijn opzeggingsmail is aankomen. Dat bewijs kan worden geleverd met behulp van zo’n pixel. Ik zie daar echt geen kwaad in. Als de houder van zo’n abonnement een aangetekende brief moet sturen dan krijgt hij ook te horen dat de brief is aangekomen alleen kost het dan negen euro.

        • Bij mijn weten geld bij consumenten hier de omgekeerde bewijslast, Voor bedrijven geld dat dit bewijs gewoon te vinden is in je mail server logs. Je kunt ook een ‘Request for Delivery Report’ meesturen met je mail, vaak krijg je dan die bevestiging. zonder dat er sprake is het mogelijk schenden van privacy. Voor het aantonen dat je een abonnement opzegt hoef je trouwens niet te bewijzen dat de ontvanger het bericht gelezen heeft. enkel dat deze (redelijkerwijs) is ontvangen.

          Tracking pixels liggen buiten het beruik van consumenten op te gebruiken, gezien het feit je infrastructuur nodig hebt om dit mogelijk te maken. Dus consumenten gebruiken ze niet, enkel bedrijven. Als je bedrijfsmatig een abbonement beeindigd is het niet ongewoon dat je dit bevestigd met meerdere middelen, (dus een telefoontje en een mailtje bijvoorbeeld) Zodat er geen twijfel over intentie is.

          En om het nogmaals te herhalen, Bewijs dat een mail is aangekomen is er nu al (zonder iets) te vinden op de mail server die je bericht vertuurd. Ook kun je met standaard SMTP headers (zit in bijna elke mail client wel ergens) vragen om een aflever bevestiging, en ook om een lees bevestiging. Deze zijn welliswaar vrijwillig, maar iemand die dit niet mogenlijk maakt kan ook niet aanemelijk maken dat een mail niet is aangekomen.

          De Tracking Pixel is en blijft gewoon een onnodig bezwarend middel om mail lees bevestiging te doen. Er zijn andere middelen die net zo effectief zijn en geen pixel nodig hebben.

          • Dat is onjuist. De verzender moet bewijzen dat de mail is aangekomen. Dat betekent dat de ontvanger kan volstaan met betwisten. Er geldt geen omgekeerde bewijslast voor consumenten. En bedrijven zullen niet voldoende hebben om hun de server logs, omdat hieruit alleen zal blijken dat de mail is verzonden. Er kan onderweg van alles gebeuren. Het is niet ongewoon dat zo’n e-mail bericht langs meerdere mail servers gaat. De versturende mail server registreert niet dat er onderweg is misgaat.

            Het is voor mij redelijk eenvoudig om van deze techniek gebruik te maken. Mijn provider ondersteunt PHP scripts tegen betaling. Een PHP scriptie van honderd regels is voldoende. En ja, je kunt verzoeken om een ontvangst- en/of leesbevestiging, maar als de ontvanger dat niet doet dan ben je nog nergens. En als de ontvanger dat wel doet dan kun je een PHP script zo inrichten dat het resultaat hetzelfde is. Dit heeft dan niet tot nauwelijks negatieven gevolgen voor de persoonlijke levenssfeer van de ontvanger.

            En omdat het versturen van een mail met een dergelijke pixel bied geen garanties bied, maken bedrijven gebruik van berichtenboxen waar deze techniek vervolgens wordt toepast.

            • Ik kan bewijzen dat de mail is aangekomen bij de ‘postkamer’ van de ontvanger. Hier een regel (met wat namen veranderd i.v.m. privacy) vanuit mijn mailserver.

              Mar 6 14:04:17 Mail.local postfix/smtp[41295]: 6B8DB1760241: to=<receiver@Nederlandseprovider.nl>, origto=alert@example.com, relay=mx4.Nederlandseprovider.nl[392.19.84.15]:25, delay=1.9, delays=0.05/0.01/1.5/0.25, dsn=2.0.0, status=sent (250 2.0.0 mxdrop.Nederlandseprovider.net accepted message v48D4Ada035671
              Hiermee kan ik bewijzen dat de mail is afgeleverd bij de doel bestemming (postkamer) van de ontvangende partij. Als deze dan nog verder het poststuk doorstuurt dan ligt de bewijslast hiervan bij die andere partij (net als bij een brief hoef ik niet te bewijzen dat het bij de persoon is aangekomen enkel bij het bedrijf. het bedrijf is zelf verantwoordelijk dat het dan bij de juiste persoon komt) Dat de aflevering succesvol was kun je opmaken uit de SMTP status code (send (250 2.0.0. …) ) dit betekend namelijk dat de ontvangende SMTP server het bericht volledig heeft ontvangen en geaccepteerd.

              Het klopt dat er van alles kan mis gaan, dit is niet anders dan bij fysieke post. Ik kan met die regel uit het log dus aannemelijk maken dat het bedrijf mijn bericht heeft ontvangen. en ik er vanuit mag gaan dat deze ook aankomt bij de bedoelde ontvanger. Of alsnog een foutmelding terug krijg dat dit niet is gelukt. Als verzender kan je niet verantwoordelijk worden gehouden voor de interne processen binnen een andere organisatie. Dus als er iets mis gaat na ontvangst bij de “postkamer” dan valt dat onder de verantwoording van het bedrijf.

              Mijn Log toont aan bij wie het is afgeleverd net zo als een aangetekende brief dit doet. die toont immers ook niet aan dat het gelezen is of bezorgd bij de juiste persoon. Enkel dat die bezorgt is en bij wie (en wanneer) .

              Overigens is het gebruik van die berichtenboxen voornamelijk een noodzaak ivm. de privacy wetgeving. e-mail is niet beveiligd tegen misbruik. een HTTP verbinding met TLS (ook wel HTTPS) is dat wel. dus als je de persoongegevens veilig wil kunnen transporteren tussen bedrijf en klant dan zal je moeten werken met een berichtenbox. Dat als bijkomstigheid je dan meer informatie kan verzamelen is fijn voor die bedrijven maar moet dan nogsteeds blijven vallen binnen de gestelde doelen zoals in hun privacy documentatie en de wettelijke voorschriften, (lees o.a. Arnouds boek over De Algemene Verordening Gegevensbescherming

              • Het is de verzender die moet bewijzen dat de ontvanger het bericht heeft ontvangen. Dat je aannemelijk kunt maken dat PostNL of de Nederlandse provider het bericht heeft ontvangen is simpelweg niet voldoende. Als PostNL of de Nederlandse provider het bericht niet door heeft gegeven aan de ontvanger dan komt aan het bericht geen werking toe. Roepen dat jij vind dat een verzender niet verantwoordelijk kan worden gehouden voor de interne processen binnen een andere organisatie en jij vind dat dit voor risico van de ontvanger moet komen, brengt daarin geen verandering.

                Een tot een bepaalde persoon gerichte verklaring moet, om haar werking te hebben, die persoon hebben bereikt. Nochtans heeft ook een verklaring die hem tot wie zij was gericht, niet of niet tijdig heeft bereikt, haar werking, indien dit niet of niet tijdig bereiken het gevolg is van zijn eigen handeling, van de handeling van personen voor wie hij aansprakelijk is, of van andere omstandigheden die zijn persoon betreffen en rechtvaardigen dat hij het nadeel draagt. (Artikel 3:37 lid 3 BW)

                Ik merk trouwens op dat in je mail log IP adressen staan opgenomen en dat je het bezwaarlijk vond dat met zo’n pixel jouw IP adres kon worden gelogged.

                • Het is de verzender die moet bewijzen dat de ontvanger het bericht heeft ontvangen. Dat je aannemelijk kunt maken dat PostNL of de Nederlandse provider het bericht heeft ontvangen is simpelweg niet voldoende. Als PostNL of de Nederlandse provider het bericht niet door heeft gegeven aan de ontvanger dan komt aan het bericht geen werking toe. Roepen dat jij vind dat een verzender niet verantwoordelijk kan worden gehouden voor de interne processen binnen een andere organisatie en jij vind dat dit voor risico van de ontvanger moet komen, brengt daarin geen verandering.

                  En jij kan bewijzen dat PostNL of welke partij dan ook daad werkelijk het heeft afgegeven? Bij de juiste persoon? (ik ben zelf nog nooit gevraagd om mijzelf te legitimeren om een bericht/pakket aan de deur te ontvangen bijvoorbeeld) Het bewijs dat word geleverd met een log is dat er (net zoals bij een post bedrijf bij een aangetekend stuk) dat het bericht is afgeleverd bij het address. Waarbij ook bekend is wanneer dit was, in datum en tijd. en bij welk address (IP address). Er staat zelfs in welke Identifier die het bericht heeft gekregen. Dit is meer dan voldoende informatie om in de log van de ontvangende partij te kunnen terug halen waar het bericht na ontvangst heen ging. (Dit zijn interne processen vergelijkbaar met een postkamer. En gebeuren dus onder de verantwoordelijkheid van de ontvangende partij. Als de ontvanger iemand inhuurt om zijn mail-processen voor hem te doen dan blijft de ontvangende partij toch verantwoordelijk voor het handelen. De Mail provider is immers enkel een partij die in opdracht van de ontvangende partij handelt,

                  Een tot een bepaalde persoon gerichte verklaring moet, om haar werking te hebben, die persoon hebben bereikt. Nochtans heeft ook een verklaring die hem tot wie zij was gericht, niet of niet tijdig heeft bereikt, haar werking, indien dit niet of niet tijdig bereiken het gevolg is van zijn eigen handeling, van de handeling van personen voor wie hij aansprakelijk is, of van andere omstandigheden die zijn persoon betreffen en rechtvaardigen dat hij het nadeel draagt. (Artikel 3:37 lid 3 BW)
                  Vanaf het moment dat de Mail door de ontvangende partij gekozen mailserver (dit is bekend en gepubliceerd als een van de MX record(s) van de ontvangende partij, in diens DNS records)

                  Dus als op de mail word gereargeert met een SMTP code van 250, wat betekend volgens RFc 2821 “OK” en daar bij de Enhanced SMPT codes worden gegeven van 2.0.0. zoals uit de RFC 1893

                  2.X.X Success Success specifies that the DSN is reporting a positive delivery action. Detail sub-codes may provide notification of transformations required for delivery.
                  Dan heb je bewijs van een afgeleverde mail. Met zelfs iets meer zekerheid dan wanneer een Post bedrijf dit doet. Omdat ook de plaats waar en het precieze moment er bij staan.

                  Derhalve zou dit bewijs de zelfde status moeten hebben als een aflever bewijs van een Postbedrijf.

                  Je kan het nog uitbreiden met Delivery-notification-report en Read-Receipt waarmee je ook kunt aantonen dat het bericht afgeleverd is, en dat het gelezen is. Deze zijn echter op vrijwillige basis en de ontvangende partij moet hier dan ook aan meewerken om deze reacties te ontvangen. Het log bestand heeft niet deze limitatie.

                  Ik merk trouwens op dat in je mail log IP adressen staan opgenomen en dat je het bezwaarlijk vond dat met zo’n pixel jouw IP adres kon worden gelogged.

                  het IP address dat ik gebruik is uit of range, in 8 Bit kun je getallen groter dan 255 niet opslaan. (dus staat een IPv4 lijkend adress zonder dat die er ook daadwerkelijk staat. Dus ik heb niets vrijgegeven nog gepubliceert. Verder gebruikte ik een mail die ik zelf verstuurde naar een mailbox van mijzelf op een andere domein/machine, Andere log gegevens had ik namelijk nooit mogen gebruiken. Verder heb ik alle identifiers aangepast zodat deze niet meer te herleiden zijn tot het oorspronkelijke bericht.

    • Een ander probleem is dat vaak met opzet de inhoud alleen maar in HTML embedded wordt meegestuurd en niet meer in tekst-formaat, en dan zodanig dat de inhoud niet (volledig) te begrijpen is zonder dat externe bronnen zijn toegestaan.

      Iemand die dan tekst weergave verkiest boven HTML ziet alleen maar de medeling: Uw programma ondersteunt geen HTML, bekijk de online versie van deze mail in uw browser (pagina vol met trackers).

      Flauwekul, dan komt tracking belangrijker dan de boodschap, dat is misbruik.

    • Een pixel die een leesbevestiging stuurt doet dat helemaal niet.

      Die pixels bestaan alleen niet.

      1. – een pixel kan helemaal niet worden ingelezen (geen externe content)
      2. – een pixel kan wel worden gelezen, maar betekent dit dat de mail gelezen is?ontvangen misschien, maar gelezen of preview. En een virusscanner zou best de pixel kunnen downloaden voor analyse, weet je ook niks.
      3. – Daarnaast zou de pixel ook bijhouden hoe vaak de mail wordt gelezen en op welk tijdstippen, dan schiet het zijn doel weer voorbij.

      Ik geef toe een leesbevestiging is absoluut een handige functie, alleen misbruik ligt op de loer. Aangetekende brieven zijn duurder, misschien moeten een aangetekende email (met leesbevestiging) een cent kosten.

  3. De cookiewet is in deze op triviale wijze te omzeilen. Het enige dat voor de tracking van belang is is dat een poging gedaan wordt om een object op een unieke URL te benaderen. Op de server kun je daaraan zien dat de ontvanger de email geopend heeft. De server hoeft helemaal geen pixel terug te sturen. Er hoeft dus niets opgeslagen te worden op de computer van de ontvanger. 404 (not found) is genoeg. 204 (no content) nog mooier.

    Dit is dus waar de cookiewet tegen bedoeld is. E-mailtrackers vallen onder het wettelijke begrip “gegevens opslaan of uitlezen” van andermans computer of telefoon.
    Je hoeft voor dit soort tracking dus geen gegevens op te slaan of uit te lezen. Maar is tracking door een unieke URL die naar een 204 (no content) leidt illegaal of niet?

    (De tracking URL hoeft trouwens helemaal geen plaatje te zijn. Een URL voor bijvoorbeeld video, geluid, fonts, embedded scripts of css-files voldoen ook prima.)

    • Als ik een mail heb verstuurd met daarin een “phone home” functie (zoals jij beschrijft) dan lees ik informatie uit, waar ik anders geen weet van had. En welke niet nodig is om mijn doel te behalen. Je leest dus wel degelijk gegevens uit. Zelfs al geef je geen reactie terug op een 204/404 na. Een email bericht is nu eenmaal wezenlijk iets anders dan een webpagina bezoeken. Bij een webpagina verwacht je als gebruiker dat er meerdere verbindingen worden opgezet tussen jouw en de server. welke (traceerbare) sporen achterlaten. Bij mail verwacht je het tegenovergestelde. je verwacht dat in de mail er sporen zijn te vinden van hoe die bij jouw is gekomen. maar niet dat deze sporen achterlaat bij derden.

      In andere woorden: Mail is statisch (net als een brief), Webpagina’s zijn dynamisch (net als een Bulletin Board). Er gelden derhalve dus ook wezenlijk andere spelregels voor mail dan dat er gelden voor websites.

        • Ik schrijf regelmatig software voor HTML mail, en je bent zo zeer beperkt in wat je wel en niet kunt doen. dat zelfs HTML Mail statisch is. dingen die je bijvoorvbeeld niet of maar heel beperkt kunt doen in HTML mail:

          • – Java script, de meeste mail clients stippen 99% hiervan gewoon weg of negeeren het.
          • – CSS, Mail clients doen veel CSS regels gewoon overschrijven met hun eigen standaard, je kunt css in de mail dus maar zeer beperkt (plaatsje / kleurtje ed.) gebruiken, CSS 3 werkt voor ruim 90% niet in de meeste mail clients.
          • – Links, Het linked van externe bronnen word vaak niet toegestaan, externee CSS / Javascript ed. word gewoonweg genegeerd.
          • – IFrame, kan in geen enkele mail client die ik ken.

          Dit alles heeft tot gevolg dat je mail statish is (hij veranderd niet) en is ook de reden waarom je nog steeds die link ziet met “zie de HTML versie hier”. op veel platformen ziet het er anders namelijk niet uit.

  4. Ik had gedacht dat een e-mail statistieken tracker onder de vrijstelling zou vallen: Artikel 8 sub f Wbp.

    Sinds de grens tussen een HTML-pagina en een HTML-email zo grijs is, kunnen we toch naar de meer duidelijke regels van een HTML-pagina kijken. Daar is een uitzondering voor gerechtvaardigd belang voor bedrijf (direct marketing) en werking (statistieken / meten is weten / AB testen).

    Indien er rekening gehouden wordt met de privacy:

    – De laatste 4 octets uit het IP worden niet opgeslagen.
    – De gebruiker wordt in de mail op de hoogte gesteld dat tracken mogelijk is,
    – Naast het [unsubscribe] knopje zit een [track mij niet] knopje.
    – Er worden geen gegevens gedeeld met derde partijen
    – De gebruiker heeft de mogelijkheid om e-mail trackers zelf, zonder medewerking van verzender, te wijgeren.

    Zie ik het probleem niet. Je kunt moeilijk verzamelstatistieken maken over welke versie (Versie A of B) het meest effectief is, zonder statistieken te verzamelen. Waarom is niet-spam, vrijwillig aangevraagde HTML-email zo verschillend van normale HTML-paginas in deze?

      • zolang je de informatie niet uit andere bronnen die al beschikbaar is, je deze informatie kan halen dan zou dat heel goed kunnen (ik ben geen jurist dus durf het niet harder dan dat te zeggen) Je houd in ieder geval rekening met de privacy. Echter als je de zelfde informatie gewoon door middel van log analyse kunt krijgen, waarom dan meer verzamelen dan nodig is? Als je namelijk meer verzamelt dan loop je snel het risico dat het niet meer te rechtvaardigen is dat je het verzameld onder genoemd artikel.

        Ook hoe zorg je er voor dat de persoon een geïnformeerde beslissing kan nemen? Informeer je de persoon voordat het eerste mailtje word verstuurd of niet? Als je voor dat het eerste mailtje de persoon informeert dat er tracking kan zijn dan zie ik geen probleem. Dit is echter net hoe de meeste tracking pixels worden gebruikt. Die worden gewoon toegevoegd zonder voorafgaande toestemming. Ook kun je die pixels niet gebruiken in je eerste contact (dan is er immers nog geen akkoord gegeven voor het gebruik ervan).

    • Ik heb zo mijn redenen om email op de ouderwetse manier te willen lezen: als plain text. Belangrijke reden: trackers, phishing en malware laten zich duidelijk zien. En, nog belangrijker, ze worden niet geactiveerd! Ja het niet opslaan van de laatste 4 octetten van mijn IP adres wordt gewaardeerd voor IPv4, het geeft mij daar goede privacy, maar bij IPv6 is dat niet genoeg… mijn provider heeft mij een /64 subnet toegekend en met de resterende 96 bits moet je in staat zijn om mij, en de device in het subnet te identificeren.

  5. Als ik deze discussie diagonaal lees heb ik het idee dat de implementatie van de cookiewet compleet is mislukt vanwege de gekozen formulering: “Cookies worden nou eenmaal opgeslagen, dus daar zal dan wel het probleem zitten” zullen de wettekstschrijvers gedacht hebben… Waarna je in de discussie belandt of een illustratief plaatje wel/niet essentieel is voor de geboden info en of het nu wel/niet wordt opgeslagen en of het dus wel/niet onder de cookiewet valt…

    Zou het hele probleem niet zijn omzeild als men had opgeschreven dat aanbieders van informatie niets mogen toevoegen wat ze méér informatie van de ontvanger oplevert dan strikt noodzakelijk voor het aanbieden van die informatie? Dan ben je volledig losgekoppeld van technische implementaties en is de wet niet al links en rechts ingehaald op het moment dat de inkt nog ligt te drogen. En dan heb je toch de essentie te pakken… Of heb je dan te weinig juridische aanknopingspunten voor praktische gevallen?

  6. Het basisidee van e-mailtracking is dat je iets opneemt in het mailbericht dat je op afstand kunt uitlezen

    Ik heb veel problemen met deze zin. Zeker in combinatie met het pixel voorbeeld is dit een zeer foute weergave van hoe dit werkt. Je kunt namelijk op deze manier NIETS van de pc waar de mail is ontvangen uitlezen. Je kunt geen verbinding maken met deze pc met deze methode. Het enige wat de email client doet is een plaatje laden, net zoals je browser dat voor elke internet pagina die je bezoekt doet. Het laad verzoek komt dus vanuit de client en de client bepaald hoeveel info (weinig) er met dat verzoek mee gaat. Je kunt als afzender wellicht bepalen hoe vaak en van welk IP adres er een poging is gedaan het plaatje op jouw server te lezen, maar dat is dan ook alles. De suggestie hier dat de verzender iets zou kunnen uitlezen op de pc van de ontvanger is fout en onnodige bangmakerij. Sinds het opvragen van het plaatje ook door een virusscanner op een mailserver kan worden gedaan is dit dus duidelijk geen leesbevestiging.

    Een beter versie van deze zin zou zijn: Het basisidee van e-mailtracking is dat je iets opneemt in het mailbericht dat iets probeert te laden van een server van de verzender, waardoor deze weet dat een applicatie geprobeerd heeft de mail te verwerken

    • Hoe is het opstarten van een HTTP verbinding niet verbinding maken met de PC waar de mail op ontvangen is? Waarbij via deze verbinding verschillende informatie te verkrijgen is over de gebruikte software en hardware. En, Wat misschien nog wel belangrijker is. Het is niet nodig! Tenminste niet voor de mail zelf. Dit betekend dat in tegenstelling dan bij een webpagina, je veel dingen niet kunt verantwoorden onder “noodzakelijk voor normale werking”. ter illustratie. – Als ik een webpagina bezoek, dan weet ik dat mijn computer (meerdere) bestanden nodig heeft om de pagina bij mij te laten zien, en dat mijn computer deze moet binnenhalen bij een andere partij (de webserver) waarbij er informatie moet worden gedeeld over mijn verbinding (mij IP-address) en informatie over mijn apperaat en software (Mobile of niet, IE of firefox ed.) mM de pagina zo goed mogenlijk voor mij te krijgen. Ik neem voor lief dat deze informatie dan ook word gelogd (anders moet ik de pagina maar niet bezoeken). Bij mail is dit anders, Daar neem ik in principe alleen contact op met mijn mail infrastructuur. (dus niet iemands server maar ‘mijn’ server). Ik mag verwachten dat dan alles wat ik nodig heb om de informatie te krijgen beschikbaar is. Als je dan een mail maaakt waarbij er informatie word geladen van een derde systeem, dan is dit zeer waarschijnlijk niet nodig om het doel (het bericht) te behalen. Dit had immers ook in de mail zelf kunnen staan.

      • Hoe is het opstarten van een HTTP verbinding niet verbinding maken met de PC waar de mail op ontvangen is?

        Het is cruciaal om te beseffen wie de verbinding initieert en met welk doel of protocol. Wanneer jij webpagina (of een mail een plaatje) leest initieer jij een verbinding naar de de webserver. De webserver kan dan antwoord terug geven over die verbinding. Echter onder normale omstandigheden en buiten specifieke router en firewall configuratie (die jij moet doen) kan diezelfde webserver geen verbinding met jou computer initiëren. Dit ondanks dat het verkeer over dezelfde porten en protocollen zou gaan. De router of firewall accepteert alleen binnenkomend verkeer als direct antwoord op een uitgaand verzoek. Als jij het verzoek niet doet (je mail client instelt om geen plaatjes te laden) kan er dus geen verbinding plaatsvinden (tenzij je, je eigen security configuratie om zeep hebt geholpen). Ook kan een webserver niet willekeurige gegeven opvragen terug over de verbinding die jij hebt opgezet. Alleen een plaatje word als antwoord geaccepteerd (bugs daargelaten).

        Een plaatje kan dus niet leiden tot iemand die met jou verbinding maakt, jij maakt altijd verbinding met hen. Zolang jij verbinding maakt bepaal jij hoeveel informatie je vrijgeeft. Het staat je vrij om browser type header of ipadress te verbergen of aan te passen. Dat niemand de moeite neemt zegt al genoeg. Ze krijgen trouwens het adres van je router niet van je pc. Als je meerder pc’s hebt kunnen ze niets met zekerheid bepalen.

        Wellicht vind je dit te technical minded, maar het is voor mij van cruciaal belang dan mensen geen angst word aangepraat door een slechte manier van de feiten weergeven.

        • Echter, als ik naar jouw iets stuur wat verbinding terug maakt naar mij, dan ben Ik de persoon die die verbinding initieert (het gaat dan over het concept initiëren binnen een juridisch kader). Ik ben namelijk de persoon die ‘bepaalt’ heeft dat de verbinding ‘moet’ worden opgezet. (dus niet de ontvanger van de mail). Het is voor ‘gewone’ mensen niet mogelijk om hun mailcliënt of netwerk zo in te stellen dat het niet mogelijk is om deze verbinding op te zetten. Niemand heeft het er hier over dat er arbitraire informatie van de computer van de ontvanger kan worden gehaald worden (dat is gewoon Computer vrede breuk (‘hacken’) en gewoon strafbaar onder de Nederlandse wet). De discussie gaat over het delen van privacy gevoelige of andere persoons-gegevens op een ongeoorloofde manier met de hulp van image trackers in e-mail berichten. Welk adres je krijgt (PC/router/etc.) is sterk afhankelijk van hoe je verbinding maakt, met welk protocol (IPv4/IPv6 is heel anders in deze bijvoorbeeld) je verbinding maakt, of je gebruik maakt van mobiel (data) netwerk en hoe je netwerk geconfigureerd is. Verder ‘lekt’ je HTTP-Client best veel data over jouw naar een webserver. Naast je IP-address (nodig voor terugkrijgen van een antwoord) word er ook een hele hoop andere informatie meegestuurd in de zogenaamde Agent-string. Wat ik in zijn geheel mis in jouw reactie ‘Bart Zuidgeest’ is dat voor de normale werking van e-mail helemaal die verbinding met ‘mijn’ server (als verzender) helemaal niet nodig is. Iedere verbinding die dus word opgezet valt niet onder de regels van “voor normaal laten werken van…”, Iets dat wel geld als ik jouw webpagina bezoek. Dit betekend dat je gegevens (mogelijk zelfs persoons-gegevens) aan het verzamelen bent voor een doel waar je niet gemachtigd bent (je geeft immers niet vooraf de keuzemogelijkheid). Het is dus niet bangmakerij waar hier over gesproken word. Maar reële potentieel misbruik dat door meerdere partijen word gedaan, waar een juridisch besef van legaliteit van deze acties ontbreekt.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS