Unexpected differences between global Shields settings, global cookies settings, and local Shields settings

[Tonev]

Description

There are unexpected differences between the global Shields settings, global cookies settings, and local Shields settings. In addition to that, the global Shields settings are set to aggressive/strict when a new user profile is created.

This is more of a UI bug since default aggressive/strict global Shields settings are not applied to global cookies settings and local Shields settings (when it concerns clean user profiles).

Steps to Reproduce

1. Clean user profile in Brave Nightly.
2. Open brave://settings/shields.
3. Open brave://settings/cookies.
4. Open https://brave.com.
5. Observe the differences between the opened pages.

Actual result:

Global Shields settings	Global Cookies settings	Local Shields settings

Expected result:

Default global Shields settings shouldn't be set to aggressive/strict, and there shouldn't be any difference between the settings displayed on brave://settings/shields and local Shields settings when it comes to a clean user profile.

Reproduces how often:

100%

Brave version (brave://version info)

Brave	1.41.33 Chromium: 102.0.5005.78 (Official Build) nightly (64-bit)
Revision	df6dbb5a9fd82af3f567198af2eb5fb4876ef99c-refs/branch-heads/5005_59@{#3}
OS	Windows 10 Version 21H2 (Build 19044.1741)

Version/Channel Information:

• Can you reproduce this issue with the current release? No
• Can you reproduce this issue with the beta channel? No
• Can you reproduce this issue with the nightly channel? Yes

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? N/A
• Does the issue resolve itself when disabling Brave Rewards? N/A
• Is the issue reproducible on the latest version of Chrome? N/A

Miscellaneous Information:

CC: @rebron @nullhook @stephendonner

[stephendonner]

@ShivanKaul @pes10k any intended changes which might've caused unexpected ones, in this area?

[pes10k]

local and global shields settings are by design not supposed to match. the former is is the local override for the latter.

For the "global Shields settings" and "global cookies settings" not syncing, i believe this is a known bug, but reloading (or closing and reopening) brave://settings should bring thenm back in sync (with both showing the correct / true value).

@stephendonner can you confirm when you have a chance?

[stephendonner]

local and global shields settings are by design not supposed to match. the former is is the local override for the latter.

Thanks; just didn't want us to miss having Trackers & ads blocking set by default, in brave://settings/shields to Aggressive (while the Shields UI correctly shows default as Block trackers & ads, as well as Block cookies now set to a new default of All in brave://settings/shields (but again, correct in the Shields UI).

For the "global Shields settings" and "global cookies settings" not syncing, i believe this is a known bug, but reloading (or closing and reopening) brave://settings should bring thenm back in sync (with both showing the correct / true value).

@stephendonner can you confirm when you have a chance?

Sure, it's on my short list now; @Tonev @MadhaviSeelam also encouraged to weigh in of course!

[stephendonner]

Using

Brave	1.41.47 Chromium: 102.0.5005.78 (Official Build) nightly (x86_64)
Revision	df6dbb5a9fd82af3f567198af2eb5fb4876ef99c-refs/branch-heads/5005_59@{#3}
OS	macOS Version 12.5 (Build 21G5037d)

Steps

1. install 1.41.47
2. launch Brave
3. open brave://settings/shields, note Block cookies is set to All
4. now set it to Disabled
5. open brave://settings/cookies and note Allow all cookies is selected under General settings
6. next, select Block third-party cookies on brave://settings/cookies
7. open brave://settings/shields
8. note Block cookies shows Disabled
9. reload or open a new brave://settings/shields page
10. Block cookies now reads All, but it should read Only cross-site

[stephendonner]

Here's a slightly convoluted screencast showing a different set of steps with the same issue:

[MadhaviSeelam]

Brave	1.41.47 Chromium: 102.0.5005.78 (Official Build) nightly (64-bit)
Revision	df6dbb5a9fd82af3f567198af2eb5fb4876ef99c-refs/branch-heads/5005_59@{#3}
OS	Windows 11 Version 21H2 (Build 22000.675)

@pes10k I am same issue as @stephendonner did in regards to brave://settings/cookies page in Win 11x64
Global shields settings, per site shield (local) settings and global cookies settings are working as expected. i.e. If any of the settings changed in global defaults page are reflected in the local site shields panel and global cookies settings page.

• Install 1.41.47
• Launch Brave
• Go to brave.com
• Local shields settings show are in default mode
• open brave://settings/shields and shields settings are NOT in default mode
• Set Trackers & ads blocking, Block fingerprinting and Block cookies to Disabled in brave://settings/shields
• Verified local shield settings (per site-brave.com) match to the global shield settings
• open brave://settings/cookies
• Verified Allow all cookies was enabled - Same as global shield settings and local shields settings
• Now select Block third-party cookies in brave://settings/cookies
• Local site shields panel (brave,com) shows Block cross-site cookies enabled
• Global defaults page still shows Disabled for Block cookies
• Refreshed the page and the setting displayed 'All`

2022-06-08_17h07_34.mp4

Note: Global shields default settings are incorrect so that page still needs a fix.

[GeetaSarvadnya]

Reproduced the issue in Windows 10 x64 - 1.41.46Nice catch @Tonev!

[Tonev]

local and global shields settings are by design not supposed to match. the former is is the local override for the latter.

I believe they should match when it concerns clean user profiles. When a user creates a user profile, the user profile is supposed to use the default global Shields settings, and without previous Shields settings changes, the local Shields settings should match the global Shields settings.

[stephendonner]

Sorry @Tonev, although you filed this earlier, looks like the work to address this was done over in #23304, so resolving as duplicate (normally we'd take the earlier issue, it was just missed).