prefetch & preconnect zeitgemäß?

[Hanzo2012]

GA z.B. ist weit weitverbreitet, deswegen befindet sich das dazugehörige Script schon im Cache der meisten Browser.

Ich habe dazu neulich gelesen, dass in Chrome bald jede Origin ihren eigenen, von den anderen isolierten Cache bekommen soll.

Ein gemeinsam genutzter Cache lässt sich nämlich missbrauchen, um z. B. herauszufinden, ob der Besucher in letzter Zeit eine bestimmte Seite (z. B. YouPorn ) besucht hat. Auch lassen sich wohl „Super-Cookies“ damit implementieren, mit denen man User noch besser ohne ihr Wissen tracken kann.

Sowas Ähnliches gab es vor langer Zeit schonmal. Da hat man einfach einen Link zu z. B. YouPorn gesetzt und mit JavaScript dessen Farbe abgefragt. Wenn der Besucher die Seite besucht hat, ist der Link nämlich anders gefärbt als wenn nicht. Das geht heutzutage nicht mehr. Was man stattdessen macht ist z. B. das Logo-Bild von YouPorn anzufragen und mit JavaScript die Zeit zu messen, die es zum Laden benötigt. Liegt es im Cache (weil der Besucher die Seite besucht hat), geht das quasi sofort, andernfalls dauert es ein wenig. Und schon hat man eine potenziell sensitive Information über den Nutzer. Das geht wohl aber noch viel weiter ...

Details hier: https://blog.josephscott.org/2019/10/16 ... ttp-cache/

Und hier: https://portswigger.net/daily-swig/new- ... nformation

Das würde bedeuten, dass Analytics, Google Fonts etc. in Zukunft zig-mal gecached werden, nämlich einmal für jede Origin, die es einbindet - wenn Google sich da nicht noch was einfallen lässt, um das zu verhindern.

Hat jetzt mit diesem Thema wenig zu tun, aber ich finde es interessant.

[supervisior]

Ein gemeinsam genutzter Cache lässt sich nämlich missbrauchen, um z. B. herauszufinden, ob der Besucher in letzter Zeit eine bestimmte Seite (z. B. YouPorn ) besucht hat. Auch lassen sich wohl „Super-Cookies“ damit implementieren, mit denen man User noch besser ohne ihr Wissen tracken kann.

Ähm, ich dachte eigentlich, dass das Thema Super-Cookies längst durch ist? Wenn da jetzt was Neues kommt, dann aber sicherlich nicht auf dem bekannten Super Cookie Prinzip, weil die ja schon Browser seitig geblockt werden.

[supervisior]

Nur weil es mir grad noch einfällt wegen den Google Schriftarten. Der TTL für diese Fonts hat grad mal 1 Std. und der Cache ist private. Von daher wohl eher unkritisch zu dem was Du meinst, oder?

[Hanzo2012]

Ähm, ich dachte eigentlich, dass das Thema Super-Cookies längst durch ist? Wenn da jetzt was Neues kommt, dann aber sicherlich nicht auf dem bekannten Super Cookie Prinzip, weil die ja schon Browser seitig geblockt werden.

Es gibt ja mehrere Möglichkeiten sowas zu erreichen. Eine davon geht wohl durch das Ausnutzen eines seitenübergreifenden Caches.

Nur weil es mir grad noch einfällt wegen den Google Schriftarten. Der TTL für diese Fonts hat grad mal 1 Std. und der Cache ist private. Von daher wohl eher unkritisch zu dem was Du meinst, oder?

Soweit ich mich erinnere, hat nur das Stylesheet eine kurze Cache-Haltbarkeit. Die darin verlinkten Font-Dateien werden wiederum wesentlich länger gecached (1 Jahr). Die Idee dahinter ist, dass Google kurzfristig die Fonts austauschen bzw. verbessern kann, indem sie einfach die Dateinamen der Font-Dateien ändern.

"Cache-Control: private", falls du das mit "private" meinst, ist nochmal was anderes. Das verbietet es einem Proxy-Server die Ressource zu cachen. Das macht man normalerweise bei Ressourcen, die z. B. eine Authentifizierung bzw. eine Session erfordern und wo man nicht möchte, dass sie von einem Proxy-Server in seinem eigenen Cache gespeichert werden, weil sie dann auch ein anderer Nutzer des Proxys - ohne Authentifizierung - abrufen könnte.

[supervisior]

"Cache-Control: private", falls du das mit "private" meinst, ist nochmal was anderes. Das verbietet es einem Proxy-Server die Ressource zu cachen. Das macht man normalerweise bei Ressourcen, die z. B. eine Authentifizierung bzw. eine Session erfordern und wo man nicht möchte, dass sie von einem Proxy-Server in seinem eigenen Cache gespeichert werden, weil sie dann auch ein anderer Nutzer des Proxys - ohne Authentifizierung - abrufen könnte.

Da bin ich jetzt zwar gaaaanz anderer Meinung als Du, aber ich lass Dich mal in Deinem Wissen....

[Hanzo2012]

Dachte ich mir schon, dass du „Cache-control: private“ komplett falsch verstanden hast, aber ist ja auch ein kompliziertes Thema, also sei dir mal verziehen. Hauptsache du bist bereit zu lernen!

Einfach mal lesen ...
https://de.m.wikipedia.org/wiki/Browser ... oxy-Server
https://www.keycdn.com/blog/http-cache-headers
https://stackoverflow.com/questions/349 ... he-control
https://www.cloudflare.com/learning/cdn ... e-control/

Dank mir später!

[supervisior]

Ich Dir danken? Jetzt komm aber mal runter von Deinem Podest. Das würde ja voraussetzen, dass Du schlauer bist als ich. Aus der vorangegangenen Diskussion hast Du das schon mal nicht bewiesen, gell?

Dass "private" sich womöglich auf Proxies auswirken könnte, will ich gar nicht mal anzweifeln. Das stelle ich auch gar nicht in Frage. Es geht mehr und konkret darum, was Google damit und außerdem damit bezweckt. Anders als Du es annimmst, dient das Private Attribut nicht ausschließlich dazu auf das Caching Verhalten von Proxies einzuwirken, aber das ist ein anderes Thema. Konkret erzwingt Google mit dem Private Attribut, dass sich der Client die Source herunterladen muss auch wenn er sich die gleiche Source schon mal anderswo in den Cache geladen hat. Die offizielle Dokumentation dazu schweigt sich darüber nur aus.

Und vorausschauend auf Deinen möglichen Einwand dazu, mein zweiter Vorname ist "Cache" mit dem Verweis auf meinen Lichtgeschwindigkeitsserver dessen essentieller Bestandteil das Cachen ist.

[Hanzo2012]

Ich Dir danken? Jetzt komm aber mal runter von Deinem Podest. Das würde ja voraussetzen, dass Du schlauer bist als ich.

Ach, man kann einem Menschen nur danken, wenn er schlauer ist als man selbst? Abgesehen davon bin ich das definitiv.

Aus der vorangegangenen Diskussion hast Du das schon mal nicht bewiesen, gell?

Die vorangegangene Diskussion hat vor allem gezeigt, dass du dich nicht in Dinge wie Header Bidding einmischen solltest, mit denen du keine Erfahrung hast (denn sonst wäre das Missverständnis gar nicht aufgekommen, wegen dem wir uns so lange im Kreis gedreht haben), und dass du wild mit Begriffen um dich wirfst, die du nicht richtig definieren kannst. Ich sage nur Verbindung und Request *hust*

Dass "private" sich womöglich auf Proxies auswirken könnte, will ich gar nicht mal anzweifeln. Das stelle ich auch gar nicht in Frage. Es geht mehr und konkret darum, was Google damit und außerdem damit bezweckt.

Da gibt's nichts anzuzweifeln, das ist der primäre Zweck davon. Außerdem: Dann sag das doch, anstatt nur pauschal den ganzen Absatz in Frage zu stellen, nur um mal wieder das letzte Wort zu haben ohne Inhalt zu liefern.

Konkret erzwingt Google mit dem Private Attribut, dass sich der Client die Source herunterladen muss auch wenn er sich die gleiche Source schon mal anderswo in den Cache geladen hat.

Wage ich zu bezweifeln, schließlich sagt Google selbst dazu folgendes (Quelle):

The font files themselves are cached for one year, which cumulatively has the effect of making the entire web faster: When millions of websites all link to the same fonts, they are cached after visiting the first website and appear instantly on all other subsequently visited sites.

Außerdem lässt sich das ja auch ganz leicht testen und zeigen, dass deine Aussage - mal wieder - falsch ist.

Und vorausschauend auf Deinen möglichen Einwand dazu, mein zweiter Vorname ist "Cache" mit dem Verweis auf meinen Lichtgeschwindigkeitsserver dessen essentieller Bestandteil das Cachen ist.

Beeindruckend, wie du eine Software installieren kannst. Pass bloß auf, dass du deinen eigenen Cache nicht als pösen pösen Hacker fehlinterpretierst so wie damals die QUIC-Nutzer

[supervisior]

Die vorangegangene Diskussion hat vor allem gezeigt, dass du dich nicht in Dinge wie Header Bidding einmischen solltest, mit denen du keine Erfahrung hast (denn sonst wäre das Missverständnis gar nicht aufgekommen, wegen dem wir uns so lange im Kreis gedreht haben), und dass du wild mit Begriffen um dich wirfst, die du nicht richtig definieren kannst. Ich sage nur Verbindung und Request *hust*

Nur damit der stille Leser keinen falschen Eindruck bekommt und die vorangegange Diskussion richtig dargestellt wird. Du hast in Deine Argumentation etwas eingebracht, was überhaupt nicht zur Diskussion stand, nicht Bestandteil des Themas war und nur für Deinen eigenen persönlichen Fall überhaupt eine Relevanz hat. Hättest Du das von vornherein kommuniziert, hätten wir uns die ganze Schreiberei zu 99% ersparen können. Also schön bei den Fakten bleiben, gell!

[Hanzo2012]

Dem stillen Leser (als ob sich irgendjemand noch dafür interessieren würde ) möge dann auch Folgendes vor Augen geführt werden: Ich habe die ganze Zeit über ganz klar gesagt, dass es darum geht, den Preconnect zu den am Header Bidding teilnehmenden Hosts durchzuführen. Was du nicht wusstest, ist, dass man diese Hosts bereits vorher kennt, da es immer die gleichen sind.

[supervisior]

Sorry, den Schuh darfst Du Dir aber trotzdem anziehen. Ob ich die Hosts hätte wissen können oder nicht, ist irrerelevant, weil die Maßgabe das Code Beispiel des Themenstarters war/ist. Warum muss Du als Yieldlove und Header Bidding Anhänger persönliche Kriterien einbringen, die unweigerlich zu einer vollkommen sinnfreien Diskussion führen. Das konnte ja nur schief gehen.

[Hanzo2012]

Warum muss Du als Yieldlove und Header Bidding Anhänger persönliche Kriterien einbringen, die unweigerlich zu einer vollkommen sinnfreien Diskussion führen. Das konnte ja nur schief gehen.

Nun, der Themenstarter nutzt selbst Yieldlove und Header Bidding, und er war derjenige, der Ganze ins Spiel gebracht hat:

Bleibt Yieldlove mit Header Bidding und den geschätzen 50 Netzwerken - das ist das overdosed.

Erst daraufhin habe ich überhaupt dieses Thema aufgegriffen.

Wirklicher Anhänger von Header Bidding bin ich übrigens nicht. Es ist zwar toll in der Hinsicht, dass es bessere Einnahmen generiert als z. B. nur AdSense, aber aus technischer und datenschutzrechtlicher Sicht ist es furchtbar.

[supervisior]

Nur um das Thema Header Bidding und Preconnect dann doch nochmal aufzugreifen, eigentlich sollte Yieldlove und die beteiligten Netzwerke auf QUIC setzen, zumal sich damit das Handshake dann doch erheblich verkürzen ließe. Auf Seiten der Browser unterstützen alle Chrome basierten Browser QUIC ja bereits und das sind ja nicht wenige.