Shield Settings Based on Root Domain

I think it’d be swell if we could set Shield defaults based on url patterns. My use-case may not be the most common, but I’m an administrator where I am creating new subdomains pretty regularly, and I have to disable shields for full functionality. If I could apply a setting for “shields down” based on matching the root domain I wouldn’t have to specify my preference every time I spin up a new subdomain.

Thanks for reading, and thanks also for a wonderful product!

I found a solution to this, as I was getting frustrated with the same issue, and the adblock filters were not working for me.
Paths I specify are for windows.
Go to “C:\Users<user>\AppData\Local\BraveSoftware\Brave-Browser\USer Data\Default” and open the Preferences file.
It is a massive JSON file in a single line. if you search for “braveShields” there should be a single instance of it. That section defines the shields state for each site you have changed it on. If formatted for readability it looks like this.

"braveShields":
 {
    "192.168.0.3,*":
    {
        "expiration": "0",
        "last_modified": "13309958750384508",
        "model": 0,
        "setting": 2
    },
    "sub1.example.com,*":
    {
        "last_modified": "13311386556522116",
        "setting": 2
    },
    "example.com,*":
    {
        "last_modified": "13311384676189891",
        "setting": 2
    }
},

Setting 2 means disabled.

Close brave before making this edit so it does not overwrite the file on you.

If you add an entry, or replace a subdomain entry with the following instead.

"[*.]example.com,*":
{
    "last_modified": "13311386556522116",
    "setting": 2
},

Start Brave up again.
This seems to match correctly and disable shields for all sub-domains at least for me.

Any sub-domains still defined in the list will overwrite the wildcard.
In my testing, the following code:

"braveShields":
 {
    "192.168.0.3,*":
    {
        "expiration": "0",
        "last_modified": "13309958750384508",
        "model": 0,
        "setting": 2
    },
    "[*.]example.com,*":
    {
        "last_modified": "13311386556522116",
        "setting": 2
    },
    "sub1.example.com,*":
    {
        "last_modified": "13311386556522116",
        "setting": 1
    },
    "example.com,*":
    {
        "last_modified": "13311384676189891",
        "setting": 2
    }
},

Had shields up for sub1.example.com, and shields down for all other sub-domains.
Order did not appear to matter.

Hope this helps.

But the thing is, why do you want to turn shields off? is it because of the scripts being blocked? in that case, then it would make more sense to use custom filters for that.
with either way as @@||example/*$scripts if you want to turn off 1p for example or use *$scripts,domain=example.com to turn every script off from that domain.

It will be also faster.

The good thing is Nightly now has a UI page in settingss where you can add domains for up and down, that means that you can achieve the same thing you are proposing, but without messing with Preferences JSON file.

image

I mean, your solution is okay for now, since you will be able to do that soon inside Brave UI soon, since it’s been couple weeks with it in the Nightly. But I don’t get why anyone would want to turn shields completely off.
Most of the problems are done because of the scripts? well, then that can be easily handled by the custom filters, I doubt fingerprinting protection, https can cause issues for functionality.
Brave in the issue of the Shields UI, also showcased in a gif the same panel for HTTPS upgrade, so maybe they will add also that, and fingerprinting protection in the future.

Note: you have an error because you typed [*.].example.com the correct address would be without the dot [*.]example.com.

I have random issues with some of my internal sites with shields up, mostly remote console windows and such. I use an internal domain name to access all of my stuff, and I don’t want to edit them individually. And since I am the one running them, and controlling their contents, I am not worried about them having access to my data. So it is easier to just turn shields off for my internal domain than to try and figure out what part of the system is causing me issues.

Well, fair enough!
It is good Brave is finally bringing the feature to make it easy to do that then, so the request is already implemented on Nightly.

They are also bringing two policies BraveShieldsDisabledForUrls and BraveShieldsEnabledForUrls, you might use in the future, they are still working on it but would be good as an admin.