Allow shields to whitelist an entire site, including subdomains

[TitaniumCoder477]

I switched from Chrome to Brave and then realized the Brave Shield has no domain whitelist feature. My work in IT requires that I use many web applications for which I do not want the shield operating. For example, I remote into dozens of servers each day using LogMeIn. Each URl is different, but the domain is always logmein.com. I would like to whitelist that domain so that each sub-domain is automatically whitelisted. AdBlockPlus has this feature. So now I have to move back to Chrome. I feel this is a basic feature that should be incorporated into the Brave Shield.

[jonathansampson]

Other users have also requested this functionality:

• https://twitter.com/nicksergeant/status/1169044157568077824

[gaui]

Any news? This is annoying as hell when I use https://codesandbox.io

[slickware]

Pinging this again. This is an incredibly necessary request, why has this sat here since July?

[ponzilover]

Yeah this would be useful

[David-Martel]

This would be a very useful feature

[vistalba]

Need this feature too.

[Elenaltarien]

Also need this for using LogMeIn for work

[geeper]

This is a close to a deal breaker for me. absolute must have

[ronanyeah]

I need this to get Google OAuth working.

[Amaneusz]

Any news on this? I got plenty of apps within my company's domain and their number is growing constantly - I'd love to see this feature get through

[bsclifton]

cc: @rebron

[Luminus]

I found this issue because I was looking for the same thing. It would be great to have a setting for doing this.

[AdamSC1-ddg]

Brave currently does allow for whitelisting via the brave://adblock/ page using adblock syntax:

@@||ads.example.com/notbanner^$~script

or entire sites:

@@||example.com^$document

if the OP needs to whitelist logmein they should be able to do so (with all subdomains) by adding:

@@||logmein.com^

What's missing currently is the ability to add URLs or to use a custom schema like ABP has to subscribe to a list:

abp:subscribe?location=https%3A%2F%2Fwww.example.com%2Fwhitelist%2Fsample-whitelist.txt%26amp%3Btitle%3DExample%20Whitelist

Brave would likely be able to solve a number of extension compatibility issues if there was a programmatic way to add exceptions or to subscribe to lists so that extensions could provide configuration files that users could decide to enable to deal with compatibility issues.

[Luminus]

Thanks @AdamSC1-ddg.

I just tried this with @@||wordpress.com^ as a quick test to whitelist all WordPress.com sites, but the shields are still operational on them.

Is there something I'm missing?

I've also tried the @@||wordpress.com^$document variant to no avail.

[geeper]

I tried the above and it didn't work for me either.

[AdamSC1-ddg]

I had managed to get this to work a while ago when targeting Outbrain ads, but, having tried again there is an issue.

To further test this I noted that:

1. Custom filters do block. For example ||redditstatic.com^ will break Reddit.
2. Custom whitelisting will overrule custom blocks. For example, placing @@||redditstatic.com^ one line under ||redditstatic.com^ over rules the blocking.

It seems that it isn't the case that whitelisting in general isn't working - but, rather that we are unable to have whitelisting over rule built-in lists and regional lists. I would guess based on the order they are being applied in? (cc: @rebron @bsclifton )

(Also @Luminus - the rule @@||wordpress.com^ wouldn't turn off shields for all WordPress sites, it would prevent any request from WordPress.com from being blocked on any site.)

[Luminus]

@AdamSC1-ddg thanks for the explanation.

So in essence, it isn't quite possible just yet to whitelist a domain and all its subdomains so that shields are down for them.

Is this something that you think will get implemented anytime soon?

[AdamSC1-ddg]

@AdamSC1-ddg thanks for the explanation.

So in essence, it isn't quite possible just yet to whitelist a domain and all its subdomains so that shields are down for them.

Is this something that you think will get implemented anytime soon?

In theory doing @@||wordpress.com^$document should whitelist all calls (same as disabling shields) on wordpress.com and its subdomains. Where as @@||wordpress.com^ should whitelist all calls to WordPress from other sites.

Not sure why its failing, but, I tagged the Brave staff who were involved in that convo above so hopefully they can investigate a fix.

[bsclifton]

Multiple +1's from https://github.com/brave/brave-browser/issues/7680

Including this great list from @Brave-Matt:

Some additional reports:

• https://community.brave.com/t/shields-is-blocking-webgl-on-itch-io/81402
• https://community.brave.com/t/how-to-widen-scope-of-saved-site-exceptions/13715
• https://community.brave.com/t/cant-deny-all-and-whitelist-cookies-in-version-0-57-18/39166/2
• https://community.brave.com/t/bravew-shields-league-of-legends/78761
• https://community.brave.com/t/a-manually-edited-whitelist-of-sites/89953
• https://community.brave.com/t/testing-brave-shields/39899/3
• https://www.reddit.com/r/brave_browser/comments/bwt4sw/whitelist_with_wildcard/

Happy to find/add more if necessary.

[bsclifton]

cc: @rebron for triage

[adamreisnz]

This is probably a reason to move back to Chrome. I really don't feel inclined to whitelist all our local IP addresses one by one...

[rebron]

@karenkliu Let's see if we can move this one along. We're looking for a list exception to turn off shields for specified domains. @AdamSC1-ddg mentioned using brave://adblock Custom Filter rules. a) It's possible we keep this as an advanced user feature and use the Custom Filter rules instead of adding UI to this. cc: @yrliou

We could also go with using b) brave://settings/content and introduce Shield settings here to manage a list or c) add a pref to brave://settings/shields. Or something else entirely.

@adamreisnz Thanks for the feedback and we do want to see why Brave users would possibly even consider moving back to Chrome and address those issues in a timely manner. With our speed and privacy advantages https://webtest.app/ we hopefully can keep you. Those seconds add up.

[wcpines]

@rebron

. . . It's possible we keep this as an advanced user feature and use the Custom Filter rules instead of adding UI to this . . . Or something else entirely.

I just did a test where I whitelisted @@||api.amplitude.com^ via chrome://adblock/. When I reloaded the page, the call was still listed as being blocked

I would think this detailed view is a great place to add a slider toggle to whitelist a domain right from the UI, rather than having to load a separate advanced settings page. I believe this would be similar to the Ghostery ux-- "for website x, allow 3rd party calls to domain y"

My $0.02

[DeltaMurillo]

I do not use Brave cause this. I preffer to keep using mozilla and NoScript, wich lets u whilelist sites and trackers one by one.

Having to unblock manually all the time is annoying.

[nsoui]

+1 here, too. We have a huge number of internal pages which I could whitelist with one line, if this were possible.

[mikeycrawford]

+1

I'm trying to get out IT support over to Brave from Chrome, but this issue is preventing me recommending Brave currently. We use LogMeIn extensively and the URL for each session changes each time we connect, e.g.

https://testpc-zmddtrpcys.app03-32.logmein.com/

and cross-site trackers enabled breaks our ability to remote on to the machine. Yes, we can untick it each time but ideally we want to disable it for *.logmein.com.

Watching this thread with interest.

[jgregmac]

+1 I am unable to authenticate to portal.azure.com (Microsoft Azure management) because my company is integrating with Duo Security as an MFA provider. Brave is interpreting some aspect of the cross-site MFA process as Ad or Tracking related, and thus breaking authentication.

The redirects happen so fast that I am unable to manually open the Shields UI to disable Shields on all sites involved. Adding the sites I believe to be involved in the exchange to the brave://adblock white list (in both @@||site.com^ and @@||site.com^$document format) is ineffective.

I am falling back to use of Firefox for Azure access, but I would prefer to use Brave for everything. I can't recommend this product to colleagues until it is compatible with all of the tools that we need to use to get our jobs done.

[frank6tg]

Definitely need this resolved. My bank recently changed its authentication when you sign in and it takes you to a URL on a subdomain that has "shields up" But I can't white list by clicking the shield because then it reloads the page / can't login to bank b/c the authentication process is interrupted.

[InsaneSplash]

+1

[andersek1]

C'mon, Why is this still not fixed? Just add a button next to the cross-site trackers in the shield "disable".

This is a huge issue for adoption.

[jgregmac]

Adding a little color to my previous comment. The scope of our problem just grew from "administrative access to a cloud service management portal" to "all institutional access to email".

My employer (a major university in the northeast) currently is rolling out an MFA-everywhere initiative. Soon, all faculty, staff, and students will need to use our external MFA provider to access all institutional web services. At that point, it will be impossible for our constituents to use Brave for access to email, calendar, and collaboration tools. Without an easy mechanism to unblock Office 365 and Duo Security, Brave adoption here will drop to zero.

[malcolmocean]

I'll add that I want this because without it twitter embeds don't show emoji

Here's an image that illustrates both how many emoji are blocked by the shield (well, a third of them) as well as what the tweet looks like without it.

Personally I basically think that blocking twitter emoji should be removed from Brave altogether—if there's an embedded tweet, twitter can already track you. It's probably in the adblock since those emoji are served from syndication.twitter.com.

[mcint]

Hiya away from twitter, @malcolmocean. It looks like adding @@||syndication.twitter.com^ to the brave://adblock/ custom blocklist would allow all requests to go through.

the rule @@||wordpress.com^ ... would prevent any request from WordPress.com from being blocked on any site.) https://github.com/brave/brave-browser/issues/5290#issuecomment-573074690

(Unless you need cookies on those requests).

---

Is there a way to modify cookie settings for the page without loading it? Or modify the site-specific cookies settings globally, by domain?

I'm having an issue using Brave to read papers with a library proxy. Each new journal site has a new-journal-site.libproxy.univ.edu sub-domain, sometimes multiple redirects (e.g. for the journal's auth redirect).

It's tricky to coerce Brave to "recognize" it's on a domain so that I can update the site-shield settings. It would be sufficient (for me) to be able to update shield settings without successfully loading the domain. This might be too complicated given entanglement in Chromium network stack 😱

[rmclaughlin-nelnet]

I love Brave, but this issue is causing my work to suffer. I am now forced to switch back to Chrome so I can do my job.

[chughtai]

I second what everyone has already said. I also cannot check organisational email (hosted outlook with ADFS etc) without completely turning off the shield.

[alexi21]

Unable to log into my switch within my LAN because of this... Brave is great but without this I have to open a different browser for managing my network.

[jamiehowarth0]

I have issues with implementing privacy policies with Iubenda because of this.

[terah]

On occasion an Office 365 website will fall into a redirect loop because of this. Today it was the forms app.

[alfonsojohan]

I have added the rule as recommended in the earlier post and have been successful in whitelisting by domain. currently running brave version 1.18.75 on windows 10 pro.

[rawtaz]

Another example of this being a complete blocker: When using BrowserStack Local, which is a software you run locally to "tunnel" requests to local (e.g. development) websites from BrowserStack's remote browsers into your local site, the browser you're accessing BrowserStack Live (the remote browsers for manual testing) with needs to connect to http://127.0.0.1:45691/?_=1610159247632 (number changes on every request), and when you have the shield up for live.browserstack.com (which you want, as there's a bunch of tracking there), the requests to 127.0.0.1:45691 (where the BrowserStack Local software is listening) fails with "GET http://127.0.0.1:45691/?_=1610159247632 net::ERR_BLOCKED_BY_CLIENT". Looking at the shield, these requests are also listed under trackers/ads that have been blocked.

I tried adding both @@||127.0.0.1^ and @@||127.0.0.1:45691^ (also tried @@||127.0.0.1:45691^$document) as the only line in the custom filters at brave://adblock, but neither of them disabled the blocking of these requests, even after reloading or restarting the tab with live.browserstack.com in it. As it stands now, for a web developer Brave is completely useless for anything but the very basic parts of web development, and I hope that a whitelist feature comes very soon. That said I totally understand and respect that I have no right to complain about this, so that's not my intent here - it's obviously up to the core developers to decide what they want to spend their time on!

[AJamesPhillips]

This feature would make it easier to use the hypothes.is plugin . At the moment you have to login every time you visit a new page or refresh it.

[fedayn1]

https://evolvingviews.com/2020/03/how-to-setup-brave-adblock-whitelist/#:~:text=In%20the%20address%20bar%2C%20go,using%20the%20Adblock%20Plus%20syntax.

[bsclifton]

Short term, we could add a checkbox for Use these shield settings for subdomains too into the Advanced version of the shields UI (maybe above Simple View)

Longer term, we could expose this wildcarding via a UI where users could view/edit/add domains for shield settings (see https://github.com/brave/brave-browser/issues/10829 and https://github.com/brave/brave-browser/issues/12782).

[ashutoshsaboo]

@bsclifton this is not just a problem with subdomains. See #12782 with 302 redirects from page X to Y (say both are on different sub domains as well as domains) then how would this work out if you wanted to change shield settings for site X? The thing is that it doesn't redirect me from X to correct auth page because of shield issues (otherwise with shields turned on it 302 redirects to an error page currently), so it's really a hard requirement to change shield settings JUST for site X.

Without exaggeration - almost everyone in my org who's wanted to use Brave has tried it, been frustrated with this, and eventually struggled and moved to either Firefox/Chrome.

As I mentioned in #12782 as well as seeing above, a lot of folks seem to have similar requests for auth to work correctly for internal sites.

The only way so far is to completely turn off the global shields (atleast that's what I'm only aware, feel free to point to any alternatives) - which is an extremely sub-optimal and privacy forging solution (since turning off global shields here).

For the short term solution, why not just add shield settings to where you can currently change site specific settings like flash/camera/audio access etc for a particular site? Would that be too much effort? Before the long term is implemented, this would be a right mix IMO as it's still easy to access the page if not the most user friendly way. And will still help achieve use-case like the one i mention easily.

[jtheletter]

An option to lower shields for all subdomains would improve my experience with AWS Console.

[FearNaBoinne]

I am amazed that 3(!) years later this still isn't implemented...

This is a BIG THING people! Some sites generate temporary sub-servers for sessions or individual publishers, like for instance Wordpress, itch.io, our 2FA system, etc. These require MANUAL enabling EVERY TIME you use them, or at least visit a different section of the site...

I am a recent convert from FF, but this shields thing is about to drive me back!

[david0178418]

This is probably the only consistent pain point I've had with Brave. More sites due authorization redirects, and it's a giant pain to lower global shield settings just to get the auth then turn them back on.

[jgregmac]

Recent posts here triggered me to go back and try Brave again to see if the user experience has gotten any better.

I managed to make it though about two days of nearly constant use before running into something untenable. Interactions between Duo Security and Microsoft 365 services have improved... I now can perform essential SSO operations without needing to drop shields. However, when trying to use the Zoom plugin to Outlook Web App I ran into blocking behavior from "Shields Up".

So we still aren't there. I am going to discontinue use of Brave pending further developments.

[rushi]

I would really like it as well so that I can whitelist my entire company's domain. Otherwise I have to endup whitelisting every domain

[bridiver]

I am seeing some comments where people say that they are forced to go back to Chrome, but I'm having trouble understanding that because Brave's features in this area are a superset of Chrome's. There is no blocking capability in Chrome that does not exist in Brave as well. Also there's nothing stopping you from using Adblock Plus in Brave. I'm not necessarily arguing for or against this change, but I don't understand how going back to Chrome is the solution when Brave has the same controls (and more).