IMA SDK feature or problem?

[de...@applixir.com]

Hi,

I have some questions regarding the operation of the IMA SDK. We've based a number of our video advertising technologies on the IMA SDK and it has been working perfectly other than this one issue. We have a large number of customers with games and other apps on the web, Android and iOS devices. However, this issue only applies to web-based games and how they are tracked directly versus how they are tracked on other platforms.

For example, let's say we are showing video ads for a game called CandyKane that can be played on their direct website at www.candykane.com as well as on apps.gamebook.com and other similar platforms. When videos are shown on the CandyKane game using the IMA SDK, everything works as expected and the videos are attributed to www.candykane.com and the publisher information is fetched from the ads.txt file located on www.candykane.com. This is true for how the IMA SDK works with the thousands and thousands of other games when running on their direct websites.

However, when CandyKane is running on apps.gamebook.com/candykane the IMA SDK behaves very differently under webkit browsers. The video ads shown on the CandyKane game when running on apps.gamebook.com/candykane are attributed to apps.gamebook.com and the publisher information is expected to be found in an ads.txt file on gamebook.com instead of on CandyClick.com. This is also true for all other similar games/apps when run on platforms like gamebook.com when users are running webkit-based browsers. Non-webkit browsers attribute video ads shown on games within platforms correctly, probably because they don't use the webkit extensions to access location.ancestorOrigins.

The enforcement of ads.txt files is further complicating this matter because as you can imagine, the largest platforms out there are not going to allow thousands and thousands of games and other apps upload their ads.txt files to their root directory so all of these games and other apps along with the advertising networks they are working with will experience a considerable revenue impact due to this upstream attribution issue with the IMA SDK. So my question is whether the IMA SDK attributes video ad impressions to these upstream platforms by design as some other posts seem to imply or if this upstream attribution is a recognized problem that will be addressed by the IMA SDK team?

Thanks,

Applixir

[Joshua Lagonera (IMA SDK Team)]

Hi there,

Kindly note that the IMA SDK only handles requesting from the page making the Ad Request and playing of the videos ads in the said page. It does not handle serving them in itself in anyway. 

That said, it would be best for you to contact the pages hosting your games for further assistance on this.

Regards,

Joshua Lagonera

IMA SDK Team

[Dean]

Hi Joshua,

Thank you for the prompt reply. I apologize for the confusion but this issue is exactly related to how the IMA SDK handles data from the page making Ad Requests and how this request data is managed by the IMA SDK in different browsers when the ad requesting page is referred by another site (e.g. Facebook).

Example 1: The ad requesting site is accessed directly at https://www.examplesite.com/index.html

Firefox example 1: IMA SDK sets the url parameter to https://www.examplesite.com/index.html (this is correct)

Chrome example 1: IMA SDK sets the url parameter to https://www.examplesite.com/index.html (this is correct)

Example 2: The ad requesting site is referred by a platform site https://www.platformsite.com from a url such as https://www.platormsite.com/examplesite

Firefox example 2: IMA SDK sets the url parameter to https://www.examplesite.com/index.html (this is correct)

Chrome example 2: IMA SDK sets the url parameter to https://www.platformsite.com/examplesite (this is incorrect, the requesting page is still https://www.examplesite.com where the video player and the ads.txt file is located. There is nothing related to the ad request at the referrer https://www.platformsite.com).

This is not a problem with Chrome. The code that sets the url parameter is located in ima3.js which returns the incorrect value for example 2 in all webkit-based browsers and returns the correct result in all non-webkit browsers. This appears to be a result of ima3.js using the webkit extensions to determine the result for url and iterating location.ancestorOrigins beyond the ad requesting site to the parent/referrer of the ad requesting site.

If you PM me I will be happy to provide you with exact urls and steps to reproduce these examples. I will also be happy to provide any additional information to clarify this.

Thank you,

Dean

[Joshua Lagonera (IMA SDK Team)]

Hi Dean,

As mentioned on my previous response, the ads that get served should be based from the page and/or domain making the Ads Request. However, this seems like an interesting issue considering your findings.

You can provide to me some sample pages/ad tags, as well as any useful information, using the Reply Privately to Author option.

Regards,

Joshua Lagonera

IMA SDK Team

[bram schoonhoven]

Looks like similar issue like here: https://groups.google.com/forum/?hl=nl#!topic/ima-sdk/VP_sn8xE014

Op vrijdag 5 januari 2018 08:04:06 UTC+1 schreef Joshua Lagonera (IMA SDK Team):

[Shawn Busolits (IMA SDK Team)]

Hi all,

Do you have a non-Facebook URL I can use to reproduce this? I opened the Facebook URL you provided but it's asking for access to my Facebook profile that I'm not willing to give. I tried creating a fake Facebook profile to test with but Facebook keeps erroring out during profile creation. I tried the URL in the thread Bram linked, but that's not working as described - I see it sending the top-level URL in both Chrome and Firefox, and it never sends the iframe URL.

Aside from that, I believe the behavior I'm seeing, where we send the top level URL in all cases, is working as designed. The reason for this is that serving cares about the website the ads are displayed on as a whole, not just the iframe that happens to be rendering the ad. If, for example, your game is being rendered on a fishing website by one user and a luxury car website by another user, we want to serve appropriate ads for each of those domains, and not necessarily the same ads in both places.

Thanks,

Shawn Busolits

IMA SDK Team

[Dean]

Hi Shawn,

I PM'd some additional info.

I agree with your scenario as it's described but that is different from the platform example for the following reasons:

In the case of the Fishing site and the Luxury Car site, they are both focused on specific and different marketing segments but are both actively advertising for online consumers.

In the case of platforms like apps.facebook.com, Plinga, Miniclip.com and others, they are working on the behalf of thousands of games to drive traffic to their sites and they specifically DO NOT want their marketing goals to be reflected inside the apps they are referring traffic to.

In addition, the IAB's ads.txt initiative further complicates matters since the locations where ads are shown are expected to contain an ads.txt file showing that the publishers are authorized to show ads on that domain. Facebook cannot manage potentially millions of ads.txt files in their root directory. It can't and won't happen and they absolutely do not want other domain's ads to be attributed to their domain.

I hope this helps. I will be happy to follow-up with any additional information you require.

Thanks,

Dean

[bram schoonhoven]

The same url: http://www.gamesonly.com/puzzle-games/royal-tower-mahjong.html in 2 different browsers have different url params and check a different ads.txt

Check Network traffic after you click 'play' in the game.

- In Chrome we detect ads.txt of gamesonly.com has not our signature and we show a message

- in Edge we get our own ads.txt and we can show an ad

- see response below

Chrome: https://googleads.g.doubleclick.net/pagead/ads?sdkv=h.3.187.0&sdki=3c0d&video_product_type=4&correlator=3097566861015673&client=ca-games-pub-5029257013560698&url=http%3A%2F%2Fwww.gamesonly.com&adk=288615339&num_ads=3&channel=1594928698%2BGaming%2BEntertainment&output=xml_vast3&sz=900x500&adsafe=high&hl=nl&ea=0&image_size=200x200%2C250x250%2C300x250%2C336x280%2C450x50%2C468x60%2C480x70%2C728x90&ad_type=text_image_video&eid=21592082&u_tz=60&u_his=5&u_java=false&u_h=1080&u_w=1920&u_ah=1080&u_aw=1920&u_cd=24&u_nplug=4&u_nmime=5&dt=1515484002039&unviewed_position_start=1&videoad_start_delay=1&u_so=l&osd=2&frm=2&sdr=1&is_amp=0&video_format=43&t_pyv=allow&min_ad_duration=0&max_ad_duration=33000&ca_type=image&description_url=https%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Fabout.html&ref=http%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Findex.html&ged=ve4_td0_tt0_pd0_la0_er0.0.154.300_vi0.0.500.900_vp100_eb24427

Edge: https://googleads.g.doubleclick.net/pagead/ads?sdkv=h.3.187.0&sdki=3c0d&video_product_type=4&correlator=3364074598230308&client=ca-games-pub-5029257013560698&url=http%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Findex.html&adk=319975447&num_ads=3&channel=1594928698%2BGaming%2BEntertainment&output=xml_vast3&flash=28.0.0&sz=900x500&adsafe=high&hl=nl&ea=0&image_size=200x200%2C250x250%2C300x250%2C336x280%2C450x50%2C468x60%2C480x70%2C728x90&ad_type=text_image_video&eid=420706008&u_tz=60&u_his=2&u_java=true&u_h=1080&u_w=1920&u_ah=1080&u_aw=1920&u_cd=24&u_nplug=2&u_nmime=3&dt=1515484158306&unviewed_position_start=1&videoad_start_delay=1&u_so=l&osd=2&frm=2&sdr=1&is_amp=0&video_format=18&t_pyv=allow&min_ad_duration=0&max_ad_duration=33000&ca_type=flash&description_url=https%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Fabout.html&ref=http%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Findex.html&ged=ve4_td0_tt0_pd0_la0_er0.0.154.300_vi0.0.500.900_vp100_eb24427 HTTP/2 GET 200 text/xml  275,35 ms XMLHttpRequest

Bram

Op maandag 8 januari 2018 17:35:57 UTC+1 schreef Shawn Busolits (IMA SDK Team):

[bram schoonhoven]

Firefox: https://googleads.g.doubleclick.net/pagead/ads?sdkv=h.3.187.0&sdki=3c0d&video_product_type=4&correlator=749148123029219&client=ca-games-pub-5029257013560698&url=http%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Findex.html&adk=3124474045&num_ads=3&channel=1594928698%2BGaming%2BEntertainment&output=xml_vast3&sz=900x500&adsafe=high&hl=nl&ea=0&image_size=200x200%2C250x250%2C300x250%2C336x280%2C450x50%2C468x60%2C480x70%2C728x90&ad_type=text_image_video&eid=509445015%2C634360301&u_tz=60&u_his=3&u_java=false&u_h=1080&u_w=1920&u_ah=1080&u_aw=1920&u_cd=24&u_nplug=0&u_nmime=0&dt=1515485225183&unviewed_position_start=1&videoad_start_delay=1&u_so=l&osd=2&frm=2&sdr=1&is_amp=0&video_format=43&t_pyv=allow&min_ad_duration=0&max_ad_duration=33000&ca_type=image&description_url=https%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Fabout.html&ref=http%3A%2F%2Fcdn.htmlgames.com%2FRoyalTowerMahjong%2Findex.html&ged=ve4_td0_tt0_pd0_la0_er0.0.155.300_vi0.0.500.900_vp100_eb24427

- This url is cdn.htmlgames.com as well as in Edge and checks the ads.txt on cdn.htmlgames.com

So only chrome gets the url of the site embedding our game. 

Op dinsdag 9 januari 2018 08:53:20 UTC+1 schreef bram schoonhoven:

[bram schoonhoven]

But let me be clear. We prefer the Edge/Firefox case :) At least for the ads.txt issues.

Op dinsdag 9 januari 2018 09:09:12 UTC+1 schreef bram schoonhoven:

[Shawn Busolits (IMA SDK Team)]

Hi Bram,

What OS are you using to reproduce this? I've tried replicating in Chrome and Firefox on both Windows and Ubuntu, but in all cases I see the url being passed for gamesonly.com.

Thanks,

Shawn Busolits

IMA SDK Team

[Bram Schoonhoven (Jijbent.nl)]

Windows 10

Op vr 12 jan. 2018 om 19:50 schreef 'Shawn Busolits (IMA SDK Team)' via Interactive Media Ads SDK <ima...@googlegroups.com>

--
You received this message because you are subscribed to a topic in the Google Groups "Interactive Media Ads SDK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ima-sdk/ZbmivEwkERQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ima-sdk+u...@googlegroups.com.
To post to this group, send email to ima...@googlegroups.com.
Visit this group at https://groups.google.com/group/ima-sdk.
For more options, visit https://groups.google.com/d/optout.

[Shawn Busolits (IMA SDK Team)]

Hmm odd, that's where I'm testing as well. I'll have a few other folks on the team try to see if they see similar results. Once we get this reproduced internally we can look into it.

Thanks,

Shawn Busolits

IMA SDK Team

Windows 10

To unsubscribe from this group and all its topics, send an email to ima-sdk+unsubscribe@googlegroups.com.

[Dean]

Hi Shawn,

Did you see the same results with the url & test account I PM'd you?

Thanks,

Dean 

Windows 10

To unsubscribe from this group and all its topics, send an email to ima-sdk+u...@googlegroups.com.

[bram schoonhoven]

Strange thing now is: ads work in all browsers now

- but in Chrome still url=www.gamesonly.com and their ads.txt does not contain our signature. 

- in Edge: url=cdn.htmlgames.com

I am confused.

I cleared cache and cookies and tried three times.

Op vrijdag 12 januari 2018 20:07:58 UTC+1 schreef Shawn Busolits (IMA SDK Team):

Windows 10

To unsubscribe from this group and all its topics, send an email to ima-sdk+u...@googlegroups.com.

[Dean]

I thought it was broken on Edge but it's working there now. Only Chrome and Opera are returning the incorrect value for the url parameter now. Shawn, let me know if you still need an additional test url.

Thanks,

Dean

[Dean]

I assume that the IMA SDK will also return the incorrect value for the URL parameter in Safari but I don't have a test environment to verify that here. It appears to be a problem with all webkit browsers (Chrome, Opera, Safari and Edge). However, Microsoft Edge states they are based on a proprietary version of webkit which must be why IMA SDK is returning the correct value in Edge.

Dean

Windows 10

To unsubscribe from this topic, visit <a href="https://groups.g

[Applixir Team]

Hi Shawn,

This problem still has not been fixed for Chrome and Opera although it's working fine for Firefox and Edge. The problem isn't with Chrome as much as how IMA3.js uses Chrome. IMA is using window.location.ancestorOrigins if it's available which is only true for Chrome and browsers based on Chrome such as Opera. There are 3 big problems with using this API:

1. It violates CORS allowing access to a domain other than the origin.

2. It can lead to ad fraud (will explain in DM if needed)

3. It breaks the IAB ads.txt and app-ads.txt initiatives by returning a domain that is not the domain legally allowed to show the current ad causing a massive amount of lost ad revenue for websites and ad networks (such as Google).

It's very simple to setup a test case for this:

A. Pick any ad-supported website to test with.

B. Create a simple HTML page in any domain that is different than the website in step A, above

C. Create an iframe in the webpage created in step B above and load the website selected in step A into the iframe document.

You will now see that if you go directly to the website selected in step A using Chrome, Firefox or Edge that the ads will work fine and the correct domain will be shown. If you go to the web page created in step B using Firefox or Chrome you will see website A displayed inside the iframe with the domain of site B displayed. Because of ads.txt, the revenue for these ads will properly go to website A.

However, if you go to website B using Chrome, you will see website A displayed in the iframe under the domain for website B but the ads will NOT be operative and website A and the associated ad network will NOT get any revenue.

Thanks,

Applixir Team

To unsubscribe from this group and all its topics, send an email to ima-sdk+u...@googlegroups.com.

[IMA SDK]

Hi there,

Thank you for bringing this to our attention. I can see that it’s been a while since the team gave an update regarding the issue. I’m going to share this with the rest of the team to gather more information. We’ll give you an update as soon as I receive feedback.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[IMA SDK]

Hi,

As an update, the team is considering this as an intended behavior. The IMA makes its best effort to get the top level URL. If this is not possible due to cross origin iframes and such, then IMA is forced to select the best URL that it can find. We recommend and encourage you to put IMA on the top level page instead of in an iframe.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[Bram Schoonhoven]

Hi Sherwin, 

There are use cases where your recommendation will not work. Consider a gaming publisher that creates html5 games that portals can embed or iframe. That publisher has no access to the top level page. What now happens is that those top level pages of game portals will contain hundreds/thousands of ads.txt entries from all game publishers.

Regards,

Bram

[IMA SDK]

Hi Bram,

Allow me to relay this use case to the rest of the team, we will review it and we'll get back to this thread as soon as possible.

Regards,
Arnaud Casame
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[Applixir Team]

As Bram pointed out the solution of seeking the highest URL on the origins list doesn't work because sites aggregating other content can't handle thousands (or millions) of ads.txt files. However, many of them don't want to do anything about it. For example, the largest site in the world is also the largest aggregator of content and has their own ad network. Your own bug is preventing Google ads from being shown to their users in any area that aggregates content which is a large percentage of their total page views. I would think this represents a lot of lost revenue.

Applixir Team

[IMA SDK]

Hi there,

Thank you for your message and for providing additional insights with regard to your concern,  I’m going to share this to my teammates to investigate further and will let you know once we get an update on this.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[Applixir Team]

Hi IMA SDK team,

Any updates on this?

Applixir Team

[IMA SDK]

Hi there,

Thanks for following up. No update yet, but rest assured the team is actively working on this. We will get back to you the soonest we receive an update.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[IMA SDK]

Hi there,

Hope you’re well.

Just an update, we have received feedback from the team regarding this behavior and I’m afraid this is something that we can not do anything about. Unfortunately the responsibility here falls on the user of the top level page (not the iframe) to ensure that this is working correctly. The SDK currently has no mechanism to specify the iframe URL and the serving stack isn't built to accept it either.

Let me know if you have further questions or clarifications.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[cam...@watchingthat.com]

Hi Sherwin

My 2 cents:

I would recommend that the IMA team seriously, and urgently, reconsider its past decision to implement the automatic, and unilateral, overwrite of the URL KVP in the MVT based the SDK's "best guess".   The required next step here is for the IMASDK to be updated to allow the url KVP to be set by other means, keeping the SDK's determination as an option the publisher can choose from.  This will solve not only the issue discussed here but other forum threads which are all variations on the theme.

I'm sure when it was first implemented the reasonings for this change were well intended based on eliminating ad fraud and protecting all involved from malicious actions and actors.  I've also no doubt, that at that time, the trade offs / risks where well understood of what it means for the IMASDK to take on such an unilateral (and opaque) role of being the sole decider/judge of which domain the advertiser should consider they are buying.  

After all, moving from being a facilitator of video ad requests to now being a critical opinion in the determination of if an ad gets served or not changes the purpose and role of the SDK completely.    As an aside, if the SDK continues with this role its decisioning needs to be open to scrutiny and oversight and must come with liability - after all a `best guess` is just that, a guess which is not always right. 

With offsite syndication a major growth area, the introduction and adoption of ads.txt and much more transparency in the programmatic ad chain via 3rd party measurement etc, the world has completely changed to the one where the original decision was no doubt made.  There are now plenty of other check points to take up the role that the SDK is playing here with its automatic overwrite of the URL KVP.

As such, the SDK should deprecate the automatic overwrite of the URL KVP asap.

[IMA SDK]

Hi there,

Thanks for your message. Allow me to share your comments with the team and will get back to this thread once we receive feedback. Will keep you posted.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[IMA SDK]

Hi,

Just an update. The team is leaning towards considering this as a Chrome issue rather than an IMA SDK issue. If this really is a privacy and security issue then we think it is a Chrome bug that offers us an API that allows us to do this. The team suggests the solution here would be to file a bug against Chrome to get them to fix the behavior of the ancestorOrigins API to not jump cross origin domains.

Regards,
Sherwin Diesta
IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[Cameron Church]

Hi Sherwin

Thanks for the quick review by the team and the outcome sounds great.  Once you guys have filed the bug please do share the ticket reference and I'm sure you'll have plenty of parties here lean into it. 

Is there a proposed workaround in the meantime?  Chrome has the biggest market share by far so the impact and severity of this issue is as high as it can be - and it will take time not only from Chrome to issue a fix but also for the relevant browser version to reach critical install levels.    That could take 3 months at least, don't you think?  

With Q4 2020 right around the corner, and with the current macro economics due to the pandemic, it will be the most important trading period the video ad industry has ever (and is likely to ever) faced, so immediate action at the code/SDK level, even as a temporary patch to provide a bridge to a full fix by Chrome,  is vital. 

What do you think?

CC

--

Cameron Church

----

CEO & Founder

Watching That Ltd

M: 07917203078

W: www.watchingthat.com

---

Incorporated in England and Wales

Company Number: 10181169

[IMA SDK]

Hi Cameron,

I work with Sherwin and will assist you. I relayed your post to the rest of my team. We will get back to you as soon as we have more information.

Regards,
Aryeh Baker

[Applixir Team]

Hi Sherwin,

Was this bug filed? I haven't seen any follow-up.

However, I'm not sure why your team feels this is the best approach. The odds of the Chrome team changing this is close to zero because any change would impact a huge number of customers who all have different objectives in using this API than the IMA team. The simplest solution would be for the IMA team to change the code which is causing the problem by using window.location.ancestorOrigins which is returning cross-origin parents. This can be fixed with just a few simple lines of code. I will send more in a PM.

Thanks,

Applixir Team 

[IMA SDK]

Hi there,

Yes please, if you could share this information with us, that would be great. Rest assured the team is actively working on this internally and we will give you an update as they come along.

Regards,

Sherwin Diesta IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref

[IMA SDK]

Hi all,

 

Hope you're all doing well. I got a response from our team and it seems like there are no expected changes in the SDK anytime soon regarding this issue, but feel free to keep an eye on our release notes for upcoming and latest development.

Regards,

Michael Angelo Legaspi IMA SDK Team

ref:_00D1U1174p._5004Q22YPpS:ref