roosterteeth.com: ads

[Pantscada]

Prerequisites

• I read and understand the policy about what is a valid filter issue.
• I verified that this issue is not a duplicate. (Use this button to find out.)
• I forced an update of my filter lists. (Click the "Purge all caches" button while holding the 'Shift' key, then click the "Update now" button.)
• I did not remove any of the default filter lists, or I have verified that the issue was not caused by removing any of the default lists.
• I did not enable external filter lists, or I have verified that the issue still occurs without enabling external filter lists.
• I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
• I am not using uBlock Origin (uBO) along with other content blocker extensions.
• I have verified that the web browser's built-in blocker or DNS blocking (standalone or through a VPN) is not causing the issue.
• I did not answer truthfully to ALL the above checkpoints.

URL address of the web page

https://roosterteeth.com/watch/lets-play-2023-4-25

Category

ads

Description

roosterteeth.com new video player, plays ads mid video that cannot be skipped

Screenshot(s)

Screenshot(s)

Configuration

uBlock Origin: 1.48.4
Firefox: 112
filterset (summary): 
  network: 121379
  cosmetic: 204569
  scriptlet: 39342
  html: 1117
listset (total-discarded, last-updated): 
  added: 
    https://www.joinhoney.com/whitelist/honey-smart-shopping.txt: 0-0, 1d.7h.3m
    adguard-generic: 70541-5495, 3d.23h.18m
    adguard-mobile: 8691-98, 3d.23h.20m
    adguard-annoyance: 67508-6012, 3d.23h.19m
    fanboy-thirdparty_social: 69-0, 1d.2h.59m
    fanboy-annoyance: 91198-15312, 1d.3h
    ublock-annoyances: 4920-4, 3d.23h.22m
    adguard-spyware-url: 999-5, 3d.23h.21m
    block-lan: 46-0, 28d.6h.58m
  default: 
    user-filters: 0-0, never
    ublock-filters: 34845-66, 1d.7h.6m
    ublock-badware: 7014-1, 1d.7h.5m
    ublock-privacy: 370-0, 2d.7h.11m
    ublock-abuse: 70-0, 2d.7h.12m
    ublock-unbreak: 2010-3, 1d.7h.4m
    easylist: 65618-652, 1d.7h.7m
    easyprivacy: 30880-1770, 3d.7h.17m
    urlhaus-1: 7279-1, 6h.58m
    plowe-0: 3746-2, 2d.11h.13m
    ublock-quick-fixes: 209-0, 6h.57m
filterset (user): [empty]
trustedset: 
  added: [array of 47 redacted]
  removed: 
    moz-extension-scheme
switchRuleset: 
  added: [array of 3 redacted]
modifiedUserSettings: 
  colorBlindFriendly: true
modifiedHiddenSettings: [none]
supportStats: 
  allReadyAfter: 1267 ms (selfie)
  maxAssetCacheWait: 479 ms
popupPanel: 
  blocked: 97
  blockedDetails: 
    brightcove.com: 54
    cookielaw.org: 2
    facebook.net: 1
    innovid.com: 1
    ngtv.io: 1
    typekit.net: 1
    wmcdp.io: 37

[dimisa-RUAdList]

@stephenhawk8054
@mapx-
@gorhill

Please add: ||brightcove.com^$xhr,removeparam=ad_config_id,domain=brightcove.net

Example: https://www.nhl.com/video/all-of-friday-s-goals-6340934708112

[dimisa-RUAdList]

@gorhill
May be: ||brightcove.com^$xhr,removeparam=ad_config_id,domain=brightcove.net|roosterteeth.com?

~> https://github.com/uBlockOrigin/uAssets/commit/fc2d7bd065b3e79d945fcfdc0da73ff33f6ea089

[gorhill]

I fear ||brightcove.com^$xhr,removeparam=ad_config_id,domain=brightcove.net is too generic and could lead to breakage, since it targets probably all sites using brightcove.com. By narrowing to accounts/..../, I feel it's much safer. If other sites are reported with the same pattern, will then re-evaluate.

[dimisa-RUAdList]

The fact is that brightcove.com and brightcove.net are different domains. In addition, the rule for roosterteeth.com has been working for several months stably and without breakdowns.

[stephenhawk8054]

I think the issue is brightcove.net could be the iframe of many other sites, unlike roosterteeth.com which is a 1st-party site and is not (or rarely) meant to be iframe inside others

@gorhill I think an approach for this is the concept of rootDomain. We actually already had an anti-adblock case of imasdk.googleapis.com iframe in which we have to allow an adserver XHR (adnxs.com) inside that iframe and it doesn't contain more specific information in the URL

#16014 (comment)

[gorhill]

Yeah, I thought about this when looking at this case.