FunkFeuer Wiki - Benutzerbeiträge [de]

Regionen/Wien

2023-06-27T09:58:39Z

Stratuscumulus: /* Mitmachen */

== Mitmachen ==
Du möchtest mitmachen? Darüber freuen wir uns sehr! Bitte '''[[Regionen/Wien/Mitmachen | hier]]''' entlang für alle Informationen!

== Verein (Rechtliches) ==
Alle Informationen zum Verein inkl. Pflichtangaben finden sich [[Regionen/Wien/Verein | hier]]

Auch dort zu finden: [[Media:Statuten_Funkfeuer_Wien.pdf | Statuten]], [[Media:Mitgliedsantrag-Funkfeuer-Wien.pdf | Mitgliedsantrag]] und Informationen zum Vorstand.

== Tools ==
* [https://map.funkfeuer.at Karte]: Eine interaktive Karte, die die Topologie inkl. sämtlicher Knoten enthält.
** [https://map.funkfeuer.at/wien/ Wien] (als [https://map.funkfeuer.at/wien/data.php XML])
** [https://map.funkfeuer.at/nodemap/ nodemap] ([https://gitlab.com/eripek/0xFF-NodeMap Projektinfos])
** [https://ff.cybercomm.at/map2/ v642 OLSRv2] ([[Benutzer:Pocki#OLSRv2-Map|Projektinfos]])
* [http://smokeping.funkfeuer.at/ Smokeping]: Ein praktisches Tool, um Latenzzeiten im [http://smokeping.funkfeuer.at/smokeping/freenet Netz] grafisch darzustellen.

== Kontakt ==
* Forum: https://forum.funkfeuer.at/
* Chat: https://wiki.funkfeuer.at/wiki/Chat (für einfache schnelle Fragen)
* Mailinglisten: https://lists.funkfeuer.at/mailman/listinfo (Sehr viele Abonnenten, aber in letzter Zeit weniger Aktivität)

Regionen/Wien

2023-06-27T09:58:23Z

Stratuscumulus: /* Mitmachen */ Leitfaden-Link entfernt - FunkFeuer als Verein darf rechtlich nicht offiziell Anleitungen geben, wie etwas (elektrisch) zusammengebaut wird, ihr könnt privat auf den Leitfaden verweisen, wenn ihr meint das Teile davon aktuell sind und ihr mit jemandem schreibt, es muss klar und deutlich sein, dass das ein Privatleitfaden von einem Mitglied ist und nicht offiziell abgesegnet.

== Mitmachen ==
Du möchtest mitmachen? Darüber freuen wir uns sehr! Bitte '''[[Regionen/Wien/Mitmachen | hier]]''' entlang für alle Informationen!

Schau

== Verein (Rechtliches) ==
Alle Informationen zum Verein inkl. Pflichtangaben finden sich [[Regionen/Wien/Verein | hier]]

Auch dort zu finden: [[Media:Statuten_Funkfeuer_Wien.pdf | Statuten]], [[Media:Mitgliedsantrag-Funkfeuer-Wien.pdf | Mitgliedsantrag]] und Informationen zum Vorstand.

== Tools ==
* [https://map.funkfeuer.at Karte]: Eine interaktive Karte, die die Topologie inkl. sämtlicher Knoten enthält.
** [https://map.funkfeuer.at/wien/ Wien] (als [https://map.funkfeuer.at/wien/data.php XML])
** [https://map.funkfeuer.at/nodemap/ nodemap] ([https://gitlab.com/eripek/0xFF-NodeMap Projektinfos])
** [https://ff.cybercomm.at/map2/ v642 OLSRv2] ([[Benutzer:Pocki#OLSRv2-Map|Projektinfos]])
* [http://smokeping.funkfeuer.at/ Smokeping]: Ein praktisches Tool, um Latenzzeiten im [http://smokeping.funkfeuer.at/smokeping/freenet Netz] grafisch darzustellen.

== Kontakt ==
* Forum: https://forum.funkfeuer.at/
* Chat: https://wiki.funkfeuer.at/wiki/Chat (für einfache schnelle Fragen)
* Mailinglisten: https://lists.funkfeuer.at/mailman/listinfo (Sehr viele Abonnenten, aber in letzter Zeit weniger Aktivität)

Regionen/Wien/MoMo (Monatliches Montagstreffen)

2023-03-27T19:03:30Z

Stratuscumulus: /* Eckpunkte */ Aktualisierung Ort

Das MoMo ist als Evolution der bisherigen Montagstreffen gedacht. Es hat sich gezeigt, dass sich insbesondere die bestehenden Mitglieder mehr Struktur und Inhalte wünschen.

Vorgeschlagene und bisherig abgehandelte Themen gibt es auf der Unterseite [[Regionen/Wien/MoMo/Themen]].

== Eckpunkte ==
* Am ersten Montag im Monat, online via BigBlueButton oder im Volkskundemuseum (Vermittlungsraum, Innenhof oder Schönbornpark), ab ca. 19 Uhr, genauer Ort/Termin vorab per Wien-Mailingliste und im Element-Wien-Raum
* Agenda mit einigen fixen und einigen variablen Inhalten
* Es ist immer mindestens ein Vorstandsmitglied anwesend
* Agenda, die sowohl Newbies als auch Mitglieder anspricht

== Agenda ==
* 19:00 Eintreffen, Kennenlernen
* 19:10 Einführungsvortrag
** Was ist Funkfeuer, Idee dahinter
** Wie funktioniert das Netz
** Wie mache ich mit, Verein
* 19:40 Q&A, Beitritt Verein, individueller Support (bei Bedarf über 20:00 Uhr hinaus parallel zum restlichen Programm)
* 20:00 Vortrag zu einem relevanten Thema (Internet, HF, Netz-Politik, Vereinsleben …) – zur [[Regionen/Wien/MoMo/Themen|Liste der Themen]]
* 20:30 Bericht des Vorstands zu aktuellen Projekten und Themen inkl. Statusbericht zu den jeweiligen Services (vorzugsweise durch die jeweiligen Maintainer)
* 21:00 Gemeinsame Arbeit an Projekten (Services + Core), open end

== FAQ ==
* Gibt es in den anderen Wochen kein Montagstreffen mehr? – Doch, sehr gerne, wenn sich Leute finden, die sich an den restlichen Montagen treffen wollen. Der Vorstand kümmert sich nur um Abhaltung und Gestaltung des jeweils ersten im Monat, und freut sich über Eure aktive Mithilfe bei Ankündigung, Planung und Abwicklung.

Regionen/Wien/Montagstreffen

2023-03-27T18:59:00Z

Stratuscumulus: /* Rahmeninfos */

=Rahmeninfos=
Montags (ausgenommen Feiertage) treffen sich FunkFeuer-Interessierte aus Wien und Umgebung ab 19 Uhr; genauer Ort und Zeit werden auf der Wien-Mailingliste und im Element-Wien-Raum vor dem jeweiligen Termin gepostet.

Treffpunkt entweder
* online via einem BigBlueButton-Link

oder

* in Persona im Vermittlungsraum, Innenhof des Volkskundemuseums (VKM), Laudongasse 15-19, 1080 Wien oder im angrenzenden Schönbornpark. [https://www.volkskundemuseum.at]

* Je nach Arbeitsauslastung kann es auch passieren, dass ein erfahrener Funkfeuer-"Mentor" erst ab 19:30 oder 20:00 Uhr da sein wird.

* In den Sommermonaten (Juli & August) wird die Beginnzeit auf 19:30 Uhr verlegt.

=Themen=
Aktuelle Themen findest Du [[Regionen/Wien/MoMo/Themen]]
Bei diesen Treffen wird hauptsächlich konkrete Hilfestellung bei Problemen geboten (Standort planen, Benutzer anlegen, Router flashen, erweiterte Konfigurationen etc.).

Falls du dich für Funkfeuer interessierst und eine ausführliche Einführung hören willst: Es finden in unregelmäßigen Abständen sogennante "Einführungsvorträge" statt. Diese werden auf der Mailingliste bekannt gegeben. Dort kannst Du auch gerne aktiv dein Interesse an einer solchen Veranstaltung bekunden!

Regionen/Wien/Montagstreffen

2023-03-27T18:58:39Z

Stratuscumulus: /* Rahmeninfos */

=Rahmeninfos=
Montags (ausgenommen Feiertage) treffen sich FunkFeuer-Interessierte aus Wien und Umgebung ab 19 Uhr; genauer Ort und Zeit werden auf der Wien-Mailingliste und im Element-Wien-Raum vor dem jeweiligen Termin gepostet.

Treffpunkt entweder
* online via einem BigBlueButton-Link

oder

* in Persona im Vermittlungsraum, Innenhof des Volkskundemuseums (VKM), Laudongasse 15-19, 1080 Wien oder im angrenzenden Schönbornpark [https://www.volkskundemuseum.at]

* Je nach Arbeitsauslastung kann es auch passieren, dass ein erfahrener Funkfeuer-"Mentor" erst ab 19:30 oder 20:00 Uhr da sein wird.

* In den Sommermonaten (Juli & August) wird die Beginnzeit auf 19:30 Uhr verlegt.

=Themen=
Aktuelle Themen findest Du [[Regionen/Wien/MoMo/Themen]]
Bei diesen Treffen wird hauptsächlich konkrete Hilfestellung bei Problemen geboten (Standort planen, Benutzer anlegen, Router flashen, erweiterte Konfigurationen etc.).

Falls du dich für Funkfeuer interessierst und eine ausführliche Einführung hören willst: Es finden in unregelmäßigen Abständen sogennante "Einführungsvorträge" statt. Diese werden auf der Mailingliste bekannt gegeben. Dort kannst Du auch gerne aktiv dein Interesse an einer solchen Veranstaltung bekunden!

Regionen/Wien/Montagstreffen

2023-03-27T18:58:16Z

Stratuscumulus: /* Rahmeninfos */

=Rahmeninfos=
Montags (ausgenommen Feiertage) treffen sich FunkFeuer-Interessierte aus Wien und Umgebung ab 19 Uhr; genauer Ort und Zeit werden auf der Wien-Mailingliste und im Element-Wien-Raum vor dem jeweiligen Termin gepostet.

Treffpunkt entweder
* online via einem BigBlueButton-Link

oder

* in Persona im Vermittlungsraum, Innenhof des Volkskundemuseums (VKM), Laudongasse 15-19, 1080 Wien oder im angrenzenden Schönbornpark ([https://www.volkskundemuseum.at]).

* Je nach Arbeitsauslastung kann es auch passieren, dass ein erfahrener Funkfeuer-"Mentor" erst ab 19:30 oder 20:00 Uhr da sein wird.

* In den Sommermonaten (Juli & August) wird die Beginnzeit auf 19:30 Uhr verlegt.

=Themen=
Aktuelle Themen findest Du [[Regionen/Wien/MoMo/Themen]]
Bei diesen Treffen wird hauptsächlich konkrete Hilfestellung bei Problemen geboten (Standort planen, Benutzer anlegen, Router flashen, erweiterte Konfigurationen etc.).

Falls du dich für Funkfeuer interessierst und eine ausführliche Einführung hören willst: Es finden in unregelmäßigen Abständen sogennante "Einführungsvorträge" statt. Diese werden auf der Mailingliste bekannt gegeben. Dort kannst Du auch gerne aktiv dein Interesse an einer solchen Veranstaltung bekunden!

Regionen/Wien/Montagstreffen

2023-03-27T18:57:52Z

Stratuscumulus: /* Rahmeninfos */ Ort und Infos aktualisiert

=Rahmeninfos=
Montags (ausgenommen Feiertage) treffen sich FunkFeuer-Interessierte aus Wien und Umgebung ab 19 Uhr; genauer Ort und Zeit werden auf der Wien-Mailingliste und im Element-Wien-Raum vor dem jeweiligen Termin gepostet.

Treffpunkt entweder
* online via einem BigBlueButton-Link

oder

* in Persona im Vermittlungsraum, Innenhof des Volkskundemuseums (VKM), Laudongasse 15-19, 1080 Wien oder im angrenzenden Schönbornpark
([https://www.volkskundemuseum.at]).

* Je nach Arbeitsauslastung kann es auch passieren, dass ein erfahrener Funkfeuer-"Mentor" erst ab 19:30 oder 20:00 Uhr da sein wird.

* In den Sommermonaten (Juli & August) wird die Beginnzeit auf 19:30 Uhr verlegt.

=Themen=
Aktuelle Themen findest Du [[Regionen/Wien/MoMo/Themen]]
Bei diesen Treffen wird hauptsächlich konkrete Hilfestellung bei Problemen geboten (Standort planen, Benutzer anlegen, Router flashen, erweiterte Konfigurationen etc.).

Falls du dich für Funkfeuer interessierst und eine ausführliche Einführung hören willst: Es finden in unregelmäßigen Abständen sogennante "Einführungsvorträge" statt. Diese werden auf der Mailingliste bekannt gegeben. Dort kannst Du auch gerne aktiv dein Interesse an einer solchen Veranstaltung bekunden!

Hausverwaltungen

2023-03-24T15:17:31Z

Stratuscumulus: /* Vorlagen zum Anfragen */

== '''Anfrage um Bewilligung''' ==
* Alle, die nicht Eigentümer des gesamten Gebäudes sind, in dem sie wohnen, müssen bei einer Hausverwaltung um die Bewilligung ansuchen, eine Antenne am Dach aufstellen zu dürfen. Es empfiehlt sich, Schreiben die per Postweg zugestellt werden sollen, eingeschrieben zu versenden.
* Prinzipiell hat jeder Mieter/Nutzungsberechtigte ein gesetzliches Recht auf eine solche Antenne.

== '''Argumente''' ==
* Redundante Anbindung an das Netzwerk - kein kommerzieller Anbieter bietet bisher dezentrale und gleichzeitig redundante Anbindung an sein Netzwerk und dadurch ins Internet.
* Mangelnde Bandbreite der kommerziellen Anbieter für z.B. HD-Videokonferenzen (weil hier nur der Upload gerechnet werden kann, der bei den meisten kommerziellen Anbietern zu gering oder zu teuer ist).
* Anbieten von (Server-)Diensten bei den meisten kommerziellen Anbietern unerwünscht oder verboten, bei FunkFeuer jedoch ausdrücklich erwünscht und auch technisch ermöglicht.
* Unterwanderung der Netzneutralität beigroßen kommerziellen Anbietern durch Verwendung von Zwangsproxies, DNS Umleitungen (um z.B. Webseiten zu sperren).
* Bürgernetze als Katastrophenschutz und Absicherung der Netzneutralität.
* Im Sinne einer engagierten Zivilgesellschaft ist das Projekt FunkFeuer unbedingt unterstützenswert.

== '''Mustervorlagen''' ==

* [[Datei:Ansuchen_um_Bewilligung_FunkFeuer.odt]]

Nachdem der prinzipielle Ablauf sowie Aufbau einer SAT-Anlage sehr ähnelt, was bei Hausverwaltungen mittlerweile gut bekannt ist, werden Vorlagen dafür angeboten die entsprechend verwendet werden können:
* [https://www.wienerwohnen.at/dms/workspace/SpacesStore/c60ff60f-478f-4742-9ab2-daef83e13f96/2330_sd0103_Ansuchen_Satellitenempfangsantenne.pdf Ansuchen Satellitenantenne] Stadt Wien - Wiener Wohnen
* [http://www.ah-wohnen.at/bewilligungen-.74.html Antragsformular zur SAT - Anlagenerrichtung] Gem. Siedlungs-Genossenschaft Altmannsdorf und Hetzendorf

== '''Gesetzestext (in der Fassung vom 23.03.2023)''' ==
=== ''§ 9 MRG Veränderung (Verbesserung) des Mietgegenstandes'' ===

(1) Der Hauptmieter hat eine von ihm beabsichtigte wesentliche Veränderung (Verbesserung) des Mietgegenstandes dem Vermieter anzuzeigen. Lehnt der Vermieter nicht innerhalb von zwei Monaten nach Zugang der Anzeige die beabsichtigte Veränderung ab, so gilt seine Zustimmung als erteilt. Der Vermieter kann seine Zustimmung und eine erforderliche Antragstellung bei der Baubehörde nicht verweigern wenn,

1. die Veränderung dem jeweiligen Stand der Technik entspricht,

2. die Veränderung der Übung des Verkehrs entspricht und einem wichtigen Interesse des Hauptmieters dient,

3. die einwandfreie Ausführung der Veränderung gewährleistet ist,

4. der Hauptmieter die Kosten trägt,

5. durch die Veränderung keine Beeinträchtigung schutzwürdiger Interessen des Vermieters oder eines anderen Mieters zu besorgen ist,

6. durch die Veränderung keine Schädigung des Hauses, im besonderen keine Beeinträchtigung der äußeren Erscheinung des Hauses, erfolgt,

7. die Veränderung keine Gefahr für die Sicherheit von Personen und Sachen bewirkt.

(2) Die Voraussetzung des Abs. 1 Z 2 ist jedenfalls gegeben, wenn es sich handelt um

1. die Errichtung oder die den Erfordernissen der Haushaltsführung dienende Umgestaltung von Wasserleitungs-, Lichtleitungs-, Gasleitungs-, Beheizungs- (einschließlich der Einrichtung von zentralen Wärmeversorgungsanlagen) oder sanitären Anlagen,

2. die der Senkung des Energieverbrauchs dienende Ausgestaltung eines Mietgegenstandes,

3. die Verbesserungen, die von einer Gebietskörperschaft aus öffentlichen Mitteln gefördert werden,

4. die Einleitung eines Fernsprechanschlusses oder

5. die Anbringung der nach dem Stand der Technik notwendigen Antennen und sonstigen Einrichtungen für den Hörfunk- und Fernsehempfang sowie für Multimediadienste, sofern der Anschluß an eine bestehende Einrichtung nicht möglich oder nicht zumutbar ist.

(3) Handelt es sich um eine wesentliche Veränderung (Verbesserung), die nicht im Abs. 2 angeführt ist, so kann der Vermieter seine Zustimmung von der Verpflichtung des Hauptmieters zur Wiederherstellung des früheren Zustandes bei der Zurückstellung des Mietgegenstandes abhängig machen.

Referenzen:
Die tagesaktuelle konsolidierte Fassung des § 9 MRG kann im Rechtsinformationssystem des Bundes (RIS) abgerufen werden.

* [https://www.ris.bka.gv.at/eli/bgbl/1981/520/P9/NOR40026132?ResultFunctionToken=d76b1d25-9316-4aef-b17d-681daf528364&Position=1&SkipToDocumentPage=True&Abfrage=Bundesnormen&Kundmachungsorgan=&Index=&Titel=&Gesetzesnummer=&VonArtikel=&BisArtikel=&VonParagraf=&BisParagraf=&VonAnlage=&BisAnlage=&Typ=&Kundmachungsnummer=&Unterzeichnungsdatum=&FassungVom=23.03.2023&VonInkrafttretedatum=&BisInkrafttretedatum=&VonAusserkrafttretedatum=&BisAusserkrafttretedatum=&NormabschnittnummerKombination=Und&ImRisSeitVonDatum=&ImRisSeitBisDatum=&ImRisSeit=Undefined&ResultPageSize=100&Suchworte=%c2%a7+9+MRG]

== '''Weiterführende Informationen beim Magistrat der Stadt Wien''' ==
* MA50 Wohnbauförderung und Schlichtungsstelle für wohnrechtliche Angelegenheiten
**[http://www.wien.gv.at/amtshelfer/bauen-wohnen/schlichtungsstelle/mietrechtsverfahren/veraenderung-mietgegenstand.html Veränderung (Verbesserung) des Mietgegenstandes]
* MA19 Architektur und Stadtgestaltung
** [http://www.wien.gv.at/amtshelfer/bauen-wohnen/stadtentwicklung/baulicheanlagen/satellitenantenne.html Satellitenantennen - Architektonische Begutachtung]
** [http://www.wien.gv.at/stadtentwicklung/grundlagen/schutzzonen/index.html Schutzzonen]

Hausverwaltungen

2023-03-24T15:16:26Z

Stratuscumulus: /* Fertige Vorlagen zum Anfragen */ Musteransuchen aktualisiert, anonymisiert und externer Link zu Google Docs entfernt, wegen datenschutzrechtlichen Bedenken

== '''Anfrage um Bewilligung''' ==
* Alle, die nicht Eigentümer des gesamten Gebäudes sind, in dem sie wohnen, müssen bei einer Hausverwaltung um die Bewilligung ansuchen, eine Antenne am Dach aufstellen zu dürfen. Es empfiehlt sich, Schreiben die per Postweg zugestellt werden sollen, eingeschrieben zu versenden.
* Prinzipiell hat jeder Mieter/Nutzungsberechtigte ein gesetzliches Recht auf eine solche Antenne.

== '''Argumente''' ==
* Redundante Anbindung an das Netzwerk - kein kommerzieller Anbieter bietet bisher dezentrale und gleichzeitig redundante Anbindung an sein Netzwerk und dadurch ins Internet.
* Mangelnde Bandbreite der kommerziellen Anbieter für z.B. HD-Videokonferenzen (weil hier nur der Upload gerechnet werden kann, der bei den meisten kommerziellen Anbietern zu gering oder zu teuer ist).
* Anbieten von (Server-)Diensten bei den meisten kommerziellen Anbietern unerwünscht oder verboten, bei FunkFeuer jedoch ausdrücklich erwünscht und auch technisch ermöglicht.
* Unterwanderung der Netzneutralität beigroßen kommerziellen Anbietern durch Verwendung von Zwangsproxies, DNS Umleitungen (um z.B. Webseiten zu sperren).
* Bürgernetze als Katastrophenschutz und Absicherung der Netzneutralität.
* Im Sinne einer engagierten Zivilgesellschaft ist das Projekt FunkFeuer unbedingt unterstützenswert.

== '''Vorlagen zum Anfragen''' ==

* [[Datei:Ansuchen_um_Bewilligung_FunkFeuer.odt]]

Nachdem der prinzipielle Ablauf sowie Aufbau einer SAT-Anlage sehr ähnelt, was bei Hausverwaltungen mittlerweile gut bekannt ist, werden Vorlagen dafür angeboten die entsprechend verwendet werden können:
* [https://www.wienerwohnen.at/dms/workspace/SpacesStore/c60ff60f-478f-4742-9ab2-daef83e13f96/2330_sd0103_Ansuchen_Satellitenempfangsantenne.pdf Ansuchen Satellitenantenne] Stadt Wien - Wiener Wohnen
* [http://www.ah-wohnen.at/bewilligungen-.74.html Antragsformular zur SAT - Anlagenerrichtung] Gem. Siedlungs-Genossenschaft Altmannsdorf und Hetzendorf

== '''Gesetzestext (in der Fassung vom 23.03.2023)''' ==
=== ''§ 9 MRG Veränderung (Verbesserung) des Mietgegenstandes'' ===

(1) Der Hauptmieter hat eine von ihm beabsichtigte wesentliche Veränderung (Verbesserung) des Mietgegenstandes dem Vermieter anzuzeigen. Lehnt der Vermieter nicht innerhalb von zwei Monaten nach Zugang der Anzeige die beabsichtigte Veränderung ab, so gilt seine Zustimmung als erteilt. Der Vermieter kann seine Zustimmung und eine erforderliche Antragstellung bei der Baubehörde nicht verweigern wenn,

1. die Veränderung dem jeweiligen Stand der Technik entspricht,

2. die Veränderung der Übung des Verkehrs entspricht und einem wichtigen Interesse des Hauptmieters dient,

3. die einwandfreie Ausführung der Veränderung gewährleistet ist,

4. der Hauptmieter die Kosten trägt,

5. durch die Veränderung keine Beeinträchtigung schutzwürdiger Interessen des Vermieters oder eines anderen Mieters zu besorgen ist,

6. durch die Veränderung keine Schädigung des Hauses, im besonderen keine Beeinträchtigung der äußeren Erscheinung des Hauses, erfolgt,

7. die Veränderung keine Gefahr für die Sicherheit von Personen und Sachen bewirkt.

(2) Die Voraussetzung des Abs. 1 Z 2 ist jedenfalls gegeben, wenn es sich handelt um

1. die Errichtung oder die den Erfordernissen der Haushaltsführung dienende Umgestaltung von Wasserleitungs-, Lichtleitungs-, Gasleitungs-, Beheizungs- (einschließlich der Einrichtung von zentralen Wärmeversorgungsanlagen) oder sanitären Anlagen,

2. die der Senkung des Energieverbrauchs dienende Ausgestaltung eines Mietgegenstandes,

3. die Verbesserungen, die von einer Gebietskörperschaft aus öffentlichen Mitteln gefördert werden,

4. die Einleitung eines Fernsprechanschlusses oder

5. die Anbringung der nach dem Stand der Technik notwendigen Antennen und sonstigen Einrichtungen für den Hörfunk- und Fernsehempfang sowie für Multimediadienste, sofern der Anschluß an eine bestehende Einrichtung nicht möglich oder nicht zumutbar ist.

(3) Handelt es sich um eine wesentliche Veränderung (Verbesserung), die nicht im Abs. 2 angeführt ist, so kann der Vermieter seine Zustimmung von der Verpflichtung des Hauptmieters zur Wiederherstellung des früheren Zustandes bei der Zurückstellung des Mietgegenstandes abhängig machen.

Referenzen:
Die tagesaktuelle konsolidierte Fassung des § 9 MRG kann im Rechtsinformationssystem des Bundes (RIS) abgerufen werden.

* [https://www.ris.bka.gv.at/eli/bgbl/1981/520/P9/NOR40026132?ResultFunctionToken=d76b1d25-9316-4aef-b17d-681daf528364&Position=1&SkipToDocumentPage=True&Abfrage=Bundesnormen&Kundmachungsorgan=&Index=&Titel=&Gesetzesnummer=&VonArtikel=&BisArtikel=&VonParagraf=&BisParagraf=&VonAnlage=&BisAnlage=&Typ=&Kundmachungsnummer=&Unterzeichnungsdatum=&FassungVom=23.03.2023&VonInkrafttretedatum=&BisInkrafttretedatum=&VonAusserkrafttretedatum=&BisAusserkrafttretedatum=&NormabschnittnummerKombination=Und&ImRisSeitVonDatum=&ImRisSeitBisDatum=&ImRisSeit=Undefined&ResultPageSize=100&Suchworte=%c2%a7+9+MRG]

== '''Weiterführende Informationen beim Magistrat der Stadt Wien''' ==
* MA50 Wohnbauförderung und Schlichtungsstelle für wohnrechtliche Angelegenheiten
**[http://www.wien.gv.at/amtshelfer/bauen-wohnen/schlichtungsstelle/mietrechtsverfahren/veraenderung-mietgegenstand.html Veränderung (Verbesserung) des Mietgegenstandes]
* MA19 Architektur und Stadtgestaltung
** [http://www.wien.gv.at/amtshelfer/bauen-wohnen/stadtentwicklung/baulicheanlagen/satellitenantenne.html Satellitenantennen - Architektonische Begutachtung]
** [http://www.wien.gv.at/stadtentwicklung/grundlagen/schutzzonen/index.html Schutzzonen]

Datei:Ansuchen um Bewilligung FunkFeuer.odt

2023-03-24T15:05:50Z

Stratuscumulus: Musteransuchen um Bewilligung

== Beschreibung ==
Musteransuchen um Bewilligung

Hauptseite

2023-03-24T00:23:14Z

Stratuscumulus: /* Kommunikation */ Aufzählung angepasst

{{#ask:[[Category:Events]]
[[EndDate::>{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}}]]
[[IsMainEvent::+]]
|?#=page
|?name=name
|?Date#ISO=date
|?EndDate#ISO=enddate
|format=template
|template=EventList_Mainpage
|named args=yes
|sort=date
|intro= <div style="display:inline-block; float:right; border: 1px solid #6991AA;margin: 3px 10px; padding: 0px 15px 15px 5px"> <h2>kommende Events</h2> {{EventListIntro_Mainpage}}
|outro= {{TableEnd}} </div>
}}

<table style="empty-cells:hide">
<tr><td>
{{InfoBanner
|title=Neu hier?
|titlebgcolor=#556270
|text=FunkFeuer.at ist jene Plattform, unter der österreichweit freie WLAN-Netze betrieben werden. <br>Die Grundidee dabei ist, einen eigenen Wireless-LAN Netzwerkknoten zu betreiben und entsprechend dem [[PicoPeeringAgreement]] darüber anderen Netzteilnehmern freien Daten-Transit zu ermöglichen.<br>Im Zusammenspiel mit dem dynamischen Routing Protokoll [http://www.olsr.org OLSR] entsteht damit fast von selbst ein gemeinschaftliches Netzwerk, bei dem jedoch die Komponenten des Netzes im Besitz der einzelnen User verbleiben.
}}

{{InfoBanner
|title=Bei FunkFeuer.at mitmachen
|text=FunkFeuer versteht sich als ein soziales Netz, bei dem sich technisch Interessierte über alle politischen, kulturellen und sozialen Grenzen hinweg dem Thema [http://de.wikipedia.org/wiki/Freies_Funknetz Freier Netze in Österreich] widmen. Eine kurze Einführung wie du mitmachen kannst findest du in unserer [[Erste Schritte|Kurzeinführung]]
}}
</td><td style="vertical-align:top">
</td></tr>
</table>
==Weitere Informationen zu FunkFeuer.at==
*[http://www.funkfeuer.at Die 0xFF-FunkFeuer Homepage]
:ist die Homepage des Community und stellt Links zu den einzelnen örtlichen Initiativen und den wichtigsten Services für die Community zur Verfügung.

*[http://gallery.funkfeuer.at/ Die Bildergalerie]
: ist unsere Foto-Sammlung, in der sich viele Panoramas, Bilder von Knoten aber auch Events finden. Möglicherweise entdeckst du dein Dach auf einem Foto! Dann ist es sehr wahrscheinlich, dass du einen Link aufbauen kannst. Du kannst in der Galerie Fotos von deinem eigenen (zukünftigen) Knoten hochladen.

===Kommunikation===
*[https://lists.funkfeuer.at/mailman/listinfo Die FunkFeuer Mailinglisten]
: dienen der schriftlichen Kontaktaufnahme innerhalb der einzelnen Communities und ist neben der Wiki eine unserer wichtigsten Dokumentationsquellen.

*[[Chat|Der FunkFeuer Wien Riot Chat]]
: ist der schnellste Weg um mit der Community in Kontakt zu treten. Für komplexere Fragen aber bitte lieber eine der strukturierteren Kommunikationskanäle wählen.

*[https://forum.funkfeuer.at/ Das FunkFeuer Forum]
: Ein Kommunikationskanal neben Chat und Mailinglisten.

== Noch kein FunkFeuer in deiner Region? ==
Unter [[Neue Initiativen]] kannst du deine Kontaktinformationen veröffentlichen und so weitere Interessenten in deiner Gegend finden, die mit dir gemeinsam ein neues Netz aufbauen. Die bestehenden FunkFeuer-Netze stehen euch dann gerne mit Rat und Tat zur Seite!

__NOTOC__

{{InfoBanner
|title=Hinweis: Wiki-Migration
|titlebgcolor=#b0d320
|text=Unser altes Wiki findet sich unter [http://oldwiki.funkfeuer.at oldwiki.funkfeuer.at] -- die Inhalte dort sind '''veraltet''', bitte nur mehr in historischem Kontext konsumieren. :-)
}}

Services/Organisation/Tunnelserver

2023-03-24T00:02:57Z

Stratuscumulus: Domain aktualisiert

{{Projekt
|name=tunnel.funkfeuer.at
|startdate=2017/09/20
|state=Aktiv
|desc=Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das FunkFeuer-Netz über eine nicht zu FunkFeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung.
}}

== Beschreibung ==

Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das FunkFeuer-Netz über eine nicht zu FunkFeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung.

Funkinseln sind entweder solche Knoten, deren einzige Verbindung zum FunkFeuer-Netz über eine nicht zum FunkFeuer-Netz gehörende Breitbandverbindung hergestellt wird, oder solche Knoten, die über eine externe Breitbandverbindung und ihre jeweilige Funkschnittstelle oder jeweiligen Funkschnittstellen entlegene Knoten, die sonst nicht mit dem restlichen FunkFeuer-Netz verbunden sind, verbinden, sowie jene Knoten, die aus Gründen der höheren Redundanz eine externe Breitbandverbindung als Backupverbindung nützen, um zwischen Nachbarknoten und dem FunkFeuer-Housing über eine Breitbandverbindung Daten weiterzuleiten, Routinginformationen auszutauschen oder selbst Daten zu übertragen.

== Maintainer ==
* [[Benutzer:erich|Erich N. Pekarek]]
* [[Benutzer:vchrizz|Christoph Lösch]]
* [[Benutzer:Pocki|Christian Pock]]
* [[Benutzer:damadmai|Daniel A. Maierhofer]]

== Abhängigkeiten ==

Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:

* Core-Team/Roofnode-Team
* v642-Projekt
* Housing/VM

<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.
* Vorbereitungen:
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.
** Tests neuer Funktionen.
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.
* Nacharbeiten:
** Anschließend die VM „Tunnel 6“ stilllegen.
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.
** Die VM „Tunnel“ anschließend stilllegen.
</s>
* Dauerarbeiten: Wartung und Betreuung.

Ziel ist es, einen redundant angebundenen Tunnelserver zu haben, der einerseits „echte Funkinseln“ mit mehreren Protokollen versorgen kann, andererseits auch versprengte IPv6-Maschinen durch das IPv4-Netz anbinden kann. <s>Eine weitere Aufgabe kann die Anbindung der vereinzelt existenten OLSRv1-IPv6 Knoten sein. Letzteres ist durch Migrationsvorhaben an den davon betroffenen Knoten jedoch nur noch bedingt relevant.</s> Gegenwärtig nützt nur noch Knoten OZW OLSRv1 mit IPv6 aus dem Prefix 2a02:60:100::/40.

== Details ==
Gegenwärtiger Status:
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s>
<s>* Tunnel6 wurde aktualisiert und wird nun um neue Features erweitert. Hier sind wir in der Testphase. Nach deren Abschluss steht die Migration sämtlicher Tunneldienste auf diese VM unmittelbar bevor.</s>
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s>
* Tunnelbetreiber wurden angeschrieben, um den Bedarf zu erheben und Dokumentationsmängel zu beheben. Nicht mehr benötigte Tunnel wurden gelöscht, ebenso wie unbenutzte Tunnel ohne jedwede oder selbst nach Nachfrage nicht nachvollziehbare Kontaktinformation. Die Nichtangabe von Kontaktinformationen verstösst nämlich auch gegen das PicoPeeringAgreement.
* Migration abgeschlossen, Regelbetrieb.
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261 eingemeldet werden. Das Maintainer-Team kümmert sich darum.

== Verwendung ==
[[OpenVPN-Tunnel_zu_FunkFeuer]]

Hausverwaltungen

2023-03-23T22:35:45Z

Stratuscumulus: /* Gesetzestext (in der Fassung vom 23.03.2023 */ Text aktualisiert, Verweis auf Jusline weggenommen, da keine offzielle Quelle, alleinig die tagesaktuelle (konsolidierte) Fassung im RIS ist ausschlaggebend

== '''Anfrage um Bewilligung''' ==
* Alle, die nicht Eigentümer des gesamten Gebäudes sind, in dem sie wohnen, müssen bei einer Hausverwaltung um die Bewilligung ansuchen, eine Antenne am Dach aufstellen zu dürfen. Es empfiehlt sich, Schreiben die per Postweg zugestellt werden sollen, eingeschrieben zu versenden.
* Prinzipiell hat jeder Mieter/Nutzungsberechtigte ein gesetzliches Recht auf eine solche Antenne.

== '''Argumente''' ==
* Redundante Anbindung an das Netzwerk - kein kommerzieller Anbieter bietet bisher dezentrale und gleichzeitig redundante Anbindung an sein Netzwerk und dadurch ins Internet.
* Mangelnde Bandbreite der kommerziellen Anbieter für z.B. HD-Videokonferenzen (weil hier nur der Upload gerechnet werden kann, der bei den meisten kommerziellen Anbietern zu gering oder zu teuer ist).
* Anbieten von (Server-)Diensten bei den meisten kommerziellen Anbietern unerwünscht oder verboten, bei FunkFeuer jedoch ausdrücklich erwünscht und auch technisch ermöglicht.
* Unterwanderung der Netzneutralität beigroßen kommerziellen Anbietern durch Verwendung von Zwangsproxies, DNS Umleitungen (um z.B. Webseiten zu sperren).
* Bürgernetze als Katastrophenschutz und Absicherung der Netzneutralität.
* Im Sinne einer engagierten Zivilgesellschaft ist das Projekt FunkFeuer unbedingt unterstützenswert.

== '''Fertige Vorlagen zum Anfragen''' ==
* [https://docs.google.com/document/d/19DQTMn_W2533U8yFV7g97nQAatOYjJEPYw_DqVP14dY Ansuchen um Bewilligung Funkfeuer-Muster] Aktuelle Version 2020, Link zu Google Docs
* [[Datei:Ansuchen_Bewilligung_Funkfeuer_Muster.pdf]] Erste Version 2013, lokale Kopie

Nachdem der prinzipielle Ablauf sowie Aufbau einer SAT-Anlage sehr ähnelt, was bei Hausverwaltungen mittlerweile gut bekannt ist, werden Vorlagen dafür angeboten die genauso entsprechend verwendet werden können:
* [https://www.wienerwohnen.at/dms/workspace/SpacesStore/c60ff60f-478f-4742-9ab2-daef83e13f96/2330_sd0103_Ansuchen_Satellitenempfangsantenne.pdf Ansuchen Satellitenantenne] Stadt Wien - Wiener Wohnen
* [http://www.ah-wohnen.at/bewilligungen-.74.html Antragsformular zur SAT - Anlagenerrichtung] Gem. Siedlungs-Genossenschaft Altmannsdorf und Hetzendorf

== '''Gesetzestext (in der Fassung vom 23.03.2023)''' ==
=== ''§ 9 MRG Veränderung (Verbesserung) des Mietgegenstandes'' ===

(1) Der Hauptmieter hat eine von ihm beabsichtigte wesentliche Veränderung (Verbesserung) des Mietgegenstandes dem Vermieter anzuzeigen. Lehnt der Vermieter nicht innerhalb von zwei Monaten nach Zugang der Anzeige die beabsichtigte Veränderung ab, so gilt seine Zustimmung als erteilt. Der Vermieter kann seine Zustimmung und eine erforderliche Antragstellung bei der Baubehörde nicht verweigern wenn,

1. die Veränderung dem jeweiligen Stand der Technik entspricht,

2. die Veränderung der Übung des Verkehrs entspricht und einem wichtigen Interesse des Hauptmieters dient,

3. die einwandfreie Ausführung der Veränderung gewährleistet ist,

4. der Hauptmieter die Kosten trägt,

5. durch die Veränderung keine Beeinträchtigung schutzwürdiger Interessen des Vermieters oder eines anderen Mieters zu besorgen ist,

6. durch die Veränderung keine Schädigung des Hauses, im besonderen keine Beeinträchtigung der äußeren Erscheinung des Hauses, erfolgt,

7. die Veränderung keine Gefahr für die Sicherheit von Personen und Sachen bewirkt.

(2) Die Voraussetzung des Abs. 1 Z 2 ist jedenfalls gegeben, wenn es sich handelt um

1. die Errichtung oder die den Erfordernissen der Haushaltsführung dienende Umgestaltung von Wasserleitungs-, Lichtleitungs-, Gasleitungs-, Beheizungs- (einschließlich der Einrichtung von zentralen Wärmeversorgungsanlagen) oder sanitären Anlagen,

2. die der Senkung des Energieverbrauchs dienende Ausgestaltung eines Mietgegenstandes,

3. die Verbesserungen, die von einer Gebietskörperschaft aus öffentlichen Mitteln gefördert werden,

4. die Einleitung eines Fernsprechanschlusses oder

5. die Anbringung der nach dem Stand der Technik notwendigen Antennen und sonstigen Einrichtungen für den Hörfunk- und Fernsehempfang sowie für Multimediadienste, sofern der Anschluß an eine bestehende Einrichtung nicht möglich oder nicht zumutbar ist.

(3) Handelt es sich um eine wesentliche Veränderung (Verbesserung), die nicht im Abs. 2 angeführt ist, so kann der Vermieter seine Zustimmung von der Verpflichtung des Hauptmieters zur Wiederherstellung des früheren Zustandes bei der Zurückstellung des Mietgegenstandes abhängig machen.

Referenzen:
Die tagesaktuelle konsolidierte Fassung des § 9 MRG kann im Rechtsinformationssystem des Bundes (RIS) abgerufen werden.

* [https://www.ris.bka.gv.at/eli/bgbl/1981/520/P9/NOR40026132?ResultFunctionToken=d76b1d25-9316-4aef-b17d-681daf528364&Position=1&SkipToDocumentPage=True&Abfrage=Bundesnormen&Kundmachungsorgan=&Index=&Titel=&Gesetzesnummer=&VonArtikel=&BisArtikel=&VonParagraf=&BisParagraf=&VonAnlage=&BisAnlage=&Typ=&Kundmachungsnummer=&Unterzeichnungsdatum=&FassungVom=23.03.2023&VonInkrafttretedatum=&BisInkrafttretedatum=&VonAusserkrafttretedatum=&BisAusserkrafttretedatum=&NormabschnittnummerKombination=Und&ImRisSeitVonDatum=&ImRisSeitBisDatum=&ImRisSeit=Undefined&ResultPageSize=100&Suchworte=%c2%a7+9+MRG]

== '''Weiterführende Informationen beim Magistrat der Stadt Wien''' ==
* MA50 Wohnbauförderung und Schlichtungsstelle für wohnrechtliche Angelegenheiten
**[http://www.wien.gv.at/amtshelfer/bauen-wohnen/schlichtungsstelle/mietrechtsverfahren/veraenderung-mietgegenstand.html Veränderung (Verbesserung) des Mietgegenstandes]
* MA19 Architektur und Stadtgestaltung
** [http://www.wien.gv.at/amtshelfer/bauen-wohnen/stadtentwicklung/baulicheanlagen/satellitenantenne.html Satellitenantennen - Architektonische Begutachtung]
** [http://www.wien.gv.at/stadtentwicklung/grundlagen/schutzzonen/index.html Schutzzonen]

Hausverwaltungen

2023-03-23T22:22:31Z

Stratuscumulus: /* Argumente */ FunkFeuer ist kein politischer Verein, daher zu politische Termini gelöscht

== '''Anfrage um Bewilligung''' ==
* Alle, die nicht Eigentümer des gesamten Gebäudes sind, in dem sie wohnen, müssen bei einer Hausverwaltung um die Bewilligung ansuchen, eine Antenne am Dach aufstellen zu dürfen. Es empfiehlt sich, Schreiben die per Postweg zugestellt werden sollen, eingeschrieben zu versenden.
* Prinzipiell hat jeder Mieter/Nutzungsberechtigte ein gesetzliches Recht auf eine solche Antenne.

== '''Argumente''' ==
* Redundante Anbindung an das Netzwerk - kein kommerzieller Anbieter bietet bisher dezentrale und gleichzeitig redundante Anbindung an sein Netzwerk und dadurch ins Internet.
* Mangelnde Bandbreite der kommerziellen Anbieter für z.B. HD-Videokonferenzen (weil hier nur der Upload gerechnet werden kann, der bei den meisten kommerziellen Anbietern zu gering oder zu teuer ist).
* Anbieten von (Server-)Diensten bei den meisten kommerziellen Anbietern unerwünscht oder verboten, bei FunkFeuer jedoch ausdrücklich erwünscht und auch technisch ermöglicht.
* Unterwanderung der Netzneutralität beigroßen kommerziellen Anbietern durch Verwendung von Zwangsproxies, DNS Umleitungen (um z.B. Webseiten zu sperren).
* Bürgernetze als Katastrophenschutz und Absicherung der Netzneutralität.
* Im Sinne einer engagierten Zivilgesellschaft ist das Projekt FunkFeuer unbedingt unterstützenswert.

== '''Fertige Vorlagen zum Anfragen''' ==
* [https://docs.google.com/document/d/19DQTMn_W2533U8yFV7g97nQAatOYjJEPYw_DqVP14dY Ansuchen um Bewilligung Funkfeuer-Muster] Aktuelle Version 2020, Link zu Google Docs
* [[Datei:Ansuchen_Bewilligung_Funkfeuer_Muster.pdf]] Erste Version 2013, lokale Kopie

Nachdem der prinzipielle Ablauf sowie Aufbau einer SAT-Anlage sehr ähnelt, was bei Hausverwaltungen mittlerweile gut bekannt ist, werden Vorlagen dafür angeboten die genauso entsprechend verwendet werden können:
* [https://www.wienerwohnen.at/dms/workspace/SpacesStore/c60ff60f-478f-4742-9ab2-daef83e13f96/2330_sd0103_Ansuchen_Satellitenempfangsantenne.pdf Ansuchen Satellitenantenne] Stadt Wien - Wiener Wohnen
* [http://www.ah-wohnen.at/bewilligungen-.74.html Antragsformular zur SAT - Anlagenerrichtung] Gem. Siedlungs-Genossenschaft Altmannsdorf und Hetzendorf

== '''Gesetzestext (Berücksichtigter Stand der Gesetzgebung: 1. Juli 2011)''' ==
=== ''§ 9 MRG Veränderung (Verbesserung) des Mietgegenstandes'' ===
(1) Der Hauptmieter hat eine von ihm beabsichtigte wesentliche Veränderung (Verbesserung) des Mietgegenstandes dem Vermieter anzuzeigen. Lehnt der Vermieter nicht innerhalb von zwei Monaten nach Zugang der Anzeige die beabsichtigte Veränderung ab, so gilt seine Zustimmung als erteilt. Der Vermieter kann seine Zustimmung und eine erforderliche Antragstellung bei der Baubehörde nicht verweigern wenn,

1. die Veränderung dem jeweiligen Stand der Technik entspricht,
2. die Veränderung der Übung des Verkehrs entspricht und einem wichtigen Interesse des Hauptmieters dient,
3. die einwandfreie Ausführung der Veränderung gewährleistet ist,
4. der Hauptmieter die Kosten trägt,
5. durch die Veränderung keine Beeinträchtigung schutzwürdiger Interessen des Vermieters oder eines anderen Mieters zu besorgen ist,
6. durch die Veränderung keine Schädigung des Hauses, im besonderen keine Beeinträchtigung der äußeren Erscheinung des Hauses, erfolgt,
7. die Veränderung keine Gefahr für die Sicherheit von Personen und Sachen bewirkt.

(2) Die Voraussetzung des Abs. 1 Z 2 ist jedenfalls gegeben, wenn es sich handelt um

1. die Errichtung oder die den Erfordernissen der Haushaltsführung dienende Umgestaltung von Wasserleitungs-, Lichtleitungs-, Gasleitungs-, Beheizungs- (einschließlich der Einrichtung von zentralen Wärmeversorgungsanlagen) oder sanitären Anlagen,
2. die der Senkung des Energieverbrauchs dienende Ausgestaltung eines Mietgegenstandes,
3. die Verbesserungen, die von einer Gebietskörperschaft aus öffentlichen Mitteln gefördert werden,
4. die Einleitung eines Fernsprechanschlusses oder
5. die Anbringung der nach dem Stand der Technik notwendigen Antennen und sonstigen Einrichtungen für den Hörfunk- und Fernsehempfang sowie für Multimediadienste, sofern der Anschluß an eine bestehende Einrichtung nicht möglich oder nicht zumutbar ist.

(3) Handelt es sich um eine wesentliche Veränderung (Verbesserung), die nicht im Abs. 2 angeführt ist, so kann der Vermieter seine Zustimmung von der Verpflichtung des Hauptmieters zur Wiederherstellung des früheren Zustandes bei der Zurückstellung des Mietgegenstandes abhängig machen.

Referenzen:
* [http://www.jusline.at/9_Ver%C3%A4nderung_%28Verbesserung%29_des_Mietgegenstandes_MRG.html jusline.at]
* [https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40026132/NOR40026132.html ris.bka.gv.at]

== '''Weiterführende Informationen beim Magistrat der Stadt Wien''' ==
* MA50 Wohnbauförderung und Schlichtungsstelle für wohnrechtliche Angelegenheiten
**[http://www.wien.gv.at/amtshelfer/bauen-wohnen/schlichtungsstelle/mietrechtsverfahren/veraenderung-mietgegenstand.html Veränderung (Verbesserung) des Mietgegenstandes]
* MA19 Architektur und Stadtgestaltung
** [http://www.wien.gv.at/amtshelfer/bauen-wohnen/stadtentwicklung/baulicheanlagen/satellitenantenne.html Satellitenantennen - Architektonische Begutachtung]
** [http://www.wien.gv.at/stadtentwicklung/grundlagen/schutzzonen/index.html Schutzzonen]

Regionen/Wien/Mitmachen

2023-03-11T09:07:38Z

Stratuscumulus: /* Schritt 1: Wiki */ Link zum Leitfaden wurde entfernt, Haftungsrisiko, da nicht durch offiziell fachkundige Personen/Firma begutachtet und abgesegnet; Satz vereinfacht

__NOTOC__
Wir freuen uns über jegliche Mitarbeit, ob du nun einen Funkknoten aufbaust, oder vielleicht technisches, soziales, … Know-How beisteuerst. Wir brauchen jede Hilfe! Üblicherweise rennt das so ab: (siehe auch [[Erste_Schritte]])

== Schritt 1: Wiki ==
Mach Dich hier im Wiki schlau oder frage in der Community nach Tipps & Tricks. Bei den "Monatlichen Montagstreffen" (MoMo) kannst Du auch alle Fragen stellen (siehe unten).

== Schritt 2: MoMo ==
Du kommst zum [[Regionen/Wien/MoMo_(Monatliches_Montagstreffen) | monatlichen Montagstreffen]] (MoMo) online oder im Volkskundemuseum [https://www.volkskundemuseum.at]. Dort helfen wir dir:
* bei technischen Details und Problemen
* bei der Planung
* mit Tipps für Gespräche mit der [[Hausverwaltungen|Hausverwaltung]]
* … und vielem mehr!

== Schritt 3: Messen & Aufbau ==
Dann geht's bei Dir aufs Dach mit Antenne, WLAN-Karte und Notebook. So sieht du, ob Du FunkFeuer-Empfang hast. Wenn alles passt, kann es mit dem Node-Aufbau losgehen. Ideal ist es, zwei Richtfunkstrecken und einen <s>Rundstrahler</s> weiteren interessanten Sektor aufzubauen.

== Schritt 4: In Kontakt bleiben + Knoten-Wartung ==
Der soziale Kontakt ist ein wichtiger Aspekt dieses Projektes! Auch technisch gibt es immer wieder neue Entwicklungen, über die Du Bescheid wissen solltest. Bitte melde Dich auf den [https://lists.funkfeuer.at/mailman/listinfo Mailinglisten] an (zumindest auf <code>discuss</code>) und schau im [[Chat]] und im [https://forum.funkfeuer.at/ Forum] vorbei!

Bitte denke daran, dass Du für deinen Knoten selbst verantwortlich bist, insbesondere dafür, die Software auf deinem Router sicher und aktuell zu halten! Wenn Du dabei Hilfe brauchst, frag einfach, es findet sich bestimmt jemand!

Regionen/Wien/Mitmachen

2022-12-22T15:05:15Z

Stratuscumulus: /* Schritt 2: MoMo */ Ort nun sichtbar

__NOTOC__
Wir freuen uns über jegliche Mitarbeit, ob du nun einen Funkknoten aufbaust, oder vielleicht technisches, soziales, … Know-How beisteuerst. Wir brauchen jede Hilfe! Üblicherweise rennt das so ab: (siehe auch [[Erste_Schritte]])

== Schritt 1: Leitfaden und Wiki ==
Mach Dich im [https://0xff-lroe.gitlab.io/kompakt-leitfaden/0.2/index.html '''FunkFeuer-Leitfaden''': Ein Quick-Start Guide zum eigenen Knoten] und hier im Wiki schlau. Alle nötigen Information, die vorab gebraucht werden, bringst Du bitte zum MoMo mit (siehe unten). Messequipment bekommst Du dort ebenfalls gegen Voranmeldung über die Mailingliste.

== Schritt 2: MoMo ==
Du kommst zum [[Regionen/Wien/MoMo_(Monatliches_Montagstreffen) | monatlichen Montagstreffen]] (MoMo) online oder im Volkskundemuseum [https://www.volkskundemuseum.at]. Dort helfen wir dir:
* bei technischen Details und Problemen
* bei der Planung
* mit Tipps für Gespräche mit der [[Hausverwaltungen|Hausverwaltung]]
* … und vielem mehr!

== Schritt 3: Messen & Aufbau ==
Dann geht's bei Dir aufs Dach mit Antenne, WLAN-Karte und Notebook. So sieht du, ob Du FunkFeuer-Empfang hast. Wenn alles passt, kann es mit dem Node-Aufbau losgehen. Ideal ist es, zwei Richtfunkstrecken und einen <s>Rundstrahler</s> weiteren interessanten Sektor aufzubauen.

== Schritt 4: In Kontakt bleiben + Knoten-Wartung ==
Der soziale Kontakt ist ein wichtiger Aspekt dieses Projektes! Auch technisch gibt es immer wieder neue Entwicklungen, über die Du Bescheid wissen solltest. Bitte melde Dich auf den [https://lists.funkfeuer.at/mailman/listinfo Mailinglisten] an (zumindest auf <code>discuss</code>) und schau im [[Chat]] und im [https://forum.funkfeuer.at/ Forum] vorbei!

Bitte denke daran, dass Du für deinen Knoten selbst verantwortlich bist, insbesondere dafür, die Software auf deinem Router sicher und aktuell zu halten! Wenn Du dabei Hilfe brauchst, frag einfach, es findet sich bestimmt jemand!

Regionen/Wien/Mitmachen

2022-12-22T15:03:24Z

Stratuscumulus: /* Schritt 2: MoMo */ Ort geändert

__NOTOC__
Wir freuen uns über jegliche Mitarbeit, ob du nun einen Funkknoten aufbaust, oder vielleicht technisches, soziales, … Know-How beisteuerst. Wir brauchen jede Hilfe! Üblicherweise rennt das so ab: (siehe auch [[Erste_Schritte]])

== Schritt 1: Leitfaden und Wiki ==
Mach Dich im [https://0xff-lroe.gitlab.io/kompakt-leitfaden/0.2/index.html '''FunkFeuer-Leitfaden''': Ein Quick-Start Guide zum eigenen Knoten] und hier im Wiki schlau. Alle nötigen Information, die vorab gebraucht werden, bringst Du bitte zum MoMo mit (siehe unten). Messequipment bekommst Du dort ebenfalls gegen Voranmeldung über die Mailingliste.

== Schritt 2: MoMo ==
Du kommst zum [[Regionen/Wien/MoMo_(Monatliches_Montagstreffen) | monatlichen Montagstreffen]] (MoMo) online oder im [https://www.volkskundemuseum.at/]. Dort helfen wir dir:
* bei technischen Details und Problemen
* bei der Planung
* mit Tipps für Gespräche mit der [[Hausverwaltungen|Hausverwaltung]]
* … und vielem mehr!

== Schritt 3: Messen & Aufbau ==
Dann geht's bei Dir aufs Dach mit Antenne, WLAN-Karte und Notebook. So sieht du, ob Du FunkFeuer-Empfang hast. Wenn alles passt, kann es mit dem Node-Aufbau losgehen. Ideal ist es, zwei Richtfunkstrecken und einen <s>Rundstrahler</s> weiteren interessanten Sektor aufzubauen.

== Schritt 4: In Kontakt bleiben + Knoten-Wartung ==
Der soziale Kontakt ist ein wichtiger Aspekt dieses Projektes! Auch technisch gibt es immer wieder neue Entwicklungen, über die Du Bescheid wissen solltest. Bitte melde Dich auf den [https://lists.funkfeuer.at/mailman/listinfo Mailinglisten] an (zumindest auf <code>discuss</code>) und schau im [[Chat]] und im [https://forum.funkfeuer.at/ Forum] vorbei!

Bitte denke daran, dass Du für deinen Knoten selbst verantwortlich bist, insbesondere dafür, die Software auf deinem Router sicher und aktuell zu halten! Wenn Du dabei Hilfe brauchst, frag einfach, es findet sich bestimmt jemand!

Projekte/Datenschutz

2021-05-27T14:55:38Z

Stratuscumulus: /* Muster-Entwürfe */ Twitter

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:Datenschutzhinweise_Facebook_DE.pdf]]

* [[Datei:Entwurf_Datenschutzerklärung_Twitter.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
1 www_wiki_new_mw_UserID
2 www_wiki_new_mw_UserName
3 www_wiki_new_mw__session
4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?
* Wiki
* Map

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Datei:Entwurf Datenschutzerklärung Twitter.pdf

2021-05-27T14:54:47Z

Stratuscumulus:

Projekte/Datenschutz

2021-05-27T14:44:27Z

Stratuscumulus: /* Muster-Entwürfe */

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:Datenschutzhinweise_Facebook_DE.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
1 www_wiki_new_mw_UserID
2 www_wiki_new_mw_UserName
3 www_wiki_new_mw__session
4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?
* Wiki
* Map

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-27T14:42:25Z

Stratuscumulus: /* Muster-Entwürfe */ Facebook hinzugefügt

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:Datenschutzhinweise_Facebook_DE]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
1 www_wiki_new_mw_UserID
2 www_wiki_new_mw_UserName
3 www_wiki_new_mw__session
4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?
* Wiki
* Map

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Datei:Datenschutzhinweise Facebook DE.pdf

2021-05-27T14:41:07Z

Stratuscumulus:

Projekte/Datenschutz

2021-05-25T17:57:46Z

Stratuscumulus: /* Cookies */

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
1 www_wiki_new_mw_UserID
2 www_wiki_new_mw_UserName
3 www_wiki_new_mw__session
4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?
* Wiki
* Map

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-25T17:57:17Z

Stratuscumulus: /* Cookies */

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
* 1 www_wiki_new_mw_UserID
* 2 www_wiki_new_mw_UserName
* 3 www_wiki_new_mw__session
* 4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?
* Wiki
* Map

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-25T17:56:33Z

Stratuscumulus: /* Cookies */

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
* 1 www_wiki_new_mw_UserID
* 2 www_wiki_new_mw_UserName
* 3 www_wiki_new_mw__session
* 4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-25T17:56:12Z

Stratuscumulus: /* Wiki-Account */ Cookies

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

* Gleiche Fragen wie oben

=== Cookies ===
1 www_wiki_new_mw_UserID
2 www_wiki_new_mw_UserName
3 www_wiki_new_mw__session
4 www_wiki_new_mw_Token

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-24T20:16:01Z

Stratuscumulus: GitHub und GitLab - Frage nach Nutzung innerhalb FFs

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== GitHub ==

* Wie wird das genutzt?

== GitLab ==

* Wie wird das genutzt?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2021-05-24T19:12:35Z

Stratuscumulus: /* Muster-Entwürfe */ Datenschutzerklärung

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Datenschutzerklärung_Entwurf.pdf]]

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Datei:Datenschutzerklärung Entwurf.pdf

2021-05-24T19:11:05Z

Stratuscumulus: Datenschutzerklärung_Entwurf

== Beschreibung ==
Datenschutzerklärung_Entwurf

Projekte/Datenschutz

2020-06-02T12:56:18Z

Stratuscumulus: Einfügen von Entwürfen zu datenschutzrechtlichen Dokumenten

== Muster-Entwürfe ==

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

* [[Datei:Auftragsdatenverarbeitungsvertrag_Muster.pdf]]

* [[Datei:Datenschutzerkl%C3%A4rung_Entwurf_01.pdf]]

* [[Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf]]

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf

2020-06-02T12:50:14Z

Stratuscumulus: EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher auf Basis des Musters der WKO. Dieses Muster wird im Laufe der Zeit durch den Verein befüllt werden, bitte in Absprache mit mir.

== Beschreibung ==
EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher auf Basis des Musters der WKO. Dieses Muster wird im Laufe der Zeit durch den Verein befüllt werden, bitte in Absprache mit mir.

Datei:Datenschutzerklärung Entwurf 01.pdf

2020-06-02T12:48:40Z

Stratuscumulus: Entwurf einer Datenschutzerklärung für die Website. Die Datenschutzerklärung wird mit Informationen angereichert, welche im Projekt "Datenschutz" erhoben werden.

== Beschreibung ==
Entwurf einer Datenschutzerklärung für die Website. Die Datenschutzerklärung wird mit Informationen angereichert, welche im Projekt "Datenschutz" erhoben werden.

Datei:Auftragsdatenverarbeitungsvertrag Muster.pdf

2020-06-02T12:44:07Z

Stratuscumulus: Auftragsdatenverarbeitungsvertrag_Muster wie WKO abgeändert durch mich, weitere Änderungen oder die Verwendung dieses Musters sind mit mir abzustimmen

== Beschreibung ==
Auftragsdatenverarbeitungsvertrag_Muster wie WKO
abgeändert durch mich, weitere Änderungen oder die Verwendung dieses Musters sind mit mir abzustimmen

Projekte/Datenschutz

2020-05-19T22:17:54Z

Stratuscumulus: Erläuterung zur Stellung von Datenschutzbeauftragten/-koordinatoren

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

== Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren ==
'''Artikel 37 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''benennen''''' auf jeden Fall einen '''''Datenschutzbeauftragten''''', '''''wenn'''''

[...]

b) die '''''Kerntätigkeit''''' des Verantwortlichen oder des Auftragsverarbeiters '''''in der Durchführung von Verarbeitungsvorgängen''''' besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der '''''Verantwortliche''''' oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

'''Artikel 38 DSGVO'''

(1) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', dass der '''''Datenschutzbeauftragte ordnungsgemäß und frühzeitig''''' in '''''alle''''' mit dem Schutz personenbezogener Daten zusammenhängenden '''''Fragen eingebunden wird'''''.

(2) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''unterstützen''''' den Datenschutzbeauftragten '''''bei der Erfüllung seiner Aufgaben''''' gemäß Artikel 39, '''''indem''''' sie die ''''''für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen'''''' sowie die zur Erhaltung seines Fachwissens '''''erforderlichen Ressourcen zur Verfügung stellen'''''.

(3) Der '''''Verantwortliche''''' und der Auftragsverarbeiter '''''stellen sicher''''', '''''dass der Datenschutzbeauftragte''''' bei der Erfüllung seiner Aufgaben ''''''keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält''''''. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte '''''berichtet unmittelbar der höchsten Managementebene des Verantwortlichen''''' oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann '''''andere Aufgaben und Pflichten''''' wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten '''''nicht zu einem Interessenkonflikt''''' führen.

Siehe dazu auch [https://www.kt.at/wp-content/uploads/2017/03/Stellung-und-Aufgaben-von-Datenschutzbeauftragten.pdf]

Projekte/Datenschutz

2020-05-18T21:53:14Z

Stratuscumulus: /* Bildergalerie im Wiki */ Anm. zu Einwilligungserklärungen

Projekte/Datenschutz

2020-05-18T10:14:47Z

Stratuscumulus: Social media Fragen hinzugefügt

Projekte/Datenschutz

2020-05-17T22:19:54Z

Stratuscumulus:

Projekte/Datenschutz

2020-05-17T22:05:24Z

Stratuscumulus:

Projekte/Datenschutz

2020-05-17T22:02:03Z

Stratuscumulus: Die Seite wurde neu angelegt: „== Grundsätzlich == * Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.…“