Firefox "Bestätigung"

[bevoller]

Also wenn ich einen leeren Tab benötige, dann verwende ich meistens STRG+T.

Eventuell meint er STRG+Shift+T, um geschlossene Tabs wiederherzustellen.

das ist doch klar: wenn ich auf den ort zugreife (link, adresszeile, F5, wie auch immer), dann will ich die neue ressource.. nehme ich den zurück-button, will ich einen "snapshot" von genau dem was im cache ist - das war doch eigentlich der sinn der sache, sonst könnte man auch den cache gleich abschalten und nur eine URL-history führen..

Möchtest du vielleicht, ich nicht. Ich möchte einfach nur auf die Ursprungsseite zurück. Ein gutes Beispiel wäre vielleicht Google, obwohl ich da eigentlich mit mehreren Tabs arbeite. Aber nehmen wir an, ich klicke ein Suchergebnis an, das mir nicht zusagt. Dann kehre ich über den Zurück-Button wieder zur Google-Suchseite zurück.

Zum Cache-Verhalten bzw. Sinn des Cachens siehe die anderen Beiträge.

 

[Shodan]

Ein gutes Beispiel wäre vielleicht Google

Treffer, versenkt: Eine der Seiten, bei denen der BFCache funktioniert. Die Seite mit den Suchergebnissen siehst du im "Auslieferungszustand", auch wenn sie längst stale ist.
Die Leute von Google wissen eben, was sie tun: Die wollen weder bei Usern, die den zurück Button gerne mal nutzen, nach Möglichkeit die selbe Anfrage nicht noch mal bearbeiten (manuell versteht sich.. Ist alles Handarbeit bei Google xD) noch wollen sie dir, wenn sich in der Zwischenzeit die Zahl oder Reihenfolge der Ergebnisse verändert hat, eine völlig andere Ergebnisliste geben.

Die Usererwartung ist hier komplett umgekehrt: Der User will genau die Liste, die er eben gesehen hat und würde sich sehr wundern, wenn zB der Link den er gerade angeklickt hat, jetzt nicht mehr da ist, weil dessen Ranking sich so änderte, dass diese auf die vorherige Seite rutschte.

und das ist eben nicht sache des webmasters, ebensowenig wie referrer, werbung, darstellung und skripte! es ist nichts anderes als ein vorschlag oder eine bitte des webmasters, denn am ende entscheidet immer der user, was er mit den vom server gesendeten daten macht, und wenn er dafür nen eigenen browser entwickeln muss..

Jo und der Table Tag in HTML 4.01 spezifiziert auch nicht, dass eine Tabelle dargestellt werden soll, er ist nur ein Vorschlag, denn wenn ich jenen Browser dann so schreibe, dass die Daten in dem Tag als Binärcodierung einer bmp verstanden werden, dann ist es ein Bild.
Nur würde ich es schwer haben jemandem davon zu überzeugen, dass etwas ein "Browser" ist, wenn es weder HTTP noch HTML konform arbeitet. Eigentlich ist das als Argument aber ein Schuß in den eigenen Fuß, denn ironischerweise war die Diskussion lange genau andersherum. RFC 2616 sagte in 13.13: "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved." Die Realität hat die Spezifikation eingeholt, die RFC 7234 enthält diesen Satz nicht mehr.

(offenbar ist es also schlimmer wenn jemand mit dem zurück-button einen abgebrochenen post oder den kontostand sieht, als die tatsache, dass derjenige bereits zugriff auf alle lokalen daten hat, da der PC ungesichert im öffentlichen raum steht, aber gut)

Wie gesagt: "Legende hat es". Ich habe es aus einem Kommentar in Bugzilla (Teil 1, Teil 2).

also blanker unsinn, was das "sicherheits-argument" angeht.

Die RFC sieht das genauso und schreibt auch klar, dass "no-store" keine Sicherheit garantieren kann.
Ich muss hier dennoch des Teufels Advokat spielen und sagen: Die Banken hatten ein berechtigtes Interesse daran, dass die Inhalte zwischen Login und Logout nicht automatisch lokal verfügbar gemacht werden. Ja es ist kein "Sicherheitsfeature". Natürlich hilft es nichts gegen Bundestrojaner und amerikanische Geheimdienste und chinesische Hacker. Aber: Die User sind doof, man kann froh sein, wenn sie sich im Internetcafe auch vom Onlinebanking abmelden. Sie haben nach dem Prinzip "jedes bisschen hilft" den jungen Firefox kurzerhand ausgesperrt, weil er als einziger etwas tat, was in der RFC stand. In einer Zeit, in der IE gerade den Krieg mit Netscape gewonnen und etwa 90% des Marktes hatte. Ach ja der IE6.. Garantiert 98% kompatibel zu IE6 xD
Ich sollte anmerken, für den Fall, dass du die Bugzilla Seite nicht liest, dass Firefox auch damals den "no-store" als solchen verstand und nicht speicherte. Es ging um "no-cache". Man hat dem jungen Mozilla quasi aufgezwungen dieses in gleicher Art wie der IE zu interpretieren. Auch heute noch wird "no-cache" bei Nutzung über SSL so ausgelegt, obwohl no-store inzwischen auch von der Konkurrenz verstanden wird. Und ja die Banken hätten einfach andere header senden können, wäre wahrscheinlich sogar einfacher gewesen, wie einen Browser aus zu sperren. Aber so ist die Legende, nur Fisher kann dir sagen, was wirklich passiert ist.

Inzwischen hat sich der Standard der Realität angepasst. Es gab nie einen Browser, der die History (all the way) so implementierte, wie man es im letzten Jahrtausend für sinnvoll hielt. Außer wget vielleicht, aber dessen HTML Kentnisse lies sogar den IE gut aussehen

Über den BFCache: https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching Ja 1.5.. Soweit ich weiß gilt der Inhalt der Seite aber noch. Führt zu dem "tollen" Webmaster Tip, dass man zwar Caches haben, aber dieses, von vielen als "user unfriendly" (Twitter Beispiel!) eingestufte Verhalten sabotieren kann, in dem man ein "unload" event nutzt.

d.h. der button ist nicht dasselbe wie ein link bzw. die adresseingabe in die adressleiste.. bei letzterem findet immer eine server-kommunikation statt

Ich weiß, ich weiß, Wall of Text. Aber lies den Teil oben über Heise noch mal.

Ansonsten muss ich mich entschuldigen. Ich rede hier über RFC2616, aber die zitierten Passagen sind schon im Http1.1 Proposal von 1997 (RFC2068) und gehen direkt auf die Formulierung in Http1.0 (RFC1945) von 1996 zurück:

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

Stellt sich die Frage, ob es je einen Http1.0 Browser gab, der das auch so handhabte. Ich vermute nicht.

 

[BurnerR]

Danke für die tollen Beiträge, shodan. Habe ein deutlich besseres Verständnis dafür, warum die Dinge so sind, wie sie sind und was der Kontext davon ist.

 

[Novgorod]

Aber nehmen wir an, ich klicke ein Suchergebnis an, das mir nicht zusagt. Dann kehre ich über den Zurück-Button wieder zur Google-Suchseite zurück.

ja genau, und die kommt dann aus dem cache und nicht erneut vom server - das ist exakt der von dir zitierte teil, den ich gesagt habe (und den shodan verstanden hat)..

Jo und der Table Tag in HTML 4.01 spezifiziert auch nicht, dass eine Tabelle dargestellt werden soll, er ist nur ein Vorschlag, denn wenn ich jenen Browser dann so schreibe, dass die Daten in dem Tag als Binärcodierung einer bmp verstanden werden, dann ist es ein Bild.

mei, so ist das nunmal bei clientseitiger darstellung, da ist alles ein vorschlag.. umso wichtiger ist es, dass es clientseitige anpassungsmöglichkeiten gibt, wie sich irgendwas verhalten soll..

Sie haben nach dem Prinzip "jedes bisschen hilft" den jungen Firefox kurzerhand ausgesperrt, weil er als einziger etwas tat, was in der RFC stand.

ok, kein problem, kann ich nachvollziehen (mit einschränkungen: konsequenterweise dürfte dann kein browser tabs bzw. mehrere fenster zulassen oder die webseite abspeichern lassen; ein tab mit der kontoübersicht verschwindet ja nicht, wenn ich mich in einem anderen tab auslogge).. und sie dürfen das von mir aus ja ruhig machen wie sie wollen - nochmal: ich habe nichts gegen das gewählte default-verhalten.. ich kann ja den firefox bequem als IE oder was auch immer ausgeben lassen (ok, "bequem" war's damals als die problematik aufkam; heutzutage muss man halt in die config oder ein addon benutzen) - aber wo ist die anpassungsmöglichkeit für das vor/zurück-verhalten?!

 

[Shodan]

aber wo ist die anpassungsmöglichkeit für das vor/zurück-verhalten?!

/netwerk/protocol/http/nsHttpChannel.cpp
[src=cpp line=10] 2848 // Even if the VALIDATE_NEVER flag is set, there are still some cases in
2849 // which we must validate the cached response with the server.
2850 else if (mLoadFlags & nsIRequest::VALIDATE_NEVER) {
2851 LOG(("VALIDATE_NEVER set\n"));
2852 // if no-store or if no-cache and ssl, validate cached response (see
2853 // bug 112564 for an explanation of this logic)
2854 if (mCachedResponseHead->NoStore() ||
2855 (mCachedResponseHead->NoCache() && usingSSL)) {
2856 LOG(("Validating based on (no-store || (no-cache && ssl)) logic\n"));
2857 doValidation = true;
2858 }
2859 else {
2860 LOG(("NOT validating based on VALIDATE_NEVER load flag\n"));
2861 doValidation = false;
2862 }[/src]
Quelle

HAFTUNGSAUSSCHLUSS: Der Ersteller dieses Posts ist "irgend so'n Typ" in "irgend so 'nem Forum" und versichert hiermit feierlich, dass er den Hinweis auf diese Codestelle in einem Jahre alten Bugtracker Kommentar gefunden hat, keinerlei fundiertes Wissen besitzt, was passiert, wenn man daran irgend etwas ändert und dies auch selber nicht tun würde.
Er hält es außerdem nicht für eine gute Idee!
Die Nutzung von irgendwelche aus diesem Post gewonnenen Erkenntnissen unterliegt allein der Verantwortung des Nutzers.

 

[Krutius]

Hm, ich frage mich ob ein komplettes snapshotten nicht auch u.U. komplette Webseiten breaken würde. Gerade diverse alte Versionen von asp.NET WebForms scheinen mir hier Kandidaten.

U.u. generiert eine Webseite alle Daten via POST requests (eine dumme Idee, aber sei's drum, das gibts). Jetzt wird aus komischen Sicherheitsgründen ein hidden field vorgehalten, dessen Wert für jeden Klick wieder an den Server geschickt werden muss. Und jetzt ist jeder Wert nur einmal gültig.

Würde jetzt ein browser die HTML Flags ignorieren und konsequent cachen, würde ab dem drücken des "Zurück" Buttons nichts mehr funktionieren. Denn jeder Link ist ein submit Button, und der *alte* Wert des hidden fields ist nicht mehr gültig, also könnte man auf dem snapshot keinen einzigen Link drücken.

Obwohl. Wenn jemand so einen Schwachsinn baut, würde ja ein POST request mit den originalen Daten auch nichts helfen. Da wäre ja auch wieder ein ungültiger hidden field value dabei. Aber moment, da gab es doch so eine praktische Warnung für den Benutzer, dass er sich das nochmal überlegen soll!

 

[Novgorod]

selbst bei derart schlecht programmierten seiten ist doch eine "eingeschränkte" usability immernoch besser als garkeine usability, oder? (dasselbe passiert doch auch, wenn man entsprechende "links" in einem neuen tab öffnet und davor wird nicht gewarnt..) zumindest kann man zurück und sich die letzte seite überhaupt anschauen, auch wenn POST-links ggf. nicht mehr funktionieren (man kann ja mit dem vor-button wieder zur aktuellen seite zurück).. ein entsprechender haken in den einstellungen (per default aus), der konsequentes cachen einschaltet mit der zugehörigen warnung, dass dann vielleicht einige links auf den gecacheten seiten nicht mehr funktionieren, wäre doch die beste lösung..

und warum gibt es eigentlich keine warnung, wenn man auf einen link klickt, dass man mit dem zurück-button ggf. nicht mehr zurück kommt?

 

[BurnerR]

dessen Wert für jeden Klick wieder an den Server geschickt werden muss. Und jetzt ist jeder Wert nur einmal gültig.

Das ist gar nicht so abwegig, das ist bei bestimmten frameworks wie vaadin der Fall, das Serverzentrierter Web-Anwendungen produziert. Allerdings ist in dem Fall die Benutzung des Vor- und Zurück Buttons des Browsers sowieso oft nicht vorgesehen.

 

[CroneKorkN]

Das Problem ist also die Erwartung, die man an den Zurückbutton hat:

• Der eine erwartet einfach nochmal genau das zu sehen, was er zuletzt zu sehen bekam und ihn interessiert nicht, was da im Hintergrund abläuft und es interessiert ihn auch nicht, dass etwas nicht mehr aktuell sein könnte. Es ist ihm aber bewusst, denn er erwartet, dass er einfach in der Zeit zurück geht.
• Der nächste hat Verständnis vom HTTP und versteht die Inkonsistenz, die entstehen würde, wenn man einfach den vorigen Inhalt aus dem Cache laden würde. Die Seite ist nicht aktuell und beim Klicken eines Links auf der gecachted Seite würde die Web-Applikation ggf. durcheinander geraten.

Ersteres Verhalten wäre aber intuitiver und ein gutes GUI definiert sich durch seine Intuitivität. In meinen Augen wäre also die hier schon vorgeschlagene Verhaltensweise "besser" die Seite blind aus dem Cache zu holen und einen Hinweis anzuzeigen, eventuell auch erst beim Versuch der Interaktion. Dieses Verhalten wäre weitaus unaufdringlicher und gleichermaßen Sicher. In den allermeisten Fällen, wenn man zB nur noch mal die Bestellübersicht ansehen will nachdem man schon abgeschickt hat und anschließend wieder den "Vor"-Button drückt, würde es dem Benutzer ärger ersparen und wenn man wirklich die aktuelle Version der URL benötigt, wird man halt zu einem Druck auf F5 aufgefordert und auf die Damit verbundenen gefahren hingewiesen.

 

[BurnerR]

Ich würde einen dünnen Banner oben einbinden von wegen "Sie sehen eine veraltete Version aus ihrem lokalen Speicher. Einige Funktionalitäten stehen daher möglicherweise nicht zur Verfügung. Um eine aktuelle Version der Seite zu laden drücken sie _hier_".
Aber ich verstehe die Sicherheitsbedenken die damit einhergehen.

 

[CroneKorkN]

Wenn man bis zum Drücken von "_hier_" Interaktionen mit der Webseite verbieten würde, wären die Sicherheitsbedenken ja ausgeräumt. Damit könnte man halt nur einen POST-Request zurückgehen, weil die Requests ja sonst möglicherweise voneinander abhängen würden.

 

[BurnerR]

Ich habe dabei mehr an den beitrag von shodan gedacht:

Legende hat es, dass es die Banken waren, die am Ende der Diskussion massivst Druck auf Mozilla ausgewirkt haben. Die Zurück-Funktionalität soll wohl Daten auch dann vorgehalten haben, wenn sie mit "no-cache" "no-store" und über SSL ankamen. Das war zwar sehr "user friendly" aber nur, bis der User aufstand und weg ging ohne seine History zu leeren. Dann konnte sich jemand anders an den Rechner setzen und per Zurück einfach über den An/-Abmeldevorgang hinweg die gespeicherten Seiten hinter dem Login anschauen. Auch heißt es Nutzung des Firefox 3.0 sei für die französische Onlinewahl deswegen ausgeschlossen gewesen, da man in dem "Speicher" (Cache war es ja nicht, hielt sich ja nicht an die Regeln) nachsehen, wie der vorherige Nutzer des Rechners gestimmt hat.

Die Frage ist, ob es nicht eine Einstellung "respect no-store" bei Browsern geben sollte, was die default Einstellung ist sei mal dahingestellt.