<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Ballsy serving move by Google</title>
	<atom:link href="http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/feed/" rel="self" type="application/rss+xml" />
	<link>http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/</link>
	<description>greg yardley on online product management</description>
	<lastBuildDate>Wed, 04 Jan 2012 05:04:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Bosko</title>
		<link>http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/comment-page-1/#comment-1581</link>
		<dc:creator>Bosko</dc:creator>
		<pubDate>Fri, 04 Apr 2008 14:42:48 +0000</pubDate>
		<guid isPermaLink="false">http://yardley.ca/?p=556#comment-1581</guid>
		<description>Greg - I agree that document.write()ing third-party tags are generally bad for publisher security (access to publisher DOM), but:

- they&#039;re (still) used; a lot of publishers who don&#039;t have established accreditation processes simply stick tags in their pages at the location where they expect ads to appear, without providing DIVs to anchor onto, nor IFRAMEs.  Sad but true.

- IFRAMEs, while great, don&#039;t unilaterally prevent third-parties from touching the publisher&#039;s DOM.  In particular, when dealing with lots of implementations of expandable units delivered within IFRAMEs, you gotta have a way of busting out of the IFRAME on expand, and that implies having a mechanism to play with the IFRAME parent&#039;s DOM (i.e., the publisher DOM).

In general, I think that there is an implicit trust relationship between publishers and their direct advertisers.  Ad units delivered through generic third-party ad network tags are a different story, but those are rarely rich units anyway and can likely safely be isolated in IFRAMEs.

This trust relationship, it&#039;s worth mentioning, exists between publishers and other &quot;service providers&quot; too, so it&#039;s not reserved solely to advertising.  For example, if I stick del.icio.us&#039; mp3 player tag code in my page, I&#039;m theoretically opening myself up to the possibility of a compromise of del.icio.us affecting my site as well.

Thanks for the post... I&#039;ll be watching for additional insights.</description>
		<content:encoded><![CDATA[<p>Greg &#8211; I agree that document.write()ing third-party tags are generally bad for publisher security (access to publisher DOM), but:</p>
<p>- they&#8217;re (still) used; a lot of publishers who don&#8217;t have established accreditation processes simply stick tags in their pages at the location where they expect ads to appear, without providing DIVs to anchor onto, nor IFRAMEs.  Sad but true.</p>
<p>- IFRAMEs, while great, don&#8217;t unilaterally prevent third-parties from touching the publisher&#8217;s DOM.  In particular, when dealing with lots of implementations of expandable units delivered within IFRAMEs, you gotta have a way of busting out of the IFRAME on expand, and that implies having a mechanism to play with the IFRAME parent&#8217;s DOM (i.e., the publisher DOM).</p>
<p>In general, I think that there is an implicit trust relationship between publishers and their direct advertisers.  Ad units delivered through generic third-party ad network tags are a different story, but those are rarely rich units anyway and can likely safely be isolated in IFRAMEs.</p>
<p>This trust relationship, it&#8217;s worth mentioning, exists between publishers and other &#8220;service providers&#8221; too, so it&#8217;s not reserved solely to advertising.  For example, if I stick del.icio.us&#8217; mp3 player tag code in my page, I&#8217;m theoretically opening myself up to the possibility of a compromise of del.icio.us affecting my site as well.</p>
<p>Thanks for the post&#8230; I&#8217;ll be watching for additional insights.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: greg</title>
		<link>http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/comment-page-1/#comment-1578</link>
		<dc:creator>greg</dc:creator>
		<pubDate>Fri, 04 Apr 2008 05:21:28 +0000</pubDate>
		<guid isPermaLink="false">http://yardley.ca/?p=556#comment-1578</guid>
		<description>Bosko - document.write directly into the publisher&#039;s DOM is a huge security issue for any ad system that allows third-party tags to be trafficked in and then served, including Google&#039;s.

Interesting, though - I believe Google&#039;s implementation might make one of the standard ways to protect pubishers, wrapping ads in an IFRAME, unable to work, since the tag in the body is dependent on the tag in the head.</description>
		<content:encoded><![CDATA[<p>Bosko &#8211; document.write directly into the publisher&#8217;s DOM is a huge security issue for any ad system that allows third-party tags to be trafficked in and then served, including Google&#8217;s.</p>
<p>Interesting, though &#8211; I believe Google&#8217;s implementation might make one of the standard ways to protect pubishers, wrapping ads in an IFRAME, unable to work, since the tag in the body is dependent on the tag in the head.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bosko</title>
		<link>http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/comment-page-1/#comment-1577</link>
		<dc:creator>Bosko</dc:creator>
		<pubDate>Fri, 04 Apr 2008 04:36:40 +0000</pubDate>
		<guid isPermaLink="false">http://yardley.ca/?p=556#comment-1577</guid>
		<description>Isn&#039;t a potential concern with this approach the requirement to serve creative third-party requested by many advertisers (i.e., serve out of advertiser&#039;s ad server) -- in these cases the publisher has no control over the advertiser&#039;s code, some of which still does document.write()s straight into the page.

So I wonder if they&#039;re going to start pushing an open toolkit for rich ad unit production for implementation within ad manager.

Personally I think I still see the whole Google Ad Manager thing as a potentially gross conflict of interest for established publishers.</description>
		<content:encoded><![CDATA[<p>Isn&#8217;t a potential concern with this approach the requirement to serve creative third-party requested by many advertisers (i.e., serve out of advertiser&#8217;s ad server) &#8212; in these cases the publisher has no control over the advertiser&#8217;s code, some of which still does document.write()s straight into the page.</p>
<p>So I wonder if they&#8217;re going to start pushing an open toolkit for rich ad unit production for implementation within ad manager.</p>
<p>Personally I think I still see the whole Google Ad Manager thing as a potentially gross conflict of interest for established publishers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cam</title>
		<link>http://yardley.ca/2008/04/03/ballsy-serving-move-by-google/comment-page-1/#comment-1576</link>
		<dc:creator>Cam</dc:creator>
		<pubDate>Fri, 04 Apr 2008 03:10:07 +0000</pubDate>
		<guid isPermaLink="false">http://yardley.ca/?p=556#comment-1576</guid>
		<description>I like what I see here Greg. I like that it is overly complex for selfish reasons.  Farewell from Cam, sorry I never got to know you more.  Keep up the great blog!</description>
		<content:encoded><![CDATA[<p>I like what I see here Greg. I like that it is overly complex for selfish reasons.  Farewell from Cam, sorry I never got to know you more.  Keep up the great blog!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

