Meinungsbild - Fhem statistics (die 2.)

[Martin Fischer]

Hallo @all,

am 31.10.2012 habe ich eine Meinungsbildabfrage zu einer angedachten
Erweiterung der update-Funktion gestartet.

Ich bedanke mich an dieser Stelle nochmals bei allen Teilnehmern und auch für
die eine oder andere hilfreiche Anregung.

Hier nochmal zur Erinnerung die Beschreibung der Erweiterung:
Die update-Funktion soll dahingehend erweitert werden, das im Rahmen eines
Updates anonymisiert Daten zu der installierten Fhem Version gesammelt werden.
Diese Daten sollen dazu dienen um Entwicklern aber auch dem interessierten
Anwender einen Überblick über die eingesetzte Hardware, Perlversion sowie die
jeweilge Anzahl der definierten Module zu verschaffen.

Die Statistik liefert ein ziemlich genaues Bild der Fhem-Umgebung um ggf.
Schwerpunkte im Rahmen der Entwicklungen abzuleiten.

Ich habe nun die letzten Tage genutzt um alles soweit umzusetzen, der
"Prototyp" ist so gut wie fertig.

Im Rahmen der ersten Abfrage haben einige von Euch den Wunsch geäussert, diese
Daten nicht ungefragt zu versenden. Andere haben widerum geäussert, das sie
damit kein Problem hätten.

Da natürlich eine statistische Erhebung nur dann sinnvolle Rückschlüsse
zulässt, wenn möglichst viele daran teilnehmen, möchte ich heute nochmals
final ein abschliessendes Meinungsbild abfragen.

Konkret: Übermittlung der Daten per default _an_

Ich würde mich freuen, wenn jeder der seine Meinung kundtun möchte, bitte nur
kurz und knapp seinen Standpunkt schildert. Eine "Grundsatzdiskussion" möchte
ich nach Möglichkeit an dieser Stelle vermeiden. Rein rechtlich gesehen, ist
die Erhebung der Daten unproblematisch, da keinerlei personenbezogenen Daten
erfasst werden.

Bevor Ihr nun aber Eure Meinungen kundtun, will ich Euch kurz den aktuellen
Stand und die Funktionsweise erklären:

fheminfo

"fheminfo" wird ein neuer Command in Fhem. Durch den Aufruf von "fheminfo"
kann der Anwender jederzeit die Informationen einsehen, die im Rahmen eines
Updates übertragen werden. Hier die aktuelle Ausgabe von fheminfo von einem
Produktivsystem:

fhem> fheminfo
Fhem info:
  Release  : 5.3
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : i686-linux-gnu-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : 2a5212a53f8c5c11771a973315213bfe

Defined modules:
  ACU        : 1
  CUL        : 1
  CUL_FHTTK  : 12
  CUL_HM     : 66
  CUL_WS     : 4
  FHEM2FHEM  : 1
  FHEMWEB    : 3
  FHT        : 9
  FHZ        : 1
  FS20       : 23
  FileLog    : 31
  Global     : 1
  HCS        : 1
  HMLAN      : 1
  HMS        : 3
  IPCAM      : 4
  KS300      : 1
  OWAD       : 1
  OWCOUNT    : 4
  OWID       : 1
  OWMULTI    : 1
  OWSWITCH   : 2
  OWTHERM    : 8
  OWX        : 1
  Twilight   : 1
  Weather    : 1
  at         : 4
  autocreate : 1
  dummy      : 23
  notify     : 54
  structure  : 3
  telnet     : 2
  watchdog   : 9
  weblink    : 17

Defined models per module:
  CUL        : CUN
  CUL_FHTTK  : FHT80TF
  CUL_HM     : HM-CC-TC,HM-CC-VD,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-SW1-
PL,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC_Dim1TPBU-FM,HM-OU-CFM-PL,HM-OU-LED16,HM-
PBI-4-FM,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SD,HM-SWI-3-FM,HM-Sen-MDIR-O
  CUL_WS     : S555TH
  FHT        : fht80b
  FS20       : fs20pira,fs20s16,fs20s4a,fs20sd,fs20st
  HMS        : hms100-mg,hms100-tf,hms100-wd
  KS300      : ks300
  OWSWITCH   : DS2413

Die obigen Informationen sind selbsterklärend, mit Ausnahme der "uniqueID".
Die "uniqueID" wird benötigt um die jeweiligen Installationen auseinander zu
halten. Sie besteht aus 16 zufällig erzeugten Hashpaaren und sollte somit
weitgehends einmalig sein.

Die "uniqueID" wird beim ersten Aufruf automatisch erzeugt und als neues
globales Attribut in der Fhem Konfiguration gespeichert. Zusätzlich wird ein
weiteres globales Attribut "sendStatistics" angelegt, mit dem der Anwender
jederzeit entscheiden kann, ob die obige Statistik übermittelt werden soll.
Das ganze sieht dann in der Konfiguration wie folgt aus:

attr global uniqueID 2a5212a53f8c5c11771a973315213bfe
attr global sendStatistics 1

Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
"sendStatistics" per default auf "1", also auf "immer übermitteln" setzen.
Somit würde relativ schnell eine "gut gefüllte" Statistik zusammenkommen.

Was passiert nun Serverseitig?

Auf fhem.de werden obige Daten in einer SQLite Datenbank zusammengetragen. Die
Datenbank hat zur Zeit vier Tabellen:
fhem_nodes:
beinhaltet die unique id, ein "lastSeen" Feld, sowie die ip-adresse. Das
"lastSeen" dient zur (zukünftigen) Filterung von "Karteileichen". Man kann
also die Statistik anhand dieses Feldes auch "eingrenzen" (berücksichtige alle
Einträge die nicht älter als 1 Jahr sind) aber auch z.B. (wenn
"sendStatistics" per default auf "1" steht) ableiten wieviele Updates pro Tag
/ Woche / Monat / Jahr durchgeführt wurden. Aber auch die Anzahl der
Neuinstallationen könnte man daraus ableiten. Die IP-Adresse dient zur
Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus lässt sich
dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit unterstützen
soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob die
tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten Stadt in
Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der gerade mal
ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
unproblematisch.

fhem_system:
beinhaltet neben der "uniqueID" alle obigen Punkte bzgl. "release", "OS",
"Architektur", "branch" sowie "Perlversion".

fhem_modules:
beinhaltet neben der "uniqueID" alle von der jeweiligen Fhem-Installation
definierten Module inkl. der Anzahl der Definitionen, wie aus der obigen
Übersicht zu entnehmen ist. Diese Daten sind dynamisch, d.h. sie werden
jedesmal überschrieben. Also wenn "meine" "uniqueID" heute übermittelt, das
ich 28 CUL_HM devices definiert habe, ich aber morgen 10 ausser Betrieb nehme,
dann werden auch nur 18 devices erfasst. Dadurch ist die Statistik immer
aktuell und z.B. "Testdefinitionen" oder die Löschung eines devices fällt
somit auch aus der Statistik.

fhem_models:
beinhaltet neben der "uniqueID" alle Modelltypen, die im Rahmen einer
Definition gesetzt sind. Bisher muss das Attribut "model" manuell durch den
Anwender gesetzt werden, sofern das jeweilige Fhem-Modul dieses Attribut
unterstützt. Ausnahme hierbei CUL_HM: hier wird das Model direkt aus der
Hardware ausgelesen und gesetzt. Somit hat man eine sehr gute Übersicht der
eingesetzten Hardware, allerdings ohne einer Gesamtzahl.

"fheminfo" soll neben der Möglichkeit über einen Befehlsaufruf in der
Commandline direkt am Ende eines Updates automatisiert aufgerufen werden. In
der Commandline unterstützt "fheminfo" das Argument "send", also "fheminfo
send". Somit hat man die Möglichkeit die Übermittlung auch manuell
anzustossen.

Die "uniqueID" kann / sollte bei einer komplettem "Reinstallation" nach
möglichkeit immer "mitgenommen", also wiederverwendet werden. Somit entsteht
keine "Karteileiche", da im Falle einer nicht vorhandenen "uniqueID" in der
Konfiguration von Fhem diese wieder neu erzeugt werden würde.

Um Euch einen Eindruck zu vermitteln wie die Daten künftig "aufbereitet"
werden sollen, füge ich einen Screenshot bei. Dies ist der erste "Entwurf" mit
ein paar Testdaten (nein ich habe kein Windows ).

So, nun hoffe ich auf rege Teilnahme und denke ich konnte die Funktionsweise
transparent "rüber bringen", so dass die meisten Bedenken aus dem Wege geräumt
sind und dem automatischem Übertragen als default Einstellung nichts entgegen
steht.

In diesem Sinne...

Gruß Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Halte ich für sinnvoll, gut und unbedenklich.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich schliesse mich LaLeLu an.... ich halte das auch für ok...

Am Samstag, 1. Dezember 2012 09:58:25 UTC+1 schrieb LaLeLu:
> Halte ich für sinnvoll, gut und unbedenklich.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Hausautomat]

                                                         

UniqID zusammen mit IP -hm?

Ich verstehe Deinen Ansatz, aber kannst Du nicht einfach nur das Ergebnis der IP, also den Ort oder besser wirklich nur das Land speichern?
Sonst würde ich eher zu default 'no' tendieren wollen.

Vielen dank.




Martin Fischer schrieb:

>Hallo @all,
>
>am 31.10.2012 habe ich eine Meinungsbildabfrage zu einer angedachten
>Erweiterung der update-Funktion gestartet.
>
>Ich bedanke mich an dieser Stelle nochmals bei allen Teilnehmern und
>auch für
>die eine oder andere hilfreiche Anregung.
>
>Hier nochmal zur Erinnerung die Beschreibung der Erweiterung:
>Die update-Funktion soll dahingehend erweitert werden, das im Rahmen
>eines
>Updates anonymisiert Daten zu der installierten Fhem Version gesammelt
>werden.
>Diese Daten sollen dazu dienen um Entwicklern aber auch dem
>interessierten
>Anwender einen Überblick über die eingesetzte Hardware, Perlversion
>sowie die
>jeweilge Anzahl der definierten Module zu verschaffen.
>
>Die Statistik liefert ein ziemlich genaues Bild der Fhem-Umgebung um
>ggf.
>Schwerpunkte im Rahmen der Entwicklungen abzuleiten.
>
>Ich habe nun die letzten Tage genutzt um alles soweit umzusetzen, der
>"Prototyp" ist so gut wie fertig.
>
>Im Rahmen der ersten Abfrage haben einige von Euch den Wunsch
>geäussert, diese
>Daten nicht ungefragt zu versenden. Andere haben widerum geäussert, das
>sie
>damit kein Problem hätten.
>
>Da natürlich eine statistische Erhebung nur dann sinnvolle Rückschlüsse
>
>zulässt, wenn möglichst viele daran teilnehmen, möchte ich heute
>nochmals
>final ein abschliessendes Meinungsbild abfragen.
>
>Konkret: Übermittlung der Daten per default _an_
>
>Ich würde mich freuen, wenn jeder der seine Meinung kundtun möchte,
>bitte nur
>kurz und knapp seinen Standpunkt schildert. Eine "Grundsatzdiskussion"
>möchte
>ich nach Möglichkeit an dieser Stelle vermeiden. Rein rechtlich
>gesehen, ist
>die Erhebung der Daten unproblematisch, da keinerlei personenbezogenen
>Daten
>erfasst werden.
>
>Bevor Ihr nun aber Eure Meinungen kundtun, will ich Euch kurz den
>aktuellen
>Stand und die Funktionsweise erklären:
>
>fheminfo
>
>"fheminfo" wird ein neuer Command in Fhem. Durch den Aufruf von
>"fheminfo"
>kann der Anwender jederzeit die Informationen einsehen, die im Rahmen
>eines
>Updates übertragen werden. Hier die aktuelle Ausgabe von fheminfo von
>einem
>Produktivsystem:
>
>fhem> fheminfo
>Fhem info:
>  Release  : 5.3
>  Branch   : DEVELOPMENT
>  OS       : linux
>  Arch     : i686-linux-gnu-thread-multi-64int
>  Perl     : v5.14.2
>  uniqueID : 2a5212a53f8c5c11771a973315213bfe
>
>Defined modules:
>  ACU        : 1
>  CUL        : 1
>  CUL_FHTTK  : 12
>  CUL_HM     : 66
>  CUL_WS     : 4
>  FHEM2FHEM  : 1
>  FHEMWEB    : 3
>  FHT        : 9
>  FHZ        : 1
>  FS20       : 23
>  FileLog    : 31
>  Global     : 1
>  HCS        : 1
>  HMLAN      : 1
>  HMS        : 3
>  IPCAM      : 4
>  KS300      : 1
>  OWAD       : 1
>  OWCOUNT    : 4
>  OWID       : 1
>  OWMULTI    : 1
>  OWSWITCH   : 2
>  OWTHERM    : 8
>  OWX        : 1
>  Twilight   : 1
>  Weather    : 1
>  at         : 4
>  autocreate : 1
>  dummy      : 23
>  notify     : 54
>  structure  : 3
>  telnet     : 2
>  watchdog   : 9
>  weblink    : 17
>
>Defined models per module:
>  CUL        : CUN
>  CUL_FHTTK  : FHT80TF
>CUL_HM     : HM-CC-TC,HM-CC-VD,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-SW1-
>PL,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC_Dim1TPBU-FM,HM-OU-CFM-PL,HM-OU-LED16,HM-
>PBI-4-FM,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SD,HM-SWI-3-FM,HM-Sen-MDIR-O
>  CUL_WS     : S555TH
>  FHT        : fht80b
>  FS20       : fs20pira,fs20s16,fs20s4a,fs20sd,fs20st
>  HMS        : hms100-mg,hms100-tf,hms100-wd
>  KS300      : ks300
>  OWSWITCH   : DS2413
>
>Die obigen Informationen sind selbsterklärend, mit Ausnahme der
>"uniqueID".
>Die "uniqueID" wird benötigt um die jeweiligen Installationen
>auseinander zu
>halten. Sie besteht aus 16 zufällig erzeugten Hashpaaren und sollte
>somit
>weitgehends einmalig sein.
>
>Die "uniqueID" wird beim ersten Aufruf automatisch erzeugt und als
>neues
>globales Attribut in der Fhem Konfiguration gespeichert. Zusätzlich
>wird ein
>weiteres globales Attribut "sendStatistics" angelegt, mit dem der
>Anwender
>jederzeit entscheiden kann, ob die obige Statistik übermittelt werden
>soll.
>Das ganze sieht dann in der Konfiguration wie folgt aus:
>
>attr global uniqueID 2a5212a53f8c5c11771a973315213bfe
>attr global sendStatistics 1
>
>Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
>"sendStatistics" per default auf "1", also auf "immer übermitteln"
>setzen.
>Somit würde relativ schnell eine "gut gefüllte" Statistik
>zusammenkommen.
>
>Was passiert nun Serverseitig?
>
>Auf fhem.de werden obige Daten in einer SQLite Datenbank
>zusammengetragen. Die
>Datenbank hat zur Zeit vier Tabellen:
>fhem_nodes:
>beinhaltet die unique id, ein "lastSeen" Feld, sowie die ip-adresse.
>Das
>"lastSeen" dient zur (zukünftigen) Filterung von "Karteileichen". Man
>kann
>also die Statistik anhand dieses Feldes auch "eingrenzen"
>(berücksichtige alle
>Einträge die nicht älter als 1 Jahr sind) aber auch z.B. (wenn
>"sendStatistics" per default auf "1" steht) ableiten wieviele Updates
>pro Tag
>/ Woche / Monat / Jahr durchgeführt wurden. Aber auch die Anzahl der
>Neuinstallationen könnte man daraus ableiten. Die IP-Adresse dient zur
>Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus
>lässt sich
>dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit
>unterstützen
>soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob
>die
>tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten
>Stadt in
>Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der
>gerade mal
>ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
>unproblematisch.
>
>fhem_system:
>beinhaltet neben der "uniqueID" alle obigen Punkte bzgl. "release",
>"OS",
>"Architektur", "branch" sowie "Perlversion".
>
>fhem_modules:
>beinhaltet neben der "uniqueID" alle von der jeweiligen
>Fhem-Installation
>definierten Module inkl. der Anzahl der Definitionen, wie aus der
>obigen
>Übersicht zu entnehmen ist. Diese Daten sind dynamisch, d.h. sie werden
>
>jedesmal überschrieben. Also wenn "meine" "uniqueID" heute übermittelt,
>das
>ich 28 CUL_HM devices definiert habe, ich aber morgen 10 ausser Betrieb
>nehme,
>dann werden auch nur 18 devices erfasst. Dadurch ist die Statistik
>immer
>aktuell und z.B. "Testdefinitionen" oder die Löschung eines devices
>fällt
>somit auch aus der Statistik.
>
>fhem_models:
>beinhaltet neben der "uniqueID" alle Modelltypen, die im Rahmen einer
>Definition gesetzt sind. Bisher muss das Attribut "model" manuell durch
>den
>Anwender gesetzt werden, sofern das jeweilige Fhem-Modul dieses
>Attribut
>unterstützt. Ausnahme hierbei CUL_HM: hier wird das Model direkt aus
>der
>Hardware ausgelesen und gesetzt. Somit hat man eine sehr gute Übersicht
>der
>eingesetzten Hardware, allerdings ohne einer Gesamtzahl.
>
>"fheminfo" soll neben der Möglichkeit über einen Befehlsaufruf in der
>Commandline direkt am Ende eines Updates automatisiert aufgerufen
>werden. In
>der Commandline unterstützt "fheminfo" das Argument "send", also
>"fheminfo
>send". Somit hat man die Möglichkeit die Übermittlung auch manuell
>anzustossen.
>
>Die "uniqueID" kann / sollte bei einer komplettem "Reinstallation" nach
>
>möglichkeit immer "mitgenommen", also wiederverwendet werden. Somit
>entsteht
>keine "Karteileiche", da im Falle einer nicht vorhandenen "uniqueID" in
>der
>Konfiguration von Fhem diese wieder neu erzeugt werden würde.
>
>Um Euch einen Eindruck zu vermitteln wie die Daten künftig
>"aufbereitet"
>werden sollen, füge ich einen Screenshot bei. Dies ist der erste
>"Entwurf" mit
>ein paar Testdaten (nein ich habe kein Windows ).
>
>So, nun hoffe ich auf rege Teilnahme und denke ich konnte die
>Funktionsweise
>transparent "rüber bringen", so dass die meisten Bedenken aus dem Wege
>geräumt
>sind und dem automatischem Übertragen als default Einstellung nichts
>entgegen
>steht.
>
>In diesem Sinne...
>
>Gruß Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo Martin,

Am 01.12.2012 05:10, schrieb Martin Fischer:
> Konkret: Übermittlung der Daten per default _an_
>
für mich in Ordnung.

> fheminfo
>
>
hierzu drei Anmerkungen:
- In der c't gab es vor längerer Zeit einen Aufsatz zu der Frage, ob die
IP-Adresse ein personenbezogenes Datum sei. Diese Frage konnte nicht
verneint werden und die Empfehlung war m.W., IP-Adressen, wenn
überhaupt, nur pseudonymisiert zu speichern. Ich schlage vor, aus der
IP-Adresse die Geolokalisierung abzuleiten und dann wegzuwerfen.
- Ich schlage vor, zu jeder UniqueID einen Timestamp mitzuführen. Neben
der Möglichkeit, die Entwicklung und Schwerpunkte im Laufe der Jahre
mitzuverfolgen gibt es uns auch die Möglichkeit, über ein Aging der
Einträge potentiell nicht mehr aktive Installationen optional nicht mehr
in den Analysen zu berücksichtigen.
- Schreibt update die UniqueID hart in die Konfigurationsdatei nach dem
Verfahren, was angewendet wird, wenn der Save-Knopf gedrückt wird? Das
möchte ich nicht - ich habe den Save-Knopf bei mir verboten, weil ich
befürchte, daß meine Konfigurationsdateien dabei durcheinanderkommen.

Viele Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ohne Speicherung der übermittelten IP, also nur die Geo-Daten währe ich
auch dafür. IP-Adressen können Netzbetreiberintern einer Person zugeordnet
werden (innerhalb einer bestimmten Zeitspamme). Auch wenn es heist, dass
das nur die Polizei auf gerichtlicher Anordnung usw. darf, steht das
"könnte" nachwievor im Raum.

Zumal, was bringt euch die IP, da die sich im Regelfall aller 24h ändert.
Die könnt ihr für keinerlei Statistiken verwenden.

Gruß
Markus

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hallo boris,

Am Samstag, 1. Dezember 2012, 10:36:19 schrieb Dr. Boris Neubert:
> [...]
> - Ich schlage vor, zu jeder UniqueID einen Timestamp mitzuführen. Neben
> der Möglichkeit, die Entwicklung und Schwerpunkte im Laufe der Jahre
> mitzuverfolgen gibt es uns auch die Möglichkeit, über ein Aging der
> Einträge potentiell nicht mehr aktive Installationen optional nicht mehr
> in den Analysen zu berücksichtigen.

das ist schon drin.. das ist das feld "lastSeen".

gruss

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:
>
> Ich schliesse mich Markus an,
> Geo-Daten ja (sprachbezogen, also deutsch, englisch, etc.), IP-Speicherung
> Nein!
> Default on eigentlich ungern, und wenn, dann nur mit deutlichem Hinweis,
> dass Daten gesendet werden.
> Moegliche Loesung, im Rahmen des Updates den Benutzer fragen.
> Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> Modul nicht mitzuuebermitteln.
>

 Als Lösung würde ich vorschlagen nur die Module zu übertragen, welche eine
SVN $Id Zeile haben. Somit nur die offiziellen Module übertragen werden.
Ich hab beispielsweise ebenfalls eigene Module die ich für spezielle Sachen
nutze.

Gruß
Markus

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Zrrronggg!]

                                                     

IP Speicherung geht gar nicht (ich verwende z.b. statische IPs)

Ansonsten ginge "default on" gerade noch so.

On 1 Dez., 15:14, Markus Bloch wrote:
> Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:
>
>
>
> > Ich schliesse mich Markus an,
> > Geo-Daten ja (sprachbezogen, also deutsch, englisch, etc.), IP-Speicherung
> > Nein!
> > Default on eigentlich ungern, und wenn, dann nur mit deutlichem Hinweis,
> > dass Daten gesendet werden.
> > Moegliche Loesung, im Rahmen des Updates den Benutzer fragen.
> > Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> > Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> > Modul nicht mitzuuebermitteln.
>
>  Als Lösung würde ich vorschlagen nur die Module zu übertragen, welche eine
> SVN $Id Zeile haben. Somit nur die offiziellen Module übertragen werden.
> Ich hab beispielsweise ebenfalls eigene Module die ich für spezielle Sachen
> nutze.
>
> Gruß
> Markus

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich bin für...
Default on.
Keine Speicherung der IP.
Eintrag der gesendeten Daten in der Log-Datei, ggf. über ein im Default eingeschaltetes Attribut abschaltbar.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Default on. Statt der IP direkt die Geodaten abspeichern.


Am 1. Dezember 2012 23:14 schrieb cge :

> Ich bin für...
> Default on.
> Keine Speicherung der IP.
> Eintrag der gesendeten Daten in der Log-Datei, ggf. über ein im Default
> eingeschaltetes Attribut abschaltbar.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 1. Dezember 2012 05:10:25 UTC+1 schrieb Martin Fischer:
>
> Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
> "sendStatistics" per default auf "1", also auf "immer übermitteln" setzen.
> Somit würde relativ schnell eine "gut gefüllte" Statistik zusammenkommen.
>
> Hallo Martin,

meine Meinung:

Ich halte es für bedenklich ohne Nachfrage beim Nutzer UniqueIDs,
IP-Adressen oder sonstiges per Default auf einen FHEM-Server zu schicken.
Sobald die UniqueID generiert ist, ist diese personenbezogen. Da reicht
schon, wenn ein User diese einmal nach FHEM users postet.
Bei der geringen Zahl FHEM-User würden allein schon Geo-Daten reichen, um
einen Nutzer zu identifizieren.

Der Benutzer muss generell zumindest einmal gefragt werden, bevor Daten
übertragen werden. Daei muss vorher angezeigt werden, welche Daten an
fhem.de übertragen werden sollen und zu welchem Zweck.

Wenn das nicht geht, muss das Senden der Daten ausgeschaltet werden.

Ich halte es nicht für gut Daten der FHEM-Benutzer zu speichern, nur weil
irgend jemand es schick findet, wenn wir Statistiken haben.

Ich möchte nicht auf diese Weise überwacht werden.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich muss zugeben, dass ich mir das Thema FHEM-Statistik bisher nicht genau
angesehen habe.

Jetzt bin ich innerlich aufgewühlt, weil FHEM evtl. anfängt ohne Nachfrage
beim Benutzer Daten auf zentralen Servern zu sammeln.

Wer hat eigentlich Admin-Rechte auf dem Server fhem.de Server bzw. das
Recht Skripte zu installieren, die Daten sammeln?

Ich muss mal eine Nacht darüber schlafen, finde jedoch das geplante
Opt-Out-Verfahren für derzeit sehr bedenklich und mit meinen Grundsätzen
nicht vereinbar.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:

> Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> Modul nicht mitzuuebermitteln.
>

Wenn der Benutzer der Übersendung der Statistikdaten zugestimmt hat, dürfen
Modulnamen, wenn überhaupt, nur anhand einer Positivliste übertragen
werden.  Auch ich verwende eigene Module und wäre darüber eindeutig
identifizierbar. Die Unterscheidung anhand des Kriteriums IDs ist nicht
ausreichend. Woher will der Benutzer wissen, dass dies das Kriterium ist?

Ich würde aber eher dafür stimmen keinerlei Modulinformationen zu
übertragen. Der Benutzer wird vermutlich über die Kombination der genutzten
Module identifizierbar sein. Zusammen mit der UniqueID kann man sogar das
Benutzervehalten herausfinden......

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Hiya @all,

eigentlich wollte ich eine Grundsatzdiskussion vermeiden. Da hier aber doch
der eine oder andere Kommentar gekommen ist, möchte ich nun auch mal meine "2
cents" dazu äussern.

Datenschutz:
Wer sich mit dem Thema Datenschutz ernsthaft auseinander setzt, der wird
zwangsläufig über den § 4 des Bundesdateschutzgesetztes "stolpern":

§ 4 Zulässigkeit der Datenerhebung, -verarbeitung und -nutzung
(1) Die Erhebung, Verarbeitung und Nutzung personenbezogener Daten sind nur
zulässig, soweit dieses Gesetz oder eine andere Rechtsvorschrift dies erlaubt
oder anordnet oder der Betroffene eingewilligt hat.
(2) Personenbezogene Daten sind beim Betroffenen zu erheben. Ohne seine
Mitwirkung dürfen sie nur erhoben werden, wenn

1. eine Rechtsvorschrift dies vorsieht oder zwingend voraussetzt oder
2. a) die zu erfüllende Verwaltungsaufgabe ihrer Art nach oder der
Geschäftszweck eine Erhebung bei anderen Personen oder Stellen erforderlich
macht oder
   b) die Erhebung beim Betroffenen einen unverhältnismäßigen Aufwand
erfordern würde und keine Anhaltspunkte dafür bestehen, dass überwiegende
schutzwürdige Interessen des Betroffenen beeinträchtigt werden.

(3) Werden personenbezogene Daten beim Betroffenen erhoben, so ist er, sofern
er nicht bereits auf andere Weise Kenntnis erlangt hat, von der
verantwortlichen Stelle über

1. die Identität der verantwortlichen Stelle,
2. die Zweckbestimmungen der Erhebung, Verarbeitung oder Nutzung und
3. die Kategorien von Empfängern nur, soweit der Betroffene nach den Umständen
des Einzelfalles nicht mit der Übermittlung an diese rechnen muss, zu
unterrichten. Werden personenbezogene Daten beim Betroffenen aufgrund einer
Rechtsvorschrift erhoben, die zur Auskunft verpflichtet, oder ist die
Erteilung der Auskunft Voraussetzung für die Gewährung von Rechtsvorteilen, so
ist der Betroffene hierauf, sonst auf die Freiwilligkeit seiner Angaben
hinzuweisen. Soweit nach den Umständen des Einzelfalles erforderlich oder auf
Verlangen, ist er über die Rechtsvorschrift und über die Folgen der
Verweigerung von Angaben aufzuklären.

Hier ist ganz klar von "Personenbezogenen Daten" die Rede. Der Befehl
"fheminfo" übersendet _absolut_ _keine_ _personenbezogenen_ _Daten_ wie hier
"befürchtet" wird. Darüber hinaus liegt der Quelltext offen, so dass jeder,
der irgendwelche bedenken hat, diesen einsehen kann.

Aufgrund einiger Anregungen wird auch serverseitig _keine_ _IP_ _Adresse_
gespeichert. Zugriff auf erhobenen Daten (OS, Architektur, Perl Version, FHEM
Version, Namen und Anzahl der definierten Module, Namen der definierten
Modelle, sowie die Geodaten) hat _ausschliesslich_ Rudolf König.

Die Geodaten basieren auf einer Geo-IP Datenbank mit einer Genauigkeit von ca.
40-80 km.

Alle erhobenen Daten kann der Anwender durch Aufruf von "fheminfo" einsehen
und selber entscheiden, ob er diese Informationen mittels "fheminfo send"
übertragen will. Wer dieses nicht möchte, ruft halt kein "fheminfo send" auf.

"fheminfo" wird nach einer initialen Testphase im Rahmen des update Prozesses
aufgerufen. Per Default werden dann diese Informationen gesendet. _ABER_ _NUR_
wenn das globale Attribut "sendStatistics" auf "1" steht.

Also auch im Falle von update hat der Anwender die volle Kontrolle über die
Übermittlung der Daten. Wer dies nicht möchte, setze "sendStatistics" auf "0".
Schon wird update _nichts_ übertragen.

Soviel zu der "technischen Umsetzung".

Nun jedoch mal meine persönliche Meinung als u.a. "Professional Certificate
Governance, Risk and Compliance ISO/IEC 27000" im Rahmen der internationalen
Norm ISO/IEC 27001 http://de.wikipedia.org/wiki/ISO/IEC_27001 der täglich bei
einem international tätigem Internet Service Provider u.a. für die gesamte
Datensicherheit zuständig ist. Und zu unseren Kunden gehört nicht "Lieschen
Müller" von neben an, sondern Bezirksregierungen, grosse Automobilunternehmen,
Banken und viele mehr. Soviel zu meinem persönlichem Background.

Ohne irgend jemand nahe treten zu wollen, denn das steht mir a) nicht zu und
b) liegt es mir fern, bin ich jedoch der Meinung, dass das Thema hier etwas
"überbewertet" wird. Jeder von uns surft täglich vielfach im Internet und
hinterlässt so viele personenbezogene Spuren (besonders die, die mit
statischer IP "unterwegs" sind) wie sonst nirgendwo im "realen Leben". Jeder
der ein Windows installiert, wird weitaus mehr Daten innerhalb einer Woche
übertragen als das es FHEM wahrscheinlich in seinem ganzen Lebenszyklus machen
wird. Zur Zeit werden gerade die ersten Rechner ausgeliefert, die in
Kombination mit Windows _hardwareseitig_ einen Key "eingepflanzt" bekommen.
Hier hat man nicht mal die Möglichkeit ein "sendStatistics" auf "0" zu setzen.
Die Informationen werden _immer_ übertragen. Wird hier dann jeder auf Windows
verzichten? Ich denke nein.

Das Thema Android und "ei"Phone und "ei"Pad, google, Fratzenbuch, Xing,
Stayfriends, etc. lasse ich mal komplett aussen vor.

Im Übrigen hätte man schon in der Vergangenheit allein durch die Auswertung
der Logfiles von fhem.de Informationen zu IP, Host, welche Module werden
geladen,etc. sammeln können.

Weiterhin setzt hier wohl ein Großteil Hardware auf Funkbasis ein, dessen
Protokoll _keinerlei_ Verschlüsselung bietet. Diese bieten weitaus mehr
Möglichkeiten personenbezogene Daten zu beziehen, wie z.B. Gewohnheiten und
mehr. Und diese kann ich dann auch einem im Haushalt lebendem Personenkreis
zuordnen.

Es wurden auch Argumente geliefert, dass anhand der Modulnamen eine
_eindeutige_ Zuordnung zu Personen gegeben ist. Dieser Argumentation kann ich
nicht folgen, es sein denn jemand nennt seine Module
"98_Martin_Fischer_Braunschweig.pm". Wenn nun ein Modul "98_foobar.pm"
existiert, dann ist hieraus _absolut_ _kein_ Rückschluss auf irgendeine Person
möglich. Man überzeuge mich von dem Gegenteil!

So könnte ich noch zig weitere Argumente liefern, denen auch zig andere
Argumente entgegen gehalten werden. Diese Diskussion kann man wahrscheinlich
_endlos_ weiterführen. Aber wir würden zu keinem Ergebniss kommen. Deshalb
möchte ich mich auch möglichst aus der weiteren Diskussion heraushalten, da
der Anwender proaktiv die Übermittlung deaktivieren kann.

Kurz nach der Ankündigung des neuen Befehls haben innerhalb von 30 Minuten die
ersten 5 Anwender ihre Daten übertragen. Es gibt also auch die Seite, die das
Übermitteln der Daten als hilfreich für FHEM ansehen. Denn genau darauf zielt
diese Statistik ab.

Sie ermöglicht den Entwicklern abzuschätzen, wie häufig "ihre" Module
eingesetzt werden. Es ermöglicht eine sehr genaue Übersicht auf welcher
Plattform FHEM mit welcher Perlversion zum Einsatz kommt. Darüber hinaus
ermöglicht die ungefähre Angabe der Geo bezogenen Daten einen Rückschluss auf
mögliche Übersetzungen um den Zugang zu FHEM zu erleichtern. Diese Merkmale
sind der alleinige Fokus bei der statistischen Auswertung.

All diese positiven Merkmale werden meiner Meinung nach etwas bei dieser
Diskussion verdrängt.

Aber wie gesagt: es steht ja jedem frei, diese Informationen zu senden. Keiner
wird gezwungen und FHEM wird die Daten (obwohl sie _nicht_ personenbezogen und
somit unbedenklich sind) ungefragt senden.

Einen Punkt nehme ich mir allerdings noch mit auf die TODO:
Die Aufführung von _nicht_ _offiziellen_ FHEM Modulen werde ich unterbinden,
da diese Module auch nicht von Interesse im Rahmen der Entwicklung von FHEM
sind.

Neben der Möglichkeit die Übermittlung der Daten über das Attribute
"sendStatistics" aktiv zu beeinflussen, besteht darüber hinaus auch die
Möglichkeit mittels "exclude_from_update" den Befehl "fheminfo" komplett
auszuschliessen und ihn lokal z.B. zu löschen oder umzubenennen. update wird
(wenn es dann soweit ist) vorab die Existenz von "fhemupdate" prüfen; und wenn
es den nicht gibt, kann update ihn auch nicht aufrufen. Aber selbst wenn er
exisitert, (ich wiederhole mich) wird ja "sendStatistics" geprüft.

Vielleicht konnte ich ein paar Zweifel aus dem Weg räumen. Und wenn mir das
hiermit nicht gelungen ist, dann wird es auch künftig nicht gelingen.

Somit soll das erstmal alles zu diesem Thema von meiner Seite sein. Ich denke,
ich habe genug Möglichkeiten aufgezeigt um einer Übermittlung der Daten "aus
dem Weg" zu gehen.

In der Hoffnung, das dennoch viele diese Funktionen nutzen um FHEM stetig zu
verbessern, wünsche ich weiterhin viel Spaß und Erfolg mit FHEM.

Gruß Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com