Do not track :Router/Websites ?

OT ...ich wusste es

Zitat von Oliver222

Bugcatcher versuchte u.A. Folgendes abzustreiten:

Das ist nicht Dein Ernst?

Wenn du zitierst, zitiere richtig und verändere Zitate nicht so, dass ihr Inhalt eine andere Bedeutung erhalten:

Zitat von bugcatcher

Sie erhält Relevanz wenn ein Router die Anfrage falsch auslegt und es dadurch zu einem ungewollten (User wills nicht so haben und weils der User nicht will, wirds auch Mozilla und der Routerhersteller nicht so haben) Verhalten kommt.

Du sprachst von zusätzlichen Header-Informationen. Und du hast selbst erkannt dass diese nicht von Relevanz sein sollten. Von Referer war zu keiner Zeit die Rede. Der wird durch den DoNotTrack Eintrag auch nicht berührt. Auch dies habe ich bereits zu Protokoll gegeben. Das du trotzdem den Zusammenhang erstellst lässt eher die Vermutung zu, dass du unsachlich unterschiedliche Thematiken beliebig zusammenwürfelst, damit sie deiner Agumentationskette dienen. Soviel zu technischen Grenzen.

Das Ignorieren oder das Ablehnen der Bereitschaft nicht Daten zu erheben stellt in der Tat kein Fehlverhalten da. Der Router ignoriert aber nicht die zusätzliche Headerinformation. Er blockiert die gesamte Anfrage. Das ist ein Fehlverhalten. Selbst wenn ein Verfahren nach Auslieferung des Systems eingeführt wird, auf welches das Gerät aus Unkenntnis noch nicht reagieren kann, bleibt es ein unerwünschtes Fehlverhalten, dass korrigiert werden muss (Firmware Update).

Zitat von Oliver222

Entschuldige darüberhinaus bitte - Aber das Mozilla „doof“ ist (Deine interpretative Wortwahl) - wurde innerhalb dieses Diskussionsverlaufs - und allgemein - von niemanden behauptet.

Hab ich nicht behauptet. Das ist die Umschreibung deines generellen Verhaltens in allen Threads an denen du dich hier beteiligst. Erinnerst Du dich (z.B.) nicht mehr an deine ganzen unbelegten und unhaltbaren Spionage-Anschuldigungen gegenüber Mozilla? Sehr bedauerlich.

So. Und jetzt mal den Admins beichten, dass der Thread mal wieder den Bach runter ist.

Zitat von bugcatcher

Wenn du zitierst, zitiere richtig und verändere Zitate nicht so, dass ihr Inhalt eine andere Bedeutung erhalten

Das O Zitate fälscht - bewußt und keineswegs auf Grund von Mißverständnissen - wurde vor einem halben Jahr unwidersprochen offenbar. Und da Zitatfälschungen - über der Beurteilung der Persönlichkeit des Betreffenden hinaus - der zwingende Tot jeder Diskussion sind (IMHO noch schlimmer als Zitate, die nicht als solche gekennzeichnet sind), haben Lautgebungen solcher Leute, denen Argumente in Wirklichkeit ausgegangen sind, für mich bestenfalls Troll-Qualität.

(Im übrigen halte ich es wie Boersenfeger.)

Es geht im Zuge dieses Threads - meiner Meinung nach - nicht bloss um „protektionistische Klüngelei“ - innerhalb dieser Gemeinschaft - sondern eher um die Darstellung der Wahrheit - von der wir hier alle letztendlich (hoffentlich) profitieren dürfen. Wenn sich dann auch alle mit qualifizierten Beiträgen beteiligen würden.

bugcatcher:
Welches Zitat - in Bezug auf Deine vergangenen Darstellungen - wurde denn von mir zu Deinen technisch argumentatorischen Nachteilen genau verfälscht? Ich höre Dir im Moment sehr genau zu (s.u.).

Bugcatcher erläuterte darüberhinaus im Zuge dieser Diskussion Folgendes.

Zitat

[...]Hab ich nicht behauptet. Das ist die Umschreibung deines generellen Verhaltens in allen Threads an denen du dich hier beteiligst...[...]

Damit hast Du Dich - meiner Beurteilung nach - gerade für weitere (technische) Diskussionen disqualifiziert. Darüberhinaus nach einen Mod zu „schreien“, da sich scheinbar Deine technische Beleuchtung zu erschöpfen erscheint, führt zu keiner Weiterführung - bzw. schlussendlichen Zielstellung dieser Thematik.

Bugcatcher stellte u.A. Folgendes dar:

Zitat

Der Router ignoriert aber nicht die zusätzliche Headerinformation. Er blockiert die gesamte Anfrage.[...]

Was für ein Wunder...
Hast Du [Bugcatcher] es denn immer noch nicht begriffen?

a. Der Zugriff auf einen dedizierten Router (zur Konfiguration) aus dem Intranet (LAN) heraus, muss i.d.R. über notwendige „HTTP-Referrer“ (als eine zusätzliche verifizierbare Zugriffs-Information dieses geschlossenen Netzwerkes) erfolgen, da solche zu konfigurierenden Router - auf diesem vereinfachten kommunikativen Level (2 oder 3) - für externe/interne Verschlüsselungsverfahren nicht immer geeignet ausgestaltet (konfiguriert) wurden. Eine notwendige (wenn auch einfache) Verschlüsselung der anfragenden IP-Pakete gegenüber so einem Router würde darüberhinaus bloss auf Level 2 erfolgen können.

b. Demgegenüber muss der öffentliche Zugriff - bzw. die Weiterführung zu übertragender Informationen (des Nachrichtenstroms) - über wie auch immer geartete Router - als funktionierende Firewall - über das Internet i.d.R. auf Basis der Kommunikationsschicht 3 (der Netzwerkschicht) selber geführt werden.

Genau dort wird gefiltert.

Das die von Dir zitierten „Anfragen“ somit bereits routerseitig abgewiesen werden, ist eher der Sicherheit, als der allgemeinen Zugänglichkeit dienlich.

@Cosmos
Das Philosophie-Forum der theoretischen Informatik befindet sich woanders.

Oliver

Zitat von Oliver222

[...]um die Darstellung der Wahrheit[...]Wenn sich dann auch alle mit qualifizierten Beiträgen beteiligen würden.

Fragt sich jetzt nur was Du dann hier noch zu suchen hast?

Zitat von Oliver222

bugcatcher:
Welches Zitat - in Bezug auf Deine vergangenen Darstellungen - wurde denn von mir zu Deinen technisch argumentatorischen Nachteilen genau verfälscht? Ich höre Dir im Moment sehr genau zu (s.u.).

Ach, ich merke nur gerade das deine benutzte Begrifflichkeit einfach nur falsch ist. Kein Wunder das Du nicht trennst und alles in einen Topf wirfst. Ich sprach explizit nicht von Referrern, was du mir aber im verfälschten Zitat unterstellst. Kannst dich nicht dran erinnern? Dann geh nochmal nachlesen.

Es gibt nur einen HTTP-Refer(r)er. Das ist EIN spezieller HTTP-Header-Eintrag. Er speichert im Grunde nur einen Wert für "von wo ein Nutzer gekommen ist". Und er ist kein Synonym für Headerangaben generell. Auch, und hier wiederhole ich mich, betrifft dies die DoNotTrack-Funktion und den entsprechenden Headereintrag NULL.

Um den Refferer gehts hier nicht. Thema verfehlt. Soviel zu technischer Disqualifikation.

Zitat von Oliver222

Was für ein Wunder...

Stells nicht hin als gäbe es bei unbekannten Headereinträgen nur eine Art mit der gesamten Anfrage umzugehen. Jede Anwendung sucht in Anfragen nur nach Headern, die sie kennt und mit denen sie was anfangen kann und ignoriert den Rest. Das ist der Standard. Nicht deeie "ich block alles was nicht genau meine gewünschten Header liefert"-Version. Wäre gerade bei den üblichen (WLAN-)Routern für den Privatkunden echt problematisch, da der Router sich hier nach den ~5 verbreitetsten Browsern und nicht die Browser nach den ~100 verbreitetsten Routern richten müssen. Jeder der Webinterfaces baut, weiß das. Soviel zu dem von dir angesprochenen "Zielkonflikt".

Zitat von Oliver222

Hast Du [Bugcatcher] es denn immer noch nicht begriffen?

Ich schon, andere auch. Nur Du scheinst wieder nicht erleuchtet sondern geblendet worden zu sein. Anders kann man es schwerlich erklären, dass Du dich über allen möglichen Kram auslässt, der aber rein gar nichts mit der Thematik zu tun hat. Der Herr ist wohl einfach orientierungslos.

Und deine ganzen Erklärungen zu Netzwerklayern und Verschlüsselungen kannst du dir auch schenken. Das HTTP-Protokoll ist auf der Anwendungsebene (und ist unabhängig von Verschlüsselungen), kann daher eh nur von "intelligenter" Hardware (bzw. der Software darauf) ausgelesen werden. In einem lokalen Netzwerk sind daran genau zwei Geräte beteiligt. Client-Rechner (aka, Rechner mit Browser) und Router (mit Web Interface). Und dazwischen liegt in der Regel nichts (evtl. Desktop- und/oder Router-Firewall, dazu später mehr). Wenn deine überflüssige Erklärung zu diesen Nebenschauplätzen keinen Nutzen hat, dann stellt sich natürlich die Frage warum diese Information eingeworfen werden. Sie dienen keiner Wahrheit und auch nicht der Problemlösung.

Zitat von Oliver222

Das die von Dir zitierten „Anfragen“ somit bereits routerseitig abgewiesen werden, ist eher der Sicherheit, als der allgemeinen Zugänglichkeit dienlich.

Das das Filtern des Headers und das Blockieren von Anfragen mit unbekannten Headereinträgen der Sicherheit dienen soll, dem werde ich nicht widersprechen. Trotzdem ist das blockieren von Anfragen mit DoNotTrack-Headereinträgen ein unerwünschtes Verhalten. Der Router verhält sich falsch und muss jetzt nachträglich dazu gebracht werden, statt ganze Anfragen mit dem DoNotTrack-Headereintrag zu blockieren, den Eintrag im Zweifel nur zu ignorieren, aber die Anfrage trotzdem weiter zu bearbeiten. Auch hier könnte ich dir deinen "Zielkonflikt" wieder an den Kopf werfen. Ein Router der sicher aber nicht einstellbar ist, ist nutzlos.

Und um noch einmal auf den Referrer zurück zu kommen, den Du ständig ran ziehst. Der ist als Sicherheitselement (falls das die Mutter des Gedankens sein sollte. Ansonsten kann ich mir nicht vorstellen, warum Du immer von Referrern redest, obwohl das DoNotTrack damit rein gar nichts zu tun hat) völlig nutzlos, da die Headerangaben einer Anfrage völlig frei und beliebig erstellt, also auch gefälscht werden können.

Eine Firewall kann sicherlich Header filtern und entsprechende Anfragen blockieren. Router haben oft auch eine Firewall eingebaut, das ist korrekt. Diese sind aber in der Regel gegen Anfragen aus dem Internet geschaltet. Anfragen aus dem lokalen Netzwerk, für das sie Gateway spielen, werden hingegen in der Regel nur durch spezielle Regeln, die vorher manuell erstellt werden müssen, gefiltert. Es ist unwahrscheinlich dass Anwender spezielle Anfrageblockierregeln erstellen um Anfragen mit "DoNotTrack"-Headereintrag im lokalen Netzwerk zu blockieren. Im aktuellen Fall wird das Webinterface sogar erreicht, eine Firewall wird also nicht aktiv, erst das Auswerten der POST-Anfrage für den Login quittiert der Router mit Ablehnung.

Eine Firewall auf Seiten des Desktops filtert ausgehende Anfragen auch nur, wenn diese entsprechend konfiguriert sind (meist Anonymisierungen usw.). Im aktuellen Fall aber höchst unwahrscheinlich. Denn die Router-Weboberfläche wird erreicht und auch wird ein unterschiedliches Verhalten des Routers bei Aktivieren und Deaktivieren der DoNotTrack-Option wahrgenommen. Insofern ist dies das Handeln des Routers selbst.

Das Blocken ist ein nicht erwünschtes Verhalten. Und damit kann man es als fehlerhaft und korrekturwürdig (Firmware Update) bezeichnen. Deine gesuchte "Wahrheit" findet sich sicher eher in Richtung "praktisch realistisch" als in deiner "theoretisch denkbar" Weltanschauung.

Zitat von pittifox

Ohne "s" ( hinten).

Korrekte Bezeichnungen oder Zitate sind halt nicht seine Stärke. Hauptsache es hört sich toll und wichtig und schlau an.
; )

Zitat von bugcatcher

Korrekte Bezeichnungen oder Zitate sind halt nicht seine Stärke. Hauptsache es hört sich toll und wichtig und schlau an.

IMHO viel bemerkenswerter: Er streitet auch jetzt die damals begangene Zitatfälschung nicht ab, sondern deklariert das als eine Frage der (seine) Philosophie. Wer könnte jemanden so gut entlarven wie der Betreffende sich selber (dem vor lauter innerer Erregung auch noch gleich ein Finger auf die Taste s gerutscht ist).

// Irgendwie wusste ich, das dieser Thread spaßig wird