Hi.
Also ich habe mir eine Firewall eingerichtet.
Sie ist sehr steng eingestellt. Mit einer großen blacklist, greylist mit
filtersystem und nur wenig per Whitelist komplett freigegeben ("trusted"
Ziele) Ports sind auch mehr zu als auf (auch ausgehend, eingehend
sowieso=
Es sind sind die ganzen ad-networks gesperrt usw. (Per ip und url
blacklist)
HTTPS ist nur zu bestimmten Zielen gestattet.
MC.net funktioniert über diese Firewall nicht, die Seite hängt sich auf,
weil sie versucht, eine Verbindung zu apis.google.com herzustellen, und
zwar mittels https.
Die Seite hängt sich dann auf.
Es geht nur, wenn ich die URL apis.google.com sowie die IP Range
74.125.77.0/24 als "Trusted" bzw per Whitelist freischalte
Allerdings ist damit dann auch wieder das Google tracking aktiviert, bzw
die Basis der Google Adword Systeme. Nur die Rückgabe, also die Werbung
wird noch weiter gefiltert, dennoch ist man schon wieder durch google
"trackbar", wenn ich diese Ziele genehmige.
mfg
Achja, an gstatic.com bleibt die Seite auch ne weile hängen. Aber zu dem Zeitpunkt ist sie schon weitestgehend fertig aufgebaut, so dass es nix ausmacht. Eventuell muss ich einen webserver mit dummyseiten einrichten und die google sachen dahin umleiten, um mc.net gangbar zu machen. ohne die Datenkrake Google zu viel freizuschalten. Dann bekomme ich auch nicht diese "access denied" Meldungen meines Proxys an 2 Stellen hier im Layout dieser Seite
Hmm, apis.google.com ist ein richtiges Sorgenkind. Wenn man das knallhart via hosts file tot legt, kommt hier auf der Seite gar nichts mehr. Nur noch ein weißes, leeres Fester. Außerdem hat apis.google.com auch noch mehrere IP Adressen in ganz unterschiedlichen Ranges: Neben der oben genannten auch noch in 209.85.148.0/24 Das muss man auch für HTTPS freischalten, damit uC.net geht. Was wird da wohl so geheimes übertragen, dass dafür https notwendig ist? Die mögen wohl keine Zaungäste. Mal schauen, vielleicht finde ich auch noch raus, was da per https übertragen wird. Vielleicht per HHTPS Proxy, so dass man da dann irgendwo mitlesen kann. Ohne die Datenkrake Google geht heute scheinbar gar nix mehr.
Nico --- schrieb: > Ohne die Datenkrake Google geht heute scheinbar gar nix mehr. Ginge schon, wenn man wollte - nur wäre dann wohl nicht mehr sehr viel los mit den Werbeeinnahmen, aus denen sich dieses Forum finanziert.
Ja, mir ist bewusst, dass sich vieles im Internet (so auch dieses Forum) über Werbung finanziert. Und Google macht es einem da schön einfach. Ich mache den Betreibern dieses Forums auch keine Vorwürfe. Ich bin nur erschrocken, dass es komplett funktionsunfähig wird (komplett weiße Seite), wenn man apis.google.com knallhart weg blockt bzw auf einen eigenen Dummy umlenkt. Nur die "Rückgabe" also die URLs mit den Werbebildchen rauszufiltern, ist meiner Meinung nach ehr unnötig. Denn da hat Google und co das Tracking schon längst gemacht. Dann kann man die Werbung auch durchlassen, ob ich jetzt im Banner Werbung habe oder das Logo meines Proxys ist dann auch kein so großer Unterschied mehr.
Hier ist übrigend eine schöne Übersicht, was Google alles im angebot hat. Die Datenkrake hat wirklich fast überall die Finger drin. Kein Wunder, das ein aussperren der Krake so massive Folgen hat. Es ist ja nicht nur diese Seite, die dann "funktionsunfähig" ist. http://images.stevieswebsite.de/tools/google/apis.jpg
Gast
#2363243
Nico --- schrieb: > Ohne die Datenkrake Google geht heute scheinbar gar nix mehr. Nur mal so eine Frage: Bist du bei Facebook angemeldet?
Nico du solltest auch deinen Browser dazu nennen, ich hab hier keine Probleme mit dem sperren diverser google apis. Und seh ich das richtig das du über https auf mikrocontroller.net surfst? Dann laufen natürlich auch alle Skripte darüber.
Hi. Also Browser ist Firefox in der Version 5. Über HTTPS surfe ich nicht auf mc.net. Ich gehe über einen Proxy und Firewall. HTTPS ist bei mir nur für gewisse Seiten freigeschaltet. Google Apps gehörte nicht dazu. Ansonsten ist die Firewall ausgehend komplett bis auf gezielt freigeschaltete Ports zu. Und Port 80 wird über den Proxy gezwungen, ohne Proxy kein herauskommen auf 80 und anderen üblichen HTTP Ports. MC.net funktionierte erst wieder, als ich 2 gewisse IP Ranges von apis.google.com für https freigeschaltet habe. Diese Google Apps wollten immer via HTTPS (und nicht via Port 80 über den Proxy) nach Hause telefonieren, selbst wenn ich uC.net via HTTP aufrief. Das endete damit, dass ich während dem Laden dieser Seite in einer "Ladeschleife" hängen blieb. Und als ich meinen Google dummy einschaltete, (leere apps.google.com Seite auf lokalem Server) ging gar nix mehr, da kam nur eine weiße Seite. Bei anderen Seiten habe ich ähnliche Probleme. Teilweise muss ich die Seiten sogar vom Proxy ausschließen oder sogar andere Ports als 80 und 443 nach außen öffnen. In einem Fall z.B. Port 8088. Facebook ist übrigens ähnlich schlimm wie google. Da gibts auch seiten, die eine HTTPS Verbindung zu Facebook für ein Facebook social Plugin herstellen wollen. Das endet dann auch in einer Ladeschleife. Die Firewall/Proxy ist für normalen Internetgebrauch schon fast zu restriktiv, zumindest ausgehend. Grüße
hm... also bei mir lädt der alles über http. Installier dir mal FireBug und schau ins Netzwerkmodul was er da tatsächlich lädt und wo es hängt, der Zeigt dir dann auch auf der Zeitlinie an wie lange es dauert.
Ich installiere mal Firebug. Ich sperre apis.google.com mal wieder und schaue dann, ob ich im Firebug was sehe.
Gast
#2363380
Trage doch ein das dein Proxy für nicht freigegebene "IP-Bereiche" er eine "Fehlerseite" zurückschickt. Wenn du nur die Bereiche blockst, dann versucht der Browser die Seite zu holen und läuft in einen Timeout, weil er ja versucht den Inhalt der Seite zu holen, die du ja geblockt hast.
So, habe eine Lösung gefunden. Es ist in der Tat ein JavaScript, was Probleme macht. Der läuft mehrmals in einen Timeout. Da der Aufruf mehrmals gemacht wird, zieht sich das über mehere Minuten, bis uC.net vollständig geladen ist. Als Workaround ist es möglich, JavaScript komplett zu deaktivieren, und zusätzlich gewisse Seiten auf eine leere, aber valide HTML Datei umzuleiten. Auch bei deaktiviertem Java Script versucht uC.net, trotzdem eine Verbindung mit apis.google.com sowie googleadservices herzustellen. Bei deaktiviertem Java Script (und zwar nur bei deaktiviertem Java Script) und leeren Dummy Seiten gehts aber. Als weitere Lösung bietet sich ein Filter an, der einfach "leere" Scripts an den Browser ausliefert. Dann kann man JS im Browser aktiviert lassen, und diese Seite lädt durch. Grüße
So, wieder da. So sieht das übrigens in Firebug aus, wenn ich das google javaScript mittels Filter im Proxy gegen einen leeren Dummy ersetze. uC.net lädt dann mit mehreren 10 Sekunden Verzögerung fertig. Es hilft wirklich nur, JS ganz abzuschalten, den BigBrother google "durchzulassen" oder wirklich tiefgehend zu "modden", um uC.net lauffähig, ohne eine mehrer 10 Sekunden lange ladepause lauffähig zu bekommen. Grüße
Angehängte Dateien:
-
fehler.png
(40 KB)
Man kann es sich auch unnötig schwer machen. Mit Sicherheitsbewusstsein hat das nichts mehr zu tun.
Naja, bei der produktivfirewall werde ich schon nicht so weit gehen wie jetzt. Aber in der Testphase kann ich ja mal probieren, was möglich ist. Aber ich sehe, du hast das mit google gefixt :) Wenn man jetzt die seiten api.google.com und googleadservices.com bannt, erkennt das dein schript und generiert selbst Werbung mit Daten von ebay oder Bücherbillig.de Und das Banner wird serverseitig erzeugt bzw vorbereitet. Auch sehr gut gelöst. Nur wenn man JavaScript komplett abschaltet, kommt gar keine Werbung. Ich finde das übrigens gut, da sich das ganze jetzt nicht mehr aufhängt beim Laden. Mit der Art und Weise, wie die "fallback" Werbung erzeugt wird, kann ich übrigens sehr gut leben. Es ist kein AdWort System, was einem nachher personalisierte Werbung zukommen lässt (was mich tozal stört), sondern es ist durch den serverbetreiber hier festgelegt, was gezeigt wird. Egal was ich vorher im Netz mal gesucht habe. Auf das Google Werbesystem habe ich es abgesehen und mir vorgenommen, die Personalisierte Werbung und das Tracking so gut es geht zu verhindern. Grüße
Nico --- schrieb: > Auf das Google Werbesystem habe > ich es abgesehen und mir vorgenommen, die Personalisierte Werbung und > das Tracking so gut es geht zu verhindern. Och, da kommst du doch um die ganze Unterwäsche-Werbung drumrum. :-) Ich habe ein normales Adblock laufen, das, was dann noch an Werbung hier durchkommt, nervt mich ehrlich gesagt gar nicht.
Nico --- schrieb: > So, wieder da. > > So sieht das übrigens in Firebug aus, wenn ich das google javaScript > mittels Filter im Proxy gegen einen leeren Dummy ersetze. > > uC.net lädt dann mit mehreren 10 Sekunden Verzögerung fertig. > > Es hilft wirklich nur, JS ganz abzuschalten, den BigBrother google > "durchzulassen" oder wirklich tiefgehend zu "modden", um uC.net > lauffähig, ohne eine mehrer 10 Sekunden lange ladepause lauffähig zu > bekommen. > > > Grüße sry aber mal im ernst...dein vorgehen ist schon etwas lächerlich... WENN jemand dich tracken will kann er das auch, sei es per handyposition, bilderkennung bei öffentlichen kameras, spracherkennung am telefon etc.. der fehler den du da siehst kommt nur wenn man die hosts von google aussperrt (zB durch nen adblocker). jedoch verlängert sich nicht die ladezeit bei einem korrekt eingestelltem browser. irgendwas wird in deiner firewall falsch konfiguriert sein, dass die requests solange dauern, wahrscheinlich kommt kein "denied" oder "not found" zurück sondern einfach ein connection timeout. in diesem fall würde ich dir raten wenn du firefox verwendest dir AdBlock+ zu installieren. die hosts werden dann direkt in firefox gesperrt und du bekommst kein timeout problem...
Jörg Wunsch schrieb: > Ich habe ein normales Adblock laufen, das, was dann noch an Werbung > hier durchkommt, nervt mich ehrlich gesagt gar nicht. Ja, das it der Unterwäsche kenne ich, schon selbst erlebt. Ich bekomme hier im Forum auch Werbung von WoW usw. Sachen, die gar nix hier mit zu tun haben. Oder als ich mal nach Sat Antennen im Netz geschaut hatte, kam halt immer personalisierte Conrad Werbung. Das hat mich massivst gestört. Nicht nur hier auf der Seite, auch anderswo. Ein Adblocker Addon im Browser unterdrückt nur die Ausgabe. Es verhindert nicht das Tracking. Mir gings drum, das Übel an der Quelle zu bekämpfen, und nicht nur die Ausgabe, sondern auch das Tracking soweit es geht zu vermeiden. Gegen statische Werbung, bzw Werbung, die vom Seitenbetreiber selbst zusammen gestellt wird, habe ich nichts, von irgendwas muss ja alles auch finanziert werden. Aber mit Google AdWord bin ich auf Kriegsfuß, und mein neuer Server eröffnet mir endlich entsprechende Gegenmaßnahmen. Viele Grüße
Andi D. schrieb: > der fehler den du da siehst kommt nur wenn man die hosts von google > aussperrt (zB durch nen adblocker). jedoch verlängert sich nicht die > ladezeit bei einem korrekt eingestelltem browser. irgendwas wird in > deiner firewall falsch konfiguriert sein, dass die requests solange > dauern, wahrscheinlich kommt kein "denied" oder "not found" zurück > sondern einfach ein connection timeout. in diesem fall würde ich dir > raten wenn du firefox verwendest dir AdBlock+ zu installieren. die hosts > werden dann direkt in firefox gesperrt und du bekommst kein timeout > problem.. Der Seitenbetreiber hier hat das Problem schon gefixt. Und du hast recht, ich habe die geblockten Verbindungen einfach ins leere laufen lassen. Nachher mit leeren Dummyseiten gings schon besser, aber immer noch nicht wirklich gut, da Scriptfehler en mass auftraten. Seit dem Fix bekomme ich halt mehr oder weniger statische, bzw hier vom Server zusammen gestellte Werbung und die Seite lädt wieder perfekt durch. ok, bei fbcdn.net (auch gebannt bei mir) bleibt er noch hängen, aber nur ca 5-10 sekunden und auch erst ganz am Ende des Ladevorganges. Und ja, ich weiß, dass jemand der einen wirklich tracken will das auch tun kann. Aber man kann ja schonmal mit der größten Datenkrake, Google, anfangen, den Trackern und Ad Netzwerken mit personalisierter Werbung das Leben ein bisschen schwerer zu machen. Sehe es einfach als Machbarkeitserprobung, denn genau das ist es. Den Proxy/Firewall habe ich ja erst knapp 2 Tage, da muss halt rumgespielt werden.
Nico --- schrieb: > Ein Adblocker Addon im Browser unterdrückt nur die Ausgabe. Es > verhindert nicht das Tracking. AdBlock Plus kann die Werbung sowohl blockieren als auch verstecken.
Verhindert es auch, dass Daten raus gehen? Oder blockt es nur die herein kommenden Daten?
Nico --- schrieb: > Verhindert es auch, dass Daten raus gehen? Wenn das Javascript nicht geladen wird, kann es auch keine Daten senden. Jedenfalls kann man die übertragenen Informationen viel besser als mit einer Firewall kontrollieren. Diese sieht ja nur: HTTP auf IP xyz -> Durchlassen In die OSI-Ebene darüber kannst du nur mit dem Browser zugreifen, oder mit einer Firewall mit Deep Packet Inspection.
>Die Datenkrake hat wirklich fast überall die Finger drin. >Kein Wunder, das ein aussperren der Krake so massive Folgen hat. Es ist >ja nicht nur diese Seite, die dann "funktionsunfähig" ist. >http://images.stevieswebsite.de/tools/google/apis.jpg Ist ja ein nettes Periodensystem der googleschen Elemente ;-)