search

trojsten / web

Trojstenovy web
MIT License
9 stars 8 forks source link

GDPR #1154

Open dodo42 opened 6 years ago

dodo42 commented 6 years ago

Zo strany web treba spraviť

maaario commented 6 years ago

Právo na zabudnutie / zmazanie účtov

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.

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

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

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.

mhozza commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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:

Updateol som podla tohto aj checklist na vrchu tejto issue.

mhozza commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Asi nechceme.

On Thu, 14 Jun 2018, 23:51 Jozef Rajník, notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trojsten/web/issues/1154#issuecomment-397461853, or mute the thread https://github.com/notifications/unsubscribe-auth/ABH4N5GgxTQWSNoV5Q5ltGnzRJwPKUrxks5t8ukBgaJpZM4Ucyi8 .

maaario commented 6 years ago

Š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š.