Hallo,
Zum Beispiel so, wie ich gerade geschildert habe. Oder dass der Konzern einfach mitloggt, wer (über den Browser-Fingerprint ist schon eine ganz passable Nutzer-Identifikation möglich) wann, wie oft und von wo aus (d.h. mit welchem Referer) die jquery-Bibliothek abruft. So entsteht ruck-zuck ein Profil von Tausenden, wenn nicht gar Millionen von Internet-Nutzern, von denen man dann weiß, welche Web-Angebote sie so im Alltag nutzen.
Ist das nicht ein wenig witzlos? Ich meine, es geht doch darum, dass jQuery vom CDN eventuell schon im Cache ist, dann wird doch erst gar kein Request abgesetzt, also kann doch der Betreiber gar keine passable Nutzer-Identifikation mehr schaffen, oder übersehe ich jetzt was?
ja, möglicherweise schon. :-)
Erstens ist es optimistisch, wenn man davon ausgeht, dass eine solche Ressource bereits im Cache ist. Das mag zutreffen, wenn man während *einer* Browser-Session mehrere Sites besucht, die dieselbe Ressource verlangen. Brave Browser löschen ihren Cache-Inhalt aber beim Beenden.
Zweitens geht eventuell auch dann ein Request raus, wenn die gewünschte Ressource bereits im Cache ist - nämlich ein "conditional GET". Das ist ein normaler GET-Request mit einem If-Modified-Since-Header, mit dem der Browser beim Server anfragt: Ich habe die Ressource in der Version vom 14.11. um 21:49, wenn du was Aktuelleres hast, schick's mir bitte. Und darauf antwortet der Server mit einem Status 304 (Not Modified) und einem leeren Response Body, oder eben mit einem 200 und der aktuellen Fassung der verlangten Ressource. Freilich kann man seinen Browser auch auf "stur" einstellen, so dass er nicht nach einer neueren Version fragt, aber das möchte man in der Regel nicht, weil es mehr Ärger als Nutzen bringt.
So long,
Martin
In sein ist schon längst wieder out.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(