Allow PCM metadata in nested iframes to allow third-party serving of ads #7
This in turn makes modern sandboxing techniques not be usable for such ads, exposing users to attacks such as auto-redirection (otherwise prevented by only allowing
Specifically for display ads, the proposal as it stands would put publishers in front of a choice:
This seems like a bad trade-off to make.
If instead origins could allow child iframes to perform conversion tracking for clicks, the trade-off would be eliminated. It isn't immediately clear that this would violate user expectations. Is there research that would suggest that that is the case?
The text was updated successfully, but these errors were encountered:
Thanks for filing, Malte!
I don't think we should assume that ads will forever be served by client-side third-parties. As websites strengthen relationships with their users they may very well make a call server-side for context aware ads and place them on their website.
But let's assume ad tech scripts have finally moved into isolated iframes. Couldn't they postMessage to the main frame what ad click attribution data they want and have the true first-party configure an encapsulating anchor tag accordingly?
Finally, let's say you convince us that third-party iframes should be able to push ad click attribution data themselves. We would still store it as an ad click on the first-party site. Do you see such a solution working?
@johnwilander The problem isn't whether or not ads will be served by third parties, its the content of the ads. As someone who has been involved in building ad tech on the engineering side for almost 15 years, there's 2 things that are definite:
This generally done using a 2-level nesting of iframes: the first level has the same domain as the publisher, and the second is by the ad agency or their vendor (Sizmek, Google, etc...)
The world is moving to paying only for viewable impressions. That requires JS today.
This is the standard that most people use for sandboxing content. It'd be nice if this placed well with that (or an upgrade of that standard)
AMP for example moved all 3P ads into sandboxed third party frames https://blog.amp.dev/2018/12/11/ads-on-amp-pages-became-safer-and-more-user-friendly-in-2018/
I think you have made this argument in a recent thread: "If you get 20% more revenue if you put this little script on my page, wouldn't you do it?" That statement was about giving private keys to third parties. I think given the status quo folks are at least an order of magnitude more likely to run 3P JS than giving somebody else their private key.
I think the server-side call you mention is actually the main risk: It puts 3P content into 1P context. I really never want to do that. Sure, there are techniques to make it safe, but see above. Sandboxing exists to make this trade-off viable.
The postMessage strategy has at least fraud implications, and assumes a simplistic ad creative (only interaction is click).
I mentioned before: It isn't obvious to me that a user, when they click on CarMaker ad on NewSite.com, that they would expect their conversion info to be shared with NewsSite.com instead of with CarMaker.
I'm not enough of an expert in the ad conversion space to say whether sharing it with either party would enable existing business models.
Thanks for the insights, @cramforce. Let's assume there are up to three parties to the interaction:
We envisioned two possible scenarios:
The publisher is the ad network. In this case, the user visits NewsSite.com, clicks on an ad, and is taken to CarMaker.com. Our proposal intends to serve this case. In our proposal, NewsSite.com would register for attribution, and at a later time, if the user completes a purchase, CarMaker.com completes the attribution. That info is eventually reported by the browser to NewsSite.com, which then tells CarMaker.com the conversion stats of its ads.
We think this is reasonably in line with user understanding. When you follow a link from NewsSite.com to CarMaker.com, it does not seem surprising that both of these sites know about it, whether it's an ad or not. The ad attribution proposal allows them to exchange some low-entropy data after the fact, which users might not totally expect. But at least they know both the parties here.
All parties are distinct. NewsSite.com hosts ad inventory from AdNet.com. AdNet.com serves up an ad that will take the user to CarMaker.com. In a version of the proposal meant to support this, AdNet.com would be able to register for attribution for purchases on CarMaker.com. at a later time, if the user completes a purchase, CarMaker.com completes the attribution. The browser would hypothetically report this info to AdNet.com.
We think this is not in line with user understanding. There's no reason for the user to know or expect that a third party, AdNet.com, would know anything about their interaction with NewsSite.com and CarMarker.com, and to be able to correlate their activity on the two sites.
So we don't aim to support this use case, at least without finding a way to make it meet user privacy expectations.
It seems like you are suggesting yet another case, which we didn't expect:
The advertiser is the ad network (perhaps facilitated by redirects, but ultimately they post the content and collect their own attribution info). In this case, the user visits NewsSite.com, clicks on an ad hosted by CarMaker.com, and is taken to CarMaker.com. CarMaker.com registers for attribution, and CarMaker.com later may complete that attribution.
This is a case we didn't think of because we did not expect it. Is it actually common? On the face of it, it seems ok for either the site hosting the ad or the site that is the target of the ad to get attribution info. We'd need to think harder, but maybe it's ok to update this proposed spec to allow either of those parties to register for attribution.
That said, it's not clear why it would be necessary. In such a scenario, CarMaker.com already knows you clicked the ad: it's the destination of the click, and the host of the content that's the click source, which knows what page it is hosted on. It's not clear why it would need a special mechanism to tell itself about a completed purchase. I guess without reliable first-party storage or identification, this mechanism could help.
I'm still not sure if the above scenario is a real one and whether I've correctly understood.
In summary, it seems reasonable for either a publisher (NewsSite.com) or an advertiser (CarMaker.com) tp get info about a user's clicks and conversions, but it would be unexpected for an ad network middleman (AdNet.com) to receive that info. If there is any implied consent in the user's ad click, it is surely to either NewsSite.com or CarMaker.com, not to an invisible third party.
To me, I see it as more as CarMaker hires AdAgency which hires AdNet to distribute ads on NewsSite.com
CarMaker.com wants to attribute clicks from NewsSite.com, but the ad content is on AdNet's servers and NewsSite.com doesn't want to give first party context to AdNet due to various fraud reasons (with RTB, NewsSite.con doesn't know if ad will be served by TrustedAdNet.com or EvilAdNet.ru, so better to sandbox it all)
Even when the publisher is the ad network, it's rare for the ad assets to be served by the publisher. The agency who makes the ad will generally hire a company like Sizmek or Flashtalking to host the ad assets, even when the publisher is doing the ad decisioning.
The agency will give the publisher a "tag", generally an HTML snippet from their own buy side ad server that loads the ad inside an iframe hosted by the buy side ad server.
Note that neither Sizmek nor Flashtalking or their competitors are ad networks: they make 0 decision on what ad to serve. They are merely hosting companies for ad assets, with management tools around ad assets for the most part.
To be clear: it is NewsSite.com that should get the attribution for the conversion on CarMaker.com. it's just that the actual content where the a href is on child iframe of NewsSite.com with a host name of ds.serving-sys.com (Sizmek's Akamai powered CDN for CarMaker.com assets).
This is still a "first party ad" in that NewsSite.com owns servers decided to serve the ad, and did serve the ad, it's just that ad is a 300x250 iframe with HTML 5 content on an entirely different domain so it doesn't break NewsSite.com
The reason websites do this? See https://davidlynch.org/blog/2011/10/xss-is-fun/. That was my coworkers bug when I worked at EyeWonder before they were acquired (my bad interweb). Oops. Publishers simply do not allow ads to run in their context because bad shit happens. Allow for the publishers to sandbox the content but still get the attribution, and it will be used. Otherwise it's dead on arrival
It sounds like the model there would be NewsSite.com getting attribution info when the registration for that attribution info was made inside a third-party iframe (from a an ad agency or the like), but still attributing from NewsSite.com (the first party top level page) to CarMaker.com (the ultimate destination of the ad click). No extra info flows to the owner of the frame in the middle (except they inevitably know the click happened leading from NewsSite.com to CarMaker.com.
It might be that specific case could still meet our privacy goals for this technology. We'd have to think about the possible privacy threats and whether this mode would enable anything we don't want.
Thanks for the detailed insights!
@jhaygood86 - For the sake of clarity, the term "sandboxing" is overloaded. An IAB SafeFrame places 3P ad content into a cross-domain iframe which invokes browser same-origin policy . However, iframes also have support for a sandbox attribute  which can be used to enable additional restrictions over the content. This is what cramforce referenced in his original post. An IAB SafeFrame does not actually use the iframe sandbox attribute.
Believe it or not, we do mention something that alludes to this third scenario in the A High Level Scenario section of the draft spec. Point 7 in the numbered list ends with "One thing to consider here is whether there should be an option to send the attribution data to the ad click destination too."
Such functionality doesn't require the advertiser to serve the ads under NewsSite.com. I think one of its main merits would be to allow double-entry bookkeeping.
Yes, I think this is what Malte is after. Spelled out:
A third-party iframe, possibly nested, would be allowed to push ad click attribution data through an anchor tag. This data will be stored as an ad click on the first-party website and any subsequent attribution reports will go to that first-party website's well-known location.
@cramforce, is this what you're asking for?
One of the reasons we didn't want to support this was that first-party websites should be in control of what ad click data is pushed on their behalf. Not only because they will receive the attribution reports, but also to make sure third-party content doesn't add ad click attribution data to all its links, whether they are ads or not. We want publishers etc to be in control of this.
Maybe we can get some comments from @darobin and @AramZS here. Would you be fine letting any third-party you load push ad click attribution data on your websites' behalf? Any attribution reports resulting from those clicks would still be sent to your servers.
@johnwilander That's the idea. To the user, it doesn't look or behave any different, but it'll allow publishers to serve ads in a third-party context, those ads to have navigation elements (a href tags, onclick handlers, whatever makes sense -- most publishers require ads to open in a new window for instance), and the click to be attributed to the publisher site.
To me, I don't think it violates any of the privacy concerns, but would completely alleviate the issue with third-party ad assets being served directly in a first-party context.
Thinking some more about this, wouldn't it suffice to support the attributes in all anchor tags? That way, the third-party iframe can use a regular link for the ad.
I'm trying to reduce complexity both for implementers and developers.
So I am not entirely sure what is being suggested in regard to applying the attributes to the frame instead of an anchor tag, or a link inside the iframe hosted by the site that wants the attribution? So we're talking about two potential cases?
<iframe addestination="[ad click destination URL]"><a src="[ad click destination URL]"></a></iframe>
<iframe src="xyz.com/adframe"><a addestination="xyz.com/landingpage">...</a></iframe>
I've been thinking about this a great deal and considering the general issue with why 3P JS happens and what might occur here and I think I'd have some concerns with the first option, and generally. What happens with forwarded links and how is this incentivized? I'm somewhat unclear on this point.
In the case of the first, there becomes an opportunity for real problematic delegation. It may apply more generally as well, the more that I think about it, but lets deal with it in this context first. And please excuse me if I'm missing something here!
Let's assume AdvertiserA wants to put an ad up and use the attribution feature. Let's assume they are bad at doing reporting and wish to use a third party service for reporting. This is a common situation.
What occurs if AdvertiserA decides that AdServerB is the dominant server in the industry and therefore a reliable metric provider who is good at generating trustworthy reports? AdServerB's dominance in the marketplace makes it easy for lazy sites like PublisherC to implement the new mechanism using AdServerB.
So AdServerB now has a service on the page that sets up ad iframes for PubliserC with
Would this be possible? If so it would seem to not solve the problem the proposal aims to address and it would seem to, assuming that an AdServerB exists in a dominant position, lend additional power to encourage users to narrow their ad server choices.
Hi Aram! Thanks for sharing your thoughts.
That is the gist of it, yes.
If so, I agree that it's better to do this for anchor tags and allow them in third-party iframes.
I'm not 100% sure I follow your case description. Let me rephrase it and explain how the proposed feature works and see if that answers your questions.
Let's go with these three actors:
Let's say we allow anchor tags inside adnetwork.example's iframe to serve ad click metadata. The first question I have is whether publishers and other websites that monetize ads through third-party ad networks are fine with third-parties pushing ad click metadata on their behalf. The attribution will be associated with publisher.example, regardless of whether the anchor tag was part of publisher.example's own webpage or part of adnetwork.example's iframe. This is because for a user, they will perceive it as having clicked an ad on publisher.example.
This also means that all attribution reports that result from subsequent conversions will got to the well-known location on publisher.example, not to adnetwork.example. This is to be able to explain it to users (they have no knowledge of adnetwork.example or the hundreds of other thrid-parties involved) and to empower publisher.example — publisher.example gets the attribution reports, can analyze them, can pick and choose products to analyze them with, et cetera.
Moving to the abuse scenario you mention, where adnetwork.example sets up an interstitial website (let's call it interstitial.example) as the
adnetwork.example could of course actually land the user on interstitial.example before taking them to advertiser.example. But at that point two things come into play:
I changed the title to reflect that we are considering supporting PCM metadata (ad campaign ID and ad destination) in third-party iframes so as to allow third-party iframes to serve ads. Note that this in itself does not change where conversion reports are sent.
https://bugs.webkit.org/show_bug.cgi?id=229204 <rdar://problem/82310386> Reviewed by Alex Christensen. Developers have said it would be great to allow measurement of links served in nested, cross-site iframes on the click source. The click still count as if it happened on the first party click source site, and any attribution report still goes to that first party. This change enables the *serving* of measurable links in nested, cross-site iframes. The standards issue where this was discussed: privacycg/private-click-measurement#7 Source/WebCore: Test: http/tests/privateClickMeasurement/store-private-click-measurement-nested.html * html/HTMLAnchorElement.cpp: (WebCore::HTMLAnchorElement::parsePrivateClickMeasurement const): Removed the block for nested, cross-site iframes. LayoutTests: * http/tests/privateClickMeasurement/resources/nestedTargetLink.html: Added. * http/tests/privateClickMeasurement/store-private-click-measurement-nested-expected.txt: Added. * http/tests/privateClickMeasurement/store-private-click-measurement-nested.html: Added. Canonical link: https://commits.webkit.org/242549@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@283593 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229204 <rdar://problem/82310386> Reviewed by Alex Christensen. Developers have said it would be great to allow measurement of links served in nested, cross-site iframes on the click source. The click still count as if it happened on the first party click source site, and any attribution report still goes to that first party. This change enables the *serving* of measurable links in nested, cross-site iframes. The standards issue where this was discussed: privacycg/private-click-measurement#7 Source/WebCore: Test: http/tests/privateClickMeasurement/store-private-click-measurement-nested.html * html/HTMLAnchorElement.cpp: (WebCore::HTMLAnchorElement::parsePrivateClickMeasurement const): Removed the block for nested, cross-site iframes. LayoutTests: * http/tests/privateClickMeasurement/resources/nestedTargetLink.html: Added. * http/tests/privateClickMeasurement/store-private-click-measurement-nested-expected.txt: Added. * http/tests/privateClickMeasurement/store-private-click-measurement-nested.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@283593 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Hi @johnwilander sorry for missing the earlier message and the long delayed response. We're continuing our testing of recent iterations of both Webkit and Chrome privacy-focused measurement proposals which is what brought me back here.
Yeah, I would assume so. That is the current state of play. It would likely be good to have some sort of security measure to allow the publisher site to allowlist particular third-parties to avoid a getting the equivalent of DDOSed.
While some publishers do want these not all publishers would want that reporting and while I'm fine with having the adnetwork.example cut out of the reporting process in this case, this is a strong example of why reports also need to go to the attribution destination website.
Yeah, that makes sense. I appreciate you walking me through it.
What brought me back to this specific thread was that I was unclear of the current state of play on the basis of this thread and the connected PR.
Do we expect that PCM is working for publishers who serve such links inside third party iframes right now? The PR attached makes it seem that way but the spec and documentation are unclear on that front.