Nuance: volgt Vodafone je met 'supercookies'?

Vodafone volgt klanten met 'supercookies' op het netwerk, waarmee het surfgedrag van gebruikers kan worden doorgegeven aan de provider, meldt NRC. Maar in de praktijk blijkt dat wel mee te vallen, toont een test van Tweakers aan.

NRC meldt dat het gaat om 'controversiële supercookies', die volgens de Amerikaanse privacy-organisatie Access Now in Nederland bij Vodafone zouden worden gebruikt. Ook De Telegraaf, de grootste krant van Nederland, bericht over het onderzoek. Via de 'supercookies' zou de provider het gebruik van apps en het surfgedrag van klanten kunnen volgen, claimt NRC.

Dat klinkt als een heftige privacy-inbreuk, maar het ligt genuanceerder. Allereerst gaat het niet om cookies die worden geïnjecteerd, maar om een header die zou worden meegestuurd. Die zogenoemde asid-header, die sommige providers inderdaad gebruiken, maakt het mogelijk om een gebruiker te volgen - zelfs als je je cookies leegt, of de incognitomodus gebruikt. De code is namelijk vanaf de kant van de gebruiker niet te verwijderen: het mobiele netwerk injecteert de header.

Dat zou nog steeds ernstig zijn, ware het niet dat Vodafone dergelijke headers slechts in bepaalde gevallen gebruikt. "We doen het alleen bij partijen met wie we een billing-relatie hebben", zegt Vodafone-woordvoerder Joost Galema. "Denk aan de applicatiewinkel van BlackBerry, of aanbieders van ringtones." In dergelijke gevallen wordt de header meegestuurd, zodat klanten via hun telefoonrekening aankopen doen. De aanbieder van de website geeft de code - de anonymous customer reference, zoals Vodafone hem noemt - aan Vodafone, waarna die provider de afrekening verzorgt. Volgens Vodafone zijn de codes niet te herleiden tot een persoon.

Op websites die niets afrekenen via de telefoonrekening, wordt de header niet meer meegestuurd. Vodafone-klanten kunnen dat controleren met deze tool, die een uitdraai maakt van alle headers die naar een server worden gestuurd.

Tot dit voorjaar stuurde Vodafone overigens wél een acr-code naar alle websites mee. "Maar die werd elke sessie opnieuw gegenereerd", zegt Galema. Dat is overigens nog steeds zo op websites die de code wel ontvangen. Het injecteren van de code werkte overigens niet op https-websites; verzoeken daarnaar kan de provider niet manipuleren. Mogelijk komt de verwarring doordat het onderzoek van Access Now plaatsvond tussen oktober 2014 en april van dit jaar, voordat Vodafone de wijziging doorvoerde.

Uit onderzoek van Tweakers blijkt dat ook KPN en T-Mobile geen acr-code meesturen naar elke server. Of ze dat wel doen naar bepaalde sites, net als in het geval van Vodafone, is op dit moment nog onduidelijk. De providers waren dinsdagochtend niet bereikbaar voor commentaar.

De headers van een Vodafone-klant: geen tracking-codes

Reacties (57)

[Verwijderd]

Het enige wat niet klopt bij het NRC artikel is de kop. Dezelfde persvoorlichter vertelt ook daar hoe de situatie momenteel bij Vodafone is en brengt zelf verwarring door te erkennen dat Vodafone gebruikmaakt van supercookies althans een variant daarvan. Dit terwijl de wijze van tracking op een geheel andere manier geschiedt. Ik vind het allemaal erg weinig basis voor een nuance artikel.

De Amerikaanse privacy-organisatie Access Now publiceerde gisteren een internationaal onderzoek naar de technologie. Daaruit bleek dat die in verscheidene landen, waaronder Nederland, wordt gebruikt. Access Now noemt Vodafone als een van de bedrijven die dat doen.

Woordvoerder Joost Galema erkent dat Vodafone de technologie inzet in Nederland. “Maar wij gebruiken die alleen waar die functioneel is. Bijvoorbeeld bij bepaalde online-betalingen die klanten laten verlopen via onze telefoonrekening. Daarvoor moeten wij de gebruiker kunnen identificeren en dat doen we via tracking headers. Een derde partij krijgt geen privé-gegevens en kan de informatie niet herleiden tot een persoon.”

De variant die Vodafone gebruikt heet anonymous customer reference-technologie, volgens Galema.
bron: http://www.nrc.nl/nieuws/...p-smartphones-gebruikers/

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:18]

[rduinmayer]

Als er niks aan de hand is, dan is er niks aan de hand.

[Blubber]

Mooi dat het feit dat deze header niet aan TLS requests wordt toegevoegd als feature wordt gezien. Dit betekent dat aankopen die op de telefoonrekening verschijnen altijd gedaan worden via een onbeveiligde verbinden ...

[Firefly III]

Onzin.

Als je via een onveilige verbinding bij de Blackberry store uit komt, met header en al, is het natuurlijk aan Blackberry om die header te koppelen aan een nieuwe veilige verbinding.

Blackberry kan de header opslaan in je sessie, en je doorschoppen naar een veilige verbinding. Voila. Geen onveilige verbinding maar wel de header onthouden.

Is toch niet zo moeilijk?

[doeternietoe]

Onzin.

Als je via een onveilige verbinding bij de Blackberry store uit komt, met header en al, is het natuurlijk aan Blackberry om die header te koppelen aan een nieuwe veilige verbinding.

Blackberry kan de header opslaan in je sessie, en je doorschoppen naar een veilige verbinding. Voila. Geen onveilige verbinding maar wel de header onthouden.

Is toch niet zo moeilijk?

Uiteraard kan dit, maar dat maakt voor een Man-in-the-Middle attack geen verschil. Als het mij zou lukken om uit die eerste, onveilige verbinding met de Blackberry store je header uit te lezen, kan ik die gebruiken om zelf een onbeveiligde verbinding (met jouw gegevens) te initiëren met de Blackberry Store. De Server ziet een geldig id, dat hoort bij een telefoonnummer/klant, en gebruikt deze om een nieuwe, veilige verbinding op te zetten. Op deze veilige verbinding kan ik dan in naam van iemand anders gaan winkelen.

Twee mogelijk bezwaren tegen deze kwetsbaarheid zijn allereerst dat je aankopen in dergelijke stores aan een account gekoppeld zullen worden en daarnaast dat het denkbaar is dat het niet mogelijk is om twee keer de overstap te maken van een onbeveiligde verbinding met een unieke id naar een beveiligde verbinding waarop aankopen gedaan kunnen worden. Mogelijk heeft Vodafone het zo geregeld dat er iedere keer een nieuwe code wordt gegenereerd.

De aanvaller kan het laatste tegengaan door de afgetapte header zelf eerst te gebruiken voordat deze doorgestuurd wordt naar het slachtoffer.

[Reactie gewijzigd door doeternietoe op 24 juli 2024 01:18]

[Zumpelvelder]

zoals Woy zegt: met een MitM attack het id uitlezen en vervolgens op je eigen (niet telefoon) verbinding injecteren. Als bijvoorbeeld BlackBerry store dat id dan onthoud, dan gaat het toch fout, of begrijp ik het verkeerd?

Toevoeging:

En als dat id slechts iedere sessie opnieuw gegenereerd wordt, waarbij ik aan neem dat het de internet sessie betreft met de telefoon toren, dan krijgt iedere website dezelfde code. Dus als je een dubieuze ringtone verkoop site wordt, dan kun je die id's makkelijk er uit vissen en daarmee dingen kopen in de BlackBerry store. (denk ik)

[Reactie gewijzigd door Zumpelvelder op 24 juli 2024 01:18]

[Kees]

Toen ze die header nog naar iedereen injecten was hij met elke request verschillend. Je kon dus niet een gebruiker ermee volgen.

[Juup]

"Maar die werd elke sessie opnieuw gegenereerd", zegt Galema

Sessie != Request

[Kees]

Voor een internetprovider is elke nieuwe connectie een sessie. Per connectie kun je inderdaad meerdere requests doen, maar alleen de eerste request kreeg de header mee iirc.

En als je keepalive uitzet dan is request = sessie vanuit het oogpunt van de provider.

[Woy]

Inderdaad, en dus is het ID ook uit te lezen d.m.v. een MitM attack, en dus kan iemand die de verbinding af kan luisteren dus ook op jouw kosten betalingen doen op de sites waar hij het verkeer van afluistert. Tevens zie ik in het bericht niet duidelijk terug dat er per host verschillende id's gebruikt worden ( Er wordt aangegeven dat er per sessie een ander ID gebruikt wordt, maar als dat per data-sessie met de mast is, dan zou het dus kunnen zijn dat het ID ook te gebruiken is bij sites die jij niet eens bezoekt ).

[t1mmy]

Tot dit voorjaar stuurde Vodafone overigens wél een acr-code naar alle websites mee. "Maar die werd elke sessie opnieuw gegenereerd", zegt Galema. Dat is overigens nog steeds zo op websites die de code wel ontvangen.

Goed om te zien dat dit een weloverwogen keuze is geweest waarbij gedacht is aan de privacy van de gebruiker, mag ook eens gezegd worden Een advertisement platform wie dan ook kan je dus nooit tracken aan de hand van deze header, want zelfs al zou de website die je bezoekt de header binnen krijgen, dan zou hij voor elk request anders zijn. Prima, lijkt mij

[Reactie gewijzigd door t1mmy op 24 juli 2024 01:18]

[Zarc.oh]

Goed om te zien dat dit een weloverwogen keuze is geweest waarbij gedacht is aan de privacy van de gebruiker, mag ook eens gezegd worden

Waar is het bewijs dat ze aan je privacy denken?

Een advertisement platform wie dan ook kan je dus nooit tracken aan de hand van deze header, want zelfs al zou de website die je bezoekt de header binnen krijgen, dan zou hij voor elk request anders zijn. Prima, lijkt mij

Vodafone weet van iedere header bij welke abonnee dit hoort:

We doen het alleen bij partijen met wie we een billing-relatie hebben

edit:
Dubbel haakje verwijderd

[Reactie gewijzigd door Zarc.oh op 24 juli 2024 01:18]

[t1mmy]

Waar is het bewijs dat ze aan je privacy denken?

Nergens. Maar het resultaat heeft wel gevolgen voor privacy, in goede zin. Daarnaast, waarom zouden ze anders elke keer een unieke header genereren? In feiten is het niet 100% noodzakelijk en zorgt alleen maar voor meer overhead.

Vodafone weet van iedere header bij welke abonnee dit hoort:

Vodafone heeft die header niet nodig om te weten welk request van welk abonnee komt. Mijn punt is dat andere bedrijven niet die header kunnen gebruiken om je overal te traceren

[Zarc.oh]

Het heeft gevolgen in de zin dat er minder gevolgd kan worden, maar het kan nog steeds, ongevraagd. Daarnaast blijf je nog steeds aannames doen dat een unieke header niet noodzakelijk is.
Laat ik het eens omdraaien, als ze overal dezelfde header invoegen, waarom zou Vodafone het dan uberhaupt doen? Dan heeft dat net zoveel nut als helemaal geen header invoegen omdat het toch overal hetzelfde is. Vodafone weet immers ook op welke websites het wordt ingevoegd, dus kun je ook alle websites waarop het van toepassing is en je bezocht hebt, bijelkaar optellen en dat is net zo nuttig als overal dezelfde header invoegen.

[GORby]

Nee, eigenlijk niet...

Telkens wanneer je met je mobiel via vodafone met een andere server verbindt, is dat een nieuwe sesse, dus met een nieuwe ID. De sites onderling kunnen dus door die ID niet weten of je op die andere sites ook al geweest bent, en kunnen je daardoor dus ook niet tracken. Ze kunnen alleen tegen vodafone zeggen: sessie ID xyz heeft aankoop abc gedaan voor 123 euro (via ip adres aaa.bbb.ccc.ddd), zodat dat mooi gefactureerd wordt door vodafone.

De enige die je kan tracken is vodafone zelf, en aangezien je hun netwerk gebruikt, hebben ze daar die ID's ook echt niet voor nodig. De enige manier om je daartegen te beschermen, is een beveiligde verbinding gebruiken (https, of via een VPN).

[BRAINLESS01]

Inderdaad, dit is helemaal geen negatief nieuws (hoewel het wel zo ingestoken is). Vodafone heeft wel nagedacht en gebruiken het alleen om daadwerkelijk functionaliteit toe te voegen (kopen via telefoonrekening). Zelfs de partners kunnen met die unieke code per request helemaal niets.

[Woy]

[...]
Een advertisement platform wie dan ook kan je dus nooit tracken aan de hand van deze header, want zelfs al zou de website die je bezoekt de header binnen krijgen, dan zou hij voor elk request anders zijn. Prima, lijkt mij

Nee het zal zeker niet voor elk request anders zijn. Zoals ze hier aangeven is dat voor elke sessie anders. Ik neem aan dat ze hier een data-sessie op het 3g/4g netwerk bedoelen. En dan blijft het dus wel over een periode gelijk. Maar ze kunnen je inderdaad niet over langere tijd tracken.

Het is wel interessant om te weten of het ID ook over verschillende hosts hergebruikt wordt, of dat het per host een ander ID is. Anders is het dus ook mogelijk om je over verschillende sites te tracken.

[Reactie gewijzigd door Woy op 24 juli 2024 01:18]

[Iftert]

Dus ze gebruiken het alleen om het afrekenen te vergemakkelijken bij bepaalde bedrijven? Ik ga er dan even vanuit dat Vodafone hier geen misbruik van maakt. Maar zijn dit soort "cookies" nu ook niet te makkelijk te misbruiken door 3e partijen?

[Martindo]

Het maakt het mogelijk aankopen te doen in een BlackBerry Store en de rekening via je mobiele abonnement te laten verlopen. En dat is mogelijk door deze asid-header mee te sturen (ofwel, te injecteren). Ik zie niet echt in hoe je deze code kunt misbruiken.

[Reactie gewijzigd door Martindo op 24 juli 2024 01:18]

[Mrjraider]

Ik ga er vanuit dat dit dus alleen maar op hun netwerk gebeurd dus als je toevallig je webmail bekijkt via de LTE o.i.d. Dus op zich valt de inbreuk wel mee. Aangezien veel gebruikers verschillende applicaties gebruiken voor mail, Facebook etc. waar, zoals ik uit het bericht haal, geen code meegestuurd word.

[Martindo]

Je verbind met een server buiten het vodafone netwerk, dus ik ga er van uit dat je wel een punt hebt dat je buiten het Vodafone netwerk zit.

[herbalx]

Denk aan de applicatiewinkel van BlackBerry, of aanbieders van ringtones." In dergelijke gevallen wordt de header meegestuurd, zodat klanten via hun telefoonrekening aankopen doen.

De vraag is of dit wel wenselijk is.

Persoonlijk wens ik helemaal geen aankopen via mijn telefoonrekening bij een derde partij te doen.

In het verleden heb ik voldoende mensen voorbij zien komen die allerlei "diensten" of "aankopen" op hun rekening terug zagen komen terwijl dit nooit bewuste keuze was van deze mensen. Bijv. doordat men perongeluk een adverntie had aangeraakt.

In mijn optiek zou het dan ook een stuk wenselijker zijn om het versturen van een ASID-header standaard uit te schakelen en deze alleen per dienst of dienstverlener in te schakelen. Derhalve zie ik het het injecteren van een ASID-header als ongevraagde manipulatie van mijn internet verkeer.

[Firefly III]

Overigens is het natuurlijk dikke vette onzin dat Vodafone je volgt "met supercookies".

Vodafone is notabene de netwerkprovider. Ze leveren alles, de complete verbinding van onderen tot boven. Afgezien van https verkeer is het voor Vodafone echt helemaal niet nodig om headers te injecteren of supercookies te plaatsen of ander primitief geneuzel. Ze weten wie je bent, ze hebben je IMEI, je zit op de masten van Vodafone en je gebruikt een simkaart van... Vodafone!

Waarom zouden ze daar bovenop nog cookies en headers gaan zitten doen?

[CAPSLOCK2000]

Nee, het valt niet mee, het had erger gekund, maar ik vind dit niet de plek voor verzachtende woorden. Wat Vodafone doet is al erg genoeg.

Een provider moet zo'n handen thuis houden en niet met z'n vingers aan het verkeer van de klanten gaan zitten. Gewoon niet doen, afblijven! Internetverkeer is prive, daar blijf je vanaf, ongeacht het doel.

Als ik een brief schrijf dan mag de postbode die toch ook niet open maken om er wat bij te schrijven? Of de postbode nu een relatie heeft met de ontvanger of niet maakt niet uit. Het is zijn werk om brieven te vervoeren, niet om ze te veranderen.

Tijd voor wetgeving om de positie van ISPs te regelen. ISPs proberen zo veel mogelijk te verdienen door klantinformatie te verkopen. Dat snoepen van twee walletjes vind ik maar niks zeker als het achter de rug van de klanten om gaat. Als klant weet je niet eens dat dit gebeurd en dan kun je ook niet weigeren of naar een andere aanbieder overstappen. Wat mij beterft wordt het helemaal verboden en moeten ISP's één ding doen: internet toegang verzorgen. Niks geen gedoe met "toestemming" vragen want dan hebben we zo het volgende cookiewetfiasco waarbij mensen gedwongen worden om blind toestemming te geven voor lange lappen juridische tekst.

[kdekooter]

Dus: in bepaalde gevallen voegt Vodafone ongevraagd eigen HTTP headers toe aan jouw request.

[RobinF]

Dus: in bepaalde gevallen voegt Vodafone ongevraagd eigen HTTP headers toe aan jouw request. zodat jij (bijvoorbeeld) aankopen kan doen in de BlackBerry Store met je mobiele abonnement

[MadEgg]

Heel aardig van ze, maar dat zouden ze me natuurlijk ook gewoon kunnen vragen als ik de BlackBerry Store bezoek. Ik zou me zo kunnen indenken dat dat via een soort van oauth systeem best kan; de BlackBerry store vraagt mij om mijn mobiele provider, doet een verzoek aan bijvoorbeeld Vodafone oAuth. Vodafone kan ongetwijfeld op basis van mijn mobiele IP-adres bepalen welk telefoonnummer / abonnee daarbij hoort en vervolgens BlackBerry laten weten dat de aankoop via de telefoonrekening gedaan kan worden.

[Kees]

Nee dat kan vodafone niet op basis van jouw IP adres. Vodafone gebruikt 255 adressen voor hun miljoenen klanten. De enige manier die vodafone heeft om jouw te authenticeren is door een header te inserten voordat je het internet opgaat.

Nu is het vast ook wel mogelijk om dit anders op te lossen, maar dit is verreweg de makkelijkste oplossing die ook nog eens veilig is; de gebruiker kan niet zelf dingen veranderen. De ontvanger kan toch niets met die header (ja, ik heb ernaar gekeken toen ze die header nog naar alle sites stuurden). Het enige is dat je weet dat die gebruiker een vodafone abonnee is. Maar die conclusie kon je toch al trekken uit het IP adres.

[MadEgg]

255? Really? De nood is echt hoog met de beperkte IPv4-adresruimte blijkbaar! Dan wordt het wel wat lastiger ja.

Ach, mij maakt het verder niet zoveel uit, ik heb een VPN van mijn telefoon naar mijn server in een datacentrum ingesteld dus al het verkeer is al ruim voordat het bij mijn provider (geen Vodafone overigens) aankomt versleuteld, dus er kan ook niet mee gerommeld worden. De reden dát ik dat doe is wel argwaan naar de providers, aangezien ze in het verleden ook al aardig wat niet al te beste beurten bij mij gemaakt hebben.

[Kees]

Ze zullen er vast ewl meer hebben, maar het gros van de vodafone klanten komt via 62.140.132.0/24

[FreshMaker]

KPN en VF ( en TM vast ook wel ) werken met een interne NAT, ik zag voorheen op mijn (oude) VF account regelmatig een 10.x ipadres, terwijl mijn server thuis mijn bezoek had gelogd inderdaad met een 62.x adres

KPN voert hetzelfde trucje uit, want ik kan geen directe incoming FTP opzetten over mijn 4G verbinding naar mijn telefoon.

Niets mis mee overigens, een groot deel van de wereld heeft geen 'eigen' IPadres meer, maar het nat-verhaal van hun ISP

255? Really? De nood is echt hoog met de beperkte IPv4-adresruimte blijkbaar! Dan wordt het wel wat lastiger ja.

Ach, mij maakt het verder niet zoveel uit, ik heb een VPN van mijn telefoon naar mijn server in een datacentrum ingesteld dus al het verkeer is al ruim voordat het bij mijn provider (geen Vodafone overigens) aankomt versleuteld, dus er kan ook niet mee gerommeld worden

Versleuteld ja, maar niet perse door of ondanks jouw VPN gebruik, want je gebruikt jouw telefoon als toegang NAAR de vpnserver.
Dus er is al een stukje wat buiten jouw macht verloopt.
Er zal altijd een verbinding opgebouwt moeten worden, tussen jou en jouw server

[Reactie gewijzigd door FreshMaker op 24 juli 2024 01:18]

[Kees]

Dat weet ik, het leek mij redelijk obvious.

Wat ik wel vreemd vind is dat vooral mobiele providers nog niet op grote schaal ipv6 uitrollen, want juist de mobiele providers zijn degene die trucs moeten toepassen om klanten internet te bieden..

[FreshMaker]

Dat weet ik, het leek mij redelijk obvious.

Wat ik wel vreemd vind is dat vooral mobiele providers nog niet op grote schaal ipv6 uitrollen, want juist de mobiele providers zijn degene die trucs moeten toepassen om klanten internet te bieden..

Jij weet dat, maar de opmerking van Madegg maakt duidelijk dat er toch gebruikers zijn die denken dat ze echt een één op één verbinding hebben met de buitenwereld.

IPv6 zou inderdaad veel problemen oplossen, voor hen ( en ons )

[Kees]

IPv6 zou onder andere oplossen dat men deze header niet meer hoeft mee te geven en dat elke website gewoon netjes de mobiele telefoons kan tracken via het IP.

Dat maakt de ophef van sommige mensen hier ook wat vreemd; bij een 'normale' internet verbinding heb je al een 'magic nummer' om iemand mee te tracken, namelijk het IP adres.

[Armin]

en dat elke website gewoon netjes de mobiele telefoons kan tracken via het IP.

Of dat 'netjes' is weet ik niet maar dat kan niet met IPv6 want jouw telefoon zal niet de hele tijd hetzelfde IPv6 adres gebruiken ivm privacy extensies. Juist om tracken te voorkomen ...

[Kees]

Maar dat is net zo 'erg' als de header van vodafone. Die wisselt ook per sessie/request.

[Armin]

Alleen heeft Vodafone geen weet/controle over mijn IPv6 adres. Die verandert namelijk niet alleen per sessie/request, maar ook binnen een sessie/request.

Vele mensen denken dat bij IPv6 je een wereld-uniek IPv6 adres krijgt. Dat is echter niet zo. Jouw PC/telefoon krijgt een range waarin ze zelf het IP kunnen samenstellen. De privacy extensies van IPv6 maken hiervan gebruik door binnen een sessie van IP te wisselen zodat er niet getracked kan worden.

Ik zeg overigens ook niet dat de header van Vodafone 'erg' is. Alleen wel dat het gebruik van IP nummers om te tracken niet gaat werken.

[FreshMaker]

De meesten reageren blind als een stier op de rode lap.
Provider + Privacy = Bad
Vanaf die stelling kun je niets meer redden in het verhaal, net zoals je momenteel in elk Windows 10 artikel privacyissues hebt

[Armin]

Versleuteld ja, maar niet perse door of ondanks jouw VPN gebruik, want je gebruikt jouw telefoon als toegang NAAR de vpnserver.
Dus er is al een stukje wat buiten jouw macht verloopt.
Er zal altijd een verbinding opgebouwt moeten worden, tussen jou en jouw server

Wellicht dat ik jouw opmerking verkeerd begrijp, maar de hele route is versleuteld van telefoon door Vodafone APN, tot aan zijn server. Dus het is versleuteld door zijn VPN gebruik.

Het opzetten van de verbinding is uiteraard nodig maar daarbij vind geen normaal gebruikers verkeer plaats. Zijn website bezoek is dus volledig annoniem en versleuteld. Keerzijde is dan ook dat hij geen ringtones of zo kan kopen bij die Blackberry en dergelijke websites.

Maar dat zal bij gewoon WiFi gebruik dan waarschijnlijk ook niet kunnen.

[McVirusS]

Hmm, zou dat niet enorm fraude gevoelig zijn? Je kan in principe natuurlijk gewoon ook zelf headers injecteren bijvoorbeeld.

[kw4h]

Mijn loadbalancer voegt ook ongevraagd eigen headers toe aan HTTP requests, en zelfs bij HTTPS als de loadbalancer dat offloadt. Je statement is een beetje overtrokken.

In principe komt het er op neer dat ze een overeenkomst hebben met bepaalde partijen zodat jij direct via je telefoonrekening iets kan afrekenen. Die andere partij heeft iets nodig om je te identificeren, en dat is in dit geval een of andere 'anoniem' (voor zover we dat kunnen beoordelen) token. Of de oplossing netjes is of niet daargelaten, is het nu wel fijn dat het niet meer naar alle websites wordt doorgestuurd zoals voorheen.

Nu vraag ik me wel af hoe goed dat token wordt gecontroleerd. Als zo'n token het enige is om iets mee af te rekenen, kan ik dan wat afrekenen op een ander mobiel abonnement door gewoon die header te injecteren?

[Armin]

Als zo'n token het enige is om iets mee af te rekenen, kan ik dan wat afrekenen op een ander mobiel abonnement door gewoon die header te injecteren?

Dat vroeg ik mij ook af, en het lijkt erop van wel. Maar dat token is dus uniek per sessie, dus heb je als aanvaller maar beperkt de kans.

[FreshMaker]

Het is echt tijd dat de zomervakanties eindigen, het 'nieuws' op de "grote" pagina's wordt steeds spannender.

Natuurlijk 'volgt' een provider jouw stappen, het probleem is echter meer WAT doen ze er mee, en hoe diep "lezen" ze mee.
Persoonlijk heb ik een vertrouwensrelatie met mijn provider, dus alles wat ik via hun verbinding doe, zullen ze kunnen oplepelen, en gebruiken.
Maar .... ik ga er van uit dat men het ( zoals ze aangeven) alleen gebruiken om de diensten te verbeteren.
Naief, ja ... dat weet ik ook wel, en er is meer tussen diensten en dataverzamelingswoede.
Dat een provider ( maakt niet uit welke ) het kan, is gewoon een technisch gegeven, ik heb meer moeite met externe partijen die tracking doen, terwijl ik technisch niets van hen wil gebruiken ( doubleclick, disquss, facebook en who ever more )
Daarom gebruik ik een addblocker / Ghostery, ik blokkeer zoveel mogelijk, en als de site in kwestie daar iets tegen heeft, blokkeren ze mij ook maar.

Maar dit soort berichten op supercookies hebben ons al de cookiewall en hetze gebracht, en kosten alleen maar meer investeringen op pagina's

[Reactie gewijzigd door FreshMaker op 24 juli 2024 01:18]