Potentiale probleme cu noile reguli GDPR, vs. SEO si nu numai, din Mai 2018

Vin sa adaug ceva informativ, de citit pentru cei care sunt interesati.

Este vorba de documentul draft de la ICO UK despre felul in care va fi analizata situatia si /sau cand se dau amenzi etc.

Important - este vorba totusi de legislatia din UK, nu din Romania. ICO este autoritatea locala care face regulile doar in UK. Dar este interesant de citit; in Romania ar trebui sa se aplice metode similare si acelasi spirit. ( Cu rezerva faptului ca desi discutam drept european comun, Romania e mereu o tara speciala. )


Un fragment interesant, ca exemplu din document:

Citat:

---

We also reserve the right to take into account any aggravating or mitigating
factors where relevant, for example15:

• whether the attitude and conduct of the individual or organisation
concerned suggests an intentional, wilful or negligent approach to
compliance or unlawful business or operating model;

• whether relevant advice, warnings, consultation feedback, conditions or
guidance from the ICO and/or the Data Protection Officer (for data
protection cases) has or has not been followed;

---

In fine, aveti documentul aici.

Iata si link-ul cu documentele disponibile pe dataprotection.ro

Recomand ca prim pas citirea ghidului orientativ .

Citat:

---

Postat în original de emm

- Recomand trecerea de la cookie necesar navigarii la session-based cookie.

---

Eu optez pentru o alta abordare - pentru un site facut cu Laravel. Deoarece id-ul sesiunii se regenereaza la fiecare request, incercand diverse solutii, in final m-am oprit la un id de forma:

Cod PHP:

---

md5($request->ip() . $request->header('user-agent') . $request->header('accept-language')) 


---

Adica hash pe ip+browser+languages. IP-ul e II, dar in forma in care il folosesc e ok.

- doar ip e cam ce foloseste trafic.ro
- languages e destul de personalizat si se poate modifica in timp
- toata combinatia e suficient de buna (oricum mai buna ca sesiunea)

Inca ma mai gandesc la varianta finala.

Citat:

---

Postat în original de Floki

Eu optez pentru o alta abordare - pentru un site facut cu Laravel. Deoarece id-ul sesiunii se regenereaza la fiecare request, incercand diverse solutii, in final m-am oprit la un id de forma:

Cod PHP:

---

md5($request->ip() . $request->header('user-agent') . $request->header('accept-language')) 


---

Adica hash pe ip+browser+languages. IP-ul e II, dar in forma in care il folosesc e ok.

- doar ip e cam ce foloseste trafic.ro
- languages e destul de personalizat si se poate modifica in timp
- toata combinatia e suficient de buna (oricum mai buna ca sesiunea)

Inca ma mai gandesc la varianta finala.

---

Ideea nu e rea, e o varianta sumara de browser fingerprinting folosind doar ceea ce ai disponibil server-side (am facut si eu proiecte pe asta). Pentru navigare onsite cred ca este ok. Cu PII nu ai probleme la o astfel de utilizare.

Poate te ajuta cumva si referer-ul, nu stiu. Ma gandesc la situatia cand 2 useri din aceeasi firma de exemplu, acelasi IP/browser vor naviga simultan, se poate intampla.

Eu folosesc sesiune, banuiesc ca ai sesiuni intrerupte sau un motiv anume sa nu folosesti sesiuni, performanta, stiu eu.

Edit: Acum am observat ca ai precizat motivul.

Citat:

---

Postat în original de emm

Poate te ajuta cumva si referer-ul, nu stiu. Ma gandesc la situatia cand 2 useri din aceeasi firma de exemplu, acelasi IP/browser vor naviga simultan, se poate intampla.

---

La mine, 3 persoane folosesc acelasi IP si acelasi browser. Accept-language difera. De ex. e ceva de genul

Cod:

---

ro,en-US;q=0.9,en;q=0.8,fr;q=0.7,de;q=0.6

en-US,en;q=0.8

---

Daca as face hash doar pe IP si browser (astea se gasesc si in log) atunci hash-ul poate fi legat de IP si nu e ok.

Refererul se poate schimba pentru acelasi vizitator.
La varianta cu sesiunea, se pierd returning visitors. In orice caz, in toate situatiile ajungi la un compromis, castigi intr-o parte si pierzi intr-alta.

@Floki - stiu; dar oricum va fi imprecis. Si vezi ce se intampla la cross-visitor "session" mismatch. Edit: Adica daca afisezi unuia ceea ce de fapt trebuia sa vada alt user... poate fi problema mare.

Ca idee, vezi javascript browser fingerprinting. Mult mai precis, peste 90% poate dar nu 100%. Insa nu e usor de implementat si uneori neaplicabil. Eu asta as folosi pentru returning visitors, dar vezi ca trebuie anonimizat.

O discutie interesanta despre IP-uri in server logs: https://www.howtoforge.com/community...logging.78654/

Desi posibila anonimizarea, astea sunt concluziile la care am ajuns eu:
- pastrez IP-urile
- reduc perioada de pastrare la 14 zile - sau chiar 7 (in nginx, /etc/logrotate.d/nginx si schimbi valoarea lui rotate)
- adaug cele de mai sus in privacy policy (temei juridic Art. 6 (1) f) GDPR)

@Floki - cred ca esti OK si cu 30 zile.

Exista si conceptul de utilizare justificata. Cata vreme nu folosesti server logs la altceva, ele sunt utilizate pentru securitate si pastrarea timp de 30 zile cred ca se incadreaza in zona asta. Mentioneaza asta in privacy policy si cred ca e suficient (discuta si cu legal). O sa revin cu o actualizare cand avem mai multe informatii.

Pentru toata lumea, rog cititi mai jos:

Exista o problema legala (un fel de gaura legislativa) legata de GDPR si de aici toata confuzia cu care ne confruntam de multe ori. Ideea este in felul urmator:

Context legal actual. GDPR vine sa adauge multe lucruri noi peste vechea ePrivacy. Atentie, GDPR este regulation (lege UE, obligatorie) in timp ce ePrivacy este directiva (recomandare UE). Statele UE sunt obligate sa aplice legea (GDPR), dar pot decide singure cum sa implementeze directiva (ePrivacy). De aici apare un haos momentan; GDPR se aplica deja peste tot in UE, in timp ce ePrivacy se aplica diferit in fiecare stat UE conform reglementarilor locale.

Conflict si neclaritati. Unele prevederi GDPR vin in conflict cu ePrivacy sau rezultatul este neclar. Spre exemplu partea cu cookies.

Noua ePrivacy. Noua directiva ePrivacy va iesi "pe piata" la sfarsitul anului curent. Vine sa anuleze vechea ePrivacy si sa armonizeze lucrurile in legatura cu GDPR. Problema este ca:

1) Nu stim cum va arata noua directiva, daca impinge lucrurile spre GDPR integral sau dimpotriva, spre consent implicit pentru lucrurile tehnice de sistem (non-marketing, "necesare", gen server logs si cookie strict de navigare)

2) Pana atunci, exista un "gap" in legislatie. Acest gap duce la interpretarea foarte restrictiva a legii in acest moment (din pacate). Pana la sfarsitul anului curent cel putin, interpretarea legala este conforma cu GDPR (restrictiv), dar odata ce:

a) Apare noua ePrivacy, si:

b) Statele UE anunta implementarea proprie a directivei (inclusiv Romania) - schimbare de situatie,

Din acel moment tot ce s-a discutat pana acum se va schimba cel mai probabil. Va deveni 100% clar ce e permis si ce nu (sa speram). In plus, este posibil sa avem nevoie de masuri tehnice diferite in functie de tara unde se afla respectivul (!) sau, mai logic, va trebui sa aplicam cea mai restrictiva metoda din toate tarile UE.

TL;DR; Pana la aparitia ePrivacy la sfarsitul anului (si dupa implementarea ei), GDPR se aplica asa cum este acum. Contextul legal e restrictiv si uneori neclar.

Dupa ePrivacy o sa ne lamurim cu totii mai bine dar se vor schimba lucruri fata de ce s-a discutat pana acum in thread.

Desi nu e motivul principal, GDPR si prima victima... https://www.startupcafe.ro/afaceri/c...nchis-gdpr.htm

WP 4.9.6 vine in ajutor pt DGPR
https://codex.wordpress.org/Version_4.9.6
https://scontent.ftsr1-1.fna.fbcdn.n...cf&oe=5B93A1FB