Nachdem ich in der letzten Zeit viel mit der iPhone App tadaa unterwegs war, um meine kleine Freuden des Alltags einzufangen, hab ich meinen kleinen Fotostream hier etwas vernachlässigt. Dies Schild, gefunden auf Usedom über Weihnachten, ist allerdings so groß, das ich das mal nachschieben muss:

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 :-).

Es hat lange gedauert, bis es bei mir soweit war, das ich mich mit Git beschäftigen musste(keine Abneigung, aber bei SVN hat mir einfach nichts gefehlt), aber just diese Woche ergab sich die Gelegenheit.

Eine Library(PHPThumbs) die ich verwenden möchte hosted ihren Code auf github.com und da mir die Library gut gefällt, mir aber eine Funktion zum Erzeugen von Tiles aus einem Image gefehlt hat, habe ich das kurzerhand als Anlaß genommen, mir mal Git anzusehen, indem ich das Projekt forke, mein benötigtes Plugin implementiere und dann das ganze dann hoffentlich zurück fließen lassen kann. Das Plugin ist implementiert und den Pull-Request hab ich auch rausgeschickt und nun warte ich ganz gespannt, was als nächstes passiert, ich bin ja soooo aufgeregt :-).

Und weil mir das Ganze so gut gefallen hat mit dem social coding(und das obwohl ich nicht mal ein Facebook Acount habe, he, he) hab ich gleich mal meine Zend Framework Beispiel Applikation (urlino.com) nach Github migriert. Jetzt heißt es warten und schauen, wann ich zum ersten Mal geforkt werde. Ich hab schon mal das „Fork me on GitHub“ Ribbon anschraubt :-).

Ansich ist Git ja wirklich angenehm, wobei ich zumindest jetzt am Anfang noch keine unerwartete Offenbarung erfahren habe, ist halt ein SCM, scheint meinen Bedürfnisse zu erfüllen und ist auch recht intuitiv zu bedienen, aber eine Sache ist mir zumindest untergekommen, die mir momentan noch nicht gefallen will: Und zwar das Einbinden von externen Libraries von denen es kein Git Repository gibt, also quasi ein svn:externals für Git, welches nicht nur mit Git Repositories spricht(gibt es und wird über submodules realisiert), sondern es auch erlaubt entfernte SVN (Teil-)Repositories auch in Git einzuhängen, was umgekehrt, also Git Repos in SVN Repo, Klasse funktioniert. Falls da ich da was übersehen habe und jemand eine clevere Lösung hat, das wär schon was :-).