Da ich heute ein Gespräch mit einem Kollegen hinsichtlich der Gefahren von fremd-gehosteten Ads hatte und ich bezüglich dessen nun schon mal den Großteil fein aufgeschieben habe hiermal meine Gedanken dazu:

Im konkreten Fall ging es um Ads die über DFP ge-scheduled werden. Generell sind im Grundsatz 2 Arten denkbar, eine Ad welches über ein Netzwerk, wie z.B. DFP, ausgeliefert wird, eingebunden werden kann:

Zum einen direkt in die Seite eingebettet oder aber in einem speziellen IFrame, welches lediglich einen kleinen html Schnipsel enthält, der für das Einbinden des Ads notwendig ist. Wobei bei ersterer Variante relativ offensichtlich ist, das das im Prinzip recht böse ist, wir laden uns (meist) Javascript in den Scope unseres Dokuments, welches dann auf Cookies, DOM, etc. zugreifen kann.
Auch ein IFrame bringt wenig Besserung, wenn  z.B. ein Ad über die im IFrame geladene Datei http://www.example.com/ads/iframe.html geladen wird, so hat man gegenüber einer direkten Einbindung unter z.B. http://www.example.com/seite.html zumindest hinsichtlich der Cookies nichts gewonnen, das DOM der einbettenden Seite ist allerdings geschützt. Für die Cookies hilft hier das setzen eines Cookies mit vollem Pfad oder aber auf verschiedene Subdomains z.B. www.example.com, während Ads über eine eigene Subdomain ausgeliefert werden, z.B. ads.example.com.

Nehmen wir also an wir sind auf des selben Domain, haben unsere Cookies nicht auf eine speziellen Pfad gebunden und die böse Cookieräuberin ist in unserem Fall Frau Google. Google ihrerseits spannt nun generell ein iframe auf, in etwas so:

1
2

<iframe frameborder="0" scrolling="no" src="http://googleads.g.doubleclick.net/pagead/ads?...">
</iframe>

So das sich jedweder Code den ein Ad mitbringt eben nicht in www.example.com Scope befindet, sondern im googleads.g.doubleclick.net, sprich die Böse Cookieräuberin kann lediglich Google beklauen und in dessen DOM rumfuhrwerken.

Heißt soviel wie: Nur Google kann uns unmittelbar Schaden zufügen, da wir deren Code in unseren Scope laden. Ein böses Ad müsste eine Schwachstelle im Googlecode nutzen um über diese in unseren Scope bzw. in unser DOM zu gelangen. Sollte jemand eben solche Schwachstelle im Google code finden, dann könnte in der Tat ein IFrame den Zugriff auf unser DOM erschweren. Die (www.example.com)Cookies sind dann aber bereits gestohlen, sollten wir nicht obige Hinweise befolgt haben.

Der hauptsächliche Grund warum man Ads in ein IFrame lädt ist Performance, sprich das entkoppeln der Ladevorgänge von Seite und Ads. Löst man dies allerdings anderweitig, bleibt meiner Ansicht nicht mehr viel von der Herrlichkeit der IFrames. Hierfür gibt es Lösungen wie writeCapture, welche ein Lazy Loading von z.B. Ads erlauben, wobei dies ein eigenes, sehr spannendes Thema ist.

Falls mein Gedankenkonstrukt irgendwo löchrig erscheint, freue ich mich selbverständlich über ein Fachgespräch :-).

Der erste Arbeitstag nach 3 Tagen auf besagter Veranstaltung, neigt sich dem Ende, trotzdem, selbst mit einem Tag Abstand schwirrt mir noch der Vortrag „CouchDB – a Database for the Web“ von Jonathan Weiss im Kopf herum, NoSQL Datebanken wie eben CouchDB hab ich auf jeden Fall bis jetzt viel zu wenig beachtet, das schreit förmlich danach, sich damit mal einzuschließen und ein paar Dinge mal ganz praktisch im stillen Kämmerlein auszuprobieren.

Was auf jeden Fall auch hängen geblieben ist, sind viele kleine Denkanstöße aus diversen Vorträgen hinsichtlich jQuery bzw. allgemein Javascript, die zwar alle allein betrachtet nichts wirklich besonderes sind, aber so geballt nochmal serviert auf jeden Fall eine Bereicherung für den Alltag. Und wo ich gerade bei Kleinigkeiten bin: Der window.onError Handler der bei Javascript Fehlern im Frontend auf einen Webservice loggt, ist zwar nicht sooo neu, aber immer noch genial und als Nico Steiner eben jenen Handler in seinem Vortrag über die 1&1 Frontend-Architektur erwähnte, viel es mir wie Schuppen von den Augen, das Ding hatte ich vor Jahren auch schon mal, aber leider ist es bei aktuellen Projekten verloren gegangen, was aber nun zack nachgeholt wird.

Ansonsten gabs Dienstag Abend lecker Bierchen, welches die Gespräche über Softwareentwicklung, Prozesse und Konzepte doch ganz anständig emotionalisiert hat. Aber nun ja … das muss auch mal sein :-). Bleibt also nur zu hoffen, das auch nächstes Jahr wieder ein vergleichbar reichhaltiges Angebot an zumindest für mich interessanten Themen geboten wird, dann bin ich auf jeden Fall wieder mit dabei.

Nun ist es also soweit! Ich habe mich dazu entschlossen, meine täglichen kleinen Erfolgserlebnisse und Rückschläge für die Nachwelt zu dokumentieren, um vielleicht den einen oder anderen davor zu bewahren, unnötig viel Zeit auf ähnlich gelagerte Probleme zu verschwenden.

Vordringlich wird es wohl um Problem aus der PHP Welt gehen, aber da ich mich momentan (notgedrungen!) auch mit .net beschäftigen muss, wird sich da sich die eine oder andere spannende Problemstellung ergeben, insbesondere da das ganz für mich weitgehend Neuland ist.