Look at this website. This isn’t allowing to acces the webpage with ad blocker turned on. Is there is anything that we could do?
That’s so annoying
Please be sure to fill out the templates that exist on the site. When you created this it should’ve had something to fill out. At the bare minimum we need to know the link for the website that you were experiencing this issue at.
And by template, i mean where you should have seen this message and the requested information when you went to create this Topic:
Troubleshooting technical issues is much easier when both the user and support agent practice clear communication. For this reason, we have provided the template below for you to fill out with information about your issue. Please provide as much detail as possible so we can most efficiently resolve your problem.
Delete the any text above the line separator below before posting
Description of the issue:
Exact URL of the website in question:
Screenshot of the ad as it appears in Brave Did the issue present with default Shields settings ? (yes/no)
Does the site function as expected when Shields are turned off?
Is there a specific Shields configuration that causes the site to break? If so, tell us that configuration. (yes/no):
Does the site work as expected when using Chrome?
Brave version (check About Brave):
brave:master ← brave:chp-anti
opened 05:05AM - 29 Jul 22 UTC
Tested in Brave Nightly.
Fixes reported issue on https://community.brave.com/… t/some-sites-are-specifically-designed-to-detect-ad-blocking-system-by-brave/418087
resolved on uBO with `||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$xmlhttprequest,redirect-rule=googlesyndication_adsbygoogle.js:5,domain=~zipextractor.app`
WIll fix the issue on the site. give it 24hrs for the update to roll out.
chh_68
July 29, 2022, 5:14am
5
It is constant fight between adblockers and those who serve ads.
Next time if it happens. Make sure to tag fanboyz. He will make sure to make changes in brave adblocker to solve the problem.
Would avoid posting clickable links to the sites also (to avoid referrer checks). Just wrap in a a code post https://www.samplesite.com.
chh_68
August 4, 2022, 4:23pm
7
Can brave then improve it’s anti-referrer mechanism. As far as I know, it strips some elements from the referrer to boost user privacy, but not all.
The http header still contains data from which site you are coming from.https://news.ycombinator.com/item?id=31337567 . If you click on the link (jwz.org ) from hacker news, the site owner trolls users from hacker news with a NSFW image (open the link on your own risk).
For brave (2nd video):-
For librewolf, when cross-orgin referrers is turned ON (3rd video):-
@pes
pes
August 4, 2022, 4:59pm
8
Hi! We actually used to strip the entire referrer on cross origin navigations, but ended up breaking a non-trivial number of sites and login flows, so changed to the current policy for compatibility reasons. Since we already have to report the origin header (again for compatibility reasons), including an origin-only referrer ends up being a compat with with no additional privacy harm (since the two headers effectively mirror each other).
The below post has more details
In order to stay one step ahead of online trackers, Brave regularly releases new privacy features and improvements. This post discusses three recent changes in Brave that each help make the web a more privacy, and person, respecting platform.
Hope this helps explain the current policy and trade offs
1 Like
chh_68
August 5, 2022, 5:14am
9
Ok
(My opinion) But, I feel more ‘secure’, ‘safer’, private with Librewolf with anti cross-origin referrer enabled.
chh_68
August 6, 2022, 7:53am
10
As a user, I would like if there was brave://flag to duplicate librewolf feature (or bring back the old brave referrer policy, with or without exceptions.).
“In addition, cross-origin requests from a .onion service have an empty Referer header and a null Origin header just like the Tor Browser” (.https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#modified-features-and-functionality )
opened 05:29PM - 29 Apr 20 UTC
Referrers [leak information](https://blog.mozilla.org/security/2018/01/31/preven… ting-data-leaks-by-stripping-path-information-in-http-referrers/) about a user's browsing activity cross-site. Browser vendors have deployed a variety of mitigations to this vulnerability, ranging from spoofing the referrer to be same-origin to changing the default referrer policy.
## Current status (please correct or add to this):
Last update: 2021-04-12
### Firefox
* Referrers [default](https://bugzilla.mozilla.org/show_bug.cgi?id=1589074) to `strict-origin-when-cross-origin`.
* Trim `document.referrer` down to eTLD+1 when we [observe tokens](https://bugzilla.mozilla.org/show_bug.cgi?id=1568341) that can be used to circumvent our cross-site tracking protections.
### Chrome
Referrers [default](https://chromestatus.com/feature/6251880185331712) to `strict-origin-when-cross-origin`.
### Safari
* All cross-site subresource HTTP referrers [are trimmed](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/) to the page's origin. This matches `strict-origin-when-cross-origin`, but sites can *not* override this setting.
* Trim all cross-site `document.referrer` to the page's origin.
* Trim `document.referrer` to eTLD+1 if the referrer has link decoration and the user was navigated from a domain classified by ITP. See [ITP 2.3](https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/).
### Brave
From [this doc](https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#modified-features-and-functionality): Referrer values default to `strict-origin-when-cross-origin` and can only be tightened via referrer policy, not weakened.
### Edge
Referrers [default](https://docs.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes) to `strict-origin-when-cross-origin`.
## Future path
At the very least it seems like we can align on defaulting to `strict-origin-when-cross-origin` (see also: https://github.com/w3c/webappsec-referrer-policy/pull/125). But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?
* Do we expect to see a lot of breakage?
* Are there legitimate uses of full cross-site referrers that we want to continue to support?
* Can we somehow prevent abuse but still allow some parties to receive full referrer?
opened 05:29PM - 29 Apr 20 UTC
Referrers [leak information](https://blog.mozilla.org/security/2018/01/31/preven… ting-data-leaks-by-stripping-path-information-in-http-referrers/) about a user's browsing activity cross-site. Browser vendors have deployed a variety of mitigations to this vulnerability, ranging from spoofing the referrer to be same-origin to changing the default referrer policy.
## Current status (please correct or add to this):
Last update: 2021-04-12
### Firefox
* Referrers [default](https://bugzilla.mozilla.org/show_bug.cgi?id=1589074) to `strict-origin-when-cross-origin`.
* Trim `document.referrer` down to eTLD+1 when we [observe tokens](https://bugzilla.mozilla.org/show_bug.cgi?id=1568341) that can be used to circumvent our cross-site tracking protections.
### Chrome
Referrers [default](https://chromestatus.com/feature/6251880185331712) to `strict-origin-when-cross-origin`.
### Safari
* All cross-site subresource HTTP referrers [are trimmed](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/) to the page's origin. This matches `strict-origin-when-cross-origin`, but sites can *not* override this setting.
* Trim all cross-site `document.referrer` to the page's origin.
* Trim `document.referrer` to eTLD+1 if the referrer has link decoration and the user was navigated from a domain classified by ITP. See [ITP 2.3](https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/).
### Brave
From [this doc](https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#modified-features-and-functionality): Referrer values default to `strict-origin-when-cross-origin` and can only be tightened via referrer policy, not weakened.
### Edge
Referrers [default](https://docs.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes) to `strict-origin-when-cross-origin`.
## Future path
At the very least it seems like we can align on defaulting to `strict-origin-when-cross-origin` (see also: https://github.com/w3c/webappsec-referrer-policy/pull/125). But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?
* Do we expect to see a lot of breakage?
* Are there legitimate uses of full cross-site referrers that we want to continue to support?
* Can we somehow prevent abuse but still allow some parties to receive full referrer?
{
"whitelist": [
{
"<all_urls>": [
"https://use.typekit.net/*",
"https://api.geetest.com/*",
"https://cloud.typography.com/*",
"https://*.vimeocdn.com/*",
"https://*.wix.com/*",
"https://player.vimeo.com/*",
"https://*.gigya.com/*",
"https://*.spreedly.com/*",
"https://*.locationiq.org/*",
"https://*.ccavenue.com/*",
"https://apis.google.com/*",
"https://*.googleapis.com/*",
"https://*.postcodeanywhere.co.uk/*",
"https://*.paymentjs.firstdata.com/*",
"https://pay.google.com/*",
"https://*.mapbox.com/*",
show original
I will stop my discussion here.
system
September 5, 2022, 7:53am
11
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
