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.

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.

You can do this in their UI as well. Go to Settings → Privacy and Security → Shields Status. You can put an exception in there in the Shields Down section. You literally put in [*.]example.com (or whatever your domain is) rather than *.example.com as I would expect the syntax to be.

I have bad news for you, wildcards are not supported in that panel anymore, at first it was allowed but then it caused issues so they removed it. https://github.com/brave/brave-core/pull/16067

Preferences files directly is the only place where you can add wildcard and maybe group policy (which they added recently).

/shrug. I just used it successfully this morning to remove shields on netlify deploy previews for the product I work on without issues. Perhaps the PR hasn’t made it into the mainline builds yet.

Seemed to work for now though.

Ah, I’m on 1.46 with an update available. I see on the PR it’s on 1.48.x. Guess I’ll have to do future updates in the conf file.