Wenn ich ausgehende Verbindungen zu "ajax.googleapis.com" mit meinem Router blocke, dann kann ich mit dem Firefox-10.0.2, ubuntuusers.de nicht mehr benutzen. Keine Probleme habe ich mit dem Firefox-3.6.24. Kann das jemand bestätigen und wenn ja, weiß jemand warum das so ist? Warum ist ""ajax.googleapis.com" so wichtig für ubuntuusers.de?
[Problem] Unerwünschte Verbindungen zu ajax.googleapis.com
|
Anmeldungsdatum: Beiträge: 2185 |
|
||
|
Supporter
Anmeldungsdatum: Beiträge: 5112 Wohnort: Wolfsburg |
[ironie] Liegt vielleicht daran: http://ikhaya.ubuntuusers.de/2010/04/01/alles-neu-macht-der-mai-neue-server-neue-suche/ [/ironie] |
||
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 2185 |
OK, verstehe. Du "kannst" nichts dazu sagen. |
||
|
Anmeldungsdatum: Beiträge: 4995 Wohnort: Wien |
Die Seite existiert ja nicht mal, oder übersehe ich was? |
||
|
Webteam & Serverteam
Anmeldungsdatum: Beiträge: 1468 |
Hast du mal versucht Firefox mit deaktivierten Addons zu starten? Hier gehts wunderbar… |
||
|
Webteam
Anmeldungsdatum: Beiträge: 526 |
Wir verwenden jQuery - damit wir dieses nicht jedem Nutzer zum Download anbieten müssen, lassen wir es vom Browser direkt von Google beziehen. Das hat den Vorteil, dass unsere Server weniger belastet werden und die Seite für jeden schneller lädt (da einerseits Google über mehr Kapazitäten als wir verfügt und andererseits der Browser vermutlich sowieso schon eine Kopie von jQuery verfügt und somit garnichts mehr nachladen muss). Benutzbar sollte ubuntuusers bei geblocktem googleapis.com oder deaktiviertem JavaScript aber bleiben, du dürftest lediglich etwas Komfort verlieren. |
||
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 2185 |
Kann sein. # nslookup ajax.googleapis.com Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: ajax.googleapis.com Address 1: 173.194.65.95 ee-in-f95.1e100.net
... 192.168.47.77.55744 > 192.168.47.1.53: 17754+ A? pagead2.googlesyndication.com 192.168.47.77.37606 > 192.168.47.1.53: 37311+ A? pagead2.googlesyndication.com 192.168.47.77.52493 > 192.168.47.1.53: 1966+ A? www.facebook.com 192.168.47.77.58449 > 192.168.47.1.53: 35075+ A? connect.facebook.net 192.168.47.77.48535 > 192.168.47.1.53: 46+ A? twitter.com 192.168.47.77.56231 > 192.168.47.1.53: 42235+ A? twitter.com 192.168.47.77.39328 > 192.168.47.1.53: 32190+ A? ajax.googleapis.com 192.168.47.77.37905 > 192.168.47.1.53: 30915+ A? ajax.googleapis.com 192.168.47.77.34934 > 192.168.47.1.53: 54882+ A? ajax.googleapis.com 192.168.47.77.52150 > 192.168.47.1.53: 48096+ A? ad-emea.doubleclick.net 192.168.47.77.37706 > 192.168.47.1.53: 13959+ A? ad-emea.doubleclick.net 192.168.47.77.48359 > 192.168.47.1.53: 13698+ A? fonts.googleapis.com 192.168.47.77.46954 > 192.168.47.1.53: 42140+ A? fonts.googleapis.com 192.168.47.77.59476 > 192.168.47.1.53: 60772+ A? www.facebook.com ... |
||
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 2185 |
Das kann ich so nicht bestätigen. Wenn ich ajax.googleapsis.com nicht blocke, dann lädt der Firefox-3.6.24 von google und das Öffnen der Seite dauert länger (insbesondere in den Abendstunden) als das Öffnen der Seite wenn ajax.googleapsis.com geblockt ist. EDIT: Ich habe keine Add-ons im Firefox-10.0.2 in meinem ubuntu. Nur eine Erweiterung und zwei Plugins. Das Deaktivieren der Erweiterung und der Plugins ändert nichts. |
||
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 2185 |
Habe die Lösung für mein Problem gefunden. Auf dem PC und in ubuntu mit iptables in der OUTPUT chain die "Fantasie-IP-Adresse" zur der ich im Router die Weiterleitungen der Mitteilungen/Anfragen an die "Datensammler" facebook, google & Co. gemacht habe, mit "-j REJECT" blocken. Jetzt funktionieren auch die anderen Foren mit dem FF-10.0.2 wieder. iptables -A OUTPUT -s 0/0 -d <Fantasie-IP-Adresse> -j REJECT |
||
|
Anmeldungsdatum: Beiträge: 610 |
Es ist doch klar, dass durch die Einbettung von googleapsis STÄNDIG IPs aller Nutzer an Google übermittelt werden und ich nehme schwer an, dass das auch fast der entscheidende Grund für Google ist, das genauso anzubieten. Denn für mich funktioniert das Forum auch so blitzschnell, obwohl ich googleapsis natürlich KEINE Skripte ausführen lasse, wenn man noscript glaube und vertrauen kann. Was fehlt mir technisch nun wirklich, erd_baer? Ich nutze es ja nicht bzw. habe es per noscript gesperrt? Also, abgesehen vom offenbar stillschweigend hier vorausgesetzen Vertrauen in BigBrother? Möglicherweise steckt mir noch der Schock von der obigen Ikayah-Seite in den Knochen. Sie ist wirklich schwer als Scherz zu erkennen. Ganz nach Heise.de-Manier und der Story vom Null-Device. |
||
|
Webteam
Anmeldungsdatum: Beiträge: 526 |
Hey Michaela, ich habe mir die Verwendung von ajax.googleapis.com / jQuery auf unserer Seite eben nochmal etwas genauer angesehen. Die Aussage ich schrieb:
muss ich zurückziehen. Wir verwenden zwar wie beschrieben das Google CDN, allerdings bewirkt dieser Abschnitt:
dass, im Falle, dass jQuery nicht von Google bezogen werden konnte (gesperrt ist), es von unseren Servern geladen wird. Von daher gibt es _keine_ Einschränkung oder Komfortverlust des Portals. Gebraucht wird es wie gesagt sowieso nur für Kleinigkeiten, darunter etwa der "Abonnieren / Als gelöst markieren" Button, der nicht ein Neuladen der Seite verursacht (okay, aktuell ist das kaputt und es lädt neu, aber das kriegen wir schon bald wieder hin Zum Thema Datenschutz: Ich vermute, dass jQuery deshalb von Google bezogen wird, da es bei den von jQuery empfohlenen CDNs als erstes aufgeführt oder einfach am zuverlässigsten und verbreitetstem ist (reine Vermutung, das Ding ist vermutlich länger im Quelltext als ich im Team Ich denke, dass wir auch auf ein anderes CDN ausweichen könnten, aber macht es wirklich einen Unterschied, ob die IP Google oder Microsoft bekommt? (ja, da kann man sich bestimmt herrlich drüber streiten
Hehe, keine Sorge, das dürfe das einzige hier sein, was Google Server verwendet Hoffe ich konnte dir den Verwendungszweck näher bringen und dass dahinter keine böse Absicht steckt, und wenn gegen einen anderen Anbieter nichts großartig spricht und das Team dahintersteht, können wir ja von Google auf diesen wechseln. Es muss ja nur ein einziger Link angepasst werden, der Aufwand ist also marginal. Gruß, erd_baer |
||
|
Anmeldungsdatum: Beiträge: 610 |
Herzlichen Dank, erd_baer! Auch wenn nichts daraus wird, bzw. es zuviel Umstände macht. Ich habe die Nase gestrichen voll, vom allgegenwärtigen Google und könnte damit Threads füllen, will ich aber nicht. Stattdessen habe ich unter Verletzung des Urheberrechts, d.h. im Rahmen des us-amerikanischen "fair use" deine Signatur halbkopiert |
||
|
Anmeldungsdatum: Beiträge: 4746 Wohnort: Wolfen (S-A) |
Ich habe jetzt mal in meinem ABP googleapis.com^ geblockt ... Das war also wirklich ein Tip. LG, track |
||
|
Anmeldungsdatum: Beiträge: 3092 Wohnort: Berlin |
prost,
Ich sehe grad, es gibt da auch ein CDN "von" jQuery, wollt ihr nicht einfach das nehmen? ( grüße, maix |
||
|
Webteam
Anmeldungsdatum: Beiträge: 526 |
Nach Absprache mit dem Serverteam wird mit dem heutigen Deploy auf jegliche CDN verzichtet, jQuery wird dann ausschließlich von unseren Servern bezogen. Gruß, erd_baer |
) und im Ikhaya, wo die Kommentare eines Artikels ein- und ausgeblendet werden können. Oder auch der Foren- / Wikieditor, welcher Syntaxelemente auf Klick in deinen Text einfügt und eine schnellerer Vorschaufunktion (da kein Neuladen der Seite notwendig ist). Spontan fallen mir nur noch ein paar administrative Funktionen des Teams ein, welche dich aber ja nicht betreffen.
). Außerdem kann Google jeder selbst nach Belieben sperren und ubuntuusers trotzdem in vollem Umfang nutzen, es ist also niemand auf Google angewiesen. Würde aber gerne noch die Rückmeldung des restlichen Web- und / oder Serverteams haben, ob und welches CDN sich besser eignet oder wir sogar darauf verzichten können / sollten (glaube ich nicht, alleine die gecached Kopien im Browser der Nutzer bringen jedem, der das jeweilige CDN nicht sperrt, einen Vorteil. Wieviel Traffic es für uns zusätzlich verursachen würde kann ich allerdings überhaupt nicht abschätzen.)
, weil ich sie super fand.
2004 – 2013 ubuntuusers.de • Einige Rechte vorbehalten