Question Brave Shields

Brave
21 Replies 2,757 Views
Help answer the author's question with clear explanations and useful steps.
n8chavez said:
Does anyone know where in the user profile Brave stores its user rules for custom blocked elements? I need to make a sandboxie exclusion for that file.
Click to expand...
n8chavez, Brave is based on Chromium, so its user profile data is stored in a similar location. For Windows, the default profile is typically at:

C:\Users\YourUsername\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default

Custom blocked elements (like those from uBlock Origin or Brave's Shields custom filters) aren't always in a single, easily identifiable file. They could be stored in:

- Local Storage or IndexedDB databases within the profile folder, often under subfolders like "Local Extension Settings" for extensions.
- For uBlock Origin specifically (which Brave supports), look for folders like "Extension Rules" or databases in User Data\Default\IndexedDB\chrome-extension_<uBlock-ID>_ (the ID is something like "cjpalhdlnbpafiamejdnhcphjbkeiagm").

If it's Brave's built-in adblock custom rules, they might be in User Data\Default\adblock or similar JSON/ database files.

For Sandboxie exclusions, you might need to exclude the entire profile folder or specific subpaths to cover databases. If you can clarify if it's via an extension or built-in, I can try to narrow it down more!
 
I've looked at every .json and .db file in the profile directory, and none of them contain anything like the entries I created in Shield.
 
Have you checked the LevelDB databases? Brave Shields rules might be stored in LevelDB format rather than standard JSON files. LevelDB is commonly used by Chromium-based browsers for storing preference and extension data.

Try looking in these locations:

1. **User Data\Default\Preferences** - Open this file with a text editor and search for "shields" or "adblock" related entries

2. **User Data\Default\Local Storage** - Brave might store Shields data in LevelDB format here

3. **User Data\Default\leveldb** - Check if there's a leveldb folder with the actual database files

Alternatively, you could:

- Use a LevelDB viewer/extractor tool to read these binary database files
- Check Brave's GitHub issues - this specific behavior might be documented there
- Monitor file access with a tool like Process Monitor while you create/modify a Shield rule. This will show exactly which file(s) get written to

For Sandboxie, if you can identify the specific files being modified, you could create targeted exclusions rather than excluding the entire profile folder.
 
The odd thing is, I still cannot find where the custom shield element blocks are stored. I've tried User Data\Default\Preferences, User Data\Default\Local Storage\, and User Data\Default\ads_service\database.sqlite. Any more ideas, @Bot?
 
n8chavez said:
The odd thing is, I still cannot find where the custom shield element blocks are stored. I've tried User Data\Default\Preferences, User Data\Default\Local Storage\, and User Data\Default\ads_service\database.sqlite. Any more ideas, @Bot?
Click to expand...
More likely than not: it’s stored in a Chromium “storage” database (LevelDB), and it won’t show up by grepping .json/.db

Brave’s built-in Shields/adblock UI can still persist data in Chromium’s normal storage backends (especially LevelDB). In that case, you can open the files, but you won’t see your rules as readable text.

Places that commonly hold this kind of data
  • Local Storage (LevelDB)
    C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Local Storage\leveldb\
  • Local Extension Settings (LevelDB) for a built-in component
    C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Local Extension Settings\<EXTENSION_ID>\
  • Sync Extension Settings (sometimes used instead of Local Extension Settings)
    C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Sync Extension Settings\<EXTENSION_ID>\
  • If you have multiple profiles
    Replace “Default” with “Profile 1”, “Profile 2”, etc.

Even if you “aren’t using an extension,” Brave often ships internal components as extensions (or extension-like components). The data then lands under one of those “Local Extension Settings / Sync Extension Settings” folders keyed by an ID.

Best way to find the exact file (reliable): Sysinternals Process Monitor
This avoids guessing and will show you exactly what Brave writes when you add/remove an element block.

  • Download/run Microsoft Sysinternals Process Monitor (Procmon).
  • Add filters:
    • Process Name is brave.exe -> Include
    • Path contains \BraveSoftware\Brave-Browser\User Data\ -> Include
    • Operation is WriteFile OR SetRenameInformationFile OR CreateFile -> Include
  • Clear the capture window.
  • In Brave, create ONE new custom “blocked element” entry.
  • Immediately look at the newest file write events and note the full path being modified.

Once you have that path, that is the correct target for a Sandboxie exclusion (and you can keep it narrow).

If you want a “practical” Sandboxie workaround without opening the whole profile
If you don’t manage to isolate the single file, the smallest “usually effective” write-allow areas (because Shields rules are commonly in LevelDB) are:

  • ...\User Data\Default\Local Storage\leveldb\
  • ...\User Data\Default\Local Extension Settings\

That’s still broader than a single file, but it’s typically much narrower than allowing the entire profile.

Conclusion
At this point, Procmon is the most dependable next step: it will reveal the exact file/folder Brave is writing when you add a custom element block, and then you can create a precise Sandboxie exclusion based on the observed path.
 
@Bot, I think maybe they are stored in BraveSoftware\Brave-Browser\User Data\Default\Preferences. The issue though is that Preferences has no file extension and I'm not sure how to add extension-less files to Sandboxie.ini.
 
Last edited:
I can't for the life of me determine where they are stored, even after using Process Monitor and following @Bot's advice. Anyone have any any ideas?
 
n8chavez said:
I can't for the life of me determine where they are stored, even after using Process Monitor and following @Bot's advice. Anyone have any any ideas?
Click to expand...
Sandboxie can target an extension-less filename

In Sandboxie/Sandboxie-Plus, the rules are not “by extension” — they’re by full path. So you can add an entry that ends in \Preferences (no .txt/.json required) and it will still match.

Typical examples in Sandboxie.ini:

  • Allow Brave to write only that one file
    WriteFilePath=brave.exe,C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Preferences
  • If Brave is using the Chromium “secure prefs” file instead
    WriteFilePath=brave.exe,C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Secure Preferences
  • Some Brave settings land in the global file (not per-profile)
    WriteFilePath=brave.exe,C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Local State

If you prefer allowing read/write in one directive, many setups use OpenFilePath instead (behavior depends on your overall Sandboxie config), e.g.:

  • OpenFilePath=brave.exe,C:\Users\<you>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Preferences

Why ProcMon often “doesn’t show it” even when you’re close

Chromium-based browsers frequently write settings like this:

  • Write to a temporary file (example: Preferences.tmp)
  • Then rename/replace it onto Preferences (a rename operation, not an obvious “write to Preferences”)

So in Process Monitor, make sure you include rename-type operations, not just WriteFile.

Suggested ProcMon filter additions:

  • Process Name is brave.exe (Include)
  • Path contains \BraveSoftware\Brave-Browser\User Data\ (Include)
  • Operation is WriteFile (Include)
  • Operation is SetRenameInformationFile (Include)
  • Operation is Rename (Include) (if present)

Then look specifically for activity involving:
  • \Default\Preferences
  • \Default\Secure Preferences
  • \User Data\Local State
  • Any *.tmp in the same directories right before a rename

Practical fallback if you just need it working

If the goal is “make sure Shields custom element blocks persist outside the sandbox” and you can’t isolate the exact single file, the smallest “usually safe enough” compromise is to allow writes to the small set of prefs files that Brave uses for most UI settings:

  • ...\User Data\Default\Preferences
  • ...\User Data\Default\Secure Preferences
  • ...\User Data\Local State

This is still much narrower than excluding the whole Brave profile.

Conclusion

You can absolutely whitelist an extension-less file in Sandboxie.ini by specifying the full path ending in \Preferences. If ProcMon wasn’t conclusive, it’s very often because the change is committed via a temporary file + rename, or because it’s going into “Secure Preferences” or “Local State” instead of “Preferences.”
 
The custom blocked elements saved location was indeed local-state!

The correct location was indeed %LocalAppData%\BraveSoftware\Brave-Browser\User Data\Local State, with the correct Sandboxie exclusion string being “OpenFilePath=brave.exe,C:\Users\\AppData\Local\BraveSoftware\Brave-Browser\User Data”

I verified it, and custom entries do remain between sandboxed sessions. I have been looking for that for a long time. It’s a bit confusing because no new entries appear at the beginning or end of the file, as I’d expect. Changes are made in the middle. So when I searched I never saw them, assuming it was the incorrect file.
 
2.JPG

1.JPG
 
Don't forget, the purpose of using a browser with integrated adblocking is because MV2 is going away tomorrow with the release of Chrome 150. Everyone can exalt uBo all they want, but the fact remains it will not be supported any longer. Users can use uBo lite, but it's a cheap imitation. But it's the best gorhill can do. Integrated blockers will not be losing functionality.
 
Last edited:
CyberNews points out a Chromium commit that removes support for the “kExtensionManifestV2Disabled” flag, which is referred to as “dead code” seeing as Chrome no longer supports Manifest V2 extensions. This removal acts as the final stop for many Manifest V2-based ad blocker extensions that were still in use today – the flag was effectively a loophole to continue using these extensions.
Click to expand...
Chrome 151 (expected July 2026): Will remove the remaining flags (ExtensionManifestV2Unsupported, ExtensionManifestV2Availability, and AllowLegacyMV2Extensions). The W3C WebExtensions Community Group documented the Chrome 150 removal on May 20, 2026, citing a Chromium code review in which a Google engineer confirmed: “MV2 extensions are no longer allowed in any supported version of Chrome, and we are removing support for them.” PiunikaWeb reported the Chrome 151 flag removals on June 8; PCWorld confirmed the timeline a day later.
Click to expand...
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top