-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Brave's Shields
setting to brave://settings/content
#12782
Comments
Are you talking about setting a shield setting for 1 domain and then any redirects after will have the same shield setting? |
I'm talking about a 302 temporary redirect here. So let's say if domain X does a 302 redirect to domain Y for authentication/SSO and to view Y in the first place it requires that shields need to be turned off for domain X. In that case how would you achieve that? My organization has some internal sites which require the shields to be disabled for authentication to work correctly as it relies on cross domain cookies. This is not a problem with the sites, and it's just how the authentication works for us internally. It's something like you go to domain X, it checks if you're already authenticated then lets you view the webpage ; and if not it does a 302 temporary redirect to domain Y where you can authenticate yourself. Now this redirection is super quick, and you can't really freeze the browser at domain X easily to change shield settings. I believe this to be a common use-case for several other organizations' internal websites as well. I wouldn't want to relax my global shield settings just for these specific internal sites to work correctly so in this case just relaxing for domain X via some ingress point would help solve this problem. Alternatively, as you mention for 302 redirection from X to Y, if I want to have stricter shield settings for X (more stricter than my global as a override) but less stricter for Y - all kinds of these cases how would you achieve without a proper ingress point? I'm not sure if there's any alternative to achieve this already currently, so feel free to provide alternatives if any! :) |
Updated issue title - this is a great feature request. We may also want to consider allowing all subdomains on a domain (see #5290 for more info) |
Partial workaround on some domains is to enter a request on the domain for a specific file, ex: "sub.domain.com/test.html" - often results in a 404 on the domain and you can then set the shields settings. Not great, but sometimes workable. Even worse, you could set a dns entry (hostfile/routerconfig/etc) to redirect the domain to your desired endpoint to serve yourself up something that would allow you to adjust shield settings. |
Any updates on this for a proper solution? @rebron |
Shields
setting to brave://settings/content
Updated the root post (keeping your original ask; just pre-pending what I believe we want) - how does this sound @ashutoshsaboo? I'm reviewing with team to make sure I have this captured properly before we take a next step |
🍾 |
Verification PASSED on
Clean profile UI and Basic functionality check_PASSED
Add a site
Remove a site
Clean profile, open a site and then add site to shield down block_encountered #26288
Clean profile, add a site to shield down block and then open site_encountered #26288
Clean profile, open a site, disable/enable shields and then change shield settings_PASSED
Upgrade profile Install 1.35.x beta build, open few sites and disable shields and then upgrade to 1.36.x beta build_PASSED
Additional testing
|
Verification
|
Brave | 1.46.83 Chromium: 107.0.5304.68 (Official Build) beta (x86_64) |
---|---|
Revision | a4e93e89d3b3df1be22214603fba846ad0183ca5-refs/branch-heads/5304@{#991} |
OS | macOS Version 11.7.1 (Build 20G918) |
Clean Profile
UI and basic-functionality check - PASSED
- Confirmed that the Shield settings are added in the content settings
brave://settings/content
- Confirmed that Shield status are added in
brave://settings/content/braveShields
- Confirmed that
Shields Down
andShields Up
blocks are added in the Shields status - Confirmed that domains can be added in the
Shields Down
andShields Up
blocks - Confirmed that added domains can be
Edit
ed/Remove
d via Shield status page - Confirmed that Shields are down for the domains which are added in the
Shields Down
blocks - Confirmed that Shields are up for the domains which are added in the
Shields Up
blocks - Confirmed that local Shields settings are updated via
Shields
panel - Confirmed that removing a domain from the
Shields Down
block enables the shield on the site - Confirmed that the Shields state is retained after the browser restarts once the site is added to the
Shields Down
block
Add www.theverge.com
to Shields Down
block
example | example |
---|---|
Remove www.theverge.com
from Shields Down
block
example | example |
---|---|
Clean profile, open a site and add it to Shields Down
- PASSED
- clean profile
1.46.x
- open
nytimes.com
site in an NTP - add
nytimes
toShields Down
block inbrave://settings/content/braveShields
- make sure shield is down for
nytimes.com
- enable the shield manually for the site
nytimes.com
- make sure shield is enabled in
brave://settings/content/braveShields
step 3 | step 4 | step 5 | step 6 |
---|---|---|---|
Clean profile, add a site to Shields Down
block, and then open site - FAIL
- clean profile
1.46.x
- add
nytimes.com
inShields Down
block underbrave://settings/content/braveShields
- open
nytimes.com
in an NTP and ensure that shield is down - remove the blocked site
nytimes.com
frombrave://settings/content/braveShields
- open
nytimes.com
tab and ensure shield is enabled and default shield settings are retained onnytimes.com
- change the global shield settings (
Trackers and ads = Aggressive
,FP= Strict, may break sites
andcookies = Disabled
) - ensured that the updated global shield settings are retained for
nytimes
- add
nytimes
toShields Down
block in content settings - ensured
nytimes
shield is down - enable the shield for
nytimes.com
manually - ensured shield is enabled and default shield settings are retained on
nytimes
(steps 6 shield settings are retained) - change the global shield settings (
Trackers and ads = Standard
,FP= Standard
andcookies = All
) - open
nytimes
, the updated shield settings are not retained for cookies,Allow all cookies
is shown in cookies dropdown instead ofBlock all cookies
step 2 | step 3 | step 4 | step 5 | step 6 | step 7 | step 8 | step 9 | step 10 | step 11 | step 12 | step 13 |
---|---|---|---|---|---|---|---|---|---|---|---|
Encountered:
Clean profile, open a site, disable/enable Shields and then change Shields settings - PASSED
- Clean profile
1.46.x
- Open
cnn.com
- Click on the Shields panel and disable the shield
- Open the content shield setting
brave://settings/content/braveShields
and ensured thatcnn.com
is added toShields Down
list - Open the
Shields
settings forcnn.com
and enable the shield - Open the content shield setting
brave://settings/content/braveShields
and ensured thatcnn.com
is added toShields Up
list - Go to global shield settings
brave://settings/shields
- Change the global shield settings and ensure that the shield settings are retained for
cnn.com
- Open
cnn.com
- Change the local shield settings
- Restart the browser and ensure that the shield settings are retained for
cnn.com
step 3 | step 4 | step 5 | step 6 | step 7 | step 8 | step 9 | steps 10 & 11 |
---|---|---|---|---|---|---|---|
Upgraded Profile - PASSED
Install 1.43.x
beta build, open a few sites, disable Shields, then upgrade to 1.46.x
beta build
- Clean profile
1.43.x
beta build - Open
cnn.com
andnytimes.com
- Open the Shields panel and disable the shield
- Upgrade the profile to
1.46.x
beta build - Open the
brave://settings/content/braveShields
- Ensured that the sites
cnn.com
andnytimes.com
are added to theShields Down
list - Open
cnn.com
andnytimes.com
sites and enable the shields - Open the
brave://settings/content/braveShields
- Ensured that the sites
cnn.com
andnytimes.com
are added to theShields Up
list - Change the global shields settings via
brave://settings/shields
- Ensure that the global shield settings are retained for the sites
cnn.com
andnytimes.com
- Change the local Shields settings for the sites and ensured site settings are retained
1.43.x
cnn.com |
nytimes.com |
---|---|
1.46.83
step 6 | step 7a | step 7b | step 9 | step 10 | step 11a | step 11b | step 12a | step 12b |
---|---|---|---|---|---|---|---|---|
Additional Testing - PASSED
- Change local Shields settings for cookies and restart the browser and ensured that cookies settings are retained
- Change local Shields settings for trackers and ads and restart the browser and ensured that trackers and ads settings are retained
- Change local Shields settings for fingerprint and restart the browser and ensured that fingerprint settings are retained
- Verified that existing/updated global shield settings are retained for the opened sites
- Confirmed that updated local/global shield settings are retained in an upgraded profile
Verification passed on
Clean ProfileUI and basic-functionality check -
|
Description (edited by @bsclifton)
brave://settings/content currently shows Permissions and Content settings.
We should also show Shield settings:
up
/down
orenabled
/disabled
)true
/false
)When showing these, folks would be able to go to a details page for each type of shield setting. For example:
On that page, folks could view / edit / manually add a domain (including wildcard). Something that looks like this (this is an example taken from
Pop-ups and redirects
)Excluded scope
Allow all cookies
/Block cross-site cookies
/Block all cookies
). We may update brave://settings/cookies to cover the Shields's cookie settingstrue
/false
). We may update brave://settings/content/javascript to cover the Shield'sBlock scripts
settingAggressively block trackers & ads
,Block trackers & ads
,Allow all trackers & ads
) and Fingerprinting (Allow fingerprinting
/Block fingerprinting
/Aggressively block fingerprinting
) - we may want to treat this specially (ex: use ASK for standard mode instead of DEFAULT. That means we can add them to settings, but only after that change is made)Original issue description
Currently on brave the only way to change site specific shield settings is by going to the domain, and going over the shield icon and changing to desired domain-level privacy settings. However if a domain X does a temporary 302 redirect automatically to Y, then with such a setting users can only change privacy settings for Y (because X would only be momentarily be there in the browser address bar). Similar to site settings page URL pattern -
brave://settings/content/siteDetails?site=https%3A%2F%2Fgithub.com
- can we include a feature to modify brave domain level shield settings also over there? That'd be an additional ingress point, which can be very easily accessed here -brave://settings/content/siteDetails?site=<HTML encoded domain url>
.Or is there any alternative currently to modify domain level shield settings for the domain X in the above use-case (I couldn't find one)?
The text was updated successfully, but these errors were encountered: