As far as malvertising is concerned, redirects remain a particular scourge for ad ops teams. On mobile in particular, a redirect can wreck a user’s session at the least. It’s worse if the user is wise enough to avoid downloading whatever the redirect tells them to download. These attacks are blatant and obvious, and at the publisher level, prevention is rarely easy. You can pick up the phone and call all of your ad tech partners to try to find the source—or you could also try to fortify your goods on your own.
One fortification method that ops folks have been passing notes about is Charles Proxy. Charles is a debugging proxy, in short. It’s used to monitor traffic to your sites and has various applications for developers—but it can also be used by ad ops to catch redirects.
Ad Ops Insider has posted some handy guides to Charles, and has also led some discussion about it on the AdOps subReddit. One of those guides helps us visualize the process, calling Charles “a program that will sit between your browser and the internet and record all the different interactions when loading a web page, even those you can’t see in the source code.” So, if you’re a developer or an ops person, you can see all of the secured and unsecured traffic, all requests and responses, between the device and the server that delivers page content. Charles makes it possible to measure all of those requests and responses, even when it involves third-party code and any other fishy or unfamiliar information. By inspecting all of these digital interactions, you can get to debugging.
Charles is a robust tool, then, and accessible to start using—it’s available via a free trial or a $50 license. But to a lot of ops professionals, it’s not beginner-level stuff. Browsers offer developer tools as part of the package, and Ad Ops Insider has advised just using those whenever possible—especially if you have an uncomplicated desktop-only site. But for mobile, browser dev tools aren’t reliable, and Charles (or something like it) would be the way to go.
There are other ops applications for Charles, aside from rooting out redirects. It can be used to test apps, or replace server files with local files, or refresh page elements—and fraudsters themselves use it, too. Charles is one form of proxy bad actors can use to break site encryption, then collect data to spoof SDKs and generate fraudulent app installs (which happen to look real, because they use real device data). What’s good for the goose is good for the, ahh… really crappy goose, right?
For more intel on advanced DIY fraud prevention, read AdMonsters’ earlier coverage of sandboxing iframes, and check out a special session on sandboxing at the upcoming Publisher Forum in Huntington Beach, CA, Mar. 4-7.