Howto: Werbeanrufe automatisch beenden lassen mit Freetz

Am Client Identifier jetzt eher nicht. Oder ist dort die Trunk-Build oder das Build-Datum kodiert? Nicht getestet, aber kann ich mir gerade nicht vorstellen.
Die Credentials sind aus nem Forumspost von Tellows selbst. Die dürften auch mehrere Leute nutzen.
Nein, ich sehe da keine Chance.

Hmm... sofern das mit IPv6 passiert, könnte ein statischer Teil in der IP-Adresse stecken. Hab bisher kein IPv6, hab noch einen Monat lang ADSL – aber nun vorsorglich ebenfalls meine alte Fritzbox getauscht, die ja nicht VDSL kompatibel ist.
 
Zuletzt bearbeitet:
Ich meine aber die Credentials. In Verbindung mit den 2 erste Zahlen deiner IP, die sich meist nicht ändern, ist das schon ziemlich sicher.
Die Abfrage geht auch ganz ohne: ?xml=0&partner=test&apikey=test123

BTW: Heute ist Safer Internet Day
 
Zuletzt bearbeitet:
Doch, der IP Pool ändert sich bei mir (1und1) sehr häufig. Ich hatte das mal längere Zeit aufgezeichnet (1 - 2 Jahre), das war, als die Abmahnungen in Tauschbörsen häufig waren. Sollte ich mal eine unberechtigte Abmahnung erhalten, hätte ich zumindest für mich selbst checken können, obs stimmte. Als Beweis ist das natürlich eher weniger geeignet.

Ich bin aber nie auf die Idee gekommen, den Tellow Score ohne Anmeldung zu erfragen.

Edit: Credentials entfernt. Thx.
 
Wenn man die Abfrage mit "xml=1" macht als Query-String, kriegt man auch eine XML-Datei zurück (da steht der Score dann als XML-Entity "score" drin) - läßt sich ggf. besser parsen als eine HTML-Entity als "span".

Aus Deinem anderen Thread muß man ja eigentlich schließen, daß Dir die Bedeutung der Kommandos für den "telefon"-Daemon (das ist das Programm, was da auf Port 1011 lauscht) geläufig ist - dort erklärst Du ja dann auch deren Notwendigkeit aus Deiner Sicht.

Das "ATP" wählt einfach nur ein Telefoniegerät an der FRITZ!Box für die "Wählhilfe" aus (das muß nicht einmal existieren, solange das nur eine gültige Nummer (analog, ISDN, DECT) sein könnte - wobei auch 50 und 59 als Rundruf funktionieren und - zumindest bei meiner 7490 - auch beide als "ISDN-/DECT-Rundruf" angezeigt werden), das "ATD" wählt die angegebene Rufnummer und das "ATH0" legt dann die Leitung auf (on-hook - praktisch das Gegenteil von "ATD" und wohl erst dann wirklich wirksam in Bezug auf den aktuellen Anruf, wenn das "ATD" (und damit das Heranholen des Anrufs) erfolgreich war).

Jedenfalls wird in der Regel jedes dieser Kommandos (so es erfolgreich war) mit einem "OK" quittiert und nach so einer Quittung macht es dann auch Sinn, das nächste Kommando hinterherzuschicken.

Normalerweise (bei einem "echten Modem") würde auch hinter jedes einzelne Kommando ein Newline gehören, aber da ist der AVM-Daemon dem Anschein nach dann so tolerant (oder auch "falsch", aber das kann auch an seinem begrenzten Kommandoumfang liegen und es gab zwar in den Modems früher tatsächlich gesonderte (Steuer-)Register, in denen die Codes für CR und LF standen, damit das Modem wußte, womit die Zeilen beendet wurden - theoretisch könnte man das auch wie eine Standardeinstellung "ATS3=20" betrachten, womit dann tatsächlich das Leerzeichen zum "Kommandoende" mutiert), daß er nach dem ersten "token" (durch Leerzeichen getrennt) wohl automatisch ein Kommando als "vollständig" ansieht und dann ausführt (das gilt dann aber eher nicht für Dein letztes "ATH0" in der Kommandofolge, weil auch das EOF in der Eingabedatei nicht zum Ausführen des Kommandos davor führt):
Code:
root@FB7490:~ $ printf "AT\n" | nc localhost 1011 <=== ein AT-Kommando

OK
root@FB7490:~ $ printf "AT" | nc localhost 1011<=== kein AT-Kommando (kein Zeilenende)
root@FB7490:~ $ printf "AT AT\n" | nc localhost 1011 <=== zwei AT-Kommandos

OK

OK
root@FB7490:~ $ printf "AT AT" | nc localhost 1011 <=== ein AT-Kommando, da nur ein Zeilenende bzw. ein Leerzeichen als Ende des ersten Kommandos

OK
root@FB7490:~ $
Wenn man sicher sein will, daß/ob ein Kommando "ohne Abschluß" ausgeführt wird oder nicht, kann man anstelle des reinen "AT" (was nur als "attention" mit einem "OK" quittiert wird und früher zum Synchronisieren der seriellen Schnittstellen diente) ja ein "ATDxxx" verwenden und dann warten, ob die angewählte Nummer klingelt oder nicht - bei mir (113.06.92) macht sie es nicht.

Bei der Wählhilfe ist es dann zusätzlich noch so, daß nach dem Abheben beim angerufenden Teilnehmer (dessen Nummer im "ATD"-Kommando enthalten war) das Telefon mit der internen Nummer aus dem "ATP"-Kommando klingelt (hier ist "intern" bereits klar und es braucht keine Sterne bzw. es darf m.W. auch keine geben), während der andere Teilnehmer die Warteansage hört (wie man das halt von der Wählhilfe kennt) und nach dem Abheben des lokalen Telefons werden die beiden Gespräche verbunden.

Das kann man jederzeit selbst mit entsprechenden AT-Kommandos in einer Shell ausprobieren ... leider quittiert der "telefon" fast alles mit "OK", was nicht offenkundiger Blödsinn ist.

Der ständige Wechsel zwischen "ATP51" und "ATP1" schaltet auch nur zwischen diesen Nebenstellen als "Wählhilfe-Telefon" um - wobei das ohnehin so blind erfolgt im FRITZ!OS, daß man da auch eine Nummer 611 angeben kann, wenn es nur ein DECT-Gerät gibt oder auch eine 52, wenn die Box nur ein einziges ISDN-Endgerät kennt.

Das ergibt dann lediglich sehr lustige Caller-Namen in der Anzeige, wenn da irgendwelche sinnlosen Speicherinhalte als Name verwendet werden - wobei das wieder von der Technologie abhängt (die sinnlosen Speicherinhalte treffen in erster Linie auf "virtuelle" ISDN-Geräte zu), denn mit "ATP611\nATD**610\n" kann man auch problemlos auf einem AVM-MT mit der internen Nummer 610 einen Anruf von der internen Nummer 611 (also als "**611") anzeigen lassen, egal ob es das Telefon mit der 611 überhaupt gibt.

Damit bleiben dann von der Kommandofolge in #1 wohl noch 9 "ATH0"-Kommandos übrig (ggf. mit einem etwas speziellen Timing, weil die anderen Kommandos noch dazwischenkommen) - das zehnte wird (nach meiner Überzeugung - siehe die Tests oben) schon nicht mehr ausgeführt, weil das abschließende Leerzeichen oder Newline fehlt. Das macht dann 5x ein "Pickup"-Dial-Kommando für das erste ISDN-Gerät mit anschließendem Auflegen und 5x ein Dial-Kommando für die erste analoge Nebenstelle, wobei dann bei vieren noch ein "onhook"-Kommando folgt.

Jedenfalls würde damit das von Dir in #1 gezeigte Skript (auch nach Deinen eigenen Worten im anderen Thread) genau dann funktionieren, wenn es in der FRITZ!Box exakt diese zwei Nebenstellen gibt, die sich für den eingehenden Anruf zuständig fühlen könnten ... einmal ein ISDN-Endgerät mit der internen MSN 51 und einmal irgendein Gerät (vorhanden oder nicht vorhanden) am ersten analogen Anschluß. Sowie der Nachnutzer auch noch DECT-Telefone hat oder ein analoges an FON2, klingeln halt diese dann weiter ... zumindest werden sie von Deiner Kommandofolge ja nicht aufgelegt und ich kann in diesem Thread hier irgendwie auch nichts entdecken, wo Du den interessierten Nachnutzer auf diesen Umstand hinweist.

Ich glaube aber ohnehin nicht so richtig daran, daß es tatsächlich eines "Auflegens" für jedes installierte Telefon bedarf ... wenn ein Call erst einmal an einem Endgerät angenommen wurde (und das sollte er m.E. nach dem "*09" dann irgendwann sein, wenn das erfolgreich war - und warum sollte man das Kommando absetzen, wenn es gar nicht ausgeführt würde), dann sollte er auch durch Auflegen dieses einzelnen (meinetwegen auch "virtuellen") Endgerätes beendet werden können ... es klingelt ja auch nicht das nächste, wenn ich einen Call an irgendeinem Telefon annehme und dann wieder auflege.

Andererseits klingelt ja auch das beim "ATP" angegebene Telefon nicht, wenn man die "*09" für Pickup wählen läßt - was der Anrufer in diesem Falle hört (wenn dieser Zustand etwas länger anhält und nicht gleich aufgelegt wird), habe ich aber auch noch nicht getestet. Aber bei mir funktioniert das mit dem o.a. Skript ohnehin nicht - auch nicht ohne Tellows-Abfrage als "alles ablehnen"-Skript ... nicht einmal dann, wenn ich nur ein einzelnes (auch nicht angeschlossenes) analoges Endgerät konfiguriert habe. Andererseits kann man mit dem "*09" ja sogar einen Call von der TAM wieder heranholen ... und die dürfte genauso ein "virtuelles" Gerät sein, wie das beim ATP-Kommando angegebene Ende einer künftigen Verbindung. Da könnte ich mir dann sogar vorstellen, daß das Gespräch noch in der Phase des Aufbaus bei Dir immer zwischen der 51 und der 1 hin- und hergerissen ist ... bis es dann irgendwo doch mal rechtzeitig "beendet" wird.

Wie wäre es denn ansonsten (wenn Deine Theorie mit dem "ein Hangup pro Nebenstelle" aus dem anderen Thread stimmt) mit dem "Ermitteln" der Telefone, die vorhanden sind (so richtig "sophisticated" wird das dann, wenn man noch ermittelt, welche Nummer angerufen wurde und welche Telefone auf diese Nummer reagieren und welche nicht) und dem gezielten (automatischen) Auflegen dieser Nebenstellen, ggf. sogar jeweils erst dann, wenn das vorhergehende Kommando tatsächlich verarbeitet wurde (also das "OK" im "nc" aufgetaucht ist)?

Wobei ich mir hier vermutlich eher ein kleines Programm als "call blocker" bauen würde, was über die CAPI-Schnittstelle als ISDN-Endgerät daherkommt, den Call per Pickup holt und ihn dann mit einem passenden Cause-Code abwürgt ... da sind die Möglichkeiten beim ISDN einfach viel größer als ein reines "on-hook" und "normal call clearing" - da sollte fast alles bis hin zur "unbekannten Nummer" möglich sein. Das kann dann auch gleich als "Abwurfziel" für alle unbekannten Rufnummern herhalten (und zumindest ein "PROGRESS" an den Anrufer übermitteln), welches gar nicht erst klingelt - hat es den Call erst einmal per Pickup an sich gezogen, sollten die anderen Telefone ja eigentlich automatisch Ruhe geben (so, wie es auch bei "echten" Telefonen der Fall wäre).

EDIT:
Das, was ich oben zum letzten Kommando geschrieben habe, stimmt so natürlich nicht, hier bin ich mir selbst auf den Leim gegangen. Anders als Du verwende(te) ich nur noch "printf" anstelle von "echo", weil die beim "echo" oft gebrauchten Optionen "-n" und "-e" nicht zum POSIX-Standard gehören und damit nicht portable sind (die fallen einem unter der "dash" dann gerne vor die Füße).

Das von Dir verwendete "echo" erzeugt jedoch automatisch noch ein "newline" am Ende (wenn es eben nicht mit "-n" aufgerufen wird) und damit kommt auch das letzte "ATH0" noch zur Ausführung. Meine Blindheit ...
 
Zuletzt bearbeitet:
Um mal hier Feedback für die Datenschutzfraktion zu liefern.
Ich hab das Skript jetzt genau eine Woche laufen, nachdem ich das letzte mal die Anrufhistorie gelöscht hab.

Ich habe seit dem 16 Anrufe erhalten. Davon waren 15 im Telefonbuch und/oder aus dem eigenen Vorwahlbereich, die nicht abgefragt wurden. Und ein Betrugsversuch ( 043428008950 ),der erfolgreich geblockt wurde.
Ich hab aber jetzt auch den Vorwahlbereich um eine Stelle kürzer gemacht. Gute Idee eigentlich. Zwar rufen tatsächlich gelegentlich aus der nächstgelegenen Kreis-Stadt mal Leute an, die mich für Sponsoring überreden wollen, aber die waren bisher ohnehin nie in Tellows gelistet.
 
Zuletzt bearbeitet:
aber die waren bisher ohnehin nie in Tellows gelistet.
Na dann mach doch einen Eintrag bei Tellows. Habe ich auch schon gemacht, damit ich nicht Score=5 erhalte.
War aber 'ne 0800er Nummer. Die könntest du ja auch ohne Tellows sofort canceln.
 
Hab ich auch schon gemacht für andere Anrufe. Für die Lokalen nicht, weil der Letzte zu einer Zeit war, als ich tellows noch nicht für Abfragen genutzt hab. Würd ich aber heute machen.
 
Datenschutz:
Falls übrigens noch jemand Fragen bzgl. des Datenschutz hat (das ist ja hier Kernthema):
Die Nutzung ist auch zu betrieblichen Zwecken erlaubt, das ergibt sich aus Art. 6 DSGVO, Abs. 1f, sofern man den Nachweis erbringen kann, dass man durch die Werbeanrufe gestört wird.

Die Verarbeitung ist nur rechtmäßig, wenn mindestens eine der nachstehenden Bedingungen erfüllt ist:
die Verarbeitung ist zur Wahrung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person, die den Schutz personenbezogener Daten erfordern, überwiegen, insbesondere dann, wenn es sich bei der betroffenen Person um ein Kind handelt.


Jetzt kommt Peter und fragt: Handelt es sich denn um ein berechtigtes Interesse?
Ja! Denn Erwägungsgrund 49 sagt:

Die Verarbeitung von personenbezogenen Daten durch [...] Betreiber von elektronischen Kommunikation diensten sowie durch Anbieter von Sicherheitstechnologien [...] stellt in dem Maße ein berechtigtes Interesse des jeweiligen Verantwortlichen dar, wie dies für die Gewährleistung der Netz- und Informationssicherheit unbedingt notwendig und verhältnismäßig ist, d.h. soweit dadurch die Fähigkeit eines Netzes oder Informationssystems gewährleistet wird, mit einem vorgegebenen Grad der Zuverlässigkeit [...] widerrechtliche oder mutwillige Eingriffe abzuwehren, die die Verfügbarkeit, Authentizität, Vollständigkeit und Vertraulichkeit von gespeicherten oder übermittelten personenbezogenen Daten sowie die Sicherheit damit zusammenhängender Dienste, die über diese Netze oder Informationssysteme angeboten werden bzw. zugänglich sind, beeinträchtigen.
 
Jetzt kommt Peter und fragt: Handelt es sich denn um ein berechtigtes Interesse?
Nein, fragt er garantiert nicht.

Weil er niemals die Verarbeitung der Daten des Anrufers im Auge hatte (das wurde aber auch oft genug betont, daß man es - wenn man das wirklich wollte - begreifen kann ... der Anrufer ist derjenige, der eine fremde Nummer wählt und damit die Initiative beim Aufbau der Verbindung hat - es mithin auch lassen kann und auch die Entscheidung trifft, ob er seine Rufnummer an den angerufenen Teilnehmer übermittelt oder nicht) und meinerseits nur Bedenken bestehen würden, daß damit die Liste der Anrufer beim Angerufenen in voller Schönheit bei diesem Online-Service vorliegt.

Der Angerufene (das ist der, bei dem das Telefon bei einem Anruf eines anderen klingelt - vielleicht (er)klärt das ja die Rollenverteilung besser) wird hier also in einem schutzwürdigen Interesse verletzt bzw. nicht einmal derjenige direkt, der diese Lösung installierte, sondern die berechtigten Mitbenutzer dieses Anschlusses, sofern sie der Übermittlung der Informationen an Dritte (das ist hier der Online-Service) nicht zugestimmt haben.

Denn anders als von Dir weiter vorne aus dem Verhalten Deines Providers geschlossen, gibt es eben lange nicht an allen Internet-Anschlüssen heutzutage noch eine automatische Trennung nach 24 Stunden und bei der nächsten Einwahl dann auch eine neue IP(v4)-Adresse. Bleibt diese aber über längere Zeit konstant (eine Laufzeit von 6 Monaten ist bei einer FRITZ!Box jetzt nicht so utopisch, solange es keine Updates der Firmware gibt und der Besitzer kein "Spielkind" ist), kann sie als Kriterium für eine Datensammlung herangezogen werden.

Ob das der Tellows-Betreiber jetzt tatsächlich macht oder nicht, spielt für die Frage, ob dieses Problem besteht oder nicht, ebenfalls keine Rolle ... eine Datenschutz-Lücke wird ja nicht erst dann zur Lücke, wenn sie jemand ausnutzt oder "etwas passiert", sondern bereits dann, wenn sie (objektiv) besteht.

Ich habe nicht einmal ein Problem damit, wenn jemand dieses "Risiko" sehenden Auges eingeht ... ich würde trotzdem erwarten, daß der Autor einer solchen Lösung auch diesen Aspekt im Auge behält - gerade dann, wenn er eine zusätzliche Qualifikation auf dem Gebiet "Datenschutz" hat.

Zumal hier die "Offline-Version" genauso einfach ist ... sie kostet halt ~ 20 EUR für zwei Jahre und basiert auf den Funktionen der FRITZ!Box (auch ohne die Modifikation mittels "Freetz"). Ich kann ebenfalls verstehen, wenn jemand diesen Betrag nicht aufwenden will, weil die Belästigung durch Werbeanrufe dann doch nicht so groß ist, daß diese Ausgabe sich lohnen würde.

Aber all dieses Verständnis ändert doch nichts daran, daß man als Autor so einer Lösung dann auch noch einen zusätzlichen Gedanken daran verschwenden kann, was der (unreflektierte) Einsatz der vorgeschlagenen Lösung bei anderen Benutzern für nachteilige Folgen haben könnte, oder?

Und mehr als einen entsprechenden "Warnhinweis": "Bitte beachte, daß damit - zumindest theoretisch - bei Tellows eine Möglichkeit der Datensammlung aller Anrufe besteht, sofern die Abfragen immer von derselben IP-Adresse erfolgen." hätte ich gar nicht erwartet - daß der Anrufende in seinen Rechten nicht verletzt wird, wenn die von ihm übermittelte Rufnummer abgefragt wird, war bereits geklärt.

Und damit stellt sich auch die Frage des betrieblichen Einsatzes gar nicht, denn hier ist der Anschlußinhaber ja der Betrieb und die Gefahr, daß daraus eine Liste der persönlichen Kontakte eines Individuums extrahiert werden kann, ist tatsächlich eher gering, da die angerufene Nummer ja nicht übermittelt wird. Die DSGVO schützt auch nur die Rechte an personenbezogenen Daten (was das ist, steht in Art. 4 DSGVO und da wird auch deutlich gemacht, daß es sich dabei um natürliche Personen handeln muß) und diese hat die angerufene Firma schon automatisch nicht - insofern kann Dein Verweis auf die DSGVO und den betrieblichen Einsatz Deiner Lösung eigentlich nur ein weiterer Hinweis darauf sein, daß Du meinen Punkt hinsichtlich des Datenschutzes gar nicht wirklich verstanden hattest (oder ihn nicht verstehen wolltest).

Aber selbst eine Firma sollte zur Vermeidung jeglichen Mißverständnisses oder Konfliktes ihre Mitarbeiter darüber informieren, daß/ob/wann über geführte Telefonate "Buch geführt" wird ... hier sogar bei ausgehenden Gesprächen. Es gibt nicht ganz umsonst auch TK-Anlagen/-Software, in denen eine passende Vorwahl definiert werden kann, bei deren zusätzlicher Verwendung kein Protokoll-Eintrag erfolgt und welche die Mitarbeiter einer Firma dann verwenden können/sollen, wenn sie (zugelassene) private Gespräche von einem Telefon der Firma führen (was in Zeiten von Mobiltelefonen und Flatrates auch immer seltener der Fall ist, weil die meisten Privatgespräche inzwischen ohnehin damit geführt werden und die Telefonnummer "Auf Arbeit" am Kühlschrank eher eine verflossene Erinnerung ist).
 
Nein, fragt er garantiert nicht.

der Anrufer ist derjenige, der eine fremde Nummer wählt und damit die Initiative beim Aufbau der Verbindung hat - es mithin auch lassen kann und auch die Entscheidung trifft, ob er seine Rufnummer an den angerufenen Teilnehmer übermittelt oder nicht

Facebook darf mit meinen Daten machen, was es will. Denn ich bin es ja, der "auch die Entscheidung trifft, ob" ich meine Daten an Facebook "übermittel oder nicht".
Daher bin ich auch nicht der Betroffene, sofern bei Facebook mal ein paar Daten in Fremde Hände gelangen, denn ich habe meine Daten ja freiwillig übermittelt, sondern ... ja wer eigentlich? Die Mitarbeiter von Facebook, die nicht in der IT Arbeiten und die Lösung technisch implementiert haben?

Hand aufs Herz. Hast du irgendwann in deinem Leben schonmal irgendwie was mit Datenschutz am Hut gehabt?
Ich hoffe deine hier hoch gelobte technische Kompetenz ergründet sich nicht aus ähnlichen Schwafeleien.
 
Ich habe das mit den Werbeanrufen bisher erfolgreich immer etwas anders gehandhabt:
- Kommt ein Werbeanruf rein, lasse ich den Anrufer kurz reden
- dann weise ich darauf hin, dass ich keine Webeanrufe erhalten möchte
- und bestehe freundlich darauf, dass meine Rufnummer sofort aus deren Listen gelöscht wird
Das funktioniert! Die Anzahl der unerwünschten Werbeanrufe liegt derzeit bei etwa 4 (vier) pro Jahr!
Und das, obwohl meine Telefonnummer und komplette private Anschrift im öffentlichen Telefonbuch (www.dasoertliche.de) gelistet ist.
 
@creon wie kommst Du jetzt auf Facebook? Dieses Wort fiel noch nicht ein mal in diesem Thread, außer vier mal in #30 und jetzt ein zusätzlicher in #32)


Hand aufs Herz......................
Neu im IP-Phone-Forum?
Etikette

  1. Höflichkeit untereinander sollte selbstverständlich sein. Bei Zuwiederhandlung musst Du mit einer Verwarnung bzw. bei mehrmaligem Verstoß mit einem (zeitweisen) Ausschluss aus dem Forum rechnen.
 
@creon:
Vermeidest Du es jetzt absichtlich, irgendwie darauf einzugehen, was die DSGVO und "betriebliche Nutzung" mit dem angesprochenen Thema "Daten(selbst)schutz" zu tun haben soll?

Ich bin hier bei Deiner Lösung ohnehin nur auf das Thema "Datenschutz" angesprungen, weil es von dritter Seite angemerkt wurde.

Ansonsten hatte ich mich erst einmal nur Deiner - für mich sehr unvollständigen - Beschreibung gewidmet. Unvollständig deshalb, weil das verwendete FRITZ!Box-Modell nicht ein einziges Mal im Text erwähnt wurde und man nur durch Ansicht der Screenshots vom "make menuconfig" darauf schließen konnte, daß Du hier mit einer 7390 arbeitest ... nun mag es Dir ja nicht geläufig sein, weil Du nur dieses Modell besitzt und verwendest, aber es gibt erhebliche technische Unterschiede zwischen den Modellen und der Gebrauch des ruKernelTools empfiehlt sich tatsächlich nur mit den alten (oder "beschnittenen", damit nicht die Frage kommt, ob ich die 4020 auch als "alt" ansehe) Modellen mit NOR-Flash.

Da das auch immer wieder zu Problemen und Mißverständnissen bei "Neulingen" führt (und mir nicht bewußt wäre, daß Du in so einem Fall schon einmal anderen Hilfestellung geleistet hättest), habe ich mir die Freiheit genommen, die von Dir etwas nonchalant zwar unbedingt mit dem Gebrauch des ruKernelTool verknüpfte, aber ansonsten nicht weiter ausgeführte "Installation" (auch wenn Du das als "das Image auf die Box bringen" umschrieben hast) zu hinterfragen bzw. vor der allzu eilfertigen Nachahmung auf der Basis dieser sehr speziellen (aber eben nicht mit entsprechenden Hinweisen versehenen) Anleitung zu warnen. Mehr war erst einmal gar nicht ...

Da wir aber unmittelbar davor an anderer Stelle die Diskussion hatten, wie AVM wohl die Anzeige des Ortsnetzes bei eingehenden Anrufen in neuerer Firmware realisiert (damit hast Du mit der 7390 dann auch nichts zu tun, daher ist es "verzeihlich", wenn Dir diese neue Funktion nicht bekannt sein sollte), war offenbar das Thema "Datenschutz" noch so präsent, daß @eisbaerin es nicht versäumen wollte (für mich nachvollziehbar), auf diesen Aspekt auch noch hinzuweisen.

Die ganze Diskussion ging ja erst dann richtig los, als Du Dich als "zertifizierter Datenschutzbeauftragter" geoutet hast und trotzdem nicht verstehen kannst oder willst, daß mit einer solchen (unreflektierten) Abfrage eines Online-Services eine Weitergabe von Daten erfolgt, deren Akkumulation mehr über den Angerufenen offenbaren kann, als man auf den ersten Blick sieht.

Wieso Du hier immer wieder auf die Datenschutzinteressen des Anrufenden eingehst:
Der Betroffene wird von dir fälschlicherweise als der Betreiber der Telefonanlage angegeben.
Das ist nicht der Fall, weil an tellows lediglich die Informationen des Anrufers weitergegeben werden, nicht die Destination-Number. Betroffener ist daher ausschließlich der Anrufer.
, verstehe ich tatsächlich absolut nicht ... der hat eben erstens seine Nummer übermittelt und zweitens kann damit noch lange kein Profil seiner anderen Anrufe erstellt werden - das ist aber durchaus der Fall für den angerufenen Anschluß, sofern dieser immer wieder dasselbe Ordnungskriterium (hier die IPv4-Adresse des Absenders so einer Abfrage) verwendet.

Und ob Du dann die angerufene Nummer an Tellows übermittelst oder nicht (was bei Dir ja die Begründung dafür ist, daß der Angerufene hier gar nicht "verfolgt" werden kann), spielt auch gar keine Rolle ... denn die IP-Adresse mußt Du bei einer Abfrage übermitteln (von der Verwendung von Anonymisierungsdiensten bei der Abfrage habe ich auch nichts gelesen) und anhand dieser ist das Sammeln von Daten auch möglich. Mit genug Informationen, welche Absender-Nummern bei dieser IP-Adresse angerufen haben und ein paar Querverweisen aus anderen Quellen (z.B. sozialen Netzwerken mit entsprechenden Graphen), läßt sich auch (zumindest mit hohen Wahrscheinlichkeiten) rekonstruieren, um welche (Telefon-)Nummer es sich bei dieser IP-Adresse handelt. Erst recht dann, wenn man solche Abfragen (wie das im Ausgangszustand ja der Fall war) auch für all diejenigen Nummern macht, die man ohnehin im eigenen Telefonbuch stehen hat ... das dürften bei den meisten FRITZ!Box-Besitzern genau diejenigen Kontakte sein, zu denen die kürzesten Verbindungen in einem Soziogramm bestehen.

Ansonsten wirfst Du munter verschiedene Themen zum Datenschutz durcheinander - Dein rhetorischer "Ausflug" zu Facebook erscheint mir als ein Zeichen dafür und das war ja auch nicht der erste, wenn ich an die Versuche der Ablenkung mit "die Anderen sind ja noch viel schlimmer" am Ende von #13 erinnern darf.

Facebook macht ja gar kein Geheimnis daraus, daß man dort Daten sammelt und teilt (höchstens noch daraus, mit wem man das tut und in welchem Umfang) und der Umfang der dort gesammelten Daten dürfte in keine sinnvolle Relation zur Übermittlung einer einzelnen Telefonnummer (des Anrufers) an Tellows zu bringen sein, womit dieses Abschweifen (und das Betrachten der Datenschutzfolgen so einer Abfrage für den Anrufenden) gar keinen Sinn ergibt.

Oder Du begehst hier ähnliche Kardinalfehler, wie so mancher Datenschutzbeauftragte in einer Firma ... man schaut noch genau bis zu den eigenen Speicher- und Verarbeitungsvorgängen (und dem, was im BDSG bisher für die eigene Verarbeitung geregelt war) und das, was man selbst "remote" im Internet mit anderen Online-Services (auch mit den heute so beliebten Micro-Services) an Daten austauscht und damit an "Spuren" erzeugt, wird gar nicht weiter hinterfragt - wenn das tatsächlich jemand anderes auswertet (auf der Basis irgendwelcher Abfragen, die man selbst gemacht hat), ist das ja (hinsichtlich Speicherung und "Anmeldung" von Datensammlungen) das Problem des jeweiligen Online-Services. Aber mit der DSGVO zieht eben auch Datenvermeidung als verpflichtendes Prinzip ein ... eine Angewohnheit, die eigentlich auch jeder Datenschutzbeauftragte zu seinem Mantra erhoben haben sollte.

Offenbar bestreitest Du ja auch gar nicht mehr, daß Deine anfänglichen Prämissen hinsichtlich der Möglichkeiten zur Datensammlung bei Tellows (die täglich wechselnde IP-Adresse war Deine (falsche) Annahme (aus Deiner eigenen, offenbar dann aber begrenzten Erfahrung) und die hast Du auch erst nachträglich in die Diskussion eingebracht) nicht so ganz stimmten ... und so ganz "mit einer Zunge" redest Du offenbar auch nicht. Anders kann ich mir Deine Aufforderung
Vielleicht diskutierst du das weitere in einem entsprechendem Forum aus. Hier geht es primär um die technische Umsetzung.
, der dann nach knapp 7 Wochen von Deiner Seite ein erneuter Exkurs zum Thema "Datenschutz" folgt in #28 (und zwar "unsolicited"), jedenfalls nicht erklären. Hast Du hier dann erwartet, daß ich auf den in #29 von mir zitierten Satz von Deiner Seite gar nicht mehr reagieren würde, weil Du es mir ja in #15 "untersagt" hattest?

Ansonsten schreibst Du hier zwar von "MiesePeterPawn" und von meinem "Geschwafel" ... aber auf Deine plausible Erklärung, warum keinesfalls mit Deiner Lösung eine Datensammlung bei Dritten möglich war bzw. ist, warten wir immer noch. Das "war" steht im vorhergehenden Satz u.a. auch deshalb, weil Du ja nach entsprechenden Hinweisen von @eisbaerin tatsächlich Verbesserungen vorgenommen hast.

Und hier geht es eben tatsächlich um die damit mögliche Datensammlung bei Tellows zu den Anrufern bei einer bestimmten IP-Adresse - das war nämlich auch der Ausgangspunkt bei der Diskussion um das neue AVM-Feature, die dieser hier unmittelbar vorausging (und auch in einem früheren Beitrag in diesem Thread angeführt wurde - so ganz kann das also auch an Dir nicht vorbeigegangen sein). Da war die Frage, wie das mit dem Datenschutz zu vereinbaren wäre, wenn die AVM-Firmware ungefragt (es gibt nämlich keine Einstellung, mit der man dieses Feature ein- oder ausschalten könnte) einfach einen Online-Service nach dem Ortsnetz einer bestimmten Nummer befragt. Inzwischen wissen wir, daß bei AVM diese Abfrage offline erfolgt und die Firmware eine Liste der deutschen Ortsnetze und ihrer Kennzahlen enthält.

Daß man Deine Lösung bei Einhaltung der Rahmenbedingungen(!) auch ohne größere Probleme mit der eigenen "Datenproduktion" verwenden kann, bestreite ich gar nicht ... aber von Dir gab es eben vor den Hinweisen von @eisbaerin gar keine Bemerkung oder Überlegung in dieser Richtung zu lesen und das, was Du dann in #8 im letzten Absatz zu diesem Thema geschrieben hast, zäumte erst einmal das Pferd (hier die "Datenvermeidung") direkt wieder von hinten auf - offenbar hast Du da den Punkt auch noch nicht sehen können oder wollen, daß Du selbst damit mehr Daten preisgibst (und die ganzen zusätzlichen Konditionen, wann das nicht der Fall ist, kamen auch erst kleckerweise im Nachhinein) als gut und notwendig ist. Dann noch Deine "Beschwerde" darüber, daß Du kaum eine Datenschutzfolgeabschätzung für alle potentiellen Nutzer treffen kannst (in #17) ... da stellt sich mir die Frage, wer solchen Themen sonst Beachtung schenken sollte, wenn nicht jemand, der nach eigener Aussage auch noch zertifizierter Datenschutzbeauftragter ist. Ein "ist alles halb so wild" kann jedenfalls kaum die Antwort sein ... und genau das hast Du aber im ersten Reflex behauptet.

Solange Du das nicht verstehst, wirst Du auch nicht verstehen, wie man von Dir als Autor dieser Lösung einen Hinweis erwarten kann, daß damit selbstverständlich beim befragten Online-Service eine Datensammlung möglich wäre und man diesen Umstand zum Anlaß nehmen sollte, von allen berechtigten und rechtsfähigen Mitbenutzern des Anschlusses die Genehmigung zur Weitergabe der Daten an Tellows einzuholen (rechtsfähig deshalb, weil Du für Deine Kinder tatsächlich in gewissem Umfang (und unter Berücksichtigung ihrer Interessen) entscheiden darfst).

Dafür braucht man aber nicht einmal "zertifizierter Datenschutzbeauftragter" zu sein ... die Erkenntnis, daß auf diesem Wege Daten (an Dritte) weitergegeben werden, sollte tatsächlich jedem schon im Rahmen von "Medienkompetenz" einleuchten - und mehr als ein Hinweis auf diesen Umstand war hier auch gar nicht das Ziel und wurde von Dir nie erwartet. Wenn Du daraus dann eine Diskussion der Datenschutz-Interessen des Anrufers machst, ist das zwar Dein gutes Recht ... es hat aber mit dem, was hier von @eisbaerin eingeführt und von mir fortgesetzt wurde, eben nichts zu tun.

Und nur mal nebenbei ... es zeugt eben selten von der Stärke der eigenen Argumentation, wenn man auf persönliche Angriffe auf den Opponenten nicht verzichten kann oder will - aber darüber kann ich tatsächlich hinwegsehen, wenn man das nur zusätzlich zur eigenen Argumentation als Notwendigkeit ansieht und das nicht an die Stelle des eigenen Arguments tritt. Auch das Aufmachen jeder Menge weiterer "Töpfe" in so einer Diskussion, trägt eben nicht dazu bei, daß man irgendwann mal auf den Punkt kommt - dabei denke ich dann an "Facebook" und das "schau mal da: ein Splitter im Auge von Anderen" aus früheren Beiträgen und die - in diesem Kontext auch nicht wirklich wichtige - Diskussion, wer nun Dienstanbieter nach TKG ist und wer das Fernmeldegeheimnis zu wahren hätte und wer nicht.

Das alles kann nämlich die Tatsache, daß diese Abfrage bei Tellows keinesfalls zwangsläufig anonym erfolgt, nicht wegdiskutieren und die Frage, ob Tellows nun eine deutsche oder eine amerikanische Firma ist, spielt auch keine Rolle für die Feststellung, ob mit dieser Abfrage dokumentiert wird, daß die Rufnummer aus der Abfrage zu diesem Zeitpunkt den Telefonanschluß hinter der abfragenden IP-Adresse angerufen hat.
 
Dem gemeinen Deutschen könnte die "Zuwiederhandlung" doch ins Auge stechen oder besser zuwider sein? Aber bei entsprechender Wiederholung könnte es in ein paar Jahren als "süddeutsch" Einzug halten.

Dass #31 von @Joe_57 propagierte Verhalten nur bedingt Wirkung zeigt, kann ich nur aus Sicht eines seit 1977 abgemeldeten Gewerbe mit andererseits noch validen Rufnummer negieren! Eine simple Google-Suche über die Rufnummer spuckt zuviel Fundstellen aus, wobei ich schon einige angemailt hatte zwecks Korrektur! Selbst auf Rückfrage und Übermittelung via FAX der Gewerbeabmeldung passierte REIN garnix. Im Gegenteil herrscht wohl Entzückung, dass die Rufnummer noch konnektiert? ... lässt sich verhökern ... Noch schlimmer man nutzt eine signifikante E-Mail-Adresse ... der Spam-Rebound ist einem gewiss!
LG
 
Moin,

ungeachtet der sinnfreien Diskussion am eigentlichen Thema des Thread vorbei, habe ich mir am Wochenende ein kleines PHP-script gebastelt, welches das automatisiert*, was ich bisher manuell im Nachgang durchgeführt habe:
  1. Unbekannte Rufnummer in Anruferliste (impliziert: nicht im Telefonbuch der Box enthalten)
  2. Verifiation im Netz
  3. Wenn Spam, dann Eintrag in das Spam-Telefonbuch zur Rufabweisung
Das Script macht genau das gleiche, nur eben automatisch und schon unmittelbar nach/oder während des Anrufes.

Für den Dauerbetrieb im Hintergrund z.B. auf einem sowieso laufenden RaspberryPi ist es noch nicht abgesichert genung (Error-Handling).

Wer hierzu kurze(!) sinnstiftende Anregung (Coding) geben möchte - darüber freue ich mich.

Darüber hinaus findet sich folgende Passage:

Code:
/* the following part does not work yet
                     *
                     * pick up call
                    $phoneClient->{'X_AVM-DE_DialNumber'}(new SoapParam('*09',"NewX_AVM-DE_PhoneNumber"));
                     * disconnect call
                    $phoneClient->{'X_AVM-DE_DialHangup'}();
                     */
Meine Idee war, den offensichtlichen spamanruf gleich abzuwürgen. Leider klappt das nicht, der HangUp Befehl würgt den "gepickten" Call leider nicht ab. Auch ein delay (sleep(4)) dazwischen bringt nix. Abgesehen davon sind die lästigen 1-Mal-Klingeln-Anrufe dann schon durch...
Wer kann mir hier weiterhelfen?

Schöne Feiertage

Black Senator


* Digitalisierung
 
Na das ist doch mal ein Grund einen Extra-Thread aufzumachen.
Bitte wenn es läuft noch eine kurze Anleitung wie es auf dem Raspian-Light zum laufen gebracht wird.
 
Hallo,

die Anleitung zu den Einstellungen für den Hintergrundbetrieb habe ich in der Read.me auf GitHub ergänzt.

Bei mir läuft es jetzt im Hintergrund auf eine RasbPi.

Black Senator
 
  • Like
Reaktionen: Micha0815

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,172
Beiträge
2,247,422
Mitglieder
373,715
Neuestes Mitglied
wesleymoons87
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.