Is Verizons perma-cookie eigenlijk wel legaal?

verizon-uidh-permacookieDe Amerikaanse provider Verizon plaatst permacookies, las ik bij Wired. Een zogeheten Unique Identifier Header (UIHD) wordt toegevoegd aan elke opvraging van webpagina’s, afbeeldingen en dergelijke. Met deze unieke code kunnen website-eigenaren vervolgens precies bijhouden wie wie is, en via Verizon specifiek op maat gemaakte advertenties plaatsen. Na de gebruikelijke ophef komt Verizon met de gebruikelijke PR-braaftaal (“delivering solutions with best-in-class privacy protections”, het moet verboden worden zulke uitspraken te citeren in nieuwsberichten) en een opt-out. Maar eh, mag dat?

Het ding heet permacookie, dus je zou zeggen dat de cookiewet hier wat over te zeggen heeft. Maar nee. Die wet bepaalt dat je geen informatie mag lezen of schrijven van randapparatuur zonder toestemming van de gebruiker. Maar wat Verizon doet, is het injecteren van een ID nádat de informatie (de http request) je randapparaat heeft verlaten. Die schrijfactie valt dus buiten het bereik van die wet.

Netneutraliteit? Nee, ook niet. Die verbiedt het belemmeren of vertragen van internetverkeer, en daarvan is geen sprake. Die ene header erbij fietsen kost echt niet zo veel vertraging dat dat een “belemmering” te noemen is.

De Wbp dan? Ja, misschien wel. De UIDH is immers ontworpen om uniek te zijn per klant, en is daarmee een persoonsgegeven. Toestemming is er niet, en een contract waarvoor dit nodig is ook niet, dus dan kom je vrijwel meteen bij de belangenafweging: hoe groot is het belang van Verizon om deze tracking te mogen faciliteren, en hoe groot is het privacybelang van de gebruiker? Ik denk dat de gebruiker daar in principe wel gaat winnen, want het belang voor Verizon bij tracking is veel kleiner dan bij een website die immers leeft van advertenties en zonder tracking zijn inkomsten zal zien kelderen.

Maar even serieus: hoe kómen ze er bij Verizon bij dat dit iets handigs is waar de consument van zou denken, “wow, wat een best-in-class privacy solution, zo fijn dat Verizon ondanks haar evolutie in het mobiele advertentie-ecosysteem de focus houdt op mijn belangen”?

Arnoud

16 reacties

  1. Verizon doet wel meer dingen die eigenlijk niet door de beugel kunnen. TechDirt staat vol met rare verhalen over Verizon. Het probleem zit hier vooral bij de monopolie-posities die providers soms stiekem weten te verkrijgen. Zo ook in Nederland. Het probleem met Verizon is dat het bedrijf te groot is en een te belangrijk aandeel heeft in de internet-infrastructuur en dus eigenlijk niet failliet mag gaan. Net als sommige banken, eigenlijk. Dit geeft hen de mogelijkheid om stoute dingen te doen zonder dat ze daar al te zwaar gestraft voor kunnen worden. Zo hebben ze ruim 2 miljard dollars ontvangen in subsidies sinds 1994 om geheel Pennsylvania van fiberglas-internet te voorzien. En daar zijn ze tegenwoordig nog steeds niet echt aan begonnen. Dus deze privacyschending is voor hen een druppel op een gloeiende plaat. Liggen ze niet wakker van.

  2. De waarde voor Verizon (Vodafone in NL) is dat deze nu de in-app advertenties ook kunnen linken aan een persoon. Apps ondersteunen namelijk geen cookies, dus ook geen tracking cookies. Dat maakt het iets lastiger om advertentieruimte binnen apps te verkopen.

    1. Niet, ze passen de zelfde strategie toe als een ‘man-in-the-middle’ aanval. Jij verbindt met hun toegangspunt om op internet te kunnen komen. Dit toegangspunt voegt dingen aan jou request toe en/of vervangt dingen in de response.

      Zo passen de Vodafone internet sticks alle URL’s naar plaatjes aan zodat deze via hun cache lopen en jij een gecomprimeerde versie van het plaatje te zien krijgt. Pas als je op het plaatje klikt krijg je de originele kwaliteit.

        1. Als je SSL gebruikt dan is er sprake van encryptie over de verbinding, inclusief de HTTP headers. Deze kunnen dan niet meer uitgelezen worden. Nu kun je bij een Man-In-The-Middle nog wel een aanval uitvoeren als je zelf een SSL certificaat hebt doordat je met de gebruiker communiceert via je eigen certificaat en met de uiteindelijke host via hun certificaat. Gewoon een kwestie van steeds decrypten met de een en encrypten met de ander.

            1. Geen idee maar als apps zelf een public certificate bevatten en er dus niet van uit gaan dat ze die over https kunnen aanvragen dan werkt dat truukje van de providers niet meer. Dat zouden browsers ook kunnen doen, alleen hebben die ook certificaten van andere partijen nodig. Maar die kunnen opgehaald worden via de browservariant. Dan kunnen providers het niet meer onderscheppen.

  3. Weet iemand hoe Verizon dit trouwens doet? Deep-packet-inspection->http?->packet alteration of is het een kwestie van dat je daar verplicht een proxy van hun moet gebruiken, waardoor het als normaal klinkt dat ze er extra headers bij gooien? (X-FORWARDED-FOR)

    1. Geen idee hoe ze dat precies doen maar ik denk dat het tijd wordt dat iedereen alleen nog maar HTTPS pagina’s gaat bezoeken. Bij normaal HTTP verkeer kunnen ze immers gewoon de request en response afvangen, aanpassen en doorsturen. Maar als SSL wordt toegepast op de verbinding dan komen ze niet bij deze data, tenzij ze zelf een eigen SSL certificaat gebruiken voor een man-in-the-middle aanpak. Dat zou je als gebruiker dan wel moeten kunnen zien in je browser als je dit certificaat nakijkt. (Maar wie controleert dit eigenlijk?) Het meest irritante hiervan is dat Verizon/Vodafone zit te knoeien met het dataverkeer dat bij een webbrowser geen probleem is maar bij apps die via REST communiceren met web services mogelijk wel.

      1. Maar wie controleert dit eigenlijk?

        Ik heb Certificate Patrol, maar eerlijk gezegd klik ik dat gewoon weg voor de 90% van alle URLs waarin ik niet ben geïnteresseerd.

        Eigenlijk zou er een P2P uitwisseling van certificaten moeten komen, zodat mensen kunnen zien wanneer er meerdere certificaten voor de zelfde site in omloop zijn. Mensen en browser-makers zouden dan de overtredende certificaat-authoriteiten uit hun browser-instellingen kunnen verwijderen.

        Jammer genoeg zijn er een boel sites (met name Google-sites) die bij elke refresh wel weer een ander certificaat lijken af te geven. Ik weet niet precies waarom ze dit doen, maar het lijkt mij beter als ze daar mee zouden ophouden.

        1. Tja, zoals ik al vroeg, wie controleert dat nu eigenlijk? Als je dit soort meldingen al blindelings wegklikt dan kun je je afvragen waarom je nog Certificate Patrol blijft gebruiken. 🙂

          Maar wat ik belangrijk vind is dat er een methode komt die het onmogelijk maakt om een man-in-the-middle aanval uit te kunnen voeren. Er moet hier toch wel iets voor te bedenken zijn? Bij apps voor b.v. tablets en mobieltjes kun je b.v. de public key opnemen in de app zelf en deze vervolgens controleren met de key die wordt gebruikt voor de connectie met de server. Alleen, het aantal developers die hiervoor genoeg ervaring voor hebben is gewoon veel te weinig. De benodigde technische kennis is vrij complex.

  4. Los van het feit dat dit voor mijn gevoel tegen de geest van net-neutraliteit in gaat: al het verkeer gelijk behandelen. Daarnaast niet zo inzie wat https hier toevoegt: https zet je op met behulp van de website. Als de website-eigenaar graag die UIDH wil zien, dan kan die toch gewoon een query sturen naar verison “Hey ik heb hier een https verbinding van ip x.y.z, geef mij die UIDH”.

    Wat ik mij nu echt afvraag: Wat is het verschil met een UIDH en een IP-adres? Verison kan niet zien of jantje of pietje op die verbinding zit, ze kunnen hooguit je huidige IP-adres verbinden met een eerder dynamisch afgegeven IP-adres. In dat opzicht wordt je privacy niet verder aangetast dan dat je standaard op een vast IP zit, en dat is nu ook weer niet echt ongewoon.

Geef een reactie

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