Sag mal, gibt es irgendeine Möglichkeit die Kontaktliste "automatisch" oder so einfach wie möglich nach Kontakten zu durchforsten, die seit x Monaten keinerlei Aktivitäten mehr gezeigt haben um diese dann zu löschen bzw. entfolgen?
Mir fällt da nur ein Hack in der Datenbank ein. Nur wird dies vermutlich nicht empfehlenswert sein?
!Friendica Support
Mir fällt da nur ein Hack in der Datenbank ein. Nur wird dies vermutlich nicht empfehlenswert sein?
!Friendica Support
OldKid ⁂
•Michael Vogel
•OldKid ⁂
•Michael Vogel
•Tuxi ⁂
•Könnte mann denn dieses Feld bei /contact anzeigen lassen?
OldKid ⁂
•Michael Vogel
•Etwas anderes wären Daten wie das letzte Login-Datum, da dies nicht von außen erkennbar ist.
Ich würde da aber gerne mal wissen, wie das andere Leute sehen, die sich intensiv mit Datenschutz beschäftigen.
OldKid ⁂
•Ich kann nur aus den Erfahrungen als Datenschutzbeauftragter in unserem Verein meine Erfahrungen einbringen und da weiß ich, dass ich selbst von öffentlich zugänglichen Daten keine Datenbank anlegen darf und diese anderen Nutzer zur Verfügung stellen darf. Und Daten die ich vom Verein sammel darf ich auch nicht ohne weiteres weiter geben, es sei denn ich habe das in der Datenschutzerklärung, der jeder zustimmen muss, bekannt gemacht.
Klar ist das die Daten notwendig sind für den Betrieb einer Instanz aber ob die gesammelte Weitergabe an die User das auch abdecken würde wäre die spannende Frage.
hackbyte (friendica) 13HB1
•Ein einfacher scan darauf ob jemand länger als xyz nicht mehr im posteingang zu sehen war berührt keinerlei fremddaten.
OldKid ⁂
•Wenn wir die Daten dann aber in die Kontenverzeichnisse des Users weiterleiten damit diese sehen können, wann jemand zuletzt aktiv etwas gepostet hat, sind das personenbezogene Daten. Die sich ja klar einer Person/Account zuordnen lassen und in diesem Fall nichts mehr mit dem Betrieb der Instanz zu tun haben, weil die Instanz läuft ja, auch wenn diese Daten nicht im Kontaktverzeichnis des User einsehbar sind. Das Zugänglichmachen dieser Daten ist nicht zwingend notwendig für den Betrieb einer Instanz.
Aber wie gesagt ist das nur meine persönliche Meinung, da wäre es spannende was ein Rechtsanwalt dazu sagt, der sich damit wirklich auskennt. Vielleicht kann uns @Thomas Schwenke einen Tipp dazu geben.
Michael Vogel
•Tuxi ⁂
•Für mich wäre das okay, aber würde man da nicht die User auf der Instanz bevormunden? 🤔
OldKid ⁂
•Tuxi ⁂
•Dann wäre dies eine super Lösung.
Michael Vogel
•Tuxi ⁂
•Das kann man ja jetzt auch nicht, wenn ich über die Kontaktliste einen User entfolge.
hackbyte (friendica) 13HB1
•hackbyte (friendica) 13HB1
•Ich stelle mir das als _user_ an dieser stelle relativ einfach vor. Ich habe einen social graph (aka meine kontakte) und lasse den von einer automatik bearbeiten, der alle meine kontakte überprüft wann diese zuletzt - öffentlich / oder für mich zugänglich - gepostet haben. Das sind an der stelle bereits lokal vorhandene daten - soweit nicht aus den caches bereits pruned (in dem fall würde im angezeigten zeitraum schlicht garkein post mehr auftauchen).
Das ich dann entscheide das ebendiese automatik auch kontakte aus meinem sozial graph löschen darf, ob passiv oder mit remote message das entfolgt wurde, tangiert _IMHO_ ersteinmal keine fremden daten sondern primär meinen social graph in der db auf der loka... show more
Ich stelle mir das als _user_ an dieser stelle relativ einfach vor. Ich habe einen social graph (aka meine kontakte) und lasse den von einer automatik bearbeiten, der alle meine kontakte überprüft wann diese zuletzt - öffentlich / oder für mich zugänglich - gepostet haben. Das sind an der stelle bereits lokal vorhandene daten - soweit nicht aus den caches bereits pruned (in dem fall würde im angezeigten zeitraum schlicht garkein post mehr auftauchen).
Das ich dann entscheide das ebendiese automatik auch kontakte aus meinem sozial graph löschen darf, ob passiv oder mit remote message das entfolgt wurde, tangiert _IMHO_ ersteinmal keine fremden daten sondern primär meinen social graph in der db auf der lokalen instanz.
Der nächste punkt ist dann, ob ich darüber ggf eine benachrichtigung erhalten kann.
Auch hier wiederrum, aus meiner sicht als user ein klares ja.
Es ist an der stelle relativ gleich, ob ich eine benachrichtigung erhalte um zuzustimmen das account xy aus meinem social graph entfernt wird oder ob ich retrospektiv darüber eine nachricht erhalte..
In beiden fällen wiederrum, sind ausschliesslich lokale daten involviert, die - auch wenn sie aus öffentlichen und halböffentlichen quellen - mir persönlich primär bereits zugänglich waren, weil das die funktionsgrundlage der webseite ist (also auch durch AGB usw abgeklärt sein muss bereits).
In allen diesen konstellationen, ist es _nicht_ der fall, das die isntanz daten aus dem web scraped um sie dann öffentlich weiterzugeben.
Es werden lokale daten aus dem privaten profil eines nutzers und der damit verbundenen accounts ausgewertet und für lokale handlungen verwendet.
Ob ggf ein "unsubscribe" an remote dabei tangiert wird weiss ich ggf nicht... Aber ich weiss auch genausowenig obs das im #fediverse generell eigentlich gibt. ;)
-----
Ich bin nicht völlig unerfahren in sachen SysOp/Admin/Host. Hab aber nie im #fediverse irgendwas gehostet... Dennoch hab ich mich immer bemüht einen sinnvollen überblick zu haben was geht und was eher nicht..... ccc und piraten nähe bleibt halt nicht aus ;)
Matthias ⁂
•Du musst eine Zweckbindung für die Verwendung beschreiben. Der Nutzende muss der systematischen Erhebung der Daten für diesen Zweck u.U. widersprechen können. Und die Daten müssen sicher gelöscht werden können.
Es ist ein Unterschied, ob ich die Daten manuell erheben kann, weil sie in den Logs enthalten sind (dafür gibt es ja einen technisch, logischen Grund, der daran gebunden ist), oder sie für einen anderen Zweck systematisch erhebe
Tuxi ⁂
•Bist Du da sicher, dass das Daten im Sinne von DSGVO sind? 🤔
OldKid ⁂
•hackbyte (friendica) 13HB1
•Das argument das du damit öffentliche daten scrapen würdest zieht da nicht.
Matthias ⁂
•Die Daten sind mit einen User verbunden, damit sind sie personenbezogen.