Back in late September, a flare up in the eternal war between ad blockers and digital advertisers happened, which centered around live streaming site Twitch. Users (including me) began getting unskippable ads that would slip through AdBlock, and I got curious enough to investigate why.
Server Side Ad Injection and Twitch Surestream
Typically, ads are served client-side, which enables digital advertisers to serve users with targeted ads tailored more specifically to the end users’ demographics. However, a quickly growing way of serving ads is ad-stitching or Server Side Ad Injection (SSAI), where the server will “stitch” it into the stream being sent to the client before delivering it to the client. According to AWS, this would result in a more seamless viewing experience for the end user, with video matching the current bitrate and quality of the existing video.
This would also in part be able to circumvent the breadth of ad blocking tools as the video appears as a single stream of video. In this case, Twitch features a SSAI-based ad service called Surestream, announced back in 2016 for unskippable midroll ads.
Why it’s not a Silver Bullet
As ad agencies flail about in search of the ever nebulous “ad impression”, SSAIs present a whole new host of ways in which ad fraud can occur. According to Pixalate, fraudsters can spoof user request headers to record an ad impression from a fictitious device.
Earlier in April, a large-scale ad fraud operation called ICEBUCKET was uncovered. This operation created 1.9 billion ad requests per day by spoofing user requests headers, and managed to cover their tracks by hiding among legitimate ad impressions, and using IP prefixes that were more prone to exploitation.
Enter the uBlock Origin Community
For Twitch and by extension Surestream, many ideas had been floated about in the uBlock Origin issues tracker. One was to simply change the region via a VPN to one that would have less ads to serve, but the far more interesting one being discussed in the thread was querying the m3u8 playlist, which is essentially a list of URLs of media to be sent to the user. It was then proposed to keep polling the playlist, waiting for one that did not stitch an ad. If it failed a set number of times the script would fallback to removing the ad chunk itself from the playlist, and showing the user a black screen where that ad would be, which would usually be much shorter than the 30-second ad.
This seemed to set off alarm bells over at Twitch headquarters though. An email was sent to u/gorhill, member of the uBlock Origin organization, shown above. It seems that there were worries that making multiple requests to the playlist would end up DDoSing the Twitch servers. Responses were somewhat unapologetic.
Thankfully, those at Twitch had nothing to fear, as the proposed solution far exceeded the complexity threshold over at uBlock Origin, which was initially designed to be as lightweight as possible. This would not prevent a new extension from being created for users to use, but it not being included in such a large extension would highly reduce the amount of users that could bombard their servers with requests.
Early on, it was discovered that playing around with the query parameters in a request for “access_token” would result in pre-roll ads not being shown on some streams. The first solution was a scattershot method of removing all the query parameters, but eventually the contributors found the “platform” parameter would remove ads, assuming that ads would be tailored to different devices. Given that this is a simple change, the fix on Twitch’s end was equally as similar, and thus began a game of whack-a-mole between the contributors and Twitch engineers.
After the platform parameter was fixed, the contributors found the “player_type“ parameter and pingponged between setting values like “flash”, “popout”, “frontpage” and “embed” to block ads, most of which were swiftly fixed on Twitch’s end, resulting in some friendly banter in the issue tracker thread.
However, some of the fixes implemented by Twitch wreaked havoc on user experience, with many users reporting being locked to 360p quality. Later on, those running AdBlock would be served with an interstitial screen, shown below every 10 minutes instead of ads.
This could be in connection to the widely criticized “automated mid-roll ad” program being tested on Twitch at around the same time. When the dust settled, it seems that Twitch backed off of attempting to plug every hole that the contributors could find, and the uBlock contributors moved on by splitting the more invasive methods of removing ad chunks or sending multiple manifest requests to new, more specialized extensions.
This eternal tug of war between advertisers and ad block users is nothing new, with valid arguments on both sides. In this case, there are many people who like to hop between streams quickly, especially in the age of Among Us, where hundreds if not thousands of viewers will swap to different streamers perspectives to watch them play, or just to find something to watch from within their follow list.
It has to be said, however, that advertisement dollars seem to skew much more favorably towards the largest streamers. One streamer who I watch regularly, mentioned that in June he received only $130 in ad revenue, and peeking at his numbers on this site, he averaged 479 viewers and 217 total hours streamed that month. Given that this is one data point in a sea of extremely volatile CPMs, this could have been an outlier, but still shows that ads seem to benefit Twitch much more than the Twitch streamer.
Edit 1: Since this was written it seems that another patch has been deployed, and users are being greeted with another Purple Screen of Death.