Privateco

[interDist]

Mi planas fari kelkajn aldonojn kadre de la “privateca ombrelo”:

• 1) tabelo kun elekteblo por ĉiu datumero (adreso, telefono, ktp), kie ĝi estu publikigita / videbla.
• 2) averto pri uzo de kuketoj kaj akcepto de tia uzo.
• 3) markobutono por akcepto de la analizaj kuketoj (de Google Analytics).
• 4) butono ebliganta elŝuti siajn proprajn datenojn en iu strukturita formato (rilatas al GDPR - Ĝenerala Datuma Protekta Reguligo #91).
• 5) malpersonigado de datenoj en datumbazoj aliaj ol la viva.

Por №1, mi proponas aldoni

    class PublishedModel(object):
        visible_online = BooleanField()
        visible_in_book = BooleanField()

Loĝejoj, telefonoj kaj aliaj relevantaj objektoj havu tiun modelon inter la gepatroj. En la konto-agordoj, sekcio “Privateco”, aperu tabelo simila al #78 (comment) , kaj tie uzantoj povu marki kaj malmarki siajn preferojn.

Por №4, mi kontaktiĝis kun la privateca teamo de CouchSurfing. Ili ne jam havas konkretan planon por kongrui al tiu postulo de la ĜDPR. Estas laŭ mi sence atendi ĝis kiam ili havos interkonsentitan (inter si) formaton, kaj eksporti en la sama formato. Tiamaniere ni estos bona ano de la gastigserva komunumeto :)

[interDist]

Miksado/malpersonigado de datenoj

La datumbazo de PS enhavas plurajn informojn kiuj estas/us konsiderataj PII (Persona Identiga Informo) fare de Eŭropuniaj reguloj. Ĉar tiuj ĉi datenoj foje estas kopiataj en aliajn lokojn ol la production datumbazo (ekzemple, al Ido, loke, por testado, ktp), necesas forigi la personajn detalojn, konservante la strukturon. Por tio mi proponas scramble-komandon kiu faru jenajn anstataŭojn:

• Uzantoj
  • salutnomo – hazarda miksaĵo el literoj kaj ciferoj
  • pasvorto – hazarde generita el literoj kaj ciferoj; laŭ tri tipoj (ĉiuj uzantoj de la sama tipo havos saman pasvorton). la komando sciigos la tri elektitajn valorojn.
    • ordinaraj uzantoj: longeco 8
    • landaj organizantoj: longeco 12
    • administrantoj: longeco 16
  • retpoŝtadreso – salutnomo@user.pasportaservo.org, konservante la prefikson INVALID se aperas
• Profiloj
  • persona nomo – el listo de antaŭdifinitaj nomoj, viraj kaj virinaj
  • familia nomo – el listo de antaŭdifinitaj familinomoj
  • naskiĝdato – hazarda dato el la sama jardeko
  • retpoŝtadreso – hazarda-kombinaĵo@spam.pasportaservo.org, konservante la prefikson INVALID se aperas
  • priskribo – hazarda paragrafo
  • profilbildo – el listo de libere haveblaj bildoj, anstataŭo de la enhavo de la fizika bildo laŭ la dosiertipo
• Telefonoj
  • numero – hazarda numero
  • komento – hazarda frazo
• Loĝejo
  • urbo – hazarda kombinaĵo de latinaj literoj
  • proksima urbo – hazarda kombinaĵo de latinaj literoj
  • poŝtkodo – hazarde generita laŭ formato NNNN AA (eble en estonteco, laŭ la formato konformanta al la normo en la koncerna lando)
  • adreso – el listo de antaŭdifinitaj stratnomoj plus hazarda numero
  • pozicio – latitudo kaj longitudo ene de la limoj de la koncerna lando
  • priskribo – hazarda paragrafo
  • mallonga priskribo – hazarda frazo

[interDist]

Tabelo por agordi videbligon por ĉiu datumero

MFP

• bazo: novaj modeloj (agordoj de videbligo) + migradoj
• bazo: UI por la tabelo en profilo/agordoj
  • minimumigitaj CSS kaj JS por bootstrap-toggle
• bazo: konservado de ŝanĝoj
• bazo: kreado de objekto lige kun kreado de datumero
• bazo: forviŝo de objekto lige kun forviŝo de datumero
• efiko: videbligo de datumeroj honorante la agordojn
  • telefonnumeroj
  • publika retpoŝtadreso
  • kunloĝantoj
• sekureco: certigi ke aliro estas disponebla nur al posedanto
• sekureco: certigi ke FormSet ne estas malice modifita
• admin: montrado de la agordoj ĉe ĉiu rilata datumero

Plikapabligoj

• UI taŭgigita por malgrandaj ekranoj (sub 600px)
  ⤑ tro komplikas krei apartan UI; anstataŭe estas montritaj instrukcioj
  por pli facila uzo (77e44f4)
• videbligo de telefonnumeroj al landaj organizantoj ĉe la
  lando-revizia paĝo laŭ la agordoj kaj elekto pri libro/retejo (65988aa)
• videbligo de loĝejoj honorante la agordojn
• en-paĝa forigo de permesitaj uzantoj
• averto pri nefunkcianta retadreso en postman-ŝablono
  (kaj montri la aliajn haveblajn [publikajn] kontaktmanierojn) (67df05c)
• transsendi uzanton al agordoj > privateco post kreo de nova
  datumero, note: “nova ___ aldonita. bv elektu kie ĝi aperu.” (af2efaa)
• enpaĝaj ŝaltiloj sur profilo-redakta paĝo apud la rilataj datumeroj
• admin: modifeblo de la agordoj ĉe ĉiu rilata datumero ?
  ⤑ eblas fari sur la retejo mem, ne plu necesas ŝanĝo en admin (a4ed74c)

[blfpd]

averto pri uzo de kuketoj kaj akcepto de tia uzo.

Ĉu eblas forigi la ŝprucaĵo pri ja kuketoj? Ne estas necesa nek por la uzantaj kuketoj, nek por GA ĉar estas anonimigitaj datumoj. Ni ne uzas marketikajn kuketojn.

[interDist]

averto pri uzo de kuketoj kaj akcepto de tia uzo.

Ĉu eblas forigi la ŝprucaĵo pri ja kuketoj? Ne estas necesa nek por la uzantaj kuketoj, nek por GA ĉar estas anonimigitaj datumoj. Ni ne uzas marketikajn kuketojn.

Fakte estas malfacila demando. Pri uzantaj kuketoj vi tute pravas. Pri GA...

• “All third‑party session and persistent cookies require informed consent.” (http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm)

• “Not all cookies are used in a way that could identify users, but the majority are and will be subject to the GDPR. This includes cookies for analytics, advertising and functional services, such as survey and chat tools.” (https://www.itgovernance.eu/blog/en/how-the-gdpr-affects-cookie-policies)

• “Every user is registered with a unique ID [...] With Google Analytics, one can survey how often any single user has visited the website, what pages they visited, for how long they stayed and how they interacted with the site. [...] According to the GDPR’s definition of personal data described above, the tracking of user behaviour and profiling is only compliant with the EU-regulations when the website obtains prior consent from the visitor” (https://www.cookiebot.com/en/google-analytics-gdpr)

• Tiu ĉi ulo asertas ke se oni uzas nur GA, tiam konsento ne estas necesa: “if Google Analytics is the only thing deploying tracking pixels AND you are not using Google Analytics Advertising features, then you do not require visitor consent” (https://brianclifton.com/blog/2018/04/16/google-analytics-gdpr-and-consent);

• sed alia ulo emfazas ke “if you are collecting User ID or other pseudonymous identifiers, you’ll need to gain consent from the user” (https://www.blastam.com/blog/5-actionable-steps-gdpr-compliance-google-analytics).

• Kaj same GDPR Report opinias ke konsento estas bezonata ĉiuokaze (https://gdpr.report/news/2018/02/01/gdpr-google-analytics-2).

Havas laŭ mi ĝenerale sencon esti afabla kaj informi al niaj uzantoj kaj vizitantoj ke ni spuras ilin, kaj kion ili povas fari por ne esti spuritaj. Ekzemple, spurado entute ne estas aktivigita ĝis kiam oni ne akceptas la diritan en la ŝprucaĵo: https://github.com/tejoesperanto/pasportaservo/blob/master/core/templates/core/snippets/google_analytics.html#L45.

[blfpd]

Do ĉu eblas forigi ambaŭ?

[interDist]

Do ĉu eblas forigi ambaŭ?

➕ ➡️ TODO