If YouTube is hosting a video, and then decides to have you watch two 30 seconds ads, and you immediately start watching the original hosted video before 60 seconds has elapsed, why wouldn't a server-side timer work to detect ad blocking? Are we forced to solve this problem client-side with Tom and Jerry Javascript battles?
I don't really understand how video streaming scales, so this is probably a very naive question.
I'm pretty sure its because the servers that host the video are just dumb servers that will serve whatever is asked. The logic is in the player. The servers don't know when you started the video watch session. If the servers had the logic and access to your state they wouldn't be able to handle as many concurrent requests.
Those are 100x (or more) more expensive than what YouTube’s backend is doing.
To do what they do affordably, there are tons of caching layers and videos are chunked into smaller opaque chunks of write-once/read-many data which get so widely distributed your head would spin.
The client code is what stitches those blocks together (and figures out what blocks are part of what), figures out what ads should be where, etc.
Any sort of consistent backend state gets very expensive fast, is often a huge bottleneck, and is avoided whenever possible.
Everything from view stats to metadata is usually even done via CRDT type eventually consistent replicated data to avoid all the bottlenecks other approaches would cause.
It would be interesting to know what the upper bound on cost for a draconian anti-adblock measure would be, taking into consideration revenue from successfully killing all ad blocking. My guess is that it's not currently worth it. People have speculated on the use of Web Integrity API but at the moment, too many things have to go right for this type of DRM to even work properly, so it may kill support for way too many devices too soon.
For quality-of-experience, YouTube would likely start buffering the original video before those 60 seconds have elapsed, so you can't look at just data loading times. And if there's a separate AJAX call, say, to tell the server that you've started watching the video, a sophisticated client-side script could try to delay or modify that ping - which brings us back into the cat-and-mouse territory.
They don't do that on YouTube but they do something similar on other platforms. Though instead of having different videos they just stitch the ads into the front of the video so you can't block them without blocking the content.
It requires a certain amount of setup, but it's actually easier to do with HLS than a classic MPEG stream because it's already broken up into blocks. Trying to dynamically reassemble an MPEG stream would be possible but annoying. And then there's the issue that inserting ads into the video puts them in the "timeline": if you rewound, you'd see the ad again.
It’s not hard for Google’s level of resources: they would need to index where the blocks in each encoding are so they could switch to serving as content at that point but they wouldn’t need to recompress the videos, just identify where to splice in the ads. I suspect that’s the next step here since it would be a significant increase in the level of effort required for ad blockers.
They could aggregate logs and figure out who is not downloading ad video. But yes, it is a cat and mouse game, because the pirates will attempt do what it takes to fool the detections.
The same one where you could watch ads or pay, but choose to circumvent instead. I hate ads as much as the next person, which is why I pay for the youtube subscription. If I didn't, I wouldn't use youtube at all.
I don't think we would have as much people creating content if ads always opt in. The system can support a percentage of ad block / ad free consumption and other models for content production beyond ads, subs and patreon.
And of course ads are a numbers game to begin with X people exposed mapping to Y people that convert.
But content on YouTube is subscription and ad free or with ads. To subvert that is generally labeled piracy.
YouTube does have drop a prop function to a creator which be another way to more directly direct money to creators of content you consume. If you do $5 one out of 1k videos you watch I thik it's fair to skip ads :)
And if that's piracy then I should be arrested for piracy when I put my computer on mute and when I look away from ads, because that's what I'll do if there's no other technical way not to watch ads.
Yes, and if they escalate to banning Google accounts entirely due to ad-blocking then people would be forced to choose between the data they have there and their adblockers.
If YouTube is hosting a video, and then decides to have you watch two 30 seconds ads, and you immediately start watching the original hosted video before 60 seconds has elapsed, why wouldn't a server-side timer work to detect ad blocking? Are we forced to solve this problem client-side with Tom and Jerry Javascript battles?
I don't really understand how video streaming scales, so this is probably a very naive question.