A lecke végére el tudod magyarázni, milyen adat keletkezik egy weboldalon, meg tudod különböztetni az első és harmadik fél szerepét, ismered a GDPR alapelveit és az érintetti jogokat, fel tudod ismerni a megtévesztő tervezési mintákat, és tervezési kérdésként tudod kezelni az adatvédelmet.
Miért tervezési kérdés az adatvédelem?
A webes szolgáltatás működés közben adatokat kezelhet a felhasználóról, a készülékéről és a viselkedéséről. A technikai lehetőség nem válaszolja meg, hogy mit indokolt gyűjteni, milyen célból, mennyi ideig és milyen valódi választási lehetőséggel. Az adatvédelem tervezési és felhasználói bizalmi kérdés is: ami nincs begyűjtve, az nem szivároghat ki (8. fejezet), és a felhasználó csak akkor dönthet értelmesen, ha érti, mi történik az adataival.
Mit jelent adat a weben?
Adat lehet a név, az e-mail-cím vagy a születési dátum, de a látszólag jelentéktelen részletek is összekapcsolhatók emberrel vagy eszközzel: egy bejelentkezési azonosító, egy tartós hirdetési azonosító, egy IP-cím (4.1), egy pontos helyadat, vásárlási előzmény vagy az, hogy mely cikkeket olvasta valaki. Egyetlen adat önmagában néha kevés, több együtt azonban részletes profilt alkothat.
Három kérdést érdemes feltenni:
Milyen adat keletkezik?
Ki kapja meg: csak az üzemeltető, vagy elemző, hirdetési, beágyazott videós és közösségi szolgáltató is?
Milyen célból és meddig őrzik?
Ha ezekre nincs világos válasz, a felhasználó nem tud értelmes döntést hozni. Egy időpontfoglaló oldalon az e-mail-cím az értesítéshez ésszerűen szükséges lehet; a böngésző nyelve segíthet a felület megjelenítésében. Az érdeklődési profil építése azonban más cél: nem következik automatikusan a foglalásból. A cél megváltoztatása különösen fontos tervezési pillanat.
flowchart LR
U[Felhasználó] --> S[Szolgáltatás]
S -->|szükséges adat| M[Működés]
S -->|külön cél és döntés| A[Elemzés vagy követés]
A --> T[Adatmegőrzés és törlés]
Cookie-k és más követési módok
A cookie működését a 7.2 leckében tárgyaltuk: a szerver név–érték párt küld, a böngésző a megfelelő későbbi kérésekhez visszaküldi. Az MDN szerint a cookie-k három fő célra szolgálnak: munkamenet-kezelés, személyre szabás és követés (a felhasználói viselkedés rögzítése és elemzése, gyakran webhelyeken át). A cookie attribútumai (Secure, HttpOnly, SameSite) biztonsági és működési tulajdonságok, nem automatikus adatvédelmi felmentések.
Nem minden cookie követés, és nem minden követés cookie. Egy első féltől származó bejelentkezési cookie sokszor a felhasználó által kért funkcióhoz kell. Azonosítás ugyanakkor történhet localStorage-ban tárolt értékkel (7.3), URL-paraméterrel, bejelentkezéssel, szerveroldali naplókkal vagy több böngészőjellemző összekapcsolásával is. Utóbbi az eszköz- vagy böngészőujjlenyomat (fingerprinting): a képernyőméret, a nyelv, a betűkészletek, a grafikus képességek és más jelek kombinációja valószínűsítheti a visszatérő eszközt, és gyakran kevésbé látható, mint egy cookie.
Első és harmadik fél; mérés és profilalkotás
Az első fél (first party) az a webhely, amelyet a felhasználó felkeresett. Harmadik fél (third party) lehet az oldalba betöltött analitikai szkript, hirdetési hálózat, térkép, betűtípus, chatmodul vagy közösségi beágyazás. Az MDN szerint a harmadik fél cookie-ja olyan beágyazott tartalomhoz tartozik, amely más webhelyről érkezik, és oldalak közötti követést is lehetővé tesz; a böngészők egyre inkább alapértelmezésben blokkolják ezeket. A böngésző hálózati nézetében (2.5) a harmadik fél tartalma külön kérésként jelenik meg. Egy kényelmes beágyazás tehát adatáramlási döntés is.
Az összesített, rövid ideig megőrzött látogatási statisztika és az egyének közötti, hosszan épített viselkedési profil között nagy a különbség. A termékfejlesztéshez hasznos megtudni, hogy egy űrlap melyik lépésénél akadnak el sokan; ehhez nem feltétlenül kell névhez kötni minden kattintást, vagy ugyanazt az embert más webhelyeken is felismerni. A célhoz illő mérés gyakran kevesebb adatból is lehetséges.
Hozzájárulás: valódi választás, nem dekoráció
Sok oldalon felbukkan a cookie-sáv. Jó esetben ez rövid és érthető döntési pont: mi szükséges a működéshez, mi opcionális, milyen célokra menne adat, és hogyan lehet később módosítani a választást. A visszautasítást sem szabad indokolatlanul elrejteni vagy nehezíteni. A „mindent elfogadok” nagy, színes gombja mellett apró, több lépéses elutasítás rossz felhasználói élmény és etikailag is problémás tervezési minta.
A hozzájárulást érdemes célok szerint bontani (szükséges, beállítások, mérés, személyre szabott hirdetés). A „szükséges” kategória nem varázsszó: csak az a technika tartozhat ide, amely nélkül a kifejezetten igényelt szolgáltatás nem működik ésszerűen. A választást később ugyanúgy elérhetővé kell tenni, mint az elfogadást. Egy érthető adatkezelési tájékoztató nem a banner helyett van, hanem annak részletes háttere. A hozzájáruló felület legyen billentyűzettel kezelhető is (9.2).
GDPR mint szemléleti keret
Az európai adatvédelmi szabályozás, a GDPR (az (EU) 2016/679 rendelet) az érintettek jogait és az adatkezelők felelősségét hangsúlyozza. A rendelet 5. cikke a személyes adatok kezelésének hét alapelvét sorolja fel:
Alapelv
Jelentése a tervezésben
Jogszerűség, tisztességes eljárás, átláthatóság
Világos tájékoztatás, nem megtévesztő kezelés.
Célhoz kötöttség
Az adatot csak a megadott célra használjuk.
Adattakarékosság
Csak a szükséges adatot gyűjtjük.
Pontosság
Az adat legyen helyes és naprakész.
Korlátozott tárolhatóság
Nem őrizzük a szükségesnél tovább.
Integritás és bizalmas jelleg
Megfelelő biztonság (4.3, 7., 8. fejezet).
Elszámoltathatóság
Az adatkezelő igazolni tudja a megfelelést.
Az érintettnek a III. fejezet szerint jogai vannak, többek között a hozzáféréshez, helyesbítéshez, törléshez, korlátozáshoz, hordozhatósághoz és tiltakozáshoz. A fenti elveket a rendelet szövege nevezi meg; az alkalmazásuk konkrét esetben az adatkezelés céljától és körülményeitől függ. Ezért nem helyes egy tárgy keretében kész jogi ítéletet mondani arról, hogy egy valós oldal „GDPR-kompatibilis-e”. A fejlesztő felelőssége inkább az, hogy időben felismerje az adatáramlást, kérdezzen, és ne késői utómunkaként kezelje a védelmet: tényleg kell-e a telefonszám? Miért őrizzük az eseménynaplót? Ki fér hozzá? Hogyan tájékoztatjuk az embert?
Digitális etika: amit a szabály még nem rendez el
Lehet valami technikailag megengedettnek gondolt, mégis tisztességtelen. A megtévesztő tervezési minták (deceptive design patterns, korábbi nevükön „dark patterns”) erre jó példák: előre bepipált opciók, félrevezető megfogalmazás, szégyenérzetet keltő elutasító gomb, vagy olyan folyamat, amely ráveszi a felhasználót több adat átadására. Az Európai Adatvédelmi Testület (EDPB) a témáról külön irányelvet adott ki (Guidelines 03/2022, a közösségi média felületekre szólva), amely felismerésükhöz és elkerülésükhöz ad segítséget. Hasonló kérdés az algoritmikus személyre szabás: ha egy rendszer ismeri a sérülékeny pillanatokat, és ezeket kihasználva próbál több időt vagy pénzt kicsikarni, a „növeli a konverziót” nem elégséges indok.
Az etikus rendszer tervezője nem csak azt kérdezi, meg tudjuk-e szerezni az adatot. Azt is, hogy a felhasználó érti-e a következményt, arányos-e az előny a beavatkozással, és ki viseli a kockázatot hiba vagy visszaélés esetén. Az adatminimalizálás gyakran egyben biztonsági előny.
Végigvezetett példa: hírlevél és látogatási mérés a Kurzuspontban
Egy rendezvényoldal hírlevélhez e-mail-címet kér, az eseményoldalon látogatottságot mér, és beágyazott videót jelenít meg. Első lépésként fel kell térképezni az adatfolyamot: az e-mail a feliratkozás kezelőjéhez jut; a mérőkód eseményeket küld; a videó betöltése külső szolgáltatóhoz kapcsolódhat. Második lépés a célok elválasztása: a hírlevél kezelése, a szolgáltatás működtetése és az opcionális elemzés nem ugyanaz.
Döntés
Indok
A hírlevélhez csak e-mail-cím kell, név nem
Adattakarékosság.
A videó „kattintásra tölt be”
A harmadik fél nem kap automatikusan adatot.
A mérés aggregált, rövid megőrzéssel
Célhoz kötöttség, korlátozott tárolhatóság.
A cookie-sáv célokra bontva, egyenrangú „elfogad”/„elutasít” gombbal
Valódi választás, nem megtévesztő minta.
A leiratkozás egy kattintás
Átláthatóság, az érintett joga.
Az eredmény nem „nulla adat”, hanem megfontolt adatkezelés.
Gyakori tévhitek
Állítás
Pontosítás
„Minden cookie tiltott, amíg nincs kattintás.”
A technika neve nem dönti el egyedül a kérdést: a kért funkcióhoz kapcsolódó tárolások mások, mint a követés; a pontos megítélés körülményfüggő.
„Az inkognitó mód teljesen anonim.”
Elsősorban a helyi böngészési nyomokat kezeli másként; a hálózat és a felkeresett oldalak ettől még láthatnak adatokat.
„Ha nem kérünk nevet, nincs személyes adat.”
Egy tartós azonosító vagy több jel együtt emberhez vagy eszközhöz kapcsolható.
„Az adatvédelmi tájékoztató megoldja az etikai problémát.”
A hosszú, érthetetlen tájékoztató nem teszi tisztességessé a manipulatív vagy aránytalan gyakorlatot.
A weben a látszólag jelentéktelen adatok (azonosító, IP-cím, böngészőjellemzők) is emberhez köthetők, együtt profilt alkothatnak.
A cookie nem azonos a követéssel; az ujjlenyomat-készítés cookie nélkül is azonosít.
Harmadik fél (analitika, hirdetés, beágyazás) adatáramlási döntés; a böngészők egyre inkább blokkolják a harmadik fél cookie-it.
A GDPR 5. cikkének hét alapelve tervezési szempont; az érintettnek hozzáférési, helyesbítési, törlési, korlátozási, hordozhatósági és tiltakozási joga van.
A megtévesztő tervezési minták etikai problémák akkor is, ha technikailag megengedettek.
Ellenőrző kérdések
Miért nem azonos a cookie a követéssel?
Mi a különbség az első és a harmadik fél között, és miért adatáramlási döntés egy beágyazás?
Sorolj fel három GDPR-alapelvet, és mondj egy tervezési következményt!
Adatvédelem, követés és digitális etika
Célok
A lecke végére el tudod magyarázni, milyen adat keletkezik egy weboldalon, meg tudod különböztetni az első és harmadik fél szerepét, ismered a GDPR alapelveit és az érintetti jogokat, fel tudod ismerni a megtévesztő tervezési mintákat, és tervezési kérdésként tudod kezelni az adatvédelmet.
Miért tervezési kérdés az adatvédelem?
A webes szolgáltatás működés közben adatokat kezelhet a felhasználóról, a készülékéről és a viselkedéséről. A technikai lehetőség nem válaszolja meg, hogy mit indokolt gyűjteni, milyen célból, mennyi ideig és milyen valódi választási lehetőséggel. Az adatvédelem tervezési és felhasználói bizalmi kérdés is: ami nincs begyűjtve, az nem szivároghat ki (8. fejezet), és a felhasználó csak akkor dönthet értelmesen, ha érti, mi történik az adataival.
Mit jelent adat a weben?
Adat lehet a név, az e-mail-cím vagy a születési dátum, de a látszólag jelentéktelen részletek is összekapcsolhatók emberrel vagy eszközzel: egy bejelentkezési azonosító, egy tartós hirdetési azonosító, egy IP-cím (4.1), egy pontos helyadat, vásárlási előzmény vagy az, hogy mely cikkeket olvasta valaki. Egyetlen adat önmagában néha kevés, több együtt azonban részletes profilt alkothat.
Három kérdést érdemes feltenni:
Ha ezekre nincs világos válasz, a felhasználó nem tud értelmes döntést hozni. Egy időpontfoglaló oldalon az e-mail-cím az értesítéshez ésszerűen szükséges lehet; a böngésző nyelve segíthet a felület megjelenítésében. Az érdeklődési profil építése azonban más cél: nem következik automatikusan a foglalásból. A cél megváltoztatása különösen fontos tervezési pillanat.
flowchart LR U[Felhasználó] --> S[Szolgáltatás] S -->|szükséges adat| M[Működés] S -->|külön cél és döntés| A[Elemzés vagy követés] A --> T[Adatmegőrzés és törlés]Cookie-k és más követési módok
A cookie működését a 7.2 leckében tárgyaltuk: a szerver név–érték párt küld, a böngésző a megfelelő későbbi kérésekhez visszaküldi. Az MDN szerint a cookie-k három fő célra szolgálnak: munkamenet-kezelés, személyre szabás és követés (a felhasználói viselkedés rögzítése és elemzése, gyakran webhelyeken át). A cookie attribútumai (
Secure,HttpOnly,SameSite) biztonsági és működési tulajdonságok, nem automatikus adatvédelmi felmentések.Nem minden cookie követés, és nem minden követés cookie. Egy első féltől származó bejelentkezési cookie sokszor a felhasználó által kért funkcióhoz kell. Azonosítás ugyanakkor történhet
localStorage-ban tárolt értékkel (7.3), URL-paraméterrel, bejelentkezéssel, szerveroldali naplókkal vagy több böngészőjellemző összekapcsolásával is. Utóbbi az eszköz- vagy böngészőujjlenyomat (fingerprinting): a képernyőméret, a nyelv, a betűkészletek, a grafikus képességek és más jelek kombinációja valószínűsítheti a visszatérő eszközt, és gyakran kevésbé látható, mint egy cookie.Első és harmadik fél; mérés és profilalkotás
Az első fél (first party) az a webhely, amelyet a felhasználó felkeresett. Harmadik fél (third party) lehet az oldalba betöltött analitikai szkript, hirdetési hálózat, térkép, betűtípus, chatmodul vagy közösségi beágyazás. Az MDN szerint a harmadik fél cookie-ja olyan beágyazott tartalomhoz tartozik, amely más webhelyről érkezik, és oldalak közötti követést is lehetővé tesz; a böngészők egyre inkább alapértelmezésben blokkolják ezeket. A böngésző hálózati nézetében (2.5) a harmadik fél tartalma külön kérésként jelenik meg. Egy kényelmes beágyazás tehát adatáramlási döntés is.
Az összesített, rövid ideig megőrzött látogatási statisztika és az egyének közötti, hosszan épített viselkedési profil között nagy a különbség. A termékfejlesztéshez hasznos megtudni, hogy egy űrlap melyik lépésénél akadnak el sokan; ehhez nem feltétlenül kell névhez kötni minden kattintást, vagy ugyanazt az embert más webhelyeken is felismerni. A célhoz illő mérés gyakran kevesebb adatból is lehetséges.
Hozzájárulás: valódi választás, nem dekoráció
Sok oldalon felbukkan a cookie-sáv. Jó esetben ez rövid és érthető döntési pont: mi szükséges a működéshez, mi opcionális, milyen célokra menne adat, és hogyan lehet később módosítani a választást. A visszautasítást sem szabad indokolatlanul elrejteni vagy nehezíteni. A „mindent elfogadok” nagy, színes gombja mellett apró, több lépéses elutasítás rossz felhasználói élmény és etikailag is problémás tervezési minta.
A hozzájárulást érdemes célok szerint bontani (szükséges, beállítások, mérés, személyre szabott hirdetés). A „szükséges” kategória nem varázsszó: csak az a technika tartozhat ide, amely nélkül a kifejezetten igényelt szolgáltatás nem működik ésszerűen. A választást később ugyanúgy elérhetővé kell tenni, mint az elfogadást. Egy érthető adatkezelési tájékoztató nem a banner helyett van, hanem annak részletes háttere. A hozzájáruló felület legyen billentyűzettel kezelhető is (9.2).
GDPR mint szemléleti keret
Az európai adatvédelmi szabályozás, a GDPR (az (EU) 2016/679 rendelet) az érintettek jogait és az adatkezelők felelősségét hangsúlyozza. A rendelet 5. cikke a személyes adatok kezelésének hét alapelvét sorolja fel:
Az érintettnek a III. fejezet szerint jogai vannak, többek között a hozzáféréshez, helyesbítéshez, törléshez, korlátozáshoz, hordozhatósághoz és tiltakozáshoz. A fenti elveket a rendelet szövege nevezi meg; az alkalmazásuk konkrét esetben az adatkezelés céljától és körülményeitől függ. Ezért nem helyes egy tárgy keretében kész jogi ítéletet mondani arról, hogy egy valós oldal „GDPR-kompatibilis-e”. A fejlesztő felelőssége inkább az, hogy időben felismerje az adatáramlást, kérdezzen, és ne késői utómunkaként kezelje a védelmet: tényleg kell-e a telefonszám? Miért őrizzük az eseménynaplót? Ki fér hozzá? Hogyan tájékoztatjuk az embert?
Digitális etika: amit a szabály még nem rendez el
Lehet valami technikailag megengedettnek gondolt, mégis tisztességtelen. A megtévesztő tervezési minták (deceptive design patterns, korábbi nevükön „dark patterns”) erre jó példák: előre bepipált opciók, félrevezető megfogalmazás, szégyenérzetet keltő elutasító gomb, vagy olyan folyamat, amely ráveszi a felhasználót több adat átadására. Az Európai Adatvédelmi Testület (EDPB) a témáról külön irányelvet adott ki (Guidelines 03/2022, a közösségi média felületekre szólva), amely felismerésükhöz és elkerülésükhöz ad segítséget. Hasonló kérdés az algoritmikus személyre szabás: ha egy rendszer ismeri a sérülékeny pillanatokat, és ezeket kihasználva próbál több időt vagy pénzt kicsikarni, a „növeli a konverziót” nem elégséges indok.
Az etikus rendszer tervezője nem csak azt kérdezi, meg tudjuk-e szerezni az adatot. Azt is, hogy a felhasználó érti-e a következményt, arányos-e az előny a beavatkozással, és ki viseli a kockázatot hiba vagy visszaélés esetén. Az adatminimalizálás gyakran egyben biztonsági előny.
Végigvezetett példa: hírlevél és látogatási mérés a Kurzuspontban
Egy rendezvényoldal hírlevélhez e-mail-címet kér, az eseményoldalon látogatottságot mér, és beágyazott videót jelenít meg. Első lépésként fel kell térképezni az adatfolyamot: az e-mail a feliratkozás kezelőjéhez jut; a mérőkód eseményeket küld; a videó betöltése külső szolgáltatóhoz kapcsolódhat. Második lépés a célok elválasztása: a hírlevél kezelése, a szolgáltatás működtetése és az opcionális elemzés nem ugyanaz.
Az eredmény nem „nulla adat”, hanem megfontolt adatkezelés.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Tanulási források