The broken dsgvo update deletes this feature. please add it back. it's not less useful because of dsgvo.
while the not dsgvo compliant patch can be hacked by changing the translationfiles easy, the deactivation of the feature needs editing the sourcecode. who don't want to make it mandtory just should config it not mandatory.
the dsgvo problems still aren't addressed. it's not possible to provide mapservers in 2 days.
maybe it would be a workaround to make sended respondd data more configurable. so contactfield could stay on nodes statuspage only.
You are mixing two very different issues in the same ticket: The contact field, and the legality of data aggregation on map servers...
1) As I understand it, Freifunk tries to support data protection. As such, it seems contradictory to enfore providing personal data. Note that you can easily fork the gluon-config-mode-contact-info package under a different name in a site module, if you really want to force users to provide the info, but I don't think it's something that Gluon should support out-of-the-box.
2) I have a few questions/suggestions. It would be great if only people with a professional background in data protection law attempted to answer.
Hi
gluon is a framework. dataproctection is important, but also with dataprotection we are allowed to user data as permitted and needed. It's the decision of the community, if they think it is necessary to be able to contact the nodeowner somehow. The feature was added, because this makes sense. No community is forced to make contact info mandatory. but now, because of a single community decision every community is forced to remove this feature. why? this doesn't match to "baukastenprinzip". Why should I hack it back and maintain an own fork, because someone else doesn't want it? It was configurable.
Entschulidge bitte dass ich auf Deutsch schreibe, in diesem Kontext ist mein Englisch allerdings zu unpräzise. Mein Professioneller Hintergrund ist lediglich, dass ich für die Umsetzung bei uns im Betrieb zuständig bin, aber ich habe mich (leider) sehr intensiv auseinandersetzen müssen. Deshalb versuche ich Deine Fragen mal mit den entsprechenden Rechtsnormen zu beantworen. Evtl. hilft Dir das ja bereits Klarheit zu erlangen.
Die Frage ist nicht wie Daten verarbeitet werden, sondern wer Daten verarbeitet. Persönliche Daten zu verarbeiten ist Verboten mit Erlaubnisvorbehalt. Welche Möglichkeiten es gibt, dass die Verarbeitung erlaubt ist findest Du in Art 6. Für uns sind (1) a) Die betroffene Person hat ihre Einwilligung zu der Verarbeitung der sie betreffenden personenbezogenen Daten für einen oder mehrere bestimmte Zecke gegeben sowie Art. 6 (1) f) die Verarbeitung ist zur Wharung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich [...]
Weiter ist für uns relevant, wann die DSGVO überhaupt Anwendung findet:
Hier regelt Art 2 (2) c) Diese Verordnung findet keine Anwendung auf die Verarbeitung personenbezogener Daten durch natürliche Perosnen zur Ausübung ausschließlich persönlicher oder familiärer Tätigkeiten.
Man kann verschieden Argumentieren, aber im Ergebnis bleibt es bei "Auf der Statuspage und im Respondd darf gemacht werden was man will".
z.B.:
Anders ist es bei Mapservern. Hier ist der Nutzer selbst nicht der Datenverarbeiter, sondern der Betreiber des Mapservers ist es. Ihn als Betreiber trifft die Pflicht die Einwilligung zur Datenverarbeitung einzuholen und ggf. auch nachweisen zu können, dass man sie eingeholt hat. Die DSGVO greift. Informationspflichten, Löschpflichten, Dokumentationspflichten. Ist aber auch sehr simpel alles zu erfüllen. Vor jeder Datenverarbeitung wird geprüft ob die Einwilligung vorliegt (ist der Haken gesetzt) und wenn nicht wird der Datensatz gelöscht. Gibt es keinen neuen Datensatz mit aktiver Einwilligung werden die Daten nach 14 Tagen gelöscht. Und schon sind wir rechtskonform.
Die Lösung über den Downloadserver ist nicht geeignet.
Der Datenverarbeiter muss nachweisen und sicherstellen, dass er nur Daten nutzt für die eine Einwilligung vorliegt. Wie soll er das hier tun? Das Image kann sonstwer runtergeladen haben. Es steht unter freier Lizenz. Oft gibt es gar vorgeflashte Geräte bei Communties. Ich sehe nicht wie man das ordentlich nachweisen will. Ein weiterer Nachteil ist, dass man die Nutzung der Daten auf die Community selbst einschränkt. Es darf dann nur der Downloadanbieter verarbeiten. Denn nur der hat die Einwilligung (wie gesagt: Wie willst Du die Einwilligung überprüfen und nachweisen? Wie willst Du realisieren dass sie widerrufen werden kann?). Von vorhandenen Knoten im Netz hast Du überhaupt keine Einwilligung zur Nutzung der Daten. Auch hast Du hier keine Informationspflichten erfüllt.
Warum reicht es nicht auf der Webseite eine Veränderung der Datenschutzerklärung zu benennen?
Die DSGVO Rechte sind: Einwilligung, Recht auf Löschung Recht auf Kopie, Recht auf Auskunft
Es lässt sich einfach umsetzen: Seite mit Erklärung und Einwilligungstext, Haken setzen lassen "ich willige ein". Haken in der Site.conf einen Namen geben lassen, Hakennamen via Respondd verteilen (für Versionstracking unterscheidung nötig welche Erklärung gegeben wurde).
Führt zu: Jeder Netzteilnehmer darf die Respondd Daten zu den Erklärten Zwecken nutzen, weil die Einwilligungserklärung mitgesendet wird. Auf den Mapservern würde man einfach alle Ohne Einwilligung $mindestversion rausfiltern. Recht auf Auskunft und Kopie kann über Link zur nodes.json abgedeckt werden. Recht auf Löschen kann durch entfernen des Hakens automatisiert umgesetzt werden. Sprich: Die Communities haben eigentlich keine Arbeit.
ToDo:
Und schon ist alles erfüllt was erfüllt werden muss. Ohne Funktionalitätsbeschränkung. Ohne Einschränkung der Leute die die Daten nutzen dürfen. Ohne krassen Implementationsaufwand.
Es ist eine rein politische Entscheidung das nicht zu wollen.
Es gibt die Rechtsauffassung wir wären Provider und es würde für uns nicht gelten. Die Ausnahmeregelung im Text bezieht sich ausschließlich auf Vermittlungstätigkeiten bei denen Daten nur weitergeleitet und weder verändert noch gespeichert werden.
Ergänzung zu existierenden Nodes:
Du brauchst die Einwilligung. Information reicht nur dann, wenn man nach 6 f) argumentieren kann. das ist aber hier nicht der Fall.
@A-Kasper: kannst du deine letzten beiden (trotzdem sehr interressanten) posts hier bitte löschen und in dem richtigen issue stattdessen posten? https://github.com/freifunk-gluon/gluon/issues/1360
In diesem Issue hier (1403) geht es nur darum, ob das Kontakt-Feld wieder mandatory gemacht wird (nicht, ob neue Felder hinzugefügt werden).
@rubo77 These were answers to neoraiders questions in this issue.
The question if it should be mandatory could regulary be answered as: It should be mandatory by default:
http://www.picopeer.net/PPA-de.shtml
PPA Art. 2:
"The owner agrees to be contactable and will provide at least an email adress"
This rule is not discussable for communitys.
(thx adorfer for this hint in freifunkforum)
ToDo:
Gluon muss erlauben einen legaltext einzufügen und den hakennamen in respondd senden
Dienste müssen respondd haken auswerten
Vollkommen unnötig.
Andersherum wird ein Schuh draus. Wer ab dem 25. nicht möchte, dass sein Knoten Daten übermittelt (mal ganz abgesehen davon, dass fraglich ist, ob diese wirklich personenbezogen sind), kann entweder seinen Knoten außer Betrieb setzen, oder sich eine Firmware ohne respondd bauen. Freifunk funktioniert prinzipiell auch ohne Karte und respondd.
Bei Bestandsroutern sehe ich auch kein wirkliches Problem. Es war schon immer so, dass alles was der Knoten per respondd liefert, inkl. Kontaktfeldinhalt, für potentiell jeden öffentlich zugänglich ist. Da ist sich auch jeder Knotenbetreiber darüber im Klaren.
Du sagst es selbst:
Durch das eigene Aufsetzen eines Dienstes, der die Kontaktdaten ins Netz stellt und mitteilt willigt der Mensch durch schlüssiges Handeln implizit in die eigene Verarbeitung durch seine Datenverarbeitungsanlage, sprich Router ein.
Was ist daran so schwer: DU BRAUCHST EINE RECHTSGRUNDLAGE WENN DU DATEN VERARBEITEST.
Diese ist die Einwilligung.
Nein Du darfst als verarbeiter nicht beliebig Daten verarbeiten. Es ist Deine Pflicht. Niemand sonst ist verantwortlich. Nur Du als Datenverarbeiter. RTFM
@A-Kasper:
PPA Art. 2:
"The owner agrees to be contactable and will provide at least an email adress"This rule is not discussable for communitys.
I think it is important to understand why this rule was written in the PPA. My understanding of this rule is that back then it was necessary to actually perform the PPA. That is to establish a peering it was necessary to communicate first. But also it was necessary to have contact information to maintain the connection, to be able to fix arising issues together.
I think both are not necessary requirements anymore these days. The peering is always open thanks to dynamic mesh routing protocols, open source firmwares and open documentation. So there is no need to contact prior establishing a pico-peering. And for issues arising we have an autoupdater in Gluon to fix issues at any time.
I agree that a contact field is highly recommended to foster the community spirit and social exchange. And often it is way easier to fix potential issues when there is a contact address. However, I'm not sure whether it should still be seen as a hard requirement these days.
It would probably be best to ask the founders of the PPA about their intentions of this rule. I think the intentions behind a rule are ultimately more important than the rule itself.
PS: I can recommend reading "Free Culture" by Lawrence Lessig to anyone who is interested. There he describes beautifully the importance of the _intention_ of a rule and how this was their main argument in the Eldrid vs. Ashcroft case he was involved with.
I don't want to take part on these "we don't need to follow laws" discussions. It think everything is said. Our Map stays offline until a DSGVO compliant solution is found.
Just to avoid confusion: My last comments were regarding PPA rules, not DSGVO. So had nothing to do with laws, I did not say that we should disregard DSGVO.
Die Interpretationen der Rechtslage und Einordnung sollte zumindest die Basic-Facts des Sachverhaltes im Auge behalten. Und diese sind erheblich anderes gelagert als bei der Datenverarbeitung im Unternehmen:
Der Knotenbetreiber ist der jenige, der seine Daten mit seinem Knoten
a. im GUI / Statuspage
b. im Respondd
selbst und absolut unzweifelhaft willentlich öffentlich macht.
Wir verarbeiten also auf dem Karten-Server / respondd öffentlich zugängliche Daten.
Diese Daten werden nicht dauerhaft gespeichert, sondern lediglich die letzten erfolgreichen Datenabrufe eines Knotens sind gespeichert.
Wir regeln: Dein Recht auf Widerruf der Datenerhebung wird ausgeübt durch dein aktives Abschalten deines Knotens.
Einen Anspruch auf "Löschung" kann auf keine andere Weise sinnvoll nachgekommen werden, denn nicht nur unser KArten-Server verarbeite die Daten, sondern auch u.U. viele andere z.B. freifunk-karte.de .
Dem Knotenbetreiber muss klar sein: Die Weitergabe unserer Community-Daten z.B. an andere Kartenserver ist weder durch die Community noch den Knotenbetreiber einschränkbar.
Fazit und Rat an den Betreiber: "Starte keinen Knoten, wenn das für dich ein Problem ist."
Insofern:
Niemand hier plädiert zum ignorieren geltenden Rechts. Die legitime Frage darf allerding sein, "tangiert uns dieser oder jener Absatz in dem Zusammenhang überhaupt?"
Könntest Du noch benennen wo Du in den Rechtsnormen findest, dass die Quelle der Daten (öffentlich) erheblich dafür ist ob Du eine Einwilligung brauchst oder nicht? Findest Du das im Anwendungsbereich? Findest Du das in Art 6? Sonstwo? Nach meiner Erkenntnis deckt sich diese Sichtweise nicht mit der Rechtsnorm. Wenn doch: Wo steht das?
@A-Kasper wichtig ist in welchem Herrschaftsbereich hier Daten eingetragen/"verarbeitet" werden. da sich der Router beim Aufsteller befindet bzw. von diesem eingerichtet/verwaltet wird ist zumindest dieser Fall analog zum Einrichten einer persönlichen Webseite auf einem privaten Webserver zu sehen. und dort gilt - deine Daten deine Verantwortung.
der bereits vorhandene hinweis in
https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-config-mode-contact-info/i18n/de.po
erklärt ausreichend was mit dieser email adresse im zweifel passiert.
da dieses Ticket "make contact field mandatory again" heisst plädiere ich für eine Ansage von @NeoRaider zu diesem Thema und das dann entsprechend abzuschliessen.
Für DSGVO Bedenken können wir jederzeit ein ordentlich benamstes Ticket aufmachen. ich persönlich habe momentan keine.
..ede
On 25.05.2018 15:13, A.Kasper wrote:
@rubo77 https://github.com/rubo77 These were answers to neoraiders questions in this issue.
The question if it should be mandatory could regulary be answered as: It should be mandatory by default:
http://www.picopeer.net/PPA-de.shtmlPPA Art. 2:
"The owner agrees to be contactable and will provide at least an email adress"This rule is not discussable for communitys.
(thx adorfer for this hint in freifunkforum)
PPA Preamble states as well
"This document is an attempt to connect those network islands ..."
. it's an attempt, a suggestion, no law. it can be applied voluntarily and needs to be respected of course if you mesh w/ a network that applies it.
gluon can be used as well out of the freifunk context, so at least mandatoriness should be configurable.
also i'd really like to know why "This rule is not discussable for communitys". as you'd (@A-Kasper) say - where is that written down? i know that ffrl insists on it, when their exit is used, but saying eg. a community provides it's own exit it can of course omit the need for a contact.
..ede
@A-Kasper: Mit deiner Rechtsauffassung wäre die Suchmaschine tot. Hab nie gehört, dass Google oder irgend ein anderer Besucher jetzt meine explizite Zustimmung braucht um mein Impressum auf meiner privaten Seite zu "sichten", sich auszudrucken, zu archivieren oder sonst wie zu "verarbeiten".
... Ich denke auch, das Thema ist jetzt durch.
Das PPA ist unsere Basis. Wer die nicht akzeptiert, DARF unsere Software und die Leistungen unserer Communities überhaupt nicht in Anspruch nehmen. Da gibt es absolut nichts zu diskutieren.
Wer gluon für was anderes benutzt oder benutzen möchte, kann die eigenen Vorstellungen ja gerne in seine eigene Firmware rein patchen.
@edeso Es geht doch nicht um die Daten im Router. Da bin ich völlig bei Dir. Es geht darum, dass es gerade kein geeignetes Verfahren gibt die Daten auf einem Mapserver oder für andere Dienste zu verwenden.
Kennst du eine Community ohne Map? Ich nicht.
Evtl. sollte man einfach mal ein paar Rechte nach DSGVO gegenüber manchen Communities geltend machen damit sie verstehen, dass sie so wie sie es gerade lösen wollen nicht in der Lage sind diesen nachzukommen. Einfach mal anfragen wo die eigene Einwilligung ist und wann sie gegeben wurde, bzw. auf welcher Rechtsgrundlage die Daten sonst verwendet werden. Dann werden sie es angeben müssen. Wäre total bescheuert und destruktiv, aber ich frage mich gerade ernsthaft wie man erreichen kann, dass hier vom Bauchgefühlgeschwätz zu mit Rechtsnormen untermauerten Rechtsmeinungen gekommen wird. Wenn eine solche Anfrage kommt muss jeder in der Lage sein sie zu beantworten. Ich sehe gerade nicht wie man das machen will. Kann ja mal wer zum Spaß durchgehen. Hier meine virtuelle Anfrage:
Welche Daten von mir werden auf Servern der Freifunks-Kleinjuristerei verarbeitet?
Zu welchem Zweck wurden die jeweiligen Daten verarbeitet?
Auf welcher Rechtsgrundlage werden die Daten verarbeitet (Siehe DSGVO Art 13 (1) c) und Art 14 (1) c))
Ich habe keine Einwilligung zu irgendeiner Verarbeitung meiner Daten bei Ihnen gegeben. Sollten Sie anderer Meinung sein bitte ich darum meine Einwilligung zu belegen. Vielen Dank.
On 25.05.2018 15:36, Heinz Schmitz wrote:
Das PPA ist unsere Basis. Wer die nicht akzeptiert, /DARF/ unsere Software und die Leistungen unserer Communities überhaupt nicht in Anspruch nehmen. Da gibt es absolut nichts zu diskutieren.
bei den Communities mag das stimmen. die Software allerdings is open source and an keinerlei nutzungbedingungen gebunden. die daraus erstellten Firmwares wiederum, sollten dann so gebaut sein, wie die Community das für richtig hält, mit oder ohne Kontakt, je nach PPA-Nutzung.
nur zur Klarstellung.. ede
On 25.05.2018 15:39, A.Kasper wrote:
@edeso https://github.com/edeso Es geht doch nicht um die Daten im Router. Da bin ich völlig bei Dir. Es geht darum, dass es gerade kein geeignetes Verfahren gibt die Daten auf einem Mapserver oder für andere Dienste zu verwenden.
Kennst du eine Community ohne Map? Ich nicht.
versteh ich. aber hat dann nichts mehr mit dem ticket topic zu tun oder wie Neo schon am anfang schrieb
"You are mixing two very different issues in the same ticket: The contact field, and the legality of data aggregation on map servers..."
. wie gesagt zeit für ein neues ticket und kontrollierte herangehensweise. welche daten werden erhoben, sind diese wirklich personenbezogen, werden sie für das netzwerk wirklich benötigt oder kann man da sparen?
die email adresse ist ausdiskutiert, weil privat gehostet und es bleibt nur die frage mandatory per default an/aus, was am ende latte ist, da jede Community das bauen kann wie sie lustich ist.
..ede
@A-Kasper : Suche bei Google mal einfach nach deiner Mailadresse oder gerne auch Telefonnummer und im Falle eines Treffers, stelle deine Anfrage einfach direkt an Google und die Online-Telefonbücher.
Vergiss aber nicht zu fragen, wem die denn jetzt ohne dein Einverständnis die Suchergebnisse auch schon widerrechtlich gezeigt haben und verlange, dass die, denen das Ergebnis gezeigt wurde, auch umgehend deinem Löschungsanspruch ebenfalls nachzukommen haben.
Das Ergebnis und die Antworten werden wir gerne hier würdigen.
Könnt ihr nicht mal einen Datenschutzbeauftragten fragen? Die beraten nämlich auch.
Am 25.05.2018 um 15:52 schrieb Heinz Schmitz notifications@github.com:
@A-Kasper : Suche bei Google mal einfach nach deiner Mailadresse oder gerne auch Telefonnummer und im Falle eines Treffers, stelle deine Anfrage einfach direkt an Google und die Online-Telefonbücher.
Vergiss aber nicht zu fragen, wem die denn jetzt ohne dein Einverständnis die Suchergebnisse auch schon widerrechtlich gezeigt haben und verlange, dass die, denen das Ergebnis gezeigt wurde, auch umgehend deinem Löschungsanspruch ebenfalls nachzukommen haben.Das Ergebnis und die Antworten werden wir gerne hier würdigen.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Meine Antwort:
Vielen Dank, für Ihre Anfrage. Leider können wir anhand der von Ihnen zur Verfügung gestellten Daten keinen Bezug zu den von uns gespeicherten Daten herstellen. Bitte übersenden Sie und ausreichend Daten, um sie eindeutig identifizieren und die hier gespreicherten Daten zweifelsfrei Ihnen zuordnen zu können.
Mit freundlichen Grüßen
Thomas Arend
Am 25. Mai 2018 15:39:59 MESZ schrieb "A.Kasper" notifications@github.com:
@edeso Es geht doch nicht um die Daten im Router. Da bin ich völlig bei
Dir. Es geht darum, dass es gerade kein geeignetes Verfahren gibt die
Daten auf einem Mapserver oder für andere Dienste zu verwenden.
Kennst du eine Community ohne Map? Ich nicht.
Evtl. sollte man einfach mal ein paar Rechte nach DSGVO gegenüber
manchen Communities geltend machen damit sie verstehen, dass sie so wie
sie es gerade lösen wollen nicht in der Lage sind diesen nachzukommen.
Einfach mal anfragen wo die eigene Einwilligung ist und wann sie
gegeben wurde, bzw. auf welcher Rechtsgrundlage die Daten sonst
verwendet werden. Dann werden sie es angeben müssen. Wäre total
bescheuert und destruktiv, aber ich frage mich gerade ernsthaft wie man
erreichen kann, dass hier vom Bauchgefühlgeschwätz zu mit Rechtsnormen
untermauerten Rechtsmeinungen gekommen wird. Wenn eine solche Anfrage
kommt muss jeder in der Lage sein sie zu beantworten. Ich sehe gerade
nicht wie man das machen will. Kann ja mal wer zum Spaß durchgehen.
Hier meine virtuelle Anfrage:Welche Daten von mir werden auf Servern der Freifunks-Kleinjuristerei
verarbeitet?
Zu welchem Zweck wurden die jeweiligen Daten verarbeitet?
Auf welcher Rechtsgrundlage werden die Daten verarbeitet (Siehe DSGVO
Art 13 (1) c) und Art 14 (1) c))
Ich habe keine Einwilligung zu irgendeiner Verarbeitung meiner Daten
bei Ihnen gegeben. Sollten Sie anderer Meinung sein bitte ich darum
meine Einwilligung zu belegen. Vielen Dank.--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/freifunk-gluon/gluon/issues/1403#issuecomment-392060866
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Coming back to the original issue title, the Freifunk Memorandum of Understanding says:
The disclosure of contact information as well as coordinates on the map are optional.
https://github.com/freifunk/MoU/blob/master/FreifunkMemorandumofUnderstanding_en.md#technical-principles
If someone needs the contact information to be mandatory for a non-Freifunk network then I'd suggest to open a new ticket with an according description.
If someone does not like the contact information being optional in Freifunk networks then I'd suggest opening and discussing a ticket on the MoU repository first.
As already mentioned, the ppa requieres a contact. (this could be everything, but it has to be the ability to contact someone.
gluon is still not dsgvo compliant. the team told here, that everything is fine and permission is not needed etc. same time you delete this feature. why?
Gluon was a framework. Now it seems like gluon tries to tell communities how to deal with their networks and deletes useful and used config parameters. Same time using mapservers is blocked until someone writes a customer package. Most communities decided to go on with silly workarounds because there will nothing happen to them. To me dealing that way with privacy is no option. I'm very frustraded about the way gluon goes now...
our map is still offline, because it's not possible to use it anymore until we hack something ourself.
there won't be any more fw updates until we are able to make the contact mandatory again.
I'll try to ask a programmer to fix this in a fork, but we don't have the capacity and money to maintain our own fork. so this is just a step until we found another firmware or shutdown our network.
i'll not change our policies because of the gluon maintainers (the deleted feature was configurable, and there is absolutly no need to delete thes feature just because some communities didn't want to use it.) I'll also not offer services that are not striktly legal. For me Freifunk is Ehrenamt, and I'll simply just stop it instead of following this way. No, I'll not force someone to do something, but I want to inform that there are also responsible people in communities who are not shitting on legal stuff and that this leads to shutdowns.
@A-Kasper:
As already mentioned, the ppa requieres a contact. (this could be everything, but it has to be the ability to contact someone.
And I noted that the MoU requires the contact mail address to be optional. So how do we solve this now?
@A-Kasper, @T-X is there a technical reason not to reimplement the optional mandatory setting? my take would be to just reimplement it with a default off setting and leave it to the communities to enable it if wanted/needed.
@A-Kasper again "gluon is still not dsgvo compliant." is not correct. it is hosting the contact info within the realm of the user who is naturally not obligated to sign a agreement with himself. maps and other services reusing the data are a different matter and should be discussed wherever they are developed.
..ede
@A-Kaspar: Btw., I also like your idea of having a configuration option to not send contact information via respondd.
I had asked in the Gluon IRC channel, there were some back and forth discussions and there was at least one person noting that they make use of it in scripts (and would need contact information via respondd) in their community. But if it is configurable via site.conf this then seems like a useful option to me.
Could you make an extra ticket for that? (or ideally, a patch/pull-request)
@edeso: Sounds good to me, too. But if it were just a reimplementation then we should probably list / document a few more of the pros and cons of (un)setting this option. E.g. mandatory(on)->breaks MoU, mandatory(off)->breaks PPA. And mandatory(on) currently breaks DSGVO (if I understood correctly).
@T-X
And I noted that the MoU requires the contact mail address to be optional. So how do we solve this now?
We have had a solution: It was configurable. I would like to go back to see gluon as framework. Means: Communities can use gluon to fit their needs. With deleting the possibility to make it configurable we left this philosophy. One community decided that other Communities are not allowed to set it mandatory anymore. I could not see why this was needed. That was the main intention of this ticket. Putting it back. Who don't wants it don't uses it.
In my mind (but I'm not maintainer, it's just a feedback) gluon should try to fit the needs. It should try to make it possible to ask for contact information but it should not decide if it is needed via implementation.
Just packages or config lines. Who wants it uses it, who don't want it don't use it.
Mandatory on don't breaks DSGVO, because it's needed data and datenverarbeiter is only the nodeowner himself.
contactinfo and also ip usage on mapserver needs permission. Same as above: If a community don't want to stay legal.. it's no problem for me. I'm not their daddy. But it should be possible. As shown above it's not as hard to fullfill the needs of DSGVO. Compared to all the things we have got the shown way should not be sooo complicated to implement. It's just a text with a hook and a hookname.
@edeso you are right: Mapserver is not compliant. But can you tell a community without mapserver?
how we deal with contact yes/now stuff:
We have it mandatory, but ask for contact not mail. It's not important for us how we can reach the person. We had discussed the cons and saw, that everybody is able to handle them by making an anonymous extra mailadress or something. also there is a possibility to use the contactmail of freifunk bochum and tell the verein who is responsible for the node with contact (so it's non public)
@T-X just reread the MoU and it states
"As Freifunkers we commit to the following existing documents:
Pico Peering Agreement ..."
&
"The disclosure of contact information as well as coordinates on the map are optional."
so actually as freifunk is concerned the field should be able to be switched mandatory (because of the PPA), but the additionally a "I agree the following data to be used.. " for coordinates and contact info would be needed to conform to the current MoU.
keeping in mind that there is at least a theoretical community using gluon not conforming to freifunk ideals, i'd rather not hard code the need for the contact info but make it switchable, as it was already.
something along those lines.. ede
@edeso you are right: Mapserver is not compliant. But can you tell a community without mapserver?
@A-Kasper it's not the communities running mapserver. it's individuals within them who are eventually responsible because it runs in their name. it is their personal responsibility to urge the maintainers to modify the software (or do it themselves) to be GDPR (deu. DSGVO) compliant. again, that should be discussed there, not here.
without getting to detailled, my vote at the moment would be, that a map server delivers publicly available data. as long as this is not cached forever, but deleted whenever a node disappeares or updated when the values are changed they are close to what a search engine does these days. hence, no violation of GDPR in sight.
And mandatory(on) currently breaks DSGVO (if I understood correctly).
@T-X wrt. the above. no, GDPR (deu. DSGVO) explicitely states, that only data not needed to provide the service is not allowed to made mandatory.
if the freifunk network providers agree, they need a contact info to reach node owners in case of rule violations or activity hurting the network reliability than this is a legitimate reason according to GDPR article 4 sentence 4 .
..ede
as no Gluon maintainer stepped up for this request until now, i consider it rejected
Most helpful comment
@A-Kasper wichtig ist in welchem Herrschaftsbereich hier Daten eingetragen/"verarbeitet" werden. da sich der Router beim Aufsteller befindet bzw. von diesem eingerichtet/verwaltet wird ist zumindest dieser Fall analog zum Einrichten einer persönlichen Webseite auf einem privaten Webserver zu sehen. und dort gilt - deine Daten deine Verantwortung.
der bereits vorhandene hinweis in
https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-config-mode-contact-info/i18n/de.po
erklärt ausreichend was mit dieser email adresse im zweifel passiert.
da dieses Ticket "make contact field mandatory again" heisst plädiere ich für eine Ansage von @NeoRaider zu diesem Thema und das dann entsprechend abzuschliessen.
Für DSGVO Bedenken können wir jederzeit ein ordentlich benamstes Ticket aufmachen. ich persönlich habe momentan keine.
..ede