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

[emm]

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:

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.

[Floki]

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

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.

[emm]

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

Recomand ca prim pas citirea ghidului orientativ .

[emm]

@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.

[Floki]

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)

[emm]

@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.

[Pami]

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

[wega77]

WP 4.9.6 vine in ajutor pt DGPR
https://codex.wordpress.org/Version_4.9.6

[Rapsodia]

Vad ca au pus la Tools si posibilitatea de a exporta sau sterge datele personale. O parte din problemele legate de GDPR se rezolva, cel putin cei ce implementeaza asta nu pot fi invinuiti de rea credinta, dar cititorii nu prea ma prind ce inteleg [ sa vezi cati or sa lase in engleza pagina, desi site-ul este in romana! - daca WP e in romana pagina se creaza automat in romana ].

Informațiile tale de contact
Informații suplimentare
Cum îți protejăm datele
Ce proceduri avem la dispoziție pentru încălcarea securității datelor
De la care părți terțe primim date
Ce decizii luăm și/sau ce profiluri realizăm automat cu datele utilizatorilor

Aici avem de munca! Trebuie sa completam singurei.

[wega77]

Eu cred ca cel mai mult o sa loveasca in cei care fac SPAM nesimtit, cumpara baze de date si le folosesc in mod abuziv, cu cat dai dezabonare cu atat primesti mai multe, probabil la ei se inregistraza mail activ.
Primesc zilnic zeci de oferte de la siteuri care habar nu nu avem ca exista, de la magazine care vand tampoane, la medicamente si biciclete.
Sunt absolut deacord ca aceasta practica trebuie sa dispara.
Sunt si siteuri unde m-am abonat, primesc mailuri, le deschid si citesc cu placere, dar de ce trebuie sa primesc oferta la tampoane sau tractoaare ???