Change default (standard) network blocking policy to always allow 1p requests

[pes10k]

To improve web compat (and so reduce how often users need to drop all shields, and so all protections) we should change the default blocking configuration in Brave. All sub-requests with the same eTLD+1 as the top level document (i.e., "first party requests") should be allowed when in "Trackers & Ads Blocked (Standard)" mode.

"Trackers & Ads Blocked (Aggressive)" mode should retain the current behavior.

This feature should be default on, ie when the flag is set to default, the above policy is active.

However, it should, day-0, be rolled out with 0% deployment (off for everyone) with Griffin

[pes10k]

I think this needs to be included in the release notes. Its a significant change, and being made for good (if not without a downside too) reason

[antonok-edm]

I figured the flag itself wasn't significant enough without any changes in-browser yet, but that sounds good

[iefremov]

However, it should, day-0, be rolled out with 0% deployment (off for everyone) with Griffin

@pes10k this is problematic for now, because griffin parameters are only applied after restart. Many people never restart, so they would have a default value aka enabled. I reckon we have to ship it as disabled by default and enable via griffin when needed

[pes10k]

This flag is mostly here so that advanced tin foil users can disable, not for a staged rollout, so I’m not so concerned in this case

…

On Aug 13, 2021, at 12:53, iefremov ***@***.***> wrote:  However, it should, day-0, be rolled out with 0% deployment (off for everyone) with Griffin @pes10k this is problematic for now, because griffin parameters are only applied after restart. Many people never restart, so they would have a default value aka enabled. I reckon we have to ship it as disabled by default and enable via griffin when needed — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[antonok-edm]

@iefremov I've implemented it as default-on, where the "on" behavior matches the current pre-flag behavior - if I understand your concern correctly that should work too.

[iefremov]

ah, correct - we would keep the current behaviour until users update & relaunch to apply the seed. That sounds good, thanks for the clarification

[stephendonner]

QA: this is QA/Blocked until brave/brave-core#9784 lands.

[stephendonner]

Verified PASSED using

Brave	1.30.38 Chromium: 93.0.4577.51 (Official Build) nightly (x86_64)
Revision	762d21050e2da59930c784c09b134d0b0b148188-refs/branch-heads/4577@{#915}
OS	macOS Version 11.5.2 (Build 20G95)

Steps:

1. new profile
2. launched Brave
3. set Shields first-party network blocking to Disabled via brave://flags, and restarted Brave
4. loaded https://dev-pages.bravesoftware.com/filtering/network-requests.html
5. confirmed there was an image loaded under First-Party Sub Requests when in Trackers & ads blocked (standard) Shields mode
6. clicked on the Brave Shields icon and Advanced View
7. clicked Got it
8. changed Trackers & ads blocked (standard) to Trackers & ads blocked (aggressive)
9. confirmed there was no image shown, and a request for it was blocked
10. confirmed that the image in the Third-Party Sub Requests section didn't display under either (standard) or (aggressive) modes for Shields
11. confirmed the request for the image was blocked

NOTE: because there are two overlapping tests on one page, the "No resources should be blocked in shields." from the test page is erroneous, as the bottom test blocks the image regardless of settings, which shows up in the 1st test's Shields info panel.

example	example	example	example

---

Verified PASSED using

Brave	1.30.66 Chromium: 93.0.4577.63 (Official Build) dev (64-bit)
Revision	ff5c0da2ec0adeaed5550e6c7e98417dac77d98a-refs/branch-heads/4577@{#1135}
OS	Linux

Steps:

1. new profile
2. launched Brave
3. set Shields first-party network blocking to Disabled via brave://flags, and restarted Brave
4. loaded https://dev-pages.bravesoftware.com/filtering/network-requests.html
5. confirmed there was an image loaded under First-Party Sub Requests when in Trackers & ads blocked (standard) Shields mode
6. clicked on the Brave Shields icon and Advanced View
7. clicked Got it
8. changed Trackers & ads blocked (standard) to Trackers & ads blocked (aggressive)
9. confirmed there was no image shown, and a request for it was blocked
10. confirmed that the image in the Third-Party Sub Requests section didn't display under either (standard) or (aggressive) modes for Shields
11. confirmed the request for the image was blocked

NOTE: because there are two overlapping tests on one page, the "No resources should be blocked in shields." from the test page is erroneous, as the bottom test blocks the image regardless of settings, which shows up in the 1st test's Shields info panel.

example	example	example	example

---

Verification passed on

Brave | 1.30.68 Chromium: 93.0.4577.63 (Official Build) beta (64-bit)
-- | --
Revision | ff5c0da2ec0adeaed5550e6c7e98417dac77d98a-refs/branch-heads/4577@{#1135}
OS | Windows 10 OS Version 2009 (Build 19043.1165)

Steps:

1. new profile
2. launched Brave
3. set Shields first-party network blocking to Disabled via brave://flags, and restarted Brave
4. loaded https://dev-pages.bravesoftware.com/filtering/network-requests.html
5. confirmed there was an image loaded under First-Party Sub Requests when in Trackers & ads blocked (standard) Shields mode
6. clicked on the Brave Shields icon and Advanced View
7. clicked Got it
8. changed Trackers & ads blocked (standard) to Trackers & ads blocked (aggressive)
9. confirmed there was no image shown, and a request for it was blocked
10. confirmed that the image in the Third-Party Sub Requests section didn't display under either (standard) or (aggressive) modes for Shields
11. confirmed the request for the image was blocked

example	example	example	example

[srirambv]

Removing Android label as a follow up issue (#18274) is logged for Android