Den zuletzt verlinkten Issue habe ich geschrieben; das war ein merkwürdiges Déjà-vu. Als ich dem Problem damals nachging, entdeckte ich ein ziemlich seltsames Verhalten.
Im Grunde lud Firefox für die betreffende Website viermal so viele Favicons wie geöffnete Tabs, und das wiederholte sich jedes Mal, wenn man Tabs öffnete oder schloss. https://aggressivelyparaphrasing.me/2022/12/12/why-does-my-l...
Dieses Problem wurde schon vor langer Zeit behoben; die Symptome sind also ähnlich, aber die eigentliche Ursache ist wohl eine andere, oder es gibt noch Leute, die eine alte Version nutzen.
WordPress scheint 404er wirklich langsam zu verarbeiten. Schon in meinen Logs sehe ich einen stetigen Strom von Bots, die beliebige URLs auf Schwachstellen abklopfen; da ist es eher erstaunlich, dass es überhaupt richtig funktioniert.
Es ist ein Open-Source-Projekt, und auf GitHub gibt es eine gute Diskussion zu den technischen Streitpunkten[1]. Es könnte auch mit bestimmten Nutzergewohnheiten zusammenhängen, etwa Hunderte Tabs offen zu lassen, aber die Komplexität, einen Browser in iOS hineinzuzwängen, spielt sicher ebenfalls eine Rolle.
Das fühlt sich an, als würde man einen Bagger in einen Sandkasten stecken und ihn dort steuern.
[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113
Ich frage mich auch, wie solche Anfragen einen Webserver derart lahmlegen können. Es werden der Feed und das Favicon angefragt, und beides ließe sich über ein CDN cachen.
Selbst ohne Cache: Wie groß kann der Traffic im Vergleich dazu sein, wenn eine andere Seite auf HN auf die Startseite kommt? Verschwendung ist es schon, aber so dramatisch wirkt es nicht.
Selbst mit Hunderten offenen Chrome-Tabs passiert so etwas überhaupt nicht. Auch wenn man in iOS Safari versehentlich Hunderte Tabs offen lässt, passiert das nicht.
Ich fände es gut, wenn ein offensichtlicher Anwendungsfehler nicht den Nutzern angelastet würde.
Schon beim Titel musste ich an die LLM-Scraper und Bots denken, die durchs ganze Web ziehen. Vielleicht laufen sie bald direkt auf dem AIphone.
Ich dachte, alle Browser unter iOS nutzten Apples Browser-Engine, und bei Android sei es genauso.
Mit anderen Worten: Ich dachte, das seien nur Skins.
Ich dachte, Firefox unter iOS sei nur ein Skin über Safari, weil Apple auf dem iPhone keine anderen Browser-Engines zulässt.
Firefox unter Android ist dank Plugin-Unterstützung großartig, auch wenn mir die UI vor 2021 besser gefallen hat.
Da die Schwesterkommentare ziemlich negativ sind, ergänze ich mal meine Erfahrung: Ich weiß nicht, was intern passiert, aber zumindest in den Jahren vor dem Rewrite fand ich die Nutzererfahrung von Android Firefox immer gut.
Obwohl ich es nicht mag, mit dem Handy im Web zu surfen, hat er es halbwegs erträglich gemacht. Zu internen Problemen kann ich nichts sagen, aber natürlich ist das ein Thema, um das man sich kümmern sollte.
Firefox auf Android ist für mich wie ein Retter. Der Trick ist, dass man auch mobil uBlock Origin und NoScript installieren kann.
Ich bin schockiert, wenn ich Leute sehe, die ohne diese beiden im Web unterwegs sind. Es ist geradezu absurd, wie sehr Menschen zulassen, dass ihnen ihre Aufmerksamkeit geraubt wird.
Firefox unter Android ist nicht großartig. Jahrelang enthielt der User-Agent den exakten Modellnamen des Telefons.
Das wirkt inkompetent. Korrektur: Die Formulierung war etwas hart, und es ging mir nicht um einzelne Mitarbeiter, sondern um das Unternehmen. Genau das ist der Zustand, den Google will: Bei Monopolfragen plausible Bestreitbarkeit schaffen, während die Alternative miserabel bleibt.
iOS verlangt zwar, dass Browser das vom Betriebssystem bereitgestellte WebKit verwenden, aber sie können eine eigene Networking-Schicht nutzen oder wie Erweiterungen selbst Skripte injizieren. Orion macht das so.
Firefox für iOS nutzte früher Alamofire als Networking-Engine, wechselte aber irgendwann zu NSURLSession/URLSession. Chrome für iOS nutzt Cronet, das vom Chromium-Networking-Stack abgetrennt ist; da die jüngere Entwicklung dort nicht mitgezogen wurde, weiß ich nicht, ob das noch immer so ist.
Firefox unter iOS ist tatsächlich ein Skin über Safari. Trotzdem vermeidet er einige Tracking-/Werbeinhalte, verhält sich also in gewissem Maß anders.
Wenn das aber so ein Problem ist, kann man einfach ein Favicon hinzufügen. Nebenbei: Ich teste unter iOS oft mit Firefox, habe dieses Phänomen aber noch nie gesehen.
Der Autor dieser Seite gibt sich normalerweise ziemlich Mühe, den Namen großer kommerzieller Unternehmen zu verschleiern, wenn sie etwas Dummes tun; wenn es Firefox ist, nennt er den Namen. Hm.
Der Autor verschleiert seinen eigenen Arbeitgeber. Dinge, die er als Endnutzer entdeckt, nennt er beim Namen.
Wenn der betroffene Browser nicht genannt würde, ergäbe der Beitrag selbst keinen Sinn.
Als jemand, der den Feed schon lange liest: Nicht wirklich; das passiert nur in bestimmten Fällen.
Ich erinnere mich, dass es früher beim Internet Explorer etwas Ähnliches gab. Er fragte das Favicon an, aber weil damals keines konfiguriert war, kam eine 404-Seite zurück, und die schien wiederum eine weitere Favicon-Anfrage auszulösen.
Interessant ist es schon. Rein von der Nutzererfahrung her ist Firefox für das iPhone wirklich eine hervorragende App und seit Jahren mein bevorzugter Browser.
Obwohl er im Grunde ein Safari-Skin ist?
Ein Favicon ist nicht Teil einzelner Verzeichnisse. Wenn es so wäre, wäre das ein dummes Design gewesen.
Favicons pro Pfad klingen tatsächlich wie ein Feature.
Heutzutage ist es ziemlich einfach, wenn man ein Tag definiert, das das Icon angibt. Das ist etwas anderes, als zu erwarten, dass die Datei an der richtigen Stelle liegt.
Kannst du mindestens ein paar Anwendungsfälle nennen, in denen man Favicons pro Pfad braucht?
Vor langer Zeit habe ich das einmal mit pragma no-cache und Referer-Prüfung umgesetzt. Es war nicht perfekt, funktionierte aber für die meisten Nutzer.
Ich benutze Firefox auf dem iPhone. Tut mir leid.
Wahrscheinlich verschwende ich damit aber immer noch weniger Energie als mit irgendwelchen Spielereien rund um generative KI.
1 Kommentare
Hacker-News-Kommentare
Den zuletzt verlinkten Issue habe ich geschrieben; das war ein merkwürdiges Déjà-vu. Als ich dem Problem damals nachging, entdeckte ich ein ziemlich seltsames Verhalten.
Im Grunde lud Firefox für die betreffende Website viermal so viele Favicons wie geöffnete Tabs, und das wiederholte sich jedes Mal, wenn man Tabs öffnete oder schloss.
https://aggressivelyparaphrasing.me/2022/12/12/why-does-my-l...
Dieses Problem wurde schon vor langer Zeit behoben; die Symptome sind also ähnlich, aber die eigentliche Ursache ist wohl eine andere, oder es gibt noch Leute, die eine alte Version nutzen.
Es ist ein Open-Source-Projekt, und auf GitHub gibt es eine gute Diskussion zu den technischen Streitpunkten[1]. Es könnte auch mit bestimmten Nutzergewohnheiten zusammenhängen, etwa Hunderte Tabs offen zu lassen, aber die Komplexität, einen Browser in iOS hineinzuzwängen, spielt sicher ebenfalls eine Rolle.
Das fühlt sich an, als würde man einen Bagger in einen Sandkasten stecken und ihn dort steuern.
[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113
Selbst ohne Cache: Wie groß kann der Traffic im Vergleich dazu sein, wenn eine andere Seite auf HN auf die Startseite kommt? Verschwendung ist es schon, aber so dramatisch wirkt es nicht.
Ich fände es gut, wenn ein offensichtlicher Anwendungsfehler nicht den Nutzern angelastet würde.
Mit anderen Worten: Ich dachte, das seien nur Skins.
Ich dachte, Firefox unter iOS sei nur ein Skin über Safari, weil Apple auf dem iPhone keine anderen Browser-Engines zulässt.
Firefox unter Android ist dank Plugin-Unterstützung großartig, auch wenn mir die UI vor 2021 besser gefallen hat.
Obwohl ich es nicht mag, mit dem Handy im Web zu surfen, hat er es halbwegs erträglich gemacht. Zu internen Problemen kann ich nichts sagen, aber natürlich ist das ein Thema, um das man sich kümmern sollte.
Ich bin schockiert, wenn ich Leute sehe, die ohne diese beiden im Web unterwegs sind. Es ist geradezu absurd, wie sehr Menschen zulassen, dass ihnen ihre Aufmerksamkeit geraubt wird.
Das wirkt inkompetent. Korrektur: Die Formulierung war etwas hart, und es ging mir nicht um einzelne Mitarbeiter, sondern um das Unternehmen. Genau das ist der Zustand, den Google will: Bei Monopolfragen plausible Bestreitbarkeit schaffen, während die Alternative miserabel bleibt.
Firefox für iOS nutzte früher Alamofire als Networking-Engine, wechselte aber irgendwann zu NSURLSession/URLSession. Chrome für iOS nutzt Cronet, das vom Chromium-Networking-Stack abgetrennt ist; da die jüngere Entwicklung dort nicht mitgezogen wurde, weiß ich nicht, ob das noch immer so ist.
Wenn das aber so ein Problem ist, kann man einfach ein Favicon hinzufügen. Nebenbei: Ich teste unter iOS oft mit Firefox, habe dieses Phänomen aber noch nie gesehen.
Der Autor dieser Seite gibt sich normalerweise ziemlich Mühe, den Namen großer kommerzieller Unternehmen zu verschleiern, wenn sie etwas Dummes tun; wenn es Firefox ist, nennt er den Namen. Hm.
Ich erinnere mich, dass es früher beim Internet Explorer etwas Ähnliches gab. Er fragte das Favicon an, aber weil damals keines konfiguriert war, kam eine 404-Seite zurück, und die schien wiederum eine weitere Favicon-Anfrage auszulösen.
Interessant ist es schon. Rein von der Nutzererfahrung her ist Firefox für das iPhone wirklich eine hervorragende App und seit Jahren mein bevorzugter Browser.
Ein Favicon ist nicht Teil einzelner Verzeichnisse. Wenn es so wäre, wäre das ein dummes Design gewesen.
Favicons pro Pfad klingen tatsächlich wie ein Feature.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
pragma no-cacheund Referer-Prüfung umgesetzt. Es war nicht perfekt, funktionierte aber für die meisten Nutzer.Unter https://stackoverflow.com/q/1321878/961353 gibt es einige Vorschläge, wie man Favicon-Anfragen vollständig deaktivieren kann.
Ich benutze Firefox auf dem iPhone. Tut mir leid.
Wahrscheinlich verschwende ich damit aber immer noch weniger Energie als mit irgendwelchen Spielereien rund um generative KI.
Für alle, die den Bug suchen möchten, hier die Stelle im Code: https://github.com/mozilla-mobile/firefox-ios/tree/main/Brow...