RFC: Adding Einverständnis zum Datenschutz to configmode

[A-Kasper]

Because many Networks are using maps with nodes.json etc. it is necessary to ask for an Einverständniserklärung zum Datenschutz and inform what is stored where.
For me there are two ways to do this:

1. need to register the node in the community and doing it that way,
   or
2. add an optional Datenschutzerklärungspage to configmode with accepted hook and refuse connecting to mesh and meshvpn as long as its not accepted.

I would like to have the second possibility.

[T-X]

3. Add an explanation regarding what a Freifunk node is (especially: a node contributing to a public(!) network, therefore being publically visible) to your community website. Something people will (and will like to!) read before downloading a firmware.

I think a general explanation would be more helpful than a checkbox with a legal disclaimer which no one will read anyway.

[A-Kasper]

It is not important that someone reads it, or better: it is not our problem if the Box is clicked without reading it. For legal reasons we need to ask to accept the conditions. Else we may not fullfill dsgvo requierements on map-servers.

If there is a legal page in config mode we would be able to realize to inform our users as requiered. There is nothing to hide, so it's easy to inform what is saved where and why and ask to accept. doing this in gluon would be the easiest way.

a general explanation would not be enough. you need to need to accept it with clicking somewhere.

[A-Kasper]

...and you need to care that you don't store data without Permission. So if you ask on a webpage, you'll need to track and register each node and owner and work with whitelists..I see many things why I don't want manual router registration.

[rubo77]

Related: freifunk-kiel/ffki-packages#17
(We put a question to accept the PPA there)

And #909 which is blocked by #1349

[A-Kasper]

yes. something like this. maybe also with respondd module sending the accepted conditions so you could use data on maps etc if allowed and elsewise skip them etc 2018-04-08 17:20 GMT+02:00 Ruben Barkow <[email protected]>:

…

Related: freifunk-kiel/ffki-packages#17 <freifunk-kiel/ffki-packages#17> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1360 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA7Ute7jyQgdlop77uUOLulXFooW8uqks5tmirDgaJpZM4TLTT7> .

[neocturne]

Does is have to be a checkbox, or is a simple text like "By completing the installation of this node, you accept the conditions" with a link sufficient, as it is often done with terms and conditions in online shops?

In any case, @T-X's solution sounds much better: Add the terms and conditions for the GDPR to your website before allowing to download the images. Cluttering the firmware with legal texts is not acceptable in my opinion.

[neocturne]

Also, which information would be covered by the GDPR? There is some basic topology data that must always be available, and that is not personal in nature. AFAICT, the "contact information" and possibly "location" fields are the only data that might be considered personal information.

This is relevant as one of my long-term development goals for Gluon is to remove the config mode as a separate installation step (by default), and make a node start meshing (and sending monitoring data) directly after flashing the image. I don't think there would be any personal data sent in this state, but again, adding the GDPR terms and conditions to the firmware downloads rather than the firmware itself seems more effective to me.

[rubo77]

Should we then add an example to the gluon docs, how the GDPR terms have to be implemented on the download page to be compliant?

[rotanid]

although my opinion is that the GDPR aren't of much relevance to "us" and even if it would be, i doubt that the regulatory body has the manpower to care about us.
that said, adding a note to a download page wouldn't be sufficient as it doesn't cover direct link downloads and especially the devices that are already flashed.

[A-Kasper]

you need to proof, that you were allowed to store. it's not possible if you don't register each router, if the router itself doesn't cover this. I don't like this legal stuff, but I don't see any good alternatives. It is not enough to show a text. you really need to set a hook or something. I think this should be a somehow easy package. Show all Information from a special config file, each set has a text (html allowed) and a hook with configurable name. And Hooktext. The Hookname and value is sended via respondd. the services can use the data they are allowed to use.

[rotanid]

again, if you really want to go down this road, that checkbox isn't enough, too, as it doesn't cover all the data already out there on the currently running nodes.

[belzebub40k]

Do we really need a checkbox to accept GDPR? None of the data a user can provide is required to run a node. If a node owner doesn't want his/her data to be processed he/she can simple erase the fields. Second we can not guarantee that the data is no longer used after opting-out because it was more or less publicly available and could have been requested by any mesh participant.

[A-Kasper]

We are not allowed to use the data without permission. If we want it or not. Routers without this box would not send the hook. The map could filter them out bzw. filter out Personenbezogene Daten like contact. this would be community choice. Other way could be to not even sent contact data if the hook is missing. I'm really open for other concepts, but we need a solution. To me this is a very simple way. Another Idea would be to stop sending contactinfo completely. this way we would not use personenbezogene daten if i don't miss something relevant. they could be stored/viewed from node only. Than it should be enough to inform that this information could be accessed via web. Don't know what is best, but let's discuss and find a way to handle this, because we will need it.

[A-Kasper]

I don't see how you would realize it via download page. How can you show, that you where allowed to use the data from a specific router? You don't got a tracking between downloads and devices and you don't got a way to handle data from already rolled out routers. I don't see how this could work. How can you prevent using data without permission?

[A-Kasper]

belzebub40k we don't need to proof that nobody use it without permission. we need to proof that we habe got the permission. that is the idea. marking in respondd if the data is allowed to be used outside of the own router. with this model we could keep data open for every developer.

[belzebub40k]

Ok, lets assume a node owner removes his/her personal data from the config-mode. In my opinion the only reason for him/her to do so is that he/she doesn't want the data to be used anymore. Once such a change is recognized by any service that is collecting respondd/alfred data it should purge this information from its database. To make this more transparent it should be mentioned in the config-mode. If this is done I don't see a violation of the GDPR.

[A-Kasper]

You need the permission to use and store it and you have to explain what is done with this data. if someone uses contact information, you'll need a permission to store and use it in different services like maps and apps.

I don't understand whats wrong with the suggested way. Maybe the problem is that it is not clear to everyone what is needed to store and use personal data?! I'm responsible for our community and want to handle everything like we have to. A solution not covering this needs is no solution.

Problematic field: contact
Maybe problematic: coordinates

Needed:
Tool to view and ask for permission before using this data. Possibility to match dataset and permission. In short time, because with dsgvo it could be expensive to use data without permission.

We could register nodes to handle this, or we could make the nodes sending permissions. hard way: stopping to use personal data completely

[rotanid]

@A-Kasper please stop repeating the same thing. either you implement something yourself or you have to wait until someone does it.
this is a project of volunteers, you don't have the right to demand anything - you already asked for it multiple times now and more is not really acceptable.

[A-Kasper]

@rotanid It's an RFC how to deal with the problem. I would never demand something. I just want to discuss how this could be solved, and offered a possible concept. I've also asked and answered to other ideas why they don't fit the juristic requirements. Every community has to deal with this until 25.5. I'm just brainstorming about possible ways.

[T-X]

The config mode currently says:

"Please provide your contact information here to allow others to contact you. Note that this information will be visible publicly on the internet together with your node's coordinates."

And as already noted before this information is not required to run a node. So my layman interpretation would be that entering such information would mean permission to those terms.

@A-Kasper: If you still feel uncertain, maybe you could ask at your "Datenschutzbehörde" (in Schleswig-Holstein we would have the Unabhängiges Landeszentrum für Datenschutz for instance) and let us know what they think about it?

[A-Kasper]

Ich antworte auf deutsch, weil diese juristerei mir auf englisch zu kompliziert ist gerade.

• das anzeigen des feldes auf der Statusseite des eigenen Routers halte ich für unproblematisch. Das ist erklärt und hier ist die ff-Community nicht die datenverarbeitende Stelle. Der Router wird vom Routeraufsteller betrieben.
• Das Abfragen, Speichern und Auswerten auf Diensteservern des Freifunks (maps, apps etc.) erfüllt die Vorraussetzungen der dsgvo über die Verarbeitung Personenbezogener Daten.

Daraus resultiert:
Einhaltung der dsgvo ist erforderlich.
Eine komprimierte Fassung was das bedeutet findet ihr hier:
https://blog.hosteurope.de/blog/dsgvo-darauf-sollten-sie-achten/

Ich bin kein Jurist, habe aber Datenschutzrecht an der Uni mit den Juristen belegt und bestanden. Ich halte mich im Thema für kompetent genug sagen zu können, dass es ohne Datenschutzerklärung und Einwilligung nicht geht.

[belzebub40k]

From my point of view we are just collection publicly data the node owner is providing to everyone in the mesh/internet (second only if the node is reachable from outside the mesh). We don't have any contract or whatever with the the owner of the node and he/she never enters any data into systems owned by the community (Verein) thus I don't see why we have any responsibilities. However I couldn't find any details in the numerous summaries of the GDPR regarding the collection of public personal data that proves or disproves my opinion.

[christf]

Auch ich bin kein Jurist. Ob auf einem Freifunknode "personenbezogene Daten" eingegeben werden oder nicht ist schon fraglich.
Selbst wenn das der Fall ist, ist auch fraglich ob irgend etwas verändert werden muss weil nichts in der Datenerhebung aktuell ein Pflichtfeld ist.
Die Daten (seien sie nun personenbezogen oder nicht) werden auf dem MAP-Server gecached und angezeigt. Ob man dabei von einer Verarbeitung sprechen kann ist auch fraglich.
Ob DSGVO hier greift, halte ich so lange für fraglich bis ein Jurist geklärt hat dass sie greift.

Die Idee von @T-X finde ich gut, bei der Datenschutzbehörde anzufragen. Hat das schon mal jemand gemacht? @A-Kasper Du vielleicht?

[mdrenger]

Hi everyone :)

I'm Markus with Freifunk Darmstadt: markus [ät] darmstadt.freifunk.net
disclaimer: IANAL - i am not a lawyer.

However, i do not agree with @A-Kasper assessment that we need to do this to be GDPR compliant.

While i think being transparent about data processing and data publication is a good thing we should do, i don't see map servers as data controller of nodes.json / respondd instances which would require consent from all node operators.

=Nodes
First and foremost we have legally independent freifunk nodes which operate based on pico-peering agreements. There is no contract with freifunk groups or map servers. A person operating a freifunk node is responsible for his/her node and his/her own data controller.
The node operator is also free to choose and run any software on his/her node. It may help to be compatible with the mesh protocol of other nodes, but this is not a requirement.
The node operator may also choose to run freifunk firmware provided by freifunk groups. In this case freifunk groups just offer free software, they are not service providers and therefore not data controllers.

=VPNs
Some nodes connect to some vpn gateway. As this is a telecommunication service, the current german law implementing the eprivacy directive allows us to process data which is needed for connectivity reasons and billing ( § 15 TMG ). As we don't collect or store any additional data and do not require any billing, we also don't require explicit consent.
Please note that a new eprivacy directive is currently discussed in brussels.

=respondd

Some nodes run respondd. Node operators voluntarily provide statistics and data about their node.
You may argue its like an extended version of ICMP and therefore a network service. Or it could be an internet service (TMG) which would require a privacy policy statement according to GDPR and a site notice ( Impressum nach TMG).

=freifunk maps
Map servers are pulling information from the nodes. This can be done by everyone within the network. There can be 0, 1 or a great number of map servers pulling that information.

Map operators are basically a 'mini-google' mining nodes for information. I don't think google requires consent from website owners to collect information (otherwise we would have heard about that).

You could start asking node operators to licence their data under an open data license, if that makes you feel better and you would consider that data worthy of a database copyright. You could integrate that license agreement in the setup page.

=nice to have

freifunk groups could integrate easy explanations into their firmware regarding

• the pico-peering agreement
• the data publishing service respondd
• licensing of respondd data under Open Data Commons Open Database License (ODbL) ( https://opendatacommons.org/licenses/odbl/ )

[MyIgel]

Jup, map server providers are only scraping the data google like but the point is the "Datenverarbeitung und Speicherung" -> Only because you can get the data doesn't mean you have the users permission to do so.
I think that adding more description to the page what could happen with the data (see #1394) and that they will be scraped and adding that the user can request to delete them after mailing to contact@ should be enough.

[rubo77]

The reason why we ask users to fill a mandatory contact field is exactly a situation like this now: We have to ask all users to agree to the changed "Datenschutzerklärung".

This is easily possible now: we can contact all users that added a contact field and ask them to agree. We just have to protocoll the answers and then generate a json file, that includes ids of old nodes, where there was no agreement-response to hide all those nodes private information, where the users didn't respond.

In the config mode we could add an option to agree to the terms in the email message body, that is generated by the link in the reboot page.

[A-Kasper]

But you are not only storing the data of people with info in contact field. How do you manage to filter them out? Whats about other personal data like IP Adresses?
How can this be automatic done? It looks like it needs someone keeping track about permissions and changes. Also about "old" and new routers. If a router was offline for more than $mapexpiretime (in most communities about 2 weeks) and comes back online how do you know you habe the permission? How do you handle all Nodes, where the Permission is not given (in most cases, because of lazyness)? How do you handle this blacklist? How do you want to proof that you have the permission?

There is a really easy solution to stay proof. For me it's very hard to unterstand why so many feedback seems to be against using it.

It would:

• Take care, that only data is used where the permission is given
• Take care, that everybody can revoke the permission everytime and it's done automatically on mapservers
• Take care of nodes entering the network before this enhancement

We need a solution. Soon. Because without we'll need to shutdown our mapservers.

Just add a Texts plus Hooks page, let communities set texts, cbxnames, and cbxstatus and send cbxnames with status via respondd (so never versions etc could be tracked on the serviceside.

It would be possible to use it for:
ppa
dsgvo
any agreement/servicesettiong needed somewhere

I know that some devs have the goal to make gluon configless, but i can't see how this could be reached this would need a noderegistration on serviceside, but how could the nodeowner identify as nodeowner? This doesn't seem to be done until dsgvo is in place

[rubo77]

What is cbx?

And why would you have to shut down map servers? What would be the punishment not?

... As far as I read, it can be max. 2% of your Umsatz... So in our community it would be 0€ 🤣

[adlerweb]

@rubo77 The maximum punishment would be up to 20 Million € or up to 4% of last years worldwide turnover - whichever is higher. So while surely no judge would go to this limit in such cases it's still there...

[mweinelt]

This number is pure fearmongering and would only be applied for repeat-offenders.

A good read is the FAQ by MEP Jan Philipp Albrecht of B90/Greens:
https://www.janalbrecht.eu/2018/05/dsgvo-haeufig-gestellte-fragen-haeufig-verbreitete-mythen/

[rubo77]

Discussion in forum:

https://forum.freifunk.net/t/eu-dsgvo-speichern-der-kontaktdaten/18601/6?u=rubo77

[A-Kasper]

Gluon and Freifunk should respekt law. I don't want to start a discussion if we have to or not and if we could spend punishment fees....
there is no problem in realising a dsgvo compliant ökosystem (gluon + mapserver). The only problem is, that people just don't want it.

cbx is short for checkbox

[csamsel]

I have a feeling that node operators or even Freifunk e.V. are not required to be compliant,

there is no problem in realising a dsgvo compliant ökosystem (gluon + mapserver). The only problem is, that people just don't want it.

BUT i have to agree on this.
Technically it's easy enough to realize, so better safe then sorry.

[A-Kasper]

I have a feeling that node operators or even Freifunk e.V. are not required to be compliant,
The thing with law is, that you have to say why and where you can find this in law.

In Freifunk Forum is the argumentation like "provide privileg" but if you read this in text you'll find out that it doesn't cover any mapserver:

`

(42) Die in dieser Richtlinie hinsichtlich der Verantwortlichkeit festgelegten Ausnahmen decken nur Fälle ab, in denen die Tätigkeit des Anbieters von Diensten der Informationsgesellschaft auf den technischen Vorgang beschränkt ist, ein Kommunikationsnetz zu betreiben und den Zugang zu diesem zu vermitteln, über das von Dritten zur Verfügung gestellte Informationen übermittelt oder zum alleinigen Zweck vorübergehend gespeichert werden, die Übermittlung effizienter zu gestalten. Diese Tätigkeit ist rein technischer, automatischer und passiver Art, was bedeutet, daß der Anbieter eines Dienstes der Informationsgesellschaft weder Kenntnis noch Kontrolle über die weitergeleitete oder gespeicherte Information besitzt.

(43) Ein Diensteanbieter kann die Ausnahmeregelungen für die "reine Durchleitung" und das "Caching" in Anspruch nehmen, wenn er in keiner Weise mit der übermittelten Information in Verbindung steht. Dies bedeutet unter anderem, daß er die von ihm übermittelte Information nicht verändert. Unter diese Anforderung fallen nicht Eingriffe technischer Art im Verlauf der Übermittlung, da sie die Integrität der übermittelten Informationen nicht verändern.

(44) Ein Diensteanbieter, der absichtlich mit einem der Nutzer seines Dienstes zusammenarbeitet, um rechtswidrige Handlungen zu begehen, leistet mehr als "reine Durchleitung" und "Caching" und kann daher den hierfür festgelegten Haftungsausschluß nicht in Anspruch nehmen.

`

[csamsel]

Well, was i really meant was: one should not rely on feelings.
Get a technically solution like the described disclaimer + checkbox to be safe and be done with it.

[christf]

technically it's easy enough to realize

If you save consent you need to save the timestamp. How do you save the current timestamp on a node that does not have a synchronized clock as is the case in config-mode most of the time? If you do not store it on the node, you have to store it on some infrastructure which clearly is outside the scope of gluon.

checkbox to be safe

no law says you have to have a checkbox.

The whole problem with providing consent to usage of the data is that this consent needs to be provided to someone for a specific use-case and time. Who is the operator of the map server? How do you make sure the data is deleted when the user choses?
These are hard problems in a community that relies on voluntary work. Best avoid a situation like that.
The sensible way around negative consequences of DSGVO is to avoid permanently storing the data and instead just caching it. This is compliant according to my discussion with Bea (lawyer for Urheberrecht & Datenschutz) and again, this is clearly outside of the scope of gluon and very easily achievable in the map server.

Edit: Of course every community is encouraged to find their own processes. Gluon is an extensible framework.

[csamsel]

If you save consent you need to save the timestamp. How do you save the current timestamp on a node that does not have a synchronized clock as is the case in config-mode most of the time? If you do not store it on the node, you have to store it on some infrastructure which clearly is outside the scope of gluon.

Use the browser time. 2 lines of javascript. If thats no good, use text field where the user enters the date.

These are hard problems in a community that relies on voluntary work. Best avoid a situation like that.
The sensible way around negative consequences of DSGVO is to avoid permanently storing the data and instead just caching it. This is compliant according to my discussion with Bea (lawyer for Urheberrecht & Datenschutz) and again, this is clearly outside of the scope of gluon and very easily achievable in the map server.

Sounds good, but you could argue, there is no clear difference between storing and caching.

[christf]

There are judgements for it, there is a difference between storing and caching.

[rubo77]

If we would add a checkbox this could be a shot in the foot:

I heard, that if you add a checkbox, then you also have to add a way for the user to recall this consent.
But you don't need a checkbox, if you thoroughly explain what is happening with the entered personal data. And without consent-checkbox, you also don't need any way to remove that consent later on.

This is what the whole DSGVO is all about: transparacy!

So you are still allowed to collect personal data, if you can justify that you need the data to do your job.

This is what we should do: explain, what is happening with the data and a link to the complete Datenschutzverordnung somewhere.

no checkbox!

[rubo77]

And most of all:

Don't panic!

Artikel 83(2) gibt außerdem eine Liste von Kriterien für die Bußgelder, woraus klar wird, dass z.B. Wiederholungstäter, die mit Vorsatz und Gewinnerzielungsabsicht besonders viele Daten rechtswidrig verarbeiten, die hohen Strafen befürchten müssen – nicht aber der kleine Verein, der aus Unkenntnis gehandelt hat. Gegen den wird es in aller Regel bei einem Erstverstoß keine Strafe geben, sondern eine Ermahnung mit Hinweisen, wie das Problem abgestellt werden kann

https://www.janalbrecht.eu/2018/05/dsgvo-haeufig-gestellte-fragen-haeufig-verbreitete-mythen/