GDPR felkészülés KKV szektorban

Közösségi kerekasztal

Sziasztok!

Véleményt szeretnék kérni tőletek, illetve tapasztalatot, hogy KKV esetén mely dolgokra koncentráljunk a májustól kötelező új szabályrendszernek való megfelelés érdekében? Van néhány anyagunk, az eddigi Infotv. szerint igyekeztünk ezeket csiszolgatni. Nincs webshop, főleg cégeknek végzünk szolgáltatást szerződés alapján, illetve részükre értékesítünk, hírleveleket nem küldünk senkinek. Melyik jogszabályt érdemes a pl. adatvédelmi nyilatkozatban hivatkozni? A magyar infotv.-t vagy az életbe lépő EU-s szabályrendszert? Van-e szerintetek lényeges szigorítás az eddigi szabályokon vagy csak egy felkapott téma lett?

Előre is köszönöm a véleményeket!

  • 13350 megtekintés

( istii | 2018. 02. 26., h – 21:25 )

A szabályok alig változtak, a kiszabható bírság változott nem kicsit. Azért lett felkapott téma, mert a bírság felső határa a korábbi több millió forintos összegről több millió eurós összeg lett, de akár a cég éves bevételének a 4%-át is elérheti.

Azon országokban ahol ez már megy, a feljelentések + incidens bejelentések ugrásszerűen megnőttek amivel bírkózik a hatóság. Idehaza az információim szerint kb 150 embert képez ki a NAIH erre a feladatra, ami a vállalkozások számát tekintve nem is olyan sok, de elképzelhető hogy lesz kapacitásuk szisztematikus ellenőrzésekre...

Kolléga egy időben sportot űzött abból, hogy a megjelölt "szabályos lejelentkezés" procedúrák többszöri végigvitele után felhívta az érintett cégeket, hogy kilátásba helyezze a következő lépését.
Azóta megsokszorozódott a webcégek száma - kétlem, hogy a kompetencia és jogkövetési szándék lépést tartott volna ezzel.

Nem erről jut eszembe: érdekes jogi eset lesz, amikor azt kell eldönteni, hogy adott csillió forintos bírságot a Kubatov Bt, a Fidesz MPP vagy Magyarország Kormánya kénytelen fizetni, vagy nincs itt semmi látnivaló.
Popcorn required.

Még az előző munkahelyemen kb. másfél-két éve kaptunk levelet valamelyik állami szervtől (fogyasztóvédelem talán), hogy szisztematikus ellenőrzésen találtak kifogásokat az oldalon (apróbb hiányok az ASZF-ben, feltüntetendő dolgok, stb.), szóval ellenőrzések már eddig is voltak.

Akkor segítőkész, támogató jellegűek voltak. Arra jutottunk, hogy nem büntetni akartak, hanem konstruktívan felkészítő jelleggel írtak. Persze, ez nem jelent semmit.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( elod v | 2018. 04. 05., cs – 12:46 )

Nézzétek át hol tároltok személyhez köthető adatokat úgy papíron mint elektronikusan. Az adatok törlésére illetve a fizikai megsemmisítésre fókuszáljatok szerintem, ezeket dokumentálni is kell. Ha vannak mobil eszközeitek azok legyenek mind titkosítva. Pendrive-ok kivezetése illetve titkosítása ha mégis kell használni.

( zolti v | 2018. 04. 05., cs – 20:01 )

http://eur-lex.europa.eu/legal-content/HU/TXT/HTML/?uri=CELEX:32016R067…

Egyszer átnéztem és ennyit jegyeztem le belőle magamnak, mint lényeg:

32. cikk idézet:
"Az adatkezelés biztonsága
(1) Az adatkezelő és az adatfeldolgozó a tudomány és technológia állása és a megvalósítás költségei, továbbá az adatkezelés jellege, hatóköre, körülményei és céljai, valamint a természetes személyek jogaira és szabadságaira jelentett, változó valószínűségű és súlyosságú kockázat figyelembevételével megfelelő technikai és szervezési intézkedéseket hajt végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja, ideértve, többek között, adott esetben:
a) a személyes adatok álnevesítését és titkosítását;
b) a személyes adatok kezelésére használt rendszerek és szolgáltatások folyamatos bizalmas jellegének biztosítását, integritását, rendelkezésre állását és ellenálló képességét;
c) fizikai vagy műszaki incidens esetén az arra való képességet, hogy a személyes adatokhoz való hozzáférést és az adatok rendelkezésre állását kellő időben vissza lehet állítani;
d) az adatkezelés biztonságának garantálására hozott technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást.
(2) A biztonság megfelelő szintjének meghatározásakor kifejezetten figyelembe kell venni az adatkezelésből eredő olyan kockázatokat, amelyek különösen a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítéséből, elvesztéséből, megváltoztatásából, jogosulatlan nyilvánosságra hozatalából vagy az azokhoz való jogosulatlan hozzáférésből erednek.
(3) Az adatkezelő, illetve az adatfeldolgozó 40. cikk szerinti jóváhagyott magatartási kódexekhez vagy a 42. cikk szerinti jóváhagyott tanúsítási mechanizmushoz való csatlakozását felhasználhatja annak bizonyítása részeként, hogy az e cikk (1) bekezdésében meghatározott követelményeket teljesíti.
(4) Az adatkezelő és az adatfeldolgozó intézkedéseket hoz annak biztosítására, hogy az adatkezelő vagy az adatfeldolgozó irányítása alatt eljáró, a személyes adatokhoz hozzáféréssel rendelkező természetes személyek kizárólag az adatkezelő utasításának megfelelően kezelhessék az említett adatokat, kivéve, ha az ettől való eltérésre uniós vagy tagállami jog kötelezi őket. "

40. cikk idézet:
"A tagállamok, a felügyeleti hatóságok, a Testület és a Bizottság ösztönzik olyan magatartási kódexek kidolgozását, amelyek – a különböző adatkezelő ágazatok egyedi jellemzőinek, valamint a mikro-, kis- és középvállalkozások sajátos igényeinek figyelembevételével – segítik e rendelet helyes alkalmazását."

Összefoglalva: Az, hogy mi vonatkozik rád a 32.cikk-ből (minden vagy semmi) azt nem neked kellene eldönteni, de mivel nem tudok kidolgozott "magatartási kódexet" ezért mégiscsak mindenki magának dönti el. Aztán majd vagy fizet vagy nem.

( dii | 2018. 04. 05., cs – 20:59 )

Ha csak szolgáltatást végeztek, akkor nincs olyan sokminden, a végzés során véletlen adathozzáférés előfordulhat, erre legyen a szerződött fél felé szóló NDA.

Biztos, hogy van belső adatkezelésetek: foglalkoztatáshoz kapcsolódan, toborzás, e-mailek, ilyesmi. Egy KKV esetén előírt papírmunka ehhez nincs, de a szabályozás fontos része, hogy neked kell bizonyítani, hogy megtettétek a megfelelő "technológiai és szervezési intézkedéseket" az adatbiztonság érdekében. Erről lehet egy egyszerű adatleltárt készíteni (ami egy excel fájl kb), de persze több szép dokumentumot is lehet szülni. Erre best practice egyelőre nem sok van, most kezd alakulni. Végiggépelni nem gépelném :)

Nem tudom merrefelé vagytok, jövő héten tartok kifejezetten KKVéknak erről ingyenes előadást: http://gymskik.hu/hu/gyor-moson-sopron-megyei-kereskedelmi-es-iparkamar…

KATA-méretű vállalkozásban tolunk user interjúzást és usability tesztelést. Arckamerás videófelvételeink és toborzással kapcsolatos levelezéseink vannak.

Amúgy van adatvédelmi nyilatkozat, mindenkivel alá is iratjuk szépen évek óta. Ebben közöljük:
- az adatkezelés célját
- az adathoz hozzáférők körét
- az adatkezelés várható idejét
- a törlés végső határidejét

Ezután ezeket a felvételeket egyszerűen letöröljük a Google Drive-ról, vagy az adott szolgáltatásról (lookback.io, hellopingpong, stb)

Az adatbázisokat (a gyakorlatban: Google forms által generált google sheets) is töröljük a toborzási időszak lezárultával, más kutatásokhoz nem használjuk.

Aszondod, mint KKV minket nem érint a GDPR?:)

(Még nem volt időm és főleg pénzem elmenni ügyvédhez...)

Még csak véletlenül sem mondok olyat, hogy KKVét nem érint :) érinti őket, de van egy csomó cipőbolt jellegű KKV akinek a megfelelés tulajdonképpen triviális.

Toborzással kapcsolatos levelezés OK, a CVéket nem lehet örökre megtartani. Toborzási kör befejezte után 6 hónappal CV törlés. (6 hónap, mert annyi ideig lehet diszkrimináció miatt panaszt emelni.) Ha szeretnéd a CVét tovább megtartani (pl jövőbeli megkeresés miatt), akkor ahhoz beleegyezést kérsz.

Arckamerás felvételhez egy rendes hozzájáruló nyilatkozat teljesen korrekt. Kapcsolódó adatkezelési gyakorlatról (ki, mikor törli le) nem rossz ha van egy process leírás. A harmadik fél bevonása (Google, stb) kapcsán arra figyeljetek, hogy a tárolás is adatfeldolgozás, ergo valamilyen papír kell arról, hogy ők megbízott adatfeldolgozók és garantálják a megfelelő színvonalú (GDPR kompatibilis) adatkezelést. Google esetén most van erre Data Processing Amendment, amit online alá lehet írni és rendben vagytok, a többi céget amit említettél nem ismerem.

Ezen kívül még van némi foglalkoztatáshoz kapcsolódó adatkezelésetek gondolom, esetleg külsős bérszámfejtés, ilyesmi...

Ügyvédekkel óvatosan, a nagy része egyáltalán nem érti a GDPR gyakorlati oldalát, IThoz csak távolról szagolnak és tisztelet a kivételnek, de olyan zöldségeket képesek terjeszteni, hogy a hajam égnek áll :)

Nálunk a raktárban biztonsági kamerarendszer van, de a raktárba csak a saját alkalmazottak és az ügyfeleink léphetnek be. Azt mondja az egyik ügyvéd, hogy kameránként meg kell írásban határozni, hogy mit rögzít, mennyi ideig és mindenkivel, aki a kamera látókörébe kerülhet, egyenként alá kell iratni, hogy hozzájárul a felvételhez. Továbbá a kamerarendszer létét be kell jelenteni az adatvédelmi hatóságnak. A másik ügyvéd szerint ez marhaság, elég táblán kifüggeszteni, hogy itt kamerafelvétel készül és csak akkor kellene bejelenteni, ha a saját kollégáinkon és az ügyfeleinken kívül (akik pl. áruért jönnek) bárki arrajárót rögzítene a kamerarendszer (mondjuk ott aztán még érdekesebb lenne, ahogy egyenként megállítjuk az arrajárókat hogy smile, you are on candid camera, pls sign here). Nálunk a raktárig csak az jut el, akit odaengedünk.

Az ügyvédek szerepe azt hiszem ennek az egésznek a létrehozásában és fenntartásában sem elhanyagolható.

https://www.hwsw.hu/hirek/58469/gdpr-eu-adatvedelem-hr-allashirdetes-me…

Ezt nemrég olvastam:

Továbbá a kamerákat is lehet használni az irodában, de elsődlegesen csak a személy- és vagyonvédelmi, valamint a magánnyomozói tevékenység szabályairól szóló 2005. évi CXXXIII. törvényben (Szvtv.) meghatározott célokból. Ha a munkáltató ettől eltérő célból tervez kamerás megfigyelést alkalmazni, a GDPR-ban meghatározott „jogos érdek” jogalapjára kell hivatkoznia, és ezt a jogos érdeket igazolnia kell. A Szvtv. szabályozza a tárolás lehetséges időtartamát is. Fontos újdonság azonban, hogy nem elegendő a kamerás megfigyelésről szóló általános tájékoztatás, hanem minden kamera vonatkozásában egyesével kell tájékoztatni az érintetteket az adott kamera látószögéről, céljáról és szükségességéről.

A szabályozás eddig is feltételekhez kötötte a kamerás biztonsági megfigyelést, ebben sztem nincsen változás. A változás egy kalapnyi teljesen értelmetlen adminisztrációban van, ami tipikusan a brüsszeli jogászok merénylete az ép ész ellen. Nomeg a változás a bejelentési kötelezettségben van, ami az alapján dől el, hogy a saját alkalmazottakon és az ügyfeleken kívül is kerülhet-e bárki a kamera látókörébe. Ha kerülhet, be kell jelenteni, ha nem kerülhet, nem kell bejelenteni.

Ennek a jogszabálynak semmi köze a jogrendszerhez. Igény persze lenne arra, hogy a rendszer is annyira túlszabályozott és ferde legyen, mint amennyire ez a jogszabály. Adminisztrációval, értelmetlen bürokráciával terhelik a nyulakat, miközben az elefántok azt csinálnak a háttérben, amit csak akarnak. Nevetséges lenne az egész, ha nem lenne ennyire siralmas.

Maguk az ügyvédek is bizonytalanok.

"Még mindig nem tudunk pontos információkat a május 26-án hatályba lépő, Magyarországon is közvetlenül hatályos európai Általános Adatvédelmi Rendelet (GDPR) ügyvédeket érintő kötelező előírásainak hatályáról. A legnagyobb problémánk, hogy a Magyar Országgyűlés még nem alkotta meg sem a rendelethez igazodó Infotörvény novellát, sem azt az egyes ágazati szabályokat módosító saláta törvényt, amely az ügyvédi tevékenységről szóló, idén hatályba lépett ágazati törvényre is vonatkozna. Nem jelölte ki továbbá azt a hatóságot sem, amely ezekben a ügyekben eljárhat. Annak várományosa, a NAIH is tehát nagyon óvatosan nyilatkozik és hangsúlyozza hogy szakmai véleményükre egyelőre ne támaszkodjunk.

A Magyar Ügyvédi Kamara elnöke már több ízben kapcsolatba lépett a jelenlegi adatügyi hatósággal és a fejleményeket követi. A szabályozási jogkörökkel nem rendelkező Budapesti Ügyvédi Kamarában pedig egy szakértői csoport alakul, amely a fővárosi ügyvédek szakmai álláspontját fogja megfogalmazni a leglényegesebb kérdésekben. Április végén és májusban – később meghirdetett időpontokban - pedig a kamarában nyilvános konzultációkat, fórumokat fogunk tartani.

Egyenlőre nincs több információnk, amint valami fontos és használható információ birtokába jutunk, azt tagjainkkal médiumaink útján közölni fogjuk."

Szóval emiatt a marhaság miatt még további rendeleteket és törvényeket kell hozni, hogy egyáltalán értelmezhető legyen. Nő a bürokrácia minden szinten és gyarapodik a semmittevő siserahad. De a legnagyobb bírság mértékét már kiszámolták. Röhej az egész.

Ha ebben a formában létre se jött volna, most nem kellene foglalkozni vele. Ha meglesz a hazai hozzáilleszkedés, lesz egy kisebb regény belőle, úgy egy tucat különböző joghelyen.

A fingra gombot varrni külön mesterség, jogászaink semmivel sem gyengébbek ebben, mint a brüsszeliek.

Az én seggemet mitől védi?
Ugyanúgy jönnek majd a 2000000email címlista 2forintért levelek, mint eddig, és azok akik ezt kiküldik, illetve igénybe veszik, azok ugyanúgy messziről tojni fognak GDPR-ra, ahogyan eddig az Info tv-re.
De legalább a vállalkozásokat szénné lehet büntetni, remek.

Azért várjál, a 2000000email címlista a kisebb baj, nekem a privát levelezésemre hetente max 1-2 db spam érkezik, az kevésbé érdekel.

Viszont kapásból tudok 4-5 céget akinek alig várom, hogy harapófogót akaszthassak a tökeire a sorozatos, levakarhatatlan baromságaik miatt. Májusban úgy fogok sátrazni az Illetékes Hivatal székhelye előtt, mintha megjelent volna az iPhone XI.

Az első ügyvédnek abban van igaza, hogy kamera szabályzatot illik írni, ami dokumentálja, hogy miért van az a kamera, mit figyel meg, hol tárolják a felvételt, ki fér hozzá és mennyi idő múlva semmisítik azt meg. A törlés a vagyonvédelem esetén ez az itthoni törvények szerint 3 munkanap. Ettől el lehet térni alaposan megindokolt "jogos érdek" alapján, azaz a cég valamilyen alapos üzleti érdekére hivatkozik, ami erősebb a természetes személyek jogainál. Vékony jég, de esetenként működhet, pl ATM esetén jóval késöbb derülhet ki egy visszaélés, ezért tovább kell tárolni az adatokat.

Abban viszont a második ügyvéddel értek egyet, hogy a személyenkénti hozzájárulás nettó marhaság :) Majd nézzük csak meg, hogy mielött(!) belép valaki egy bankba majd mindenkivel kitöltetnek-e egy ilyen hozzájárulást :) Nyilván nem életszerű és a rendelet is inkább arról szól, hogy tisztességes módon történik az adatkezelés. Ez kamerás rendszerek esetén a bejártnál kívülről (belépés elött) látható tájékoztatással a legegyszerűbb megoldani, miszerint odabent felvétel készül.

Az ügyvédek szerepét a történetben nem vitatom, van egy alapos hisztériakeltés :)

Lesz több kanyar a történetben :)

Az arcfelismerés bonyolítja a helyzetet, mert van biometrikus adatfeldolgozás mögötte. A személyek biometrikus adatai a 9. cikkelyben említett különleges adat körébe tartoznak, amit alapvetően hozzájárulással lehet kezelni, így a belépőknek ilyet alá kellene írni. Sajnos az ajtóra kihelyezett kamera figyelmeztetés ez esetben nem elég.

Ámde :) foglalkoztatás körében nem lehet hozzájárulást kérni semmihez, mert "egyenlőtlen erőviszonyok" állnak fent a munkáltató és a munkavállaló között. (Azaz úgy érezheted, hogy ha meg akarod tartani a munkádat akkor hozzájárulást adsz mindenhez.) A feloldása az ellentmondásnak, hogy a munkaszerződésben vagy annak kiegészítésében kell ezt rögzíteni, hogy a cég ilyen rendszert üzemeltet a szerverterem védelmére. (Külsősökkel marad a hozzájárulás aláiratása.)

Valami ilyesmi :) attól tartok ennek egyszerűbb megoldása nincs, ha a rendelet szerint akartok eljárni. HA :)

A 3 nap komolytalan. Nálunk ami átmegy a kamera területe alatt, 4-5 nap, amíg odaér a rendeltetési helyére (Portugáliába). Azért van a felvétel, hogy látszodjon, milyen állapotban, hogyan indult el a raklap, ki és hogyan rögzítette a kamionban. Az első reklamáció 6-7 nap múlva érkezhet akkor, ha sérülten érkezik. De jog szerint egy éven belül bármikor reklamálhatnak. Egy évig csak azért nem tudom megtartani a felvételt, mert nincs akkora tárhely.

A "jogvédő" aki a 3 napot kitalálta, jogász lehetett. Nem akarom megsérteni.

Nem kell nagyon ráparázni, jogos érdek keretében lehet hosszabb a tárolási idő, az említett kamionos sztori az tipikusan ilyen. A kamera szabályzatban meg kell róla emlékezni, hogy ilyen olyan okból mi úgy döntöttünk, hogy X napig fogjuk tárolni a kamera felvételt és jók vagytok.

A három napos szabály inkább az ilyen barkács bolt jellegű dolgokra van kigondolva, ahol rengeteg ember megfordul, nyilván van valamennyi vagyonvédelmi jelentősége a dolognak, de azért elég indokolatlan lenne az idők végezetéig tárolgatni a felvételeket.

Ez alapján a jogszabály alapján egy közepes ügyvéd félkézzel bármikor bebizonyítja, hogy a kamerafelvétel, amit 3 nap után nem töröltek, az jogellenes. Egy jó ügyvéd szép kis pénzt kipörölhet az alkalmazottnak sérelmi díjként az ilyenért.

Nem para, csak megint túl van szabályozva valami, ami semmiféle törvényi szabályozást nem igényelne (a kamerafelvétel törlését simán lehetne az általános elévülés szabályai szerint rendelni). Teli vagyunk unatkozó jogászokkal, ha a töküket vakargatnák naphosszat, előrébb lennénk.

Ez a 3 nap nevetséges. Hozzánk közeli gyilkosság(!) után 6 nappal jöttek most kikérni felvételt. Az is érdekes volt mikor a rendőrök meglepődtek mikor rákérdeztem, hogy a gyilkosság miatt jöttek-e. Mert hogy se a hírekben nem szerepel, se a helyi kapitányságon nem tudnak róla (ugyanis ilyen esetekben direkt a Teve utcából jönnek). Persze környéken már mindenki tudta, hogy egy szerencsétlen egyedül élő idős bácsi fejét otthon szétverték. Gondolom a valószínű elkövetők miatt olyan nagy a hírzárlat. Kérdezték hogy vasazó cigányok járnak-e erre. Persze hogy járnak, minden héten és szép lassan mennek és felmérik a házakat, hol és mikor ki van otthon. Többen is beszóltak már, hogy igazoltassák őket, de persze rendőr mindig csak a dolgozó állampolgáron talál fogást, ezeket nem állítják meg. Az autó amivel mennek rohad, konkrétan forgalmit helyszínen be lehetne vonni. Elsősegélycsomag? háromszög? szerinted? Milyen üzemanyaggal mennek, hogy megéri? Nem-e feledékeny a vezető/utas? Például elfelejtett bevonulni a börtönbe (bármennyire is vicces, ez ma nagyon gyakori jelenség).

Nagyon szépen köszönöm :)

CV-t nem tartunk, ez egy kérdőív, mittom, használtál-e már email marketing szoftvert, a cégnél beosztásod vezető-marketinges-egyéb stb, az a lényeg, szűri a jutalomra hajtó delikvenseket aszerint hogy célközönsége-e a szoftvernek amit tesztelünk épp. Viszont nyilván kell az emailcíme is, hogy felvehessük vele a kapcsolatot ha megfelelt a kritériumoknak, innentől kezdve beazonosítható....

A többi szoftvernek is muszáj GDPR kompatibilisnek lenni, ezek szakszoftverek, nem hiszem h kidobnák az EU piacot kompletten emiatt.

Azt nem tudom, a Google-nél a törlés dokumentációját hogy oldjuk meg. Az egyes alanyok könyvtárait monogram jelzi, egy hónap után már én se szoktam tudni ebből ki kicsoda :) de ha belenéznék a videóba nyilván beugrana.

Szóval alapvetően - mivel történt már visszaélés beazonosíthatósággal - komolyan van véve nálunk az anonimizáció, de a zabhegyezés fogalmam nincs milyen szinten kell hogy legyen.

Ah, akkor a toborzást én értettem félre :) Az ilyen jellegű adatgyűjtéshez egyszerűen hozzájárulást kell kérni, ha van a korábban említett adatvédelmi tájékoztatásnál ilyen, akkor nincs más tennivaló, ha nincs, akkor ezzel érdemes kiegészíteni.

Az egyéb szoftverek kapcsán, ha azok nálatok futó szoftverek, nem kell külön GDPR megfelelés, nektek kell adatvédelmi szempontból okos módon használni őket. Azthittem, hogy azok is felhő szolgáltatások, abban az esetben több a bonyodalom.

A törlést akkor érdemes lehet fejleszteni, hogy egyértelmű legyen mi a régi adat.

Zabhegyezni szerintem mérsékelten érdemes, ideális esetben egy "szakértővel" egy óra alatt átnéznétek a gyakorlatot, leírnátok mit kell finomítani és kész. Sajnos jelenleg úgy néz ki a GDPR piac, hogy kevés az igazán hozzáértő, azok meg elsősorban a nagy cégek drága megfelelésén szertenek dolgozni és ilyen KKV jellegű ránézésekben nem partnerek (vagy nem tudják mit kezdjenek vele, mert ők csak a nagyágyú módszereket ismerik).

Van az alján egy adatkezelési szövegblokk, nem nagy, de van:

http://bit.do/jelentkezes_kutatasra

E-mail cím mezőnél ott van. Persze infotörvény meg NAIH szám nincs, pedig tudom h kéne, de most ez gyorsan kellett.

Ez az adatkezelésink: https://drive.google.com/open?id=0B9rEsG3a7264bzZhVXkwa2Z4c0U

Én azt gondolom, reálisan senkinek nem lehet kifogása az ellen, hogy kontaktáljak vele egy személyes interjú időpontegyeztetése miatt, ha egyszer pont erre jelentkezik, és nyilván minden más megoldás csak bonyolítja.

Van valaki aki ezeket le tudja tisztázni es ajánlod?

NAIH szám május 25-től nem kell, úgyhogy azt megússzátok :)
Ezek a kis kiegészítések szerintem tök elégségesek, nem kell jogi szöveg, egyszerű érthető leírása annak, hogy mi történik az adattal. A tetején nekem kicsit fura a megfogalmazás, nem egyértelmű, hogy a kutatás kapcsán az iTeam Holding Zrt a kivitelező, azaz nekik adom oda az adataimat vagy csak az ő kutatásuk, de más cég jár el. Ezt talán lehetne javítani.

Az adatkezelési doksi nincs nyilvánosra téve, ha megteszed arra is rápillantok. Hogy ki az aki le tudja tisztázni, ajánlom magamat, de nem biztos hogy erre szükségetek van :)

Jó meglátás, ha nem is az e-mail cím mellé, de a lap aljára kellene egy checkbox, hogy "hozzájárulok, hogy az adatkezelő az elérhetőségeimet a megkeresés céljából és idejére eltárolja" vagy valami ilyesmi.

A kérdőívre újra ránézve, még annyi probléma van, hogy az adatkezelő nincs azonosítva. A cég elérhetőségét illene feltüntetni. Opcionálisan egy teljesebb adatkezelési tájékoztatót lehet linkelni, ahol nem csak az adatkezelési gyarkolat van leírva, hanem hogy hogyan élhetnek az adat alanyok a jogaikkal, stb.

( csardij v | 2018. 04. 06., p – 10:19 )

Arra van valakinek ötlete, hogy hogy lehet user blacklistet fentartani a jövőben? Gondolom simán az email cím nem lesz jó, mert azt törölni kell. Abból képzett hash se jó ha minden igaz, mert egyértelműen azonosít embert (ja, az lenne a cél). Szóval ötletek?

Érdekes kérdés, töprengetem rajta egy cseppet :)

Jelenlegi álláspont szerint az email cím lehet személyes adat, ha azonosít valakit (pl. kovacs.szombra.geza@microsoft-budapest.hu, elég konkrét), de lehet nem személyes is, ha csak valami fantázia név. Ez nem sokat segít, hasonló az IP logoláshoz, a dinamikus IP mögött nem tudod ki van, de egy megvásárolt fix IP mögött már tudhatod, mégis szükség van arra hogy mindenféle hozzájárulás nélkül tárold a szerven a dolgot. A CJEU állásfoglalása szerint az IP nem személyes adat például (ignorálták a fix IP kérdést). No ez nem sokat segít, csak leírtam érdekességként :)

Gyakorlatibb vizeken a lényegesebb dolog az, hogy a GDPR elismeri a vállalkozás "jogos érdekét", mint jogalapot. Ilyen jogos érdek lehet kiberbűnözés elleni védekezés, így a szerver logok esetében vagy a te esetedben a csalással összefüggő azonosítók tárolása nem jelenthet problémát. Más contextusban (pl telekommunikáció esetén) kifejzetten előkerül a WP29-es útmutatókban a csalás elleni védekezés kapcsán elismert adatkezelés. Annyi kérése van a rendeletnek, hogy a transzparencia legyen meg, azaz az oldalad privacy notification oldalán jelezd a kedves látogatóknak, hogy az e-mail címek tárolásra kerülhetnek, ám _kizárólag_ a visszélések megelőzése érdekében használod azt (és nem spammeled őket). Ha pedig valaki explicit kéri az eltávolítását az adatbázisodból, akkor azt pedig tedd meg...

Garantálni nem kell, elég ha nagyon valószínűsíthető. Megtörtént eset, hogy a jóember a céges fix IPről meglátogatta a szuper-prémium-mindenre-megoldás-szoftver honlapot, majd másnap kapott egy hívást a cégtől, hogy tudnak-e neki segíteni a döntésben, kell-e extra infó, stb. Ez több adatvédelmi szakértő szerint is erősen problémás, de egyelőre amig marad az CJEU iránymutatás, addig az IP cím nem privát. (Ez alól kivétel, ha tudod azonosítani, pl ISP vagy, esetleg olyan állami szervezet aki ehhez hozzáfér, stb.)

"Abból képzett hash se jó ha minden igaz, mert egyértelműen azonosít embert"

Erre tudsz adni valami forrást? Mert mi pont így oldjuk meg a törölt userek nyilvántartását. (User jelzi, hogy törölni akarja magát, megtesszük az éles rendszerből, de a backupokból nem, csak ha vissza kell állítani a backupot. Ehhez viszont valahogy logolni kell, hogy ki a törölt user.)

Ha a fenti állításod igaz, akkor feloldhatatlan ellentmondások keletkeznek a rendszerünkben, és félek, fel fogunk szívódni egy hirtelen keletkezett szingularitásban.

--
Csaba

Ez már eddig is így volt az infotörvény alapján. Mindegy, hogy ID, hash, vagy akármi, amíg egyértelműen beazonosítható az ember, az személyes adat (és a hash egyértelműen azonosítja, mert gyakorlatilag egyedi).

Úgy tudom, ha kérte a törlést (és más törvény miatt nincs ennek akadálya, pl. számla megőrzés), eddig is törölni kellett a backupból, mert nincs külön kezelve a biztonsági mentés a jog által.

Olvastam állásfoglalást, ahol kijelentették, hogy a személyes adatból képzett akármi is, amíg egyedien azonosítja az alanyt, ugyanúgy személyes adat. Szerintem a hash-ra is illik ez, mert az oké, hogy az eredeti adat nem visszafejthető belőle, de egyedileg azonosítja az embert.

Pont azért kérdeztem rá, mert mi implementáció előtt lezongoráztuk ezt a céges ügyvéddel, aki azt mondta, hogy a hash nem személyes adat, mert nem állítható belőle vissza az eredeti. Most nagyon ki vagyunk akkor segítve...

Tudsz forrást adni az általad hivatkozott állásfoglalásra? Csak mert ha igazad van, akkor az egész megoldásunk borul.

--
Csaba

Állásfoglalásról én nem tudok, de a working party (a GDPR mögötti tanácsadó testület) wp136-os véleményében a "one-way cryptography"-t is pseudonym adathoz sorolja sajnos. A technológia megoldások értelmezése nem mindig erőssége a GDPR-nak. A hashelés önmagában lehet jó és rossz is. Volt olyan cég, ahol telefonszámokat akartak behashelni, nyilván egy számhoz ugyanaz a hash jön fel az egész adatbázisban, amit összerakva egyéb információkkal már nem biztosított a "nem azonosíthatóságot", tehát rossz megoldás volt. A ti megoldásotok szerintem a jók közé tartozik és nincs a rendelet szerinti fekete/fehér definició.

Egyébként a log, ami alapján újra törölnétek az adatokat recovery után, hash-elés nélkül is elfogadható (mégha átmenetileg olyan személyes adatot tárol amit elvileg törölni kellett volna). Mint ahogy a backup-ban is ott van visszanyerhetően az adat átmenetileg. Ez hozzátartozik a technológiai limitációkhoz. A fontos az, hogy a törlésre jelölt adatok ne kerüljenek további feldolgozás alá, semmilyen körülmények között.

van naponta gzippelt sql dump. abbol hogy torlod utolag? mindegyiket visszatoltod egy testz rendszreen, lefuttatod az sql parancsokat ami kipucolja az osszes tablabola vele kapcsolatos adatokat, aztan ujra lemented? vagy megy az egesz backupod a devnullba? esetleg irsz sed/awk/stb scripteket ami bele kokanyol az sql dumpba?
(a dolog meg izgibb mssql eseten)

Ilyen jellegű backupból nem törlünk, a rendelet "elvárható mértékű erőfeszítést" ír elő. Arról viszont tarthatsz egy log fájlt / jegyzetet, hogy ki kérte, hogy töröljék az adatait és ha a backupból visszaállításra kerül a sor, akkor egyszerűen újra törlöd az élesben (még mielött az adatokat újra elkezdet processzálni). Elöbb utóbb kipörög :)

"Úgy tudom, ha kérte a törlést (és más törvény miatt nincs ennek akadálya, pl. számla megőrzés), eddig is törölni kellett a backupból, mert nincs külön kezelve a biztonsági mentés a jog által."

Itt érzek némi ellentmondást, kimondja a GDPR, hogy ilyen esetben töröljük az adatait a rendszerből, ez pipa, de kimondja egy másik törvény, hogy a mentéseket 10 évig meg kell őriznünk (pénzügyi terület), ez gyakorlatilag megoldhatatlan! (több 100 TB adatról lehet szó, több különböző rendszerből)

A törvények bizonyos esetekre előírnak kötelezően megtartott adatot, de ezeknek a köre elég kicsi, amúgy ez erősebb, mint a felejtéshez való jog.

1. Amíg mindenki boldog, van egy csomó adatod a felhasználóról, semmi gond.
2. A felhasználó kéri a törlést. Törölsz mindent, amit nem muszáj megtartani, amit meg muszáj megtartani, azt nem törlöd.
3. Ha a törvény által előírt idő letelik, törlöd a maradék adatot is.

Azt a GDPR és az eddigi adatvédelmi törvény is mondja, hogyha valamit más miatt meg kell tartanod, akkor azt addig az ideig kezelheted. Pl. a számlát meg kell őrizni 8 évig, azt nem tudod törölni. De mondjuk azt, hogy a preferált vásárlási módja a bankkártya, azt már törölnöd kell.

Ahogy fentebb írtam a working party (a GDPR mögötti tanácsadó testület) wp136-os véleményében (opinion on personal data) a "one-way cryptography"-t is pseudonym adathoz sorolja. A pseudonym adat pedig, mégha közvetlen nem is értelmezhető, személyes adatnak minősül.

Ennek ellenére lehet az emailt vagy a hasht bizonyos célokkal tárolni (pl az említett backup visszaállítós újra törlés az ilyen). Mint psudonymizáció növeli az adat biztonságát, ezt egy esetleges ellenőrzésnél figyelembe fogják venni, de a hashelés önmagában nem fogja kivonni az információt a rendelet hatálya alól.

Mutass mar egy birot vagy egy auditort aki bebizonyitja, hogy az egy hash, es hogy abbol tudom, hogy milyen emaile. Azert ennyire ne szarjuk mar ossze magunkat. Masik topikban lattam egy gyokeret, aki meg akarta oldani hogy egy query-bol csak egy email johessen ki es ezert dobta volna el az SQL-t. Ennyit mar tenyleg nem er az egesz, inkabb irj egy privacy policy-t, hogy ezeket te minosegbiztositasi okokbol rogzited, keresre anonimizalod (torlod, de a relaciokat meghagyod), de amugy nem adod ki senkinek es kesz.

A privacy policy-t miota kotelezo elfogadni? Le is lehet lepni az oldalrol, senki nem tart pisztolyt a fejedhez hogy add meg az email cimed.

Raadasul ez nem is GDPR specifikus argument (de anelkul is, meg annak is baromsag). Egyaltalan. Szemelyisegi jogok korabban is leteztek, megis lehoz a SELECT email FROM users ezt-azt valami csoda folytan. A kifejezes amit keresel: szemelyes adat.

Ha a tobbiek is ilyen sotetek a topikban akkor mar ertem mi ez a droidkodas itt.

A jogellenes feltételekkel kötött szerződés semmisnek tekintendő, a hatályos jog ellenében nem köthetsz ki saját feltételeket. A sotetseggel kapcsolatban először is egy kicsit a saját búrádban kellene turkalnod!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Egészen pontosan:

A "2010. évi CXXX. törvény a jogalkotásról" alapján a szolgáltató nem jogalkotó és nem jogforrás. Következményként az ÁSZF/EULA törvényt nem írhat felül.

Még ezer éve olvastam egy adatvédelmi valaki állásfoglalásáról (a témában) született izében, de csak ennyit mentettem el belőle...

Nem minden adathalmaz végtelen. Az adott hashelési eljárásodhoz én is le tudom generálni a hash-eket. Pl. ha magyar lakosok neveit tárolod hashben, fogom a lakossági névjegyzéket, legenerálom a 10M emberre és máris tudom, hogy melyik kihez tartozik... A hash pseudonym adat nagyon sok esetben.

Es ha sozom, es nem mondom meg neked hogy mi alapjan es hogy soztam? Oke, Hunger lehet talalna valakit aki arra is rajonne, de nem olyan fog jonni auditornak. Balfasz meg nem vagyok hogy valaki titoktartasi nelkul dumpolgathassa a db-imet. Es mindenki latta, hogy mindent elkovettem az adatbiztonsag erdekeben.

Lehet hogy a hatóság elfogja fogadni. Azt tudom mondani, hogy az állásfoglalás szerint, az egy irányú titkosítás, sózva is, pseudonym marad, mert ha megszerzik a sót, akkor újra előállítható. Ameddig nem anyonym, addig marad személyes adat.

Valószínű hogy eseti mérlegelés lesz. Volt olyan nagy cég, aki kért állásfoglalást arról, hogy a nagyon titokba tartott kulcs segítségel titkosított backup tekinthető-e úgy, hogy törölve van. És becsszóra csak 2 embernek lesz meg a kulcs. Hatósági válasz született róla, hogy ez nekik megfelel, míg betű szerint értelmezve a szabályt ez tökre nem okés. Arra mondjuk kíváncsi leszek, hogy a NAIHnak lesz-e elég házon belüli kvalifikációja technológiailag helytálló véleményt alkotni a gyakorlatban.

Egész pontosan meg kell szerezned:
1. a pontos algoritmust,
2. mely személyes adatokból (és más adatokból, pl. só), mily módon átalakítva kerül hash-elésre.

A legfőbb gond itt azzal van, hogy ahhoz, hogy tudd, hogy melyik hash kihez tartozik, ahhoz neked meg kell szerezned azon személynek a hash-elésben szereplő személyes adatait. Ha valaki meg tudja szerezni egy személy személyes adatait, akkor a hash-el nem lesz előrébb, hiszen már megvannak neki a személyes adatok.

Egy cikkben ezt írták:
"Személyes adatnak ugyanis az olyan információ számít, amely egy azonosítható élő személlyel kapcsolatos vagy éppen az információk összegyűjtése egy bizonyos személy azonosításához vezethet. Ebbe a körbe tartoznak a titkosított vagy álnevesített személyes adatok is, amelyek felhasználhatóak egy személy újraazonosítására. Egyedül az nem képezi a kör részét, amelyet úgy anonimizáltak, hogy az érintett már többé nem azonosítható az alapján, tehát "az anonimizálásnak visszafordíthatatlannak kell lennie" - írja a közlemény."

A hash az egy visszafordíthatatlan anonimizálás, nem?

--
Ickenham template engine

Tételezzük fel, hogy van egy adatbázisod, amiben vannak oszlopok, hogy "családnév" és "keresztnév", benne a hashek. Legenerálom a hash-eket általános nevekre, hogy "kovács", "horváth", "lászló", "géza". Elég egyszerű módszer arra, hogy azonosítsam az adatot. Ennél fogva anonimizálásként nem fogadja el a rendelet, azaz az adat nem vonódik ki a rendelet hatálya alól. (Ettől még persze tárolhatod megfelelő indokokkal.) A pseudonymizálási technológiák, mint biztonsági tényezőt növelő intézkedés elismert a GDPRban, de a lényeg, hogy a hashelt adat is jellemzően személyes adat marad.

Ezt lehet vitatni, ha be tudod bizonyítani, hogy semmilyen technológiai megoldással nem lehet visszaforgatni, személyhez rendelni, a hatóságnak illene ezt elfogadni. De biztos vagyok benne, hogy lesznek esetek, ahol nem lesz elfogadható, pl a példa amít említettem.

"A legfőbb gond itt azzal van, hogy ahhoz, hogy tudd, hogy melyik hash kihez tartozik, ahhoz neked meg kell szerezned azon személynek a hash-elésben szereplő személyes adatait. Ha valaki meg tudja szerezni egy személy személyes adatait, akkor a hash-el nem lesz előrébb, hiszen már megvannak neki a személyes adatok."

Két dolog (minimum) van.
- Az egyik, amit már kolléga írt, hogy simán lehet bruteolni, adott esetben akár rainbowolni egy ilyet. Igen, tudom, só és hasonlók, de látni kell, hogy az csak nehezít, nem lehetetlenné tesz. Az meg, hogy eléggé nehezít-e már nyilván eseti megítélés kérdése. Amiben nincs semmi csoda, a jogrendszer alapvetően így működik, csak itt a gyakorlatban majd nyilván bejön az, hogy jogászoknak kellene felfogni és átlátni olyan dolgokat, ami tipikusan az ITs kollégáknak sem megy zökkenőmentesen. Ebből azért várható némi bizonytalanság. Egyébként ez sem egyedülálló, gyakorlatilag minden műszaki szakértő bevonását igénylő kérdésben többé-kevésbé jelen van ez.

- A másik meg az, hogy a hashelésben simán lehet, hogy kevesebb adat szerepel, mint ami a hash visszafejtésével rendelkezésre áll. Nyilván ilyesmi tipikusan úgy történik, hogy mondjuk a törzsadat tábla sorából lesz hash, ami kb a név, email, stb mentén mozog, de ha ez megvan, akkor az összes kapcsolódó cucc az adatbázisodban hirtelen kiderül, kihez tartozik.

Illetve van még egy harmadik is az ilyen "backupból ezeket a hashűeket nem kell visszatölteni" dolgokkal, hogy aztán ha a user újra regisztrál, azt gondolja, hogy tiszta lappal, aztán vagy leveszed a hasht a listáról, és simán lehet, hogy egy esetleges restorenál visszajönnek törölt dolgai, vagy nem veszed le, és egy esetleges restorenál beszopja. Ez ellen mondjuk azért nem olyan nehéz védekezni, csak ésszel kell hashelni.

Hehe, ebből a kommentből most kicsit jobban belegondoltam a buliba, és az van, hogy ez egy kissé spec helyzet. Az általános patterneknél ugyanis a salt az bizony random egyedi, minden elemnél. Nézz csak megy egy /etc/shadow -t mondjuk "$6$bla$blablabla". Itt a 6 a hash algoritmus, az első bla a salt, a többi meg a hash.

Ugye az a dictionary attack meg a rainbow táblák ellen véd valamennyire (egyébként ugyanazért, a rainbow tábla tulajdonképp "csak" egy előre kalkulált dictrionary attack, ha az input halmaz is szar, meg hashelés is), azzal, hogy nem elég minden feltételezett inputot kiszámolni egyszer, és megnézni, hogy van-e passzoló hash valahol, hanem minden lehetséges inputot végig kell számolni az egyedi saltjával minden lehetséges hashra.

Viszont ez csak akkor működik, ha a normális use-caseben van valami, amiből be lehet azonosítani az egy darab vizsgálandó hasht. Ugye tipikusan ilyen a usernév, azt akarjuk megnézni, hogy neki az-e a jelszava ami, fogjuk amit beírt, hozzácsapjuk a saltot a hash elől, hashelünk, ha jó, nyert, ha nem, akkor még kétszer dobhat.

Ellenben így hirtelen nem tudom, hogy mondjuk egy db restore esetén lehet-e olyan adatot találni, ami önmagában nem személyhez köthető, és be tudja azonosítani azt a hasht, amelyiket le kell ellenőrizni, hogy be kell-e tölteni, nem lehetetlen, de azért messze nem olyan triviális.

Ha ilyen nincs, és fix saltot használsz, annak túl sok haszna nincs. Egyetlen, hogy ha a fix saltot ilyenkor nem teszed mellé, hanem azt kvázi mint egy titkos kulcsot kezeled, akkor funkcionalitásában ekvivalens azzal, hogy a saltolatlan hasheid egyébként titkosítva tartod. Hogy biztonsági szintjében is tudja-e ugyanazt, azon erősen el kellene gondolkodnom, addig inkább maradnék a reasonable doubt álláspontján.

Ráadásul ha van olyan info, ami alapján be lehet azonosítani a sort, ami alapján meg lehet nézni a hasht, akkor egyébként a hash elsőre fölöslegesnek tűnik, elég eltenni ezt az infót, és nem betölteni a sorokat, amire passzol. Pl hashelgetés helyett tartani egy listát a users tábla blacklistelt IDjairól.

( csontika v | 2018. 04. 07., szo – 00:12 )

Pont ilyen támogatsban felkészítésben várnám el a kamarűnak a segítségét.
Csinálnának a főb vállalkozástipusokhoz egy-egy sablont, azzal már azért sokan előrébb lennének.

Nálatok nem csinál? Nálunk volt, talán 2x is

"Tisztelt Cégvezető!

Ezúton tisztelettel meghívom Önt a Csongrád Megyei Kereskedelmi és Iparkamara és a Szegedi Tudományegyetem Munkaügyi Kapcsolatok és Társadalombiztosítási Képzések Intézete által szervezett „GDPR - az EU Általános Adatvédelmi Rendelete - minden vállalkozás életét érintő jogszabály” című regionális rendezvényre.

A GDPR minden céget érint, ahol személyes adatokat kezelnek (a munkavállalóké is az), online tevékenységet folytatnak, bármilyen céllal adatbázisokkal foglalkoznak. A papíron lévő adatok is ide tartoznak. Részletes program a mellékletben olvasható.
Időpont: 2018. március 12. (hétfő) 10.00-12.30
Helyszín: Csongrád Megyei Kereskedelmi és Iparkamara Székháza, II. emeleti konferenciaterem
(6721 Szeged, Párizsi krt. 8-12.)

A rendezvényen történő részvétel térítésmentes, azonban előzetes jelentkezéshez kötött. A jelentkezését kérjük, 2018. március 8-ig töltse ki: JELENTKEZÉS

Tisztelettel:

Bács-Kiskun Megyei Kereskedelmi és Iparkamara
Kommunikációs iroda"

Nem hinném, hogy probléma lenne egy bármekkora terem megtöltése Budapesten, szerintem igen gyorsan lehetne termet is szerezni hozzá. :)

Mi a véleményed a Git history-ról? Az én véleményem az, hogy itt a megőrzési kötelezettség (nekem bizonyítanom kell tudni, hogy az adott forráskód honnan van, és jogosan van ott) erősebb, mint a felejtés joga.

Ugyanezt a gondolatmenetet követném a Gerritnél (code review adatbázis, belül Git-et használ).

Amit még nem tudok, hogy pl. Jira, Redmine ... stb. esetén is megállhatnak a fentiek, vagy ott mindenképpen törölni kell a usereket ha kérik.

Igen, úgy tűnik érdeklődés van rá, de önerőből nem szívesen szervezek ilyet, ahhoz sürű a menetrend. Majd a héten még koptogatok a BKIK-nál.

A Git-es kérdés kapcsán. Az hogy meglegyen az információ arról, hogy az adott commit-ot ki csinálta, ahogy írtad, a cég jogos érdeke és ez megállja a helyét a JIRA, stb esetén is. Az accountot inaktiválod, de nem kell történelemhamisításba kezdeni :)

Keringenek olyan értelmezések, hogy ha valaki lelép a cégtől, akkor a nevét az összes e-mailből törölni kell, még ha csak CCén volt akkor is vagy hogy a szerződésekről hibajavítóval lehúzod :) Ezek hozzátartoznak a szépen épülő GDPR urban legends katalógushoz. A rendelet explicit azt mondja, hogy elvárható erőfeszítést teszel a törlés érdekében, az említett értelmezések bőven túl vannak ezen és egyébként is teljesen életszerűtlenek.

Erdekes volt az eloadas bar kulon tetszett az "attol fuggetlen, hogy mi itt mit mondunk az semmit sem jelent, a NAIH azt csinal amit akar" felhang.

Ertem en, hogy mi volt a szandek az egesz mogott, miert kell ez az egesz GDPR, de ebben az orszagban ez a penzbehajtasrol fog szolni szerintem...

--

"You can hide a semi truck in 300 lines of code"

Ah, voltak HUPperek \o/

Sajnos a NAIH gyakorlatáról még semmit nem tudunk. Külföldön, ahol már részlegesen megy a GDPR az látszik, hogy a hatóság elúszik az incidens bejelentésekben és külön vegzáló kommandók nincsenek egyelőre. Remélem nem mennek rá a szivatásra. Nekem a NAIH vezetőről egyébként jó benyomásaim vannak, de nyilván átnyúlhatnak felette ha pénzbehajtásra akarják használni. Annyi "jó" dolog azért van a történetben, hogy az adatvédelmi hatóságoknak nemzetközileg is össze kell hangolni, hogy miért és hogyan büntetnek. Ha valami nagyon gerinctelen dolog történik, akkor lehet az EU felé panaszkodni... elviekben. Gyakorlati tapasztalat erről egyelőre nincs.

Az előadást visszük tovább hamarosan Mosonmagyaróvárra, Sopronba. A BKIK egész egyszerűen nem írt vissza (összesen 5 e-mail címen próbálkoztam), úgyhogy Budapest egyelőre nincs tervben :(

Igen, en legalabb 4 HUPpert lattam az elso 2 sorban. \o/
Az eloadas maga tenyleg jo volt es latszott, hogy sok munka volt benne, hogy az atlag szamara is ertheto nyelven fogalmazza meg a dolgokat.

Aki mar foglalkozott ezzel annak valoszinuleg sok uj dolgot nem mond az eloadas, de segit rendszerbe foglalni a dolgokat.

--

"You can hide a semi truck in 300 lines of code"

( benyovszky v | 2018. 04. 08., v – 08:06 )

[Troll on]
Az adatkezeleshez kitoltott beleeggyezesi nyilatkozatokat meddig taroljam, es milyen beleeggyezo nyilatkozat kell a tarolasahoz?
Infinite loop
[Troll off]

Szerintem nem olyan veszélyes a dolog. Az e-mail archiválás növeli az adatok integritását, ebből a szempontból a GDPR barátja :)

Annyira kell figyelni, hogy ez is adatkezelésnek fog minősülni, ergo, te adatfeldolgozó leszel. Az adatfeldolgozó csak olyan adatokhoz nyúlhat hozzá (és olyan módon), amiket a megbízója (az adat kezelő) meghatároz. Azaz, kell hogy legyen egy szerződéses megbízás amiben azt mondja a megbízó cég, hogy: "Figyi én megbízlak az e-mailek archiválásával, aminek keretein belül hozzáférést adok egy csomó érzékeny adatot tartalmazó e-mailhez. Azt kérem, hogy ezek az e-maileket archiváld nekem, úgy hogy mindeközben illetéktelen arcok ne férjenek hozzá. Továbbá kérem, hogy az archiváló rendszer az adatok érzékenységének megfelelő technikai védelemmel legyen ellátva, és kérlek garantáld hogy a céged és szolgáltatásod GDPR előírásoknak megfelelő módon működik."

Ilyesmi :)

ok, koszi. Viszont nem csak szolgaltatoi oldalrol gondoltam a dolgot, hanem arrol, ha egy ceg sajat maga (vesz egy szoftvert, es azzal) vegez email archivalast. Milyen kovetelmenyeknek kell megfelelni maganak a szoftvernek, hogy az gdpr kompatibilis legyen? Vagy gyakorlatilag barmelyik (esszeruen osszerakott) szoftverrel megoldhato a kompatibilitas, mert az elsosorban a ceg folyamatain ill. lepapirozasan mulik?

Ezt te mint software vendor nem annyira tudod eldönteni. Adhatsz garanciákat arra, hogy a te szoftvered ilyen vagy olyan jó adatbiztonság szempontjából, pl auditáltatod vagy vulnerability scan-t csinálsz ilyesmi. Innentől fogva a szoftver használójának kell eldönteni, hogy a szoftvered az ő adatkezeléséhez elég jó-e vagy nem.

Ha mondjuk egy horgászbot bolt használja az archiválódat, akkor az adatok érzékenysége nem túl nagy, kb ki vett horgászbotot. Alapvető biztonság elég. Ha a szoftvered a nemzetbiztonsági hivatal használja ugyanarra a funkcióra, ott már súlyos adatok vannak, amihez már lehet hogy nem elég biztonságos az alkalmazás. De hogy ki mire használja nem tudhatod.

Példa: excelben le lehet jelszavazni a fájlt. Az MS-nek nem fáj a feje amiatt, hogy ez elég-e vagy nem, amikor te beírod az adatokat az táblázatba, neked kell eldönteni, hogy ez most okés-e így vagy sem.

Persze, csak aztán majd jön a mindenféle légből kapott X nap, midnenhonnan, irgumburgum, még a backup backupjából is jellegű, technológiailag nehezen kivitelezhető és egyébként is életszerűtlen jogi dolgok.

Egyébként ilyen szempontból amire még nagyon sokan nem godnolnak az például a logok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még másfél éve voltunk egy egy áttekintő napon GDPR témában. Ott az volt a mondás, hogy az "élő adatokból", kell törölni. Egy naplózás vagy mentés egyébként még egyéb jogszabályi megfelelőséghez is kellhet. Ami a trükkös, az a mentésből visszaállításkori törlése a közben törölteknek, viszont akkor valahogy tárolni kell, hogy kit töröltél... :)

Ami a trükkös, az a mentésből visszaállításkori törlése a közben törölteknek, viszont akkor valahogy tárolni kell, hogy kit töröltél...

Ahogy fentebb említettem, nálunk pont ez van. Úgy oldottuk meg, hogy a usereket egyedi, random IDvel azonosítjuk (amit nem a user saját adatából generálunk, hanem timestampből), a törölt usernek csak az ID-ját tároljuk, és backup visszaállítás esetén az ID alapján töröljük őket a visszaállított éles rendszerből. A mi jogászunk állásfoglalása szerint az ilyen módon generált ID anonim adat, ezért nem vonatkozik rá a GDPR (személyes adatokra vonatkozó része).

Egyébként a jelen thread alapján futottam újabb köröket a cégben, de úgy tűnik, ez jó megoldás.

--
Csaba

Ez teljesen jó, de a korábbi hozzászólásban, csak az adat hasheleését írtad, ezzel bevittél minket egy kicsit a málnásba :) Úgy értelmeztem, hogy valami személyes adatot hasheltek, és az alapján töröltök. De ha van egy ilyen random jellegű userID, aminek nincsen tartalmi kapcsolata személyes adattal, az sokkal jobb. Én is úgy gondolom, hogy ez bőven megfelel.

csak aztán majd jön a mindenféle légből kapott

ez megalapozatlan es folosleges panikkeltes. Masfelol a vilag civilizaltabb reszen vannak torvenyek, jogszabalyok, whatever, de legbol kapott dolgok nincsenek.

A logok az jo kerdes. Elso lepeskent ossze kell szedni, hogy egyreszt mit loggolunk, masreszt hogy azt hogyan kezeljuk (meedig taroljuk, ki fer hozza, stb)...

--
'Amikor az embernek rossz szerencséje van, az rossz szerencse' - Best of Leekens, a foci feltamasztoja (muhahaha)

( trey | 2018. 04. 11., sze – 15:19 )

Nálam ma éppen a kamerák és a felvételek rögzítés, azok kezelésének kérdése volt soron a GDPR felkészülés kapcsán.

--
trey @ gépház

( carlcolt | 2018. 04. 13., p – 12:19 )

Vajon mi lesz a GDPR-hez a first amendment? :P

( blr v | 2018. 04. 24., k – 12:55 )

No, egy fogós, ravasz kérdés:
Egy webshopaggregátor-szerűség a megrendelés végén ki kell hogy küldjön egy visszaigazoló e-mailt (az eladó nevében, de az aggregátor címével). A megrendelő személyes adatait a feldolgozó szerver titkosítva kapja meg, így a rendelés adatain (termékek típusa, darabszáma) kívül csak a megrendelő e-mail-címe van meg olvasható formában az adatbázisban az aggregátor által.
Személyes-adat-e ez esetben az e-mail-cím?
(Most tekintsünk el attól, hogy mit mond a hatályos magyar adatvédelmi törvény, csak a GDPR szempontjából érdekes.)

Hál' Istennek, ezt a döntést nem nekünk kell meghozni.

"Pseudonymisation reduces the linkability of a dataset with the original identity of a data subject; as such, it is a useful security measure but not a method of anonymisation. [...] Encryption with secret key: in this case, the holder of the key can trivially re-identify each data subject through decryption of the dataset because the personal data are still contained in the dataset, albeit in an encrypted form."

"Neither encryption nor key-coding per se lends itself to the goal of making a data subject unidentifiable: as, in the hands of the controller at least, the original data are still available or deducible."

Errefelé lehet többet olvasni róla: http://ec.europa.eu/justice/article-29/documentation/opinion-recommenda…

A felhőszolgáltatós mondat pedig hülyeség, a GDPR nem azt mondja, hogy egyáltalán nem lehet személyes adatokat kezelni, csak bizonyos keretek közé tereli a kezelésüket és feldolgozásukat.

Akkor te adatfeldolgozó vagy, és egész más szabályok érvényesek rád. Nagyon leegyszerűsítve: az ügyfél ha szeretne valamit, az adatkezelőnél kell kopogtatnia, ő majd megmondja neked, hogy mit honnan törölsz. Ettől még a titkosítás nem anonimizáció --> a titkosított személyes adat is személyes adat.

Probléma megoldva: az e-mail-küldést nagy nehezen rávertem egy konkrétan a webshop (adatkezelő) illetőségébe tartozó gépre, és a rendelés fennmaradó törzsadatai is titkosításra kerülnek a kliens oldalon, így nem maradt semmilyen plaintextben olvasható adat az aggregátornál. Ha bármilyen adatot törölni kell az adatbázisból, azt a webshop kezdeményezheti a saját szoftveréből.

És akkor a „titkosított személyes adat is személyes adat” esete:

Ügyfelem X webshop (vele áll a vevő kapcsolatban, ergo ő az adatkezelő), aki a megrendelést Y alvállalkozóval (nekem szintén ügyfelem) gyártatja le, aki így adatfeldolgozóvá válik. Amikor a megrendelés adatai felkerülnek az A aggregátorhoz (hozzám, legyek én A), akkor a gyártáshoz szükséges (személyes) adatok Y kulcsával vannak titkosítva, a rendelés adatai X-ével. X hiába kérné tőlem, hogy töröljem a megrendeléshez tartozó adatokat, minden titkosítva van, azokat csak Y tudja feloldani.
Ezek után ha a vevő bejelentkezik X-nél, hogy inkább törölné a rendelését, akkor X megnyom egy gombot, és A törli a megrendelés rekordját. A rendszer automatikusan törli az összes tétel adatsorát is, így azt is, amely Y-é.
Ez eddig rendben, de mi lesz a kapcsolt adatfájlokkal (minden fájl egyedi random AES256-titkosított, a kulcs a tételadatok közé van betéve), amelyek tele vannak titkosított személyes adatokkal? Mi történik, ha Y még el sem kezdte feldolgozni az adatokat, vagyis le sem töltötte? Így senki nem tudja megmondani, mely fájlokat kellene törölni, ezért a kapcsolt adatok elárvulnak, életciklusuk végén (30-60 nap) automatikusan törlésre kerülnek.

A konfliktus: A fenti eset problémáját meg tudom oldani, amennyiben tárolom a fájlok adatait, és ezzel a megrendeléshez kötöm. Viszont ezekre az adatokra nekem semmi szükségem nincs, így megsérteném az annyi adatot kezeljek, amennyire minimálisan szükség van elvet.

Én úgy gondolom, hogy az a titkosított személyes adat, amely semmilyen definiálható módon nem köthető személyhez, és tartalma sem ismerhető meg, az nem tekinthető személyes adatnak. Ennyi erővel kiadok egy dd if=/dev/random bs=1M count=1 parancsot, aztán ha elég sokáig próbálkozok, akkor találok egy olyan titkosítási algoritmust és hozzá egy kulcsot, amellyel „dekódolva” kapok egy JPEG-et, amelyen az asszony lesz rajta meztelenül. Na, az aztán személyes! :)

A titkosított adat is személyes, de nem akarlak ezzel hergelni, mert ez most nem lényeges :)

Ha jól értem, nálad a láncolatban X->A->Y esetén az "A" entitás nem fér hozzá az adatokhoz, mivel azok megfelelő módon titkosítva vannak X-nél és nincs racionális technológia megoldás, hogy kiszedd a tartalmát. Most ha agyonütnek sem tudom melyik WP doksiban olvastam, de van erről megemlékezés, hogy a továbbító rétegeknek az alapvető technikai normákat tartani kell, de egyéb felelősége nincs a történetben. Például ha online bankolsz, a gépedtől a bankig tartó SSL beszélgetést továbbító hálózati eszközök nem fognak tőled hozzájárulást követelni :)

Az esetleg aggályos lehet, ha technológiailag te valósítod meg az összes szereplő installációját, ez azért jelzi, hogy elég könnyen be tudod szerezni a kulcsot, ha akarod. De paranoiába nem hajtanálak, ez csak teoretikus gondolat. Ahogy az adatminimalizálással kapcsolatos aggályod is. A rendelet elvárja, hogy a technológia megoldásokat figyelembe véve a legkevesebb adatod legyen, de ha ennek vannak jól indokolható korlátai, nem hiszem hogy bárki kötekedne. A megoldásod már így is jóval több szerintem mint ami elvárható.

Végső soron természetesen én adok mindent az installhoz, még ha fizikailag nem is én végzem, de a kulcsokat minden ügyfél saját magának generálja le, akár óránként gyárthat újat is, az ő tulajdonában lévő gépről csak akkor kerül ki a privát fele, ha ő kiviszi. (Persze, igen, tudom, berakhatok a kliensszoftverbe olyan kódot, amely azt nekem továbbítja, de ugye az már Btk. kategória.)

Arra a kérdésre, hogy személyes adat-e az e-mail cím, a válasz az hogy igen. Már az e-mail cím maga potenciálisan tartalmazhat elég információt ahhoz, hogy azonosíts egy természetes személyt akihez tartozik. (eg. ritkanevű.richárd.1987@sárospatafelső.hu) Mivel emiatt elképzelhető hogy személyes, ezért általános szabályként személyes adatként kezelendő.

"Mivel emiatt elképzelhető hogy személyes, ezért általános szabályként személyes adatként kezelendő."
Na, nekem is valami ilyesmi rémlik. De hol van ez leírva? Úgy emlékeztem, az adatvédelmi törvényünkben benne volt, most nem találtam (egy hónap múlva meg mindegy, hogy benne van-e).

( veyron007 | 2018. 05. 04., p – 22:07 )

Elég sok mindenről volt már itt szó, bevallom őszintén nem olvastam minden végig. Olykor elterelődtek kicsit a szálak :)
Viszont egy rövid kérdésem lenne:

EV weboldala, ahol csak:
- a kapcsolati formon kitöltött adatokat tárolja a weblap (Név, mail, tel, üzenet tárgya ill maga az üzenet, IP)
- a "szolgáltatás megrendelő" formon kitöltött adatokat tárol a weblap (név, mail, tel, cím, IP, date, üzenet)

Ott kell GDPR vagy sem? Elegendő csak egy szabályzat feltöltése az oldalra, miszerint minden adat csak a szolgáltatás biztosítása érdekében van rögzítve, s kérésre töröljük. Stb.

Ugyebár ezek az adatok e-mailben is elmennek a tulajdonosnak/weblapon is nézegetheti és _csakis_ a szolgáltatások működése szempontjából vannak fenntartva ezek az adatok. Regisztráció nincs. Hírlevélküldés nincs. Az adatkezelő/adatfeldolgozó maga a tulaj.

Kérésre bármilyen adatot törlünk/ürítjük a formot.

Köszönöm a választ.
UI: Ügyvéd bevonása (remélhetőleg ért a GDPR-hez) már folyamatban van.

Engem az is érdekelne, hogy mi történik ha valaki (pl. a konkurenciád), létrehoz egy kamu weboldalt (mintha a tiéd lenne) valami shared hosting szerveren fake adatokkal, aztán ezt a weboldalt feltölti a te vállakozásd adataival, majd telipakolja mindenféle nem gdpr megfelelő adatgyüjtéssel és felnyom a hatóságnál hogy a weboldalad nem gdpr megfelelően gyűjt adatokat.

Ilyenkor hogy bizonyítod be hogy az a weboldal nem a tiéd?
És most nyilván nem a microsoft.com-ról beszélünk, de a szomszéd fodrászatnak létrehozni egy ilyen kamu landing page-t pár ezer forint meg fél óra és vszinüleg olcsóbb "megoldás" az eltüntetésére mit alámenni árakkal...

Semmi ilyen nem kell, full kamu adatokkal akármilyen weboldalt tudok regisztrálni (feltéve hogy más még nem regisztrálta).
Felmegyek a namecheap oldalára, beregisztrálom a copass.io weboldalt, kifizetem pl. paypallal a 30 dollárt. A kutya nem ellenörzi hogy ki vagy.

Aztán - mivel vállalkozó vagy és szerepelsz a vállalkozói adatbázisban amit bárki lekérhet - szépen csinálok neked egy wordpress oldalt, amin feltüntetem minden adatod, meg odateszek egy email cím-es feliratkozó oldalt, természetesen nem gdpr kompatibilisen, meg elfejetek felrakni egy adatkezelési tájékoztatót, majd másnap (május 25e után) irok a naih-nak hogy te milyen csúnyaságot csinálsz itt, gyüjtögeted a személyes adatokat...

Akik, ha komolyan veszik a munkájukat, a következő nap kopognak nálad...

Életszerütlennek tünik? Hát, 30 dollárért cserébe örökre bezárathatom a konkurens vállalkozásod, nulla kockázattal, az évszázad biznisze.

És akkor még olyan "apróságokról" nem is beszéltünk hogy mi történik a vizsgálat során, amig te próbálod bizonyítani hogy az nem a te weboldalad vagy a hatóság hogy de a tiéd, zárolják a céges számlád a vizsgálat idejére? Elviszik a szerveredet? Simán a padlóra küldhetnek és hiába derül ki 2 év múlva hogy bocs ez mégsem a te weboldalad volt csak valaki visszaélt vele, akkor már sokra mész a visszakapott gépeddel...

Nem lennék meglepve ha május 25 után sok ezer vagy százezer (a teljes EU-ra) ilyen ügy indulna, hisz a GDPR - jelen formájában - egy kiváló fegyver arra hogy tetszőleges vállalkozást csődbe vigyél ilyen vagy hasonló módon. Ez még a szabadalom trollkodásnál is jobb, hisz ott pereskedni kell, ahol kockázat is van hogy elbukod, itt meg csak fel kell jelenteni, aztán nyugodtad hátradőlhetsz és élvezheted ahogy a hatóság küzd az ellenfeleddel.
De ez a fegyver akár országok között is müködhet, kellően ügyes országok (pl. kína) simán ki tudja használni hogy EU beli konkurenciát csődbe vigye vagy ideiglenesen blokkolja.

Aztán persze ne legyen igazam de én semmi akadályát nem látom annak amit feljebb írtam (maximum hogy pl. a magyar hatóság nem fog jobban foglalkozni az ilyen bejelentésekkel mint eddig).

(feltéve hogy más még nem regisztrálta).

ez az 1. gyenge pont: en pl. kapasbol azt mondanam, hogy elnezest, de nezze meg az x.com oldalt, ez az en honlapom. Az x.xyz, meg az x.biz oldalakhoz semmi kozom, azt sem tudtam, hogy ilyenek leteznek

Akik, ha komolyan veszik a munkájukat

ez a 2. gyenge pont

30 dollárért cserébe örökre bezárathatom a konkurens vállalkozásod, nulla kockázattal, az évszázad biznisze.

tul sok sci-fi-t nezel. Nyilvan te gondoltal erre a hack-re eloszor...

--
'Amikor az embernek rossz szerencséje van, az rossz szerencse' - Best of Leekens, a foci feltamasztoja (muhahaha)

"ez az 1. gyenge pont: en pl. kapasbol azt mondanam, hogy elnezest, de nezze meg az x.com oldalt, ez az en honlapom. Az x.xyz, meg az x.biz oldalakhoz semmi kozom, azt sem tudtam, hogy ilyenek leteznek

Oké akkor fordítsunk a labdán, nem visszaélnek a nevemmel, hanem valóban én vagyok a gonosz cég.
Ezek szerint ha én gonoszkodni akarok, akkor nincs más dolgom mint csinálni két weboldalt, egy gpdr kompatibiliset, meg egy másikat ahol szépen gyüjtöm az ügyfelek adatait (pl. ott írattatom fel őket a körlevelekre), és ha jön az ellenörző hatóság, akkor nincs más dolgom mint közölni velük hogy hát az én oldalam a gdpr kompatibilis, a másikhoz semmi közöm.

Ha az elképzelésed megállna a lábán, akkor innentől kezdve az összes gonoszkodó cégnek csak annyit kéne csinálnia hogy csinál egy második weboldalt és ott végzi a piszkos dolgait, majd ha jön az ellenörzés, boci szemekkel közölné hogy az nem az ő oldala az övé a másik...

"ez a 2. gyenge pont"
Ezzel egyetértek, de ez maximum nekünk "szerencse", egy német hatóság már lehet hogy másképp áll a dolgokhoz.

"tul sok sci-fi-t nezel. Nyilvan te gondoltal erre a hack-re eloszor..."
Nem tudni hányan gondoltak erre, lévén majd csak május 25 után lesz aktuális, akkor kiderül.
Az a baj hogy kevés sci-fit nézek, mert például azt hinné az ember hogy egy négyzet alapon kör címü 4 éves ovodás által firkált rajzot nem lehet levédetni a szabadalmi hivatallal maximum a sci-fikben, aztán meg kiderül hogy ez a valóság és dollár milliárdos perek mennek rajta.

hanem valóban én vagyok a gonosz cég.

ez sokkal inkabb egy ostoba ceg leirasa. Nem latom, mi ertelme 2 site-ot fenntartani, ha az egyik amugy is compliant. Annal is inkabb, mert egy website csak a jeghegy csucsa. A viz alatti resz meg az, ami a cegen belul tortenik.

Btw. minden ertelmes szankcio alapelve, hogy inkabb hagyjunk futni egy bunost, mintsem megbuntessunk egy artatlant.

azt hinné az ember hogy egy négyzet alapon kör címü 4 éves ovodás által firkált rajzot nem lehet levédetni a szabadalmi hivatallal maximum a sci-fikben,

ez irrelevans a topik szempontjabol...

--
'Amikor az embernek rossz szerencséje van, az rossz szerencse' - Best of Leekens, a foci feltamasztoja (muhahaha)

ez így működik:
- kapok egy levelet hogy a copass.io oldalam személyes adatokat gyüjt, stbstb.
- írok egy választ hogy az nem az én oldalam, az enyém a copass.hu, csatolom a papírokat amivel igazolom hogy csak az enyém és semmi közöm a copass.io-hoz. tehát együttműködök a hatóságokkal.
- feljelentést teszek a rendőrségnél vagy hogy visszaéltek az adataimmal copass.io oldalon,ststbstb. a nyomozás során megkeresik az .io-t, kérnek adatoszolgáltatást.mivel paypal-al fizettél így meglesznek az adataid azonnal.
mert a paypal kiadja a hatóságnak ezeket az adatokat (paypalpoliszi 7.a = Továbbíthatjuk a szükséges információkat: a rendőrség és más bűnüldöző szervek részére...)

az meg pláne egy téveszme hogy azonnal ugrani fog a naih majd azért mert te névtelenül sírsz nekik. mert ők azzal kezdik majd hogy írnak egy levelet megint hogy volt-e xy-tól megkeresés.
"Az Infotv. fenti szabályozására tekintettel a Hatóság a panaszokat csak abban az esetben vizsgálja ki, amennyiben az érintett a Hatóságnál tett bejelentését megelőzően már megkereste az adatkezelőt a bejelentésben megjelölt jogainak gyakorlásával kapcsolatban."
én nem fogok tudni semmiről, mivel a kamu oldal, kamu emailjére megy minden megkeresés.
postázni meg már senki nem lesz olyan bátor.

Valahogy így kellene működnie, de biztosan így is működik?
Sokszor leírtam már: feltörtnek látszó router -> szolgáltató javasolta, hogy tegyek feljelentést. No nem azért, hogy megtalálják az elkövetőt, csak hogy legyen nyoma, ha valami disznóságra használta a behatoló a routeremet/előfizetésemet.
Hát izé... ha lezárták volna azzal, hogy eredménytelen volt, azt elfogadom. Finoman szólva marhaság volt az "eredmény" :)
Persze lehet, hogy a céges ügyeket komolyabban veszik.

"Persze lehet, hogy a céges ügyeket komolyabban veszik."

Ne gondold. Illetve hát komolyan veszik kb. annyira, hogy ha nem cibálod magaddal konkrétan az elkövetőt is az eltakarított bizonyítékokkal együtt is a feljelentés megtételéhez, akkor jó eséllyel le fogják zárni évek múltán, hogy bizonyíték hiányában nem lehet mit kezdeni.

Engem pl. egyszer valamikor július környékén hívtak, hogy menjek már be augusztusban tanúskodni egy fél-egy évvel korábban megtett feljelentéshez és igazából kb. olyan érzésem volt az egész tanúskodáson, mintha a nyomozó nem azt keresné, hogy hogyan lehet elindulni azon az úton, hanem azt, hogy hogyan lehet ezt a szálat minél hamarabb lezárni. Mondjuk ok, elég profi munka volt, és a másik irányból valószínűleg több értelme lett volna elindulni, viszont azt még közvetlen a feljelentéskor kellett volna egyből.

Konkrétabbat nem akarok mondani, mert nem tudom hogy áll a sztori, mindezektől függetlenül időközben munkahelyet váltottam.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kamu weboldal sem kell.

Azt látom, hogy hiába "volt 2 éved", hogy felkészülj. Az összes konkurensem sincs még felkészülve. Persze nem fogom feljelenteni őket.
Én igyekszem felkészülni. Viszont annyira nem egyértelmű sok dolog, hogy így is lehet, hogy találnak fogást, ha nagyon keresnek.

A nagyobb cégek is még csak most csöpögtetik az információkat. Azok is ellentmondóak egymásnak. Pl. a Google egyértelműen áthárította a reklámoknál a felelősséget a megjelenítő oldalakra (nem mintha tehetne mást).

Ha jól értelmezem és egyelőre még csak próbálom értelmezni:
Neked kell a felhasználók egyértelmű beleegyezését kikérned a reklám megjelenítésekhez. Ez viszont elég nagy gáz. Sok oldal ezért tud jelenleg ingyenes lenni.

A Google kb. 5 megoldást javasolt a felhasználók beleegyezésének kikérésre, hogy sütiket használhass reklám megjelenítéshez.

Mondanom sem kell, hogy mind az 5 máshogy működik:
- Az egyiknél csak elutasíthatod és elfogadhatod az összes webhelyhez kapcsolódó sütit.
- A másiknál egy felugróban kikapcsolgathatod külön-külön. Alapból be vannak kapcsolva.
- A harmadiknál a reklámok kivételével minden be van kapcsolva alapból.
- A negyediknél semmi sincs bekapcsolva alapból. A felhasználó, ha így fogadja el. Semmire sincs jogod.
- A jelenleg az EU saját (még nem GDPR-os) oldalán található eset nagyjából megegyezik az elsővel, kivéve, hogy azt javasolja, hogy eu-n kívüli cég sütijét ne használd. Pl. Google Analytics.

Abban mondjuk mindegyik megegyezik, hogy visszavonható a döntésed.
3 esetben megegyeznek, hogy vannak süti kategóriák: szükséges (pl. CloudFlare), felhasználói beállítások (pl. nálam reklámok tilthatósága), Analitikai (pl. Google Analytics), Marketing (pl. Google Adsense).

Most ez a nagy fejtörőm, hogy pontosan akkor melyik is a megfelelő?
Ha a reklámokat külön kategóriába rakom, akkor ha alapból be van pipálva sértek-e valamilyen elvet? Ha nincs bepipálva, a felhasználók 90%-a nem fogja bepipálni, csak nyom egy "ok"-ot. Ekkor nagyjából be is csukhatna a weboldalam.

Már a 2. ügyvédnél vagyok és mindegyik máshogy értelmezi a dolgokat. Legutóbb 2 napja ezt a fejtörőt adtam fel az ügyvédemnek. Még nem jött válasz.

Ez a legfontosabb kérdés most. A többi is fontos, de azok ráérnek.

Most ott tartok, hogy kb. 10 hónapra fizetve vannak a szervereim. 5 hónapig tudom pihentetni a vállalkozást. Addig leveszem a reklámokat, analytics-et, letiltom a kapcsolati lehetőségeket. Leveszem az access logokat. Kialakítok egy adatvédelmi oldalt, ahol leírom, hogy "semmit sem gyűjtök" és megvárom mi fog történni a többiekkel, vagy mit alakítanak az oldalaikon.

Az alapból bepipált hozzájárulás sajnos nem kompatibilis a szabályozással, recital 32: "Consent should be given by a clear affirmative act...", azaz tevőleges hozzájárulásnak kell lenni. Ez a Working Party szerint nem lehet semmiképpen sem előre bepipált checkbox vagy "ha folytatod a böngészést elfogadod" típusú hozzájárulás.

Az analitikai sütiket majd könnyíti, ha végre elfogadásra kerül az ePrivacy Regulation, ami a süti és direkt marketing kapcsán egy kiegészíti rendelete a GDPR-nak. Eredetileg május 25 lett volna az is, de késik, valószínű év vége felé érkezik. A GA-val ki lehet ezt várni a szürke zónában, persze ez némi kockázat.

Az nem világos, hogy a reklámokat miért tiltod, nem biztos hogy GDPR szempontjából erre szükség van...

(Az ügyvédek általában nem értik, hogy mit akarsz amikor a perzisztens sütikről kezdesz el velük beszélgetni :) )

1. Alapból a Google személyre szabott reklámokat ad. A profil alkotás pedig különösen célzott terület úgy tudom a GDPR-nél.

2. Ki lehet kapcsolni a személyre szabott reklámokat. Viszont akkor is rak le sütiket. Tehát ahhoz is egy alapból kipipálatlan hozzájárulás szükséges. Mivel az emberek sietnek, így nem fogják bepipálni, hanem inkább nyomnak egy "ok"-ot, csak tűnjön már el az a zavaró popup.

Jam, a Google Ads sütizése világos, félreértettem a reklám kikapcsolását a korábbi hozzászólásban.

Mivel nincs jobb, ezért szoktam javasolni, hogy "meggyőző" hozzájárulást kérő szöveg kell, mint például "a honlapunk az elhelyezett hirdetésekből tartja fent magát, a további ingyenes működéshez kérlek járulj hozzá, hogy a hírdetőpartnerünk sütit helyezzen el a gépeden".

Igen. Nem kötelező, de akkor nem lesz annyi bevételem amiből fent tudom tartani az oldalt.
A Google Ads:
1. Személyre szabotthoz biztos rak le sütiket.
2. Ha nem személyre szabott akkor is rakhat le sütit, ha jól tudom. Ezt majd tesztelem. Ez is már 30-50%-os bevétel csökkenést jelent kb. az első ponthoz képest.

Ezt én értem, viszont ezt nem eroltetheted a latogatoidra (vagy igen, ha az oldal latogatasanak alapfeltetelekent kötöd ki, és ha nem vállalja, akkor elnavigalod, csak mondjuk így még nem lesz túl nagy sikered).

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Igen ez így van.

Eddig is volt lehetőség, hogy letiltsák a reklámokat.

Egy próbát megér a lentebb javasolt megoldás. Ha nem jön be, akkor ez az oldal is becsuk.

Volt egy másik hobbi blog oldalam, ami már így is éppen csak kitermelte a fenntartási költségeket. Így az most áldozatul esik a GDPR-nek.

Én úgy értettem, és jó lenne ha kijavítana valaki, hogy nincs így :), hogy külön kell választani az oldal működéséhez szükséges cookie-kat az analízis és a reklám cookiektól, és nem teheted az oldal látogatás előfeltételévé az analízis / reklám cookiek elfogadását, ezeket külön, teljesen önkéntesen kell engedélyeznie.

Kérdés, hogy ez csak 3rd party szolgáltatás esetén van így, tehát pl. Google Analyticsnál, és ha felrak az ember egy Piwik-et, akkor nem kell ez a külön consent, vagy ez mindig így van?

Igen. Ebben az esetben viszont "csak" a reklám sütik maradnak. Google Analytics lekerül. A CloudFlare meg nem letiltható.
Tehát már csak a reklámokat kell jóváhagynia.

Most nézelődök én is piwik stb. irányában. De előbb még kigyomlálom a YouTube stb. függőségeket is.

Én pedig jobban rühellem, ha pl. mindenféle vásárlási szándék nélkül, pusztán kíváncsiságból megnézek egy terméket a neten, majd aztán napokig, kéretlenül a képembe tolja a google ugyanazt, az összes olyan oldalon, ahova csak a szaruk be van ágyazva. Erősen kontraproduktív és akaratlanul is azt az oldalt is kerüli utána az ember, ahol zsinórban operálnak ezzel a trükkel. Szívesen fizetnék a kedvenc híroldalaimnak, ha megoldanák, hogy a fizető látogatók ne kapjanak a beágyazott reklámokból.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Köszönöm. Ez jó ötletnek tűnik. Érdemes volt feltenni a kérdést. :-)

További gondolatok:
Ha csak a reklámokat tartom meg mint süti készítőket, akkor nagyjából ez a szöveg jó is lenne. Ekkor elég lenne egy "OK".
Szerintem még pipa sem kell. Mert csak 1 féléhez kérek hozzájárulást. Ehhez viszont akkor a Google Analytics-t még ki kellene kapcsolnom.

Személyre szabott reklámok nélkül kb. 30-50%-al csökkenhet a reklámbevétel.
Viszont a személyre szabott reklámokra ha rákérdezek, akkor valahogy így nézne ki a dolog:
"A honlapunk az elhelyezett, személyre szabott hirdetésekből tartja fent magát, a további ingyenes működéshez kérlek járulj hozzá, hogy a hirdetőpartnereink sütit helyezzenek el a gépeden."
"Elfogadom" / "Nem fogadom el"
Ha a "Nem fogadom el"-re kattint, akkor még feljöhet:
"Kérlek, hogy oldalunk működtetésének érdekében a nem személyre szabott reklámok elfogadásához járulj hozzá."
"Elfogadom" / "Nem fogadom el"

Ha "Nem fogadom el"-re kattint, akkor kénytelen leszek reklámokat nem megjeleníteni vajon? Vagy a második esetben elég egy "Elfogadom" csak? Ezt még tesztelnem kellene, hogy a nem személyre szabott reklámoknál tényleg raknak-e le a Google és partnerei sütiket.

Az "OK" gomb megoldást nem javaslom, alapvetően azt tartják helyes megoldásnak, ha van "elfogadom" és "elutasítom" gomb.
Itt egy kis olvasni való a European Commission gondozásában: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm

A nem személyre szabott reklámok talán nem raknak követő sütiket, de a Google Ads-ot annyira nem ismerem. Ha nem raknak, akkor nem kell hozzájárulás.

Megoldás tehát egy nagyobb, zavaróbb süti elfogadó ablak, hogy kénytelen legyen dönteni. Eddig egy picikével megoldottam.

Köszi a linket, tanulmányozom. Ezt a google is megadta már, mint fentebb írtam, de nem olvastam még el. Összezavart a többi oldal, ahol egyenként lehetett a kategóriákat jóváhagyni. De megoldás lehet ha az analytics-et letiltom és így már csak a reklám marad. :-)

No, olvasgattam a linkelt anyagot. Előjött még néhány dolog amire nem gondoltam:

1. "For example, the German Data Protection Institution has declared it does not authorize the use of Google Analytics on public websites."
Nem is gondoltam volna, hogy a német törvények tiltják is a Google Analytics használatát.

2. Youtube videók is vannak embeded módban az oldalon. Ezeknek most képeket készítek és a képekre kattintva nyílnak meg új ablakban.

Ha csak Google Analytics van, akkor összességében ez jó megoldás szerintetek? (nincsen fb pixel, nincs adsense, stb.)

Egy alsó sáv lenne, amiben leírom, hogy:

"A honlap látogatottságát a Google Analytics méri, melyhez úgynevezett "sütiket" használ. Ha ezzel nem értesz egyet, zárd be az oldalt! "Ok"

Illetve, ha van pár beágyazott youtube videó + céges fb oldal is egy pici boxban? ezeket érinti a gdpr?

Maga az irány jó amúgy szerintem - nekem sem hiányzik az a sok spam amit bizonyos cégek küldözgetnek.. de tényleg röhejes hogy azok a szervek, akik később az ellenőrzéseket fogják végezni (?), képtelenek kiadni egy pár oldalas gyakorlatias pdf-et. No mindegy, szerintem fel van fújva kicsit a dolog, ha az ember tisztességesen áll hozzá és nem küld kéretlen leveleket a korábbi feliratkozóknak, és tényleg bizalommal kezeli a megadott adatokat, akkor nagyon kicsit az esélye, hogy bármi balhé lenne..

a az ember tisztességesen áll hozzá és nem küld kéretlen leveleket a korábbi feliratkozóknak, és tényleg bizalommal kezeli a megadott adatokat, akkor nagyon kicsit az esélye, hogy bármi balhé lenne..

ez elegge utolso mondat szagu...

--
"dolgozni mar reg nem akarok" - HZ 'iddqd' zoli berserk mode-ba kapcsol

"de tényleg röhejes hogy azok a szervek, akik később az ellenőrzéseket fogják végezni (?), képtelenek kiadni egy pár oldalas gyakorlatias pdf-et"
Az a röhejes, hogy a Kamara képtelen volt megcsinálni egy normális tájékoztatót és minta dokumentumokat a KKV-k számára, pedig abba a pár milliárdba, amit behajtanak tőlük a semmiért, csak belefért volna, és látható eredménye is lenne a pénztemetőnek…

( csardij v | 2018. 05. 06., v – 13:06 )

Mikor ki az adatfeldolgozó?

Pl. egy osztott tárhely esetén gondolom a szolgáltató, mivel ő üzemelteti a környezetett (adatbázis szervert, stb).

De egy VPS esetén már az aki a VPS-t üzemelteti, nem pedig a VPS szolgáltatója, ugye?

Egy-egy esetben lehet több adatkezelő és adatfeldolgozó is, technikai megoldásoknál néha egészen kacifántos a helyzet. (Pénteken voltam valakinél, ahol kb 20 percet gondolkoztam rajta, hogy ki kicsoda :) )

A jelen esetben, az a fontos, mi számít adatkezelésnek: "4/ 2. „adatkezelés”: a személyes adatokon vagy adatállományokon automatizált vagy nem automatizált módon végzett bármely művelet vagy műveletek összessége, így a gyűjtés, rögzítés, rendszerezés, tagolás, tárolás, átalakítás vagy megváltoztatás, lekérdezés, betekintés, felhasználás, közlés továbbítás, terjesztés vagy egyéb módon történő hozzáférhetővé tétel útján, összehangolás vagy összekapcsolás, korlátozás, törlés, illetve megsemmisítés;"

A VPS esetén, ha mást nem, minimum tárolja az adatokat, esetleg még van backup is, így ennek a célnak kapcsán a VPS szolgáltató az adatkezelő. Az Amazonnál például az admin oldalon alá lehet írni az adatkezelési megbízást és rendben is van a dolog, kisebb szolgáltatóknál bőven el tudom képzelni, hogy erre nincsenek felkészülve még.

Hogy lehet egyszerre több adatkezelő? A példád alapján az ügyfeled kérhetné a VPS szolgáltatódtól, hogy törölje a te backupodból a személyes adatait?

Olvass tovább! A 4/7., ill. 4/8. definiálja az „adatkezelő”-t és az „adatfeldolgozó”-t.
Te vagy az adatkezelő, a VPS-szolgáltató adatfeldolgozó, és kvázi te felelsz azért, hogy ő megfeleljen a GDPR-nak.

Sorry, én hibám + az idióta nyelvezet, a VPS természetesen adatfeldolgozó, aki adatkezelést végez a nevedben. Az adatkezelést végző nem feltétlenül adatkezelő ugye :)

Több adatkezelő ettől függetlenül még lehet, akár a 26-os cikkelyben megfogalmazott szerint vagy még bonyolultabb módon, de az most nem ide tartozik.

( zoldnap | 2018. 05. 11., p – 18:20 )

Papír alapú dokumentumoknál mi a követendő eljárás? Ha az adott szoba zárható és csak annak van hozzáférése, aki jogosult belelátni az adatokba, akkor szobán belül már nem kell külön zárható szekrényt fenntartani, ugye? He kell zárható szekrény, egyátalán milyen védelmi szint megfelelő? Fából készült zárható szekrény elég, vagy lemez/páncélszekrény kell?

Az adat alanyok kockázatával megfelelő arányú védelem. A rendelet nem írja elő, hogy milyen technikai vagy szervezési intézkedeéseket teszel, csak hogy legyen arányos. A legtöbb kisvállalkozás által kezelt papír (számlák, bérszámfejtés, ilyesmi) nem nagy kockázat. Ilyen esetén, ha valóban ki lehet jelenteni, hogy ott idegen nem tartózkodik (mondjuk nincs takarítócégnek bejárása), akkor a tény, hogy az iroda zárt elég lehet. Persze arra is érdemes gondolni, hogy az illetéktelen munkatársak ellen is meg kell védeni, ha nagy a sürgés forgás nem tudod biztosítani, hogy jogosulatlan ember nem nyúlja le a papírokat, ilyenkor egy alap zárható szekrény azért jogos elvárás.

( covix v | 2018. 05. 19., szo – 11:20 )

Sírva röhögős, komolyan. Éjszaka esett be spamtrap-ra:

Május 25-én lép hatályba a Magyarországon is érvényes új európai uniós adatvédelmi rendelet,
a General Data Protection Regulation (GDPR), miszerint szállodánknak is eleget kell tenni
az adatkezelésre vonatkozó szabályozásnak.

Ezúton szeretnénk megerősítését kérni, hogy a jövőben is küldhessünk hírlevelet Önnek. Kérjük töltse ki feliratkozó oldalunkat és jelölje meg, melyik témákban szeretne tőlünk hírlevelet kapni*

KoviX

Egyik ismerős szálloda kapta a Magyar Szállodák és Éttermek Szövetségétől.

"Az új Adatvédelmi törvénynek való megfelelés minden vállalkozásnál, minden szállodánál azzal kell hogy kezdődjön, hogy hozzáértő szakember el kell végezzen egy ún. adatkezelési auditot.

Ennek során megnézik, hogy a szálloda adatkezelése (úgy a vendégek, mint a munkavállalók esetében) jelenleg hogyan történik, s ennek alapján milyen intézkedésekre van szükség, hogy a törvény elvárásainak megfeleljen.
...

Szövetségünk – a szállodavállalatok, nagyobb szállodák javaslata alapján – a következő cégeket tudja ajánlani, de természetesen rengeteg hasonló vállalat működik Magyarországon:"

Az ajánlott cégek ajánlatában szereplő árról inkább nem mondok véleményt.

( Fisher v | 2018. 05. 23., sze – 10:03 )

Oké, egyre több oldal könyörög hogy optineljek, néha meg is teszem.
Viszont a régi spamok továbbra is jönnek, ezeket hol/hogy kell/lehet/célszerű (majd) felnyomni? Őszintén szólva nem biztos hogy a NAIH lenne amit ilyen hülyeségekkel terhelnék, hacsak nem az van, hogy most már tényleg lenne értelme.

( szilard_ v | 2018. 05. 24., cs – 22:07 )

Ma megkérdezték, hogy mi a helyzet a konferencián az üveggömbbe bedobott névjegyeken lévő adatokkal?
Ezek azok a kártyák, amiket azért dobnak be, hogy felvegyük velük a kapcsolatot, hiszen több száz emberrel lehetetlen részletesen beszélni ilyenkor.
Név, telefonszám, email. Azért kaptuk, hogy megkereshessük őket, de ez nem egy klasszikus feliratkozás.

Ezt hogyan kezelnétek?

Én azt mondtam, hogy küldjünk mindenkinek emailt utólag, hogy rögzítve lettek az ügyféltörzsben az adataik. Maradhat: Igen/Nem. Jobb ötletem most nincs.

"de ez nem egy klasszikus feliratkozás."

Szerintem egyébként de.

"Én azt mondtam, hogy küldjünk mindenkinek emailt utólag, hogy rögzítve lettek az ügyféltörzsben az adataik. Maradhat: Igen/Nem. Jobb ötletem most nincs."

Én ezt alapvetően már opt-innek venném, szóval utólag már tennék fel eldöntendő kérdést, max annyit tennék, hogy abba az utólagos levélbe (ami lehet akár az is, amiben megkerestétek), abba max beírni a végére, hogy ezt opt-innek vettétek, egyébként a processz szerint így meg így tud szólni, hogy töröljük.

( zitev v | 2018. 05. 25., p – 18:26 )

Kérdés: az adatkezelo felrakja az adatokat a felhobe (harmadik fél (google), adatfeldolgozo), és erről tájékoztatja az usert, majd az adat valahogy kikerul a felhobol - ezért ki lesz a felelős? Az user nyilván az adatkezelot perli és o pedig tovább perli az adatfeldolgozot?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Gondolom a saját adataidról van szó, akkor te nem közvetlnül a cloudot pereled (bár nem tudom ez jó kifejezés e, NAIH vizsgálódik, és büntet, nem peres eljárásról van szó), hanem az adatfeldolgozót, aki majd továbbtolja az adatkezelőre, stb.stb. igy láncolatban.

De ma már valaki felnyomta a facebookot meg a guglit, meglátjuk mi lesz ebből.

( mraacz | 2018. 05. 27., v – 08:52 )

"Mi úgy implementáljuk a rendeletet, tehát úgy tesszük a magyar jog részévé, hogy osztrák mintára a kis- és közepes vállalkozások számára figyelmeztetésre van lehetőség."

1. Az EU szabály egy keret, amelynek a következményként szükséges magyar jogi szabályozása még nincs meg. Részek vannak, mert eddig is voltak, de a lényeg még hiányzik.
2. A magyar szabályozás nem szándékozik 20 millió eurós büntetéseket kiszabni kis- és közepes vállalkozásokra pl. azért, mert az EU rendeletben előírt adminisztrációt csak részben vagy nem végezték el.
3. Ami ebben a témában kis- és középvállalkozások számára fontos volt (pl. titokvédelem, internetes biztonság, pontos dokumentáció) azt eddig is jogszabály írta elő és ha nem írta volna elő, akkor is minden normális vállalkozás számára ésszerű volt.
4. Az egész GDPR hisztéria jó sok bevételi lehetőséget hozott tökfölösleges papírokat, nyilatkozatokat és szabályzatokat gyártó jogászok és informatikusok számára.

1. Jelen esetben ez egy EU rendelet, nincs olyan, hogy a magyar szabályozása nincs meg. (Nem irányelv.)
2. Tök mindegy, hogy mit mondanak, ez egy EU rendelet, magyar jogszabály még mindig nem bírálhatja felül. (Mit érsz azzal, hogy mit mond a NAIH, ha mondjuk a német adatvédelmi hivatal jár el?)
3. Na, ez így igaz.
4. Azoknak a tök fölösleges papíroknak, nyilatkozatoknak és szabályzatoknak alapvetően létezniük kellett volna eddig is: l. 3. pont.

1. Egy EU rendeletről van szó, amely sokmindent a helyi szabályozás alá rendel, ami még nincs meg. Nincs meg. Pont.
2. Nem ismered az EU rendeletet. https://gdpr-info.eu/ Egy sor dolgot, pl. a bejelentési kötelezettség, az eljáró hatóság stb. ügyében a helyi törvénykezésnek kell szabályoznia. Senki nem akar felülírni semmit, ne zavarjon.
4. Ahol léteztek, ott nem jártak rosszul vele, ahol nem, ott a jövőben sem fog vele foglalkozni senki (ha egy csepp esze van, sokkal nem is tesz többet, mint amit eddig is kellett volna).

Ostoba hiszti az egész (természetesen a liberális értékekre és a jogrendbe vetett bizalomra hivatkozással).

( kalvi | 2018. 05. 28., h – 15:46 )

Most nem az a deal, hogy egy árva süti sem töltődhet be amíg a látogató nem járul hozzá? Meglátogattam néhány GDPR tanácsadó oldalt és a Privacy Badger 4-5 sütit is jelzett. Főként facebook és a google.. sütik voltak meg pár általam ismeretlen.
A saját oldalamnál már nem is próbálkozom. Szerintem a kiegészítők is önállósítják magukat.

Hát ezt többféleképpen értelmezik. Amit én gondolok az átolvasott anyag alapján: vannak olyan sütik amikhez nem kell hozzájárulás. Ilyenek pl. a session sütik, felhasználói beállítást tároló sütik, biztonsági sütik.

Tehát ez elég tág értelmezést adhat. Ez alapján minősíthették akár a Google jogászai úgy, hogy session sütinek neveznek olyat, amit eddig nem így nevezetek például.

Az OTP nem aprózza el, elég részletesen lehet választani:
https://www.otpbank.hu/static/portal/sw/file/Sutitajekoztato.pdf

Alap működést biztosító sütik

Ezen sütik biztosítják a weboldal megfelelő működését, megkönnyítik annak használatát, és látogatóink azonosítása nélkül gyűjtenek információt a használatáról.

Használt sütik:

Munkamenet (session) sütik
Használatot elősegítő sütik
Csökkentett funkcionalitású Google Analytics

Statisztikai célú sütik

Ezen sütik a weboldal használatáról részletesebb, elemzési célú információszerzést tesznek lehetővé, így segítenek weboldalunk ügyfélfókuszú továbbfejlesztésében.

Használt sütik:

Google Analytics

Célzó- és hirdetési sütik

Ezen sütik a weboldal felhasználói szintű viselkedési adatainak összegyűjtésével segítenek, hogy látogatóink számára releváns ajánlatokat kínáljunk.

Használt sütik:

Google Adwords
Google Analytics
Facebook
DoubleClick Floodlight
portalId