Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDPR #1154

Open
9 tasks
dodo42 opened this issue Jun 6, 2018 · 13 comments
Open
9 tasks

GDPR #1154

dodo42 opened this issue Jun 6, 2018 · 13 comments
Assignees

Comments

@dodo42
Copy link
Contributor

dodo42 commented Jun 6, 2018

Zo strany web treba spraviť

  • adresa, dátum narodenia, rok maturity - v user modeli ako nepovinné, ale nastaviteľné ako povinné pre súťaž + nastaviť súťažiam čo to potrebujú
  • pohlavie dať ako optional (možné použitie pre skloňovanie, momentálne sa na nič nepoužíva)
  • škola - chceme len za účelom uvedenia vo výsledkovke / korešpondencie na školu - napísať im pri GDPR možnosti mazania, že ak ju nechcú, nech dajú "iná škola"
  • cookies pop-up Cookies pop-up #1135
  • nemali by sme bez suhlasu pouzivatela pouzivat cookies tretich stran, ktore vedia identifikova pouzivatela prepnutie: google analyticsov do modu s anonymnymi IP-ckami bez suhlasu, FB pixel asi iba s odushlasenymi cookies
  • možnosť zmazať údaje - tlačítko, stránka s informáciami, deaktivácia účtu, mail vedúcemu
  • stránka o tom, aké údaje zhromažďujeme a na čo ich používame (na trosjten.sk, bude na ňu odkaz z registrácie)
  • checkbox pri registrácii na súhlas so spracovaním osobných údajov (+ súhlas zák. zástupcu pre < 16-ročých), checkbox nemôže byť by default zaškrtnutý
  • opätovné získanie súhlasu na spracovanie - v databáze uchovávať či súhlasia + ak ešte nesúhlasia, pri prihlásení zobraziť popup + poslať mail aktuálnym používateľom, keď to bude?
@maaario
Copy link
Contributor

maaario commented Jun 10, 2018

Právo na zabudnutie / zmazanie účtov

  • čo s výsledkovkami? z freeznutých nebudeme nič mazať, ak by človek veľmi chcel vieme ručne editovať JSON
  • čo so zoznamami účastníkov sústrediek? pri zmazaní účtu sa zmaže účastník zo zoznamu
  • pri žiadosti treba explicitne zmazať účet, alebo stačí anonymizovať používateľa? - viď postup v miovom komentári nižšie
  • čo so zálohami databáz? je to problém?

Dotknutá osoba má podľa GDPR právo kedykoľvek svoj súhlas odvolať, čo jej musí byť pred
poskytnutím súhlasu špecificky oznámené. Odvolanie súhlasu musí byť také jednoduché ako
jeho poskytnutie.

  • znamená odvolanie súhlasu zmazanie účtu? Odosielanie riešení chcmeme mať asi stále spojené
    s ľuďmi, čiže ak nebudú súhlasiť ani s uchovaním (meno, priezvisko, mail), tak musíme zmazať. Inak chceme minimalizovať minimálne požiadavky na osobné údaje aby si mohli ľudia zmazať nechcené informácie ale aby si čo najviac nechalo účet.

Uchovávať len osobné údaje, ktoré sú nevyhnutne potrebné (a žiadne iné) pre každý konkrétny účel spracúvania

  • chceme meno, priezvisko, mail - pre zabráneniu spamov, možnosti kontaktovať
  • škola a rok maturity budú nepovinné, ale naviazaná na všetky súťaže (jediný od koho by sme toto potenciálne nemuseli chcieť sú náhodní rodičia a učitelia)
  • pohlavie nechceme, dátum narodenia bude optional čo si môžu zmazať
  • implementovať adresu používateľa ako dodatočnú vlastnosť pre papierové súťaže

Rovnako tieto systémy musia zabezpečiť, že sa údaje nebudú spracúvať neobmedzene, ale len na nevyhnutnú dobu.

  • asi stačí napísať, že dáta nám treba, kým riešitelia riešia súťaž a potom si môžu údaje vymazať v nastaveniach a dať ignorovať súťaž (martinus má napísane " kým máte konto zriadené", takže asi ok)
  • freezenuté výsledkovky zabezpečujú, že aj keď riešiteľ začne ignorovať súťaž,
    zostane v starých výsledkoch

Rovnako musia takéto opatrenia zabezpečiť, aby osobné údaje neboli štandardne prístupné neobmedzenému počtu zamestnancov prevádzkovateľa, ale len zamestnancom, ktorí nevyhnutne potrebujú prístup k týmto osobným údajom.

  • well

@mhozza
Copy link
Member

mhozza commented Jun 10, 2018

Z freeznutych vysledkoviek nechceme nic mazat, a pri mazani uctu o tom chceme uzivatela informovat.
Mozno chceme dat moznost ze ak by velmi chceli byt zmazany aj od tial, nech nam napisu z ktorych vysledkoviek chcu byt zmazany, potom vieme poeditovat v DB ten JSON.
Nepredpokladam ze sa to niekedy stane.

Zoznamy ucastnikov sa zatial nefreezuju, ak budeme mat historiu skol, tak sa asi ani nemusia.
Znamena to ale, ze ludia odtial potom zmiznu ak si zmazu ucet. Zavisi ci to vadi. Mozme si archivovat/freezovat nejaku safe verziu tych zoznamov ak to ne nieco potrebujeme. Ale osobne udaje by sme odtial mali zmazat. Ak si uzivatel maze ucet, treba ho o informovat o tom co sa stane s jeho udajmi zo zoznamov ucastnikov.

Ak si chceme byt isty ze dodrzujeme zakon, tak asi najlepsie je pouzivatela naozaj zmazat. Toto zmaze aj vsetky asociacie s nim v DB. A je to najjednoduchsie nakodit. Ano, zrejme stratime kopu mozno uzitocnych informacii, ale that's the point.
Postupoval by som takto:

  1. clovek stlaci tlacitko zmazat
  2. Zobrazi sa mu hlaska o tom co to prenho znamena a ci to chce naozaj spravit.
  3. Ucet sa mu okamzite deaktivuje a odhlasi sa
  4. Veducim sa posle mail, ze maju zmazat dany ucet (ak by sa toto dialo casto, tak sa to da nahradit scheduled taskom, ale urcite by som to nerobil hned pri stlaceni zmazat)
  5. Posle sa mu mail o tom, ze jeho ucet bude zmazany natrvalo coskoro, co to prenho znamena a ze ked si nepoziadal o zmazanie/si to rozmyslel, tak ze sa ma ozvat veducim.
  6. Veduci skontroluje ci si do dany clovek nerozmyslel a potom rucne zmaze cloveka z DB.

Asi chceme minimalizovat potrebne info. Dovolit uzivatelom mazat/menit vacsinu udajov o sebe podla lubovole, s tym ze ak zmazu nieco co nam fakt treba, tak im vysvetlime, co to pre ich znamena (pravdepodobne, ze sa nebudu zobrazovat vo vysledkovke a nebudu pozyvany na sustredka).

Pohlavie chceme asi odmazat, je nam to na nic a zrejme by sme na tom nemali nic zakladat.

Datum narodenia moze byt uzitocny pri ludoch, ktori sa rovnako volaju. Plus sme to zvykli davat aj do zoznamov ucastnikov. Myslim, ze stale to moze byt uzitocna info, ale asi by som ho dal ako optional a nechal uzivatelov rozhodnut ci ho chcu mat v zoznamoch ucastnikov...
Skola a maturita by mali zostat podmienkou pre zobrazenie vo vysledkovkach, a ak to clovek nevyplni tak mu treba povedat, ze nebude zobrazeny vo vysledkovkach.

Vacsina veducich potrebuje pristup k mnohym udajom. Ti co nepotrebuju, zrejme nepotrebuju pristup do admina. Okrem toho v adminovi vieme nastavit pristupy pre jednotlivych ludi a skupiny. Takze ak bude treba obmedzit pristup, da sa to.

@maaario
Copy link
Contributor

maaario commented Jun 10, 2018

Postup pri mazaní by asi mohol byť ako píšeš - že teda vedúci klikne na zmazať používateľa v adminovi
a django vypíše, že zmažú sa všetky objekty používateľa a hotovo.

Pri ľuďoch čo sa volajú rovnako ti môže pomôcť mail /login ... a keď tých ľudí nepoznáš tak asi ti dátum narodenia veľa nepovie. Ale teda som za to, aby sa to stalo dodatočnou vlastnosťou.
Dátum narodenia si aj tak vypýtame pri prihláške na sústredko, a inak ho nikde nezverejňujeme (v zozname účastníkov len pre byrokratické účely).

Ohľadom prístupových práv - zatiaľ do admina potrebuje prístup väčšina vedúcich kvôli opravovaniu.
Keďže ale ide o osobné údaje, ktoré sú citlivejšie, možno by sme mohli obmedziť prístup k modelu User.
Mať skupinu iba pre toto?

@mhozza
Copy link
Member

mhozza commented Jun 10, 2018

Skupina pre pristup k uzivatelskym datam znie rozumne, ak teda nie je potreba mat pristup k nim pre vacsinu veducich.

Btw este co sa tyka zaloh DB, mozme ich automaticky mazat napr. po 60 dnoch. Mozno to uz robime @black3r.

@dodo42
Copy link
Contributor Author

dodo42 commented Jun 10, 2018

Viac sa mi páči len premazanie citlivých údajov ako mazanie účtu. Čiže riešiteľ by mal možnosť kliknúť na tlačítko, vypísalo by sa mu, čo to všetko obnáša a že v prípade, že chce byť úplne zmazaný, tak nech nám napíše. Čo tak ešte taký postup, že by sa vytvoril nový user, ktorý by sa mergol s tým, ktorý sa chce zmazať, pričom pri merge by sa ponechali len údaje z novovytvoreného, ktorý bude mať len meno a priezvisko. Toto je v podstate zmazanie účtu, akurát sa ponechajú údaje toho, čo poriešil, kde sa zúčastnil a pod. Nakoľko sú toto veci, čo by sme tiež nemali uchovávať?

Na Slacku padlo, že by ani žiadne premazávanie nemuselo byť implementované, stačí to poriešiť ručne, keď bude o to niekto žiadať. A keby toho veľa, tak sa to môže automatizovať.

@dodo42
Copy link
Contributor Author

dodo42 commented Jun 13, 2018

Padlo tu, že informácie ako škola, adresa a pod. chcú byť povinné len pre riešiteľov súťaží. Chceme to dávať do UserProps, lebo nie všetko sa tam pekne dáva:

  • Školu si tam neviem moc dobre predstaviť, ale tá nie je ani teraz povinná, resp. môže mať človek "Iná škola", po novom None. Keď bude história škôl, tak bude uchovávaná v samostatnom modeli UserSchool.
  • Adresa má špecifický formát (ulica + číslo, mesto, PSČ, krajina), tú treba mať povinnú niekde. Cheme ju vedieť parsovať (napr. pri tvorbe nálepiek na obálky). (O adresách sa písalo aj v Prekopat adresy pouzivatela #884 )
  • Dátum narodenia má tiež špecifický formát, asi ho netreba na žiadnu súťaž.
  • Rok maturity sa dá dať v pohode do UserProps.

UserProps umožňujú mať povinné vlastnosti pre súťaž, ale problém je s formátom, lebo majú len CharField. Viem si predstaviť, že by sme tam ukladali veci v špecifickom formáte, aby sa ľahšie parsoval, len užívateľom podľa mňa nechceme dať, že napíšte nám tetnto string v presne takomto formáte. Plus, v kóde keď treba napr. adresu, ťahať ju z UserProps podľa mena kľúča mi nepríde ako moc čisté.

Alebo môžeme tieto veci ponechať vo fieldoch tak, ako sú teraz, len nejako umožniť, aby si súťaže vedeli povedať, že chcú aj nejaké fieldy povinné. Asi by aj stačilo niečo ako zopár checkboxov pre každý field usera, ktorého sa to môže týkať, či je v danej súťaži povinný a podľa toho potom rooviť veci ako zobrazovanie vo výsledkovke a pod.

@mhozza
Copy link
Member

mhozza commented Jun 14, 2018

Tak ma napadlo, preco vlastne chceme mat adresu povinnu? Podla mna by sme ju mohli nechat uplne nepovinnu, pre vsetky sutaze a mat ju tam len v pripade ak si s nimi chceme posielat postu - ci chcu riesit cisto elektronicky alebo posielat postu.
Proste ak nemaju adresu, nic im neposleme (alebo posleme do skoly).

AK adresu potrebujeme na sustredko, tak ich to mozme nechat vyplnit v prihlaske a potom zase zabudnut po sustredku.

Co sa tyka ostatnych veci, tak navrhujem podobny postup, spravit vsetky nadstandardne udaje, ktore nikde priamo nevyuzivame nepovinne.

Mohli by sme niekde spytat co ktora sutaz potrebuje a preco.
Pokial viem, tak by nam malo stacit:
Meno, Priezvisko, Skola, Rok maturity.

Dokonca aj skola/rok maturity by som nechal ako nepovinne polia (kludne v User modeli, blank=True, null=True), ale tych by som nezobrazoval vo vysledkovke.

@maaario
Copy link
Contributor

maaario commented Jun 14, 2018

Adresu chceme mat ako blank true v user modeli - ale nech sa da nastavit niektorym sutaziam ako povinna.

Na sustredko sa udaje zbieraju samostatne.

Ohladom skoly a roku maturity sme sa s @dodo42 bavili na slacku, ze ich nechame v user modeli a viac menej povinne:

  • Rok potrebujeme na odlisovanie stredoskolakov (teda sutaziacich). Ak by sme rok spravili nepovinny, aj tak by sme ho ziadali od kazdeho a to sa zda ako zbytocna praca (je na rozdiel od adresy je potrebny v uplne kazdej sutazi)
  • Skola nam v podstate moze byt jedno - sluzi na reprezentaciu ich skoly vo vysledkovke (ak nechcu reprezentovat, nemusia sa ku svojej skole priznat), alebo ako korespondencna adresa. Ak tam clovek nechce mat skolu, moze zaskrtnut "ina skola" (kvoli policku ina skola sa inak skola neda spravit povinnou).

Updateol som podla tohto aj checklist na vrchu tejto issue.

@mhozza
Copy link
Member

mhozza commented Jun 14, 2018

Nepoviny rok maturity by to mohlo byt napr. pre neriesitelov (ucitelia, veduci a podobne). Suhlasim ze vlastne rok maturity je jediny povinny udaj pre vysledkovku.

Registracia by mohla byt 2 krokova - prva stranka povinne udaje -> vyrobi pouzivatela.
Druha stranka zadanie skoly, roku maturity, adresy - s popisom na co je co dobre.

AK toho nebude vela, tak sa obe stranky mozu zobrazit naraz pod sebou, nemusime to rozdelovat, ale funkcionalita moze zostat rozdelena.

@dodo42
Copy link
Contributor Author

dodo42 commented Jun 14, 2018

Keď som to začal robiť, tak vlastne som dal testovať podmienku že ak user.get_mailing_address(self) is None, tak riešiteľ nie je validný pre súťaž, ktorá má zaškrnuté, že chce adresu. Vyzistím si aj od vedúcich, čo si o tom myslia. Myslím, že by nemal byť problém pridať k tomu aj kontrolu, či má vyplnený rok maturiry a spraviť ho teda nepovinný.

Páči sa mi dvojkroková registrácia. Pričom by som doplnil aj niečo ako po prvom kroku ponúkne, ktoré súťaže chce riešiť a podľa toho v druhom kroku ponúkne potrebné vlastnosti na vyplnenie. Ak vyberie, že žiadne, tak registráciu môže ukončiť, čo môžu využiť učitelia a pod. Uvidím ešte nakoľko to zvládnem.

@dodo42
Copy link
Contributor Author

dodo42 commented Jun 14, 2018

A chceme aj školu vynucovať zo strany webu? To teraz nevynucujeme, je v pohode, keď niekto má Iná škola, normálne je vo výsledkovke.

@mhozza
Copy link
Member

mhozza commented Jun 14, 2018 via email

@maaario
Copy link
Contributor

maaario commented Jun 15, 2018

Školu vynucavať nevieme (iná škola) a teda ani nechceme - viď záver v popise issue úplne hore.

Kontrolovať get maiiling address znie fajn, len nech je tamvo vnútri ošetrené to school none - pozriem ešet matúšov PR...

Rok maturity podľa môže byť nepovinný a zaškrtávací v competition. Odľahčí to tých zopár učiteľov a rodičov. No dá sa mi to ale tiež trochu zbytočné, lebo narozdiel od adresy je povinný vo všetkých súťažiach, tak si myslím, že by mohol ostať povinný s vysvetlením, žo ho treba všade pre výsledkovky.
(Tiež ma napadlo, že ak by chcel niekto niekedy robiť súťaže pre niekoho iného ako stredoškolákov, tak aj tak potrebuje spraviť zásah do rules, kde sa kontroluje tento rok.) Takže sprav ako chceš.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants