Für 119.000 war es eindeutig ; )
Beiträge von bugcatcher
-
-
Brrr. 119.000 muss man fast berücksichtigen. ; (
-
Nein.
Es ist die Entscheidung des Benutzers ein Update durchzuführen. Man kann es ihnen anbieten, aber nicht erzwingen. Wenn sie ablehnen, werden sie ihre Gründe haben. Es mögen die falschen sein, aber es sind ihre eigenen.
Und die Anzahl der Crash Reports sind keine echte "Belastung" für die Datenbank. Ist also auch kein Grund.
-
Nicht existierende Begriff als Tag für eine Suche einzubauen, halte ich für überflüssig. "bewegte Bilder" würde ich ja sogar noch gelten lassen... aber "Bewegtbilder"?
-
Ich glaube "Bewegtbilder" ist kein Wort. "Animierte Grafiken" schon eher.
Egal. Gibt about:config in die Adresszeile ein, such nach dem Eintrag image.animation_mode und ändere den Wert von normal auf none.
-
-
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 Oliver222bugcatcher:
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 Oliver222Hast 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 Oliver222Das 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 pittifoxOhne "s" ( hinten).
Korrekte Bezeichnungen oder Zitate sind halt nicht seine Stärke. Hauptsache es hört sich toll und wichtig und schlau an.
; ) -
Du kannst mit der mittleren Maustaste (Scrollrad) den Eintrag anklicken und ihn so als neuen Tab öffnen.
-
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 Oliver222Entschuldige 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.
-
Ich vermute auch das F5 gemeint ist. Aber die Beschreibung ist schon arg bizarr.
-
Ich würde einfach mal ein neues Profil versuchen.
Oder noch einfacher. Einen Firefox Portable:
http://stadt-bremerhaven.de/downloadbereich/ -
Ihr werdet machen. Dazu gibts ein Projekt.

-
Da man mit Oliver eh wie mit einer Wand redet, wird das zuhören sicher langweilig werden. Wie Ulli bereits festgestellt hat: es wurde bereits alles zum Thema (sowohl Router & DoNotTrack, als auch zum guten Oliver) gesagt. Zumindest von meiner Seite aus. ; )
-
Wenn die Seite per serverseitigen Scriptsprache wie z.B. PHP erstellt wird, kann man darüber HTTP-Header direkt selbst bestimmen ohne globale Angaben für den Server zu setzen.
-
Fuck Firefox, ganz eindeutig.
-
Versuch dich mal hier dran:
http://support.mozilla.com/de/kb/Allgemei…n-zurakcksetzen -
Meines Wissens nach wurden die Meta-Tags der Seite diesbezüglich schon immer ignoriert, wenn der Server im HTTP-Header (nicht! <head>!) bereits Angaben gemacht hat. Was steht im Header?
-
Sparts euch. Der schuldige wurde schon identifiziert. Der Themenersteller wünscht keine Hilfe.
-
Zitat von Oliver222
Ist uns bekannt - Du erklärst uns bedauerlicherweise - zumindest mir - leider nichts Neues.
Das du alles weißt ist uns bereits bekannt. Naja, bis auf das Wissen, wie man Probleme zielgerichtet löst.Zitat von Oliver222Update in Bezug auf welche Anfragen? Aus dem geschlossenen Intranet oder systemübergreifend aus dem Internet? Firefox oder andere Browser?
Allein die Fragestellung zeigt eigentlich schon, dass Du zur eigentlichen Thematik bisher nichts beitragen wolltest.Zitat von Oliver222Klingt das eben von Dir genannte nicht etwas arrogant? Ich glaube wir sprechen hierbei von zwei unterschiedlichen streckentechnischen Zugriffsverfahren auf solche Router.
Deine ständigen Erklärungen die im Grunde nichts mit der Problematik zu tun haben und deine Feststellungen das bisherige korrekte Analysen falsch wären, halte ich für viel arroganter. Das Du immer von irgendwas anderem redest, ist inzwischen klar. Das Du Themen mit für die Problematik irrelevanten Informationen in die irre führst halte ich allerdings für noch viel schlimmer. Keiner deiner Beiträge zu dieser Thematik hatten für die Themeneröffnet einen themenbezogenen Nutzen.Zitat von Oliver222Darüberhinaus stellt - meinen bisherigen Kenntnissen nach - das von Dir [bugcatcher] genannte sog. Header Block Tracking der durch den Firefox übertragenen IP-Pakete keinen wirklichen Schutz (also keine Opt-Out-Massnahme) gegenüber möglichen individuellen Auswertungen diverser Webseiten dar
Diese Thematik ist eine völlig andere als hier behandelt. Über den Sinn und Nutzen dieser Option darf man sich gern streiten, aber dafür darfst Du ein eigenes Thema eröffnen. Das einzige was Du mit solchen Einwürfen erreichst, ist es von der eigentlichen Thematik abzulenken und das ist für die Lösung eines Problems kontraproduktiv.Zitat von Oliver222Es wird dabei bloss eine Anfrage auf Unterdrückung der zusätzlichen Header-Informationen erwirkt, die jedoch nicht von Relevanz ist.
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.Zitat von Oliver222Webseiten müssen somit nicht auf die angefragte Ablehnung des „Header-Block-Tracking“ durch den Browser reagieren.
Der Router reagiert aber und zwar falsch. Darum gehts hier.Zitat von Oliver222Der Firefox-Browser ist obendrein durch seine Verbreitung inzwischen auf den uneingeschränkten Zugriff möglichst vieler Internetseiten angewiesen. Diese benötigen jedoch zur statistischen Auswertung möglichst viele internal records informations (interne Datenzugriffsaufzeichnungen), die jedoch durch anonymisierende Zugriffsverfahren des Browsers selber nicht mehr gewährleistet werden können.
Thema verfehlt.Zitat von Oliver222Denke abschliessend bitte noch einmal in Ruhe über diesen „Zielkonflikt“ und Deine vorangestellten Ausführungen nach - und melde Dich darüberhinaus im Anschluss daran bitte mit einer möglichst objektiven Aussage gegenüber „Tracking-Procedures" wieder. Nicht böse gemeint.

Der Zielkonflikt hat ebenfalls nichts mit diesem Thema zu tun. Darum werde ich mich dazu auch hier nicht auslassen. Geh mal lieber in dich und prüfe ob du zur eigentlichen zielgerichteten Hilfestellung für die Hilfsanfrage in diesem Thread schon irgendwas gehaltvolles beigetragen hast. Und wenn nicht, überleg dir wie du das ändern könntest. Und wenn dir dazu nichts einfällt, dann störe wenigstens nicht weiter die Hilfsversuche.Und das ist nicht "böse" gemeint. Aber es ärgert mich inzwischen bös, dass Du trotz deines Sachverstandes im Grunde bei fast jedem Thema bei dem Du dich beteiligst, nur ureigene Interessen verfolgst, in dem Du die Threads dazu missbrauchst, auf nach deiner Meinung im Firefox sich anhäufende Fehlentwicklungen hinweist und Grundsatzdebatten anzettelst, statt dem Fragenden eine zielgerichtete Hilfestellung zu liefern.
Mozilla hat eine Do-Not-Track-Funktion integriert. Mit dieser aktiv kommt es bei manchen Routern zu Problemen. Erkläre dem Fragenden doch bitte, wie er wieder auf seinen Router kommt. Erklär ihm nicht warum nach deiner Meinung Mozilla doof ist.
-
Gab ein Problem im Cache (die Temporäre Internet Dateien des Firefox). Mit der Tastaturfolge oben umgeht man den Cache und erzwingt das saubere Neuladen aller Dateien.