If Grindr would have adopted App-Ads.txt selling protocol, would that prevented this sophisticated fraud scheme from happening?
How the DiCaprio scheme worked:
When a real user opened Grindr, the supply-side partner(s) offered a display ad impression (adrequest). In addition to sending the required elements to fill the display creative, the responding Content Delivery Network (CDN) would also send a response back to Grindr, which called new JavaScript tags to run in the background of the phone and initiate new adrequests. These new ad request were for 1920x1080 video ads, claiming to originate from a Roku app on a Roku device. However, the spoofed ad requests were fed information via the “DiCaprio script” — a sophisticated algorithm apparently built to spoof Roku traffic. Advertisers would then bid on the fake Roku inventory, thinking they were reaching real Roku users (and serving them an ad); in reality however, it was fabricated Roku traffic functioning behind the scenes of the Grindr app.
What is App-Ads.txt?
App-ads.txt is a plain text file hosted on the domain of the app developer's website to identify the authorized digital sellers. This method allows advertisers to trust that they are buying authentic app inventory. Buyers that bid on app inventory can use the app-ads.txt which has been declared by the app developer on their website in order to verify that their impressions come from authorized sellers.
If Grindr would have adopted App-Ads.txt, would that prevented this sophisticated fraud scheme?
The short answer? No. The hackers (or; criminals) found a loop-hole in the Grindr application and selling inventory based on App-Ads.txt would not have prevented this fraud scheme. Essentially, we are talking about two entirely different OpenRTB scenario’s/aspects. For the people actually reading this blog; you could say that this question/comparison is not logical. That might be true but the real message of this blogpost? Potentially, anno 2020, the in-app advertising eco-system is just at the doorstep of experiencing sophisticated fraud scheme’s by hacking into popular Apps which have - until now - questionable safety procedures, protection or development present. Preventing your (popular) App from being hacked should have the same priority as extended protection and safety procedures that - for example - financial institutions uphold for their App(s).