[Discuss] Adress-Vergabepraxis, Aktualität der Daten, neue Konfigurationskonzepte - war: Re: [Wien] ip-adresse (KNOTENDICHTE)

[L. Aaron Kaplan]

On Nov 25, 2013, at 5:54 PM, Erich N. Pekarek <(spam-protected)> wrote:

> Am 2013-11-25 16:35, schrieb (spam-protected):
>> Am 25. November 2013 16:31 schrieb L. Aaron Kaplan <(spam-protected)>:
>> ...
>> Eh! Das stimmt schon.
>> Allerdings ist einfach der Opt-in der fairere Ansatz. Warum? Weil es gab hier (oder auf wien@) mal  eine ganz grosse Diskussion wegen Datenschutz. Im Zuge dessen wurde auch argumentiert, dass das Volumen an Traffic von einem Node auskunft darueber gibt, ob die Person zu Hause ist oder nicht. Der Effekt ist, dass diese Daten besser geschuetzt wurden.
>> 
>> Also Trafic-Volumen würd ich da sowieso nicht mitreinnehmen, weil es wie du schon argumentiert hast viel zu privat ist. Ich hatte eher an Latenz, Bandbreite (aus einer iperf messung oder sowas), Packet-Loss usw. zu jedem der vorhandenen Nachbarn gedacht.
> 
> Hä? Datenvolumen gibt Auskunft über Daheimsein??? Sind wir neuerdings bei der Telekom mit lauter individuellen Einzelanschlüssen?

Das war Markit's Argumentation.
An sich ja, man kann *potentiell* etwas ueber ein Verhalten aussagen, wenn man Volums-graphen einer *statischen* IP Adresse sieht. Das ist schon korrekt.
Man wird (== meine Argumentation) nicht besonders viel rauslesen koennen aber fuer den Durschnittsfall schon.
Das Argument ist aehnlich wie bei den Smartmetern und remote Stromablesung im 15 Min Takt.

> Bei einem Router-Knoten, der nicht bloß Endknoten ist, trifft das nicht zu. Beim Endknoten kann es zutreffen, muss es aber nicht.
Bin bei dir. Trotzdem haben sich Leute drueber aufgeregt. 
Vielleicht wollen die deine Argumente entkraeften?

> Ich denke, dass dieses Kriterium längst überholt ist - falls es überhaupt je richtig war. Die Verbreitung von Heimsteuerungen, PVRs und anderen Spielereien kommt da noch dazu.
> Den Traffic nur auf den Public-Interfaces zu nehmen halte ich für vertretbar.
> 
>>  
>> 
>> SNMP Daten sind aber potentiell viel genauer als das.
>> Sprich: entweder man macht ein opt-in Verfahren oder man ueberlegt sich ein Opt-out aber dann muss man sich auch sehr genau ueberlegen, wie man die Daten klassifizert, wie sie behandelt werden, welche Schutz-Mechanismen da sind etc etc.
>> Sprich: es wird komplexer.
>> 
>> Aber natuerlich gebe ich dir recht, dass ein Opt-in den Nachteil haben wird, dass wenige Leute mitmachen.
>> 
>> Ein möglicher Kompromiss wäre vielleicht, die Entscheidung verprflichtend in den auch schon (bei den letzten Testtagen) viel diskutierten Config-Wizard der beim ersten aufrufen der Web-Config-Maske nach dem Firmware-flashen aufpoppen soll mit reinzunehmen, und somit den User zu zwingen ja oder nein zu drücken.
> Das würde ich mir doch auch erwarten! Das Hakerl zum Smokeping gibt's schließlich auch und bei allem Verständnis für Automatisierung:
> Die freie Wahl des Endgerätes und die freie Wahl der Firmware darf nicht eingeschränkt werden. Mir missfallen diese Tendenzen (Zwang, Vorgaben) zunehmend, obwohl ich zugleich radikalere Zugänge zum "Aufräumen im Netz" postuliere. Dass gewisse Vorgaben (aus Bequemlichkeit - weil es ja eh eine hübsche, bunte Firmware gibt) unreflektiert geschluckt werden, kann doch bitte nicht Sinn und Zweck eines freien Netzes sein.

Sehe ich absolut genau so wie du!

> (Ja, es ist mir bewusst, dass ich damit von mir selbst geäußerte Meinungen hinterfrage - ich lade jeden Teilnehmer hier dazu ein, dasselbe zu tun.)
> 
Nein, ich bin da an dieser Stelle deiner Meinung.
Ich finde es zum Beispiel ganz ganz schlecht, dass da ein ssh key von wem-auch-immer in der Backfire Vienna drinnen ist.
Den meisten Leuten ist das nicht mal bewusst! 

Deswegen ist es so wichtig, dass Leute auch mitmachen koennen mit einer beliebigen HW und SW.

lg,
a.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 163 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20131125/e798e44f/attachment.sig>