4 ms·

It's not really that difficult. If the ads are blocked the servers can just return 403 for the videos. Since they have their own ad platform they can easily ver

It's not really that difficult. If the ads are blocked the servers can just return 403 for the videos. Since they have their own ad platform they can easily verify if a specific ad was served from the server which is difficult to work around from the client. Even if someone puts in the work to download the ad without playing it to satisfy the server Google still makes money so they're happy. When it comes to corporations like Google I don't really mind watching ads but I don't want to help them with their revenue.

zb3 3y ago
After analyzing the code I see that it's indeed the server that's supposed to return whether to display this popup (so presumably the video info data would not be included in that response). However this still doesn't mean there's a reliable channel to detect whether the ad was actually displayed, and as far as I understand there might be some architectural limits as to what data can be collected by a given server (for example, the CDN). Now, I don't think advertisers 'd be very happy if Google counted simply downloading the ad as an impression :)
- worksonmine 3y ago
  > Now, I don't think advertisers 'd be very happy if Google counted simply downloading the ad as an impression :) That's how it's been done for years, and verified with tracking pixel from a third-party to correlate numbers. I used to work at a startup in the ad space ages ago and most third-parties were on block lists, we weren't. So we couldn't get paid for real impressions because the numbers didn't add up. How would a site confidently verify that a video was actually played as opposed to simply downloaded? The path of least resistance is good enough, and Google is Google, advertisers do what they say. If they're unhappy is there even a way to let them know?
  - zb3 3y ago
    I was refering to the fact that before a click is recorded, YT uses a thing called BotGuard, presumably to prevent malicious clicks (I might be misunderstanding the use of BG here), so I thought they use similar measures when counting impressions in general.
    - worksonmine 3y ago
      I'm confused, are you now arguing that it's difficult to work around Youtubes mitigations and that they have all kinds of checks to make sure an ad was viewed? That said I'm sure bot detection is more interesting for the adsense part of their business to catch malicious publishers and content creators not adblockers. A simple check that the rest of the video is requested at least $now >= ($ad_request_time + $min_skip_or_view_time) will catch most adblockers while degrading none of the regular users. All done server-side, no need to complicate things. Sure the adblocker could play some elevator tunes and display a spinner while waiting, but what's even the point. Next step they require a hash of the ad in the next request as proof and on it goes. See facebooks markup for the "Sponsored" string for a similar example in the wild. Last I checked ublock origin gave up.
      - zb3 3y ago
        More like I'm arguing that if they use their BG detection for catching adblockers as well, then that part _might_ be attacked with a greater force than before - and if broken, might hurt them more than adblockers did. Of course it's just pure speculation. Back to the technical argument, I was refering to the fact that a DB read to check if an ad should be served (done on the player page) as well as the DB write to check if the video was downloaded earlier (on the CDN, we have signatures there and expiry date passed as a parameter) might be infeasible from the architectural/performance point of view, but I gotta admit I actually don't have any relevant knowledge here so I'm just speculating because this seems interesting.
        worksonmine 3y ago
        It would be done in-memory on whatever server the load-balancer assigns the visitor to, at the same time that the request is checked for permissions anyway. Compared to the rest of the data Google collects the extra timestamp isn't even a rounding-error and doesn't need to be persisted in long-term storage (the request is in the logs anyway).

zb3 3y ago

After analyzing the code I see that it's indeed the server that's supposed to return whether to display this popup (so presumably the video info data would not be included in that response). However this still doesn't mean there's a reliable channel to detect whether the ad was actually displayed, and as far as I understand there might be some architectural limits as to what data can be collected by a given server (for example, the CDN). Now, I don't think advertisers 'd be very happy if Google counted simply downloading the ad as an impression :)

worksonmine 3y ago
> Now, I don't think advertisers 'd be very happy if Google counted simply downloading the ad as an impression :) That's how it's been done for years, and verified with tracking pixel from a third-party to correlate numbers. I used to work at a startup in the ad space ages ago and most third-parties were on block lists, we weren't. So we couldn't get paid for real impressions because the numbers didn't add up. How would a site confidently verify that a video was actually played as opposed to simply downloaded? The path of least resistance is good enough, and Google is Google, advertisers do what they say. If they're unhappy is there even a way to let them know?
- zb3 3y ago
  I was refering to the fact that before a click is recorded, YT uses a thing called BotGuard, presumably to prevent malicious clicks (I might be misunderstanding the use of BG here), so I thought they use similar measures when counting impressions in general.
  - worksonmine 3y ago
    I'm confused, are you now arguing that it's difficult to work around Youtubes mitigations and that they have all kinds of checks to make sure an ad was viewed? That said I'm sure bot detection is more interesting for the adsense part of their business to catch malicious publishers and content creators not adblockers. A simple check that the rest of the video is requested at least $now >= ($ad_request_time + $min_skip_or_view_time) will catch most adblockers while degrading none of the regular users. All done server-side, no need to complicate things. Sure the adblocker could play some elevator tunes and display a spinner while waiting, but what's even the point. Next step they require a hash of the ad in the next request as proof and on it goes. See facebooks markup for the "Sponsored" string for a similar example in the wild. Last I checked ublock origin gave up.
    - zb3 3y ago
      More like I'm arguing that if they use their BG detection for catching adblockers as well, then that part _might_ be attacked with a greater force than before - and if broken, might hurt them more than adblockers did. Of course it's just pure speculation. Back to the technical argument, I was refering to the fact that a DB read to check if an ad should be served (done on the player page) as well as the DB write to check if the video was downloaded earlier (on the CDN, we have signatures there and expiry date passed as a parameter) might be infeasible from the architectural/performance point of view, but I gotta admit I actually don't have any relevant knowledge here so I'm just speculating because this seems interesting.
      - worksonmine 3y ago
        It would be done in-memory on whatever server the load-balancer assigns the visitor to, at the same time that the request is checked for permissions anyway. Compared to the rest of the data Google collects the extra timestamp isn't even a rounding-error and doesn't need to be persisted in long-term storage (the request is in the logs anyway).