Force aggressive cosmetic filtering on youtube

[antonok-edm]

Resolves brave/brave-browser#30896

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run lint, npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

Visit youtube.com and verify that there's no difference in parts of the page visible when toggling between Block trackers & ads and Aggressively block trackers & ads in the Advanced controls section of the Shields panel.

Toggling to Allow all trackers & ads or turning Shields off completely should still show preroll and page ads.

[antonok-edm]

Doesn't seem to matter, but I changed the port to 443 here for consistency.

[iefremov]

can you also please add a comment that links a ticket(s) in both cases

[pes10k]

looks great to me, though please make sure to sync with @cuba when hes back from PTO to make sure iOS matches

[pes10k]

LGTM

[iefremov]

i would rather move this check to a separate statement, to avoid mixing exceptional/hardcoded cases with normal code. I.e. making corner cases very clear and visible never hurts

[atuchin-m]

+1
Also ask iOS team to make a ticket to sync these changes.

[atuchin-m]

BTW we already use per-frame GetBlinkPreferences().force_cosmetic_filtering.
IMHO if we change force_cosmetic_filtering to cosmetic_filtering_mode we will get a single point to in the browser process to setup cosmetic filter mode for a single frame.

The exceptions like youtube & g_vetted_search_engines could be moved there.
And cosmetic_filtering_mode will be the one source to check for CosmeticFiltersJsHandler.

[bridiver]

I agree this check is not great, but I think these changes could probably move to a follow-up if done immediately following this since it's apparently a high priority fix, but my bigger concern here is that there is no test to verify this.

[cuba]

The relevant iOS changes to correspond with these changes are here: It's introducing network level standard mode and the youtube.com exception to both network blocking and CF.

[iefremov]

cc @atuchin-m

[iefremov]

pls make the requested changes in a followup