Brave is blocking javascript fetch calls back to my own site!

Description of the issue:
I’m developing a web app, and fetching partial html for dynamic page navigation using javascript fetch (when javascript is enabled).

Brave seems to be blocking a url with the term advertisements in the episode slug, even though the page has nothing to do with serving ads! The page is not blocked when navigating to it directly in the browser, just when using fetch. The content-type returned is text/html; charset=utf-8 in case that’s relevant.

Fetch fails with net::ERR_BLOCKED_BY_CLIENT, Brave shows “1 cross-site tracker blocked”. The fetches are done back to the same origin as the document location so that really makes no sense.

Is there something I can do while writing the webapp to make sure calls back to my same origin always succeed?

Exact URL of the website in question:
http://<localhost or custom domain>/episode/advertisements-<hexstring>.html

Did the issue present with default Shields settings? (yes/no)
Yes

Does the site function as expected when Shields are turned off?
Yes

Is there a specific Shields configuration that causes the site to break? If so, tell us that configuration. (yes/no):
Unknown, it fails with standard settings

Does the site work as expected when using Chrome?
Yes

Brave version (check About Brave):
Version 1.23.75 Chromium: 90.0.4430.93 (Official Build) (x86_64) ](https://brave.com/latest/)

Hey, you can get around it in brave://adblock, Adding the following:

@@/episode/advertisements- should help here.

Avoiding the term /advertisements- would prevent false positives, I would rename this file here

1 Like

That’s not the point. The url contains a dynamic show slug based on a podcast episode. The title of the episode happened to be “advertisements”, but it could other mystical banned words banned by Brave in the future. Surely there must be a way for developers of a webapp to mark fetch calls back to their own domain as trusted as top-level browser navigations?

Easylist (which Brave uses) is a term based adblock filter, certain terms are blocked due to being popular advert terms. Not specifically a Brave issue, it’s Easylist (so it’ll affect all/most adblockers here)

If it’s a single public site, that can be replicated by myself, we can make an exception. If its local only, or used by many sites I would recommend changing the term to be less “ad-like”.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.