FAQ and/or Tracker Bug (white-list)

Description of the issue:

On the FAQ pages under the question: ‘ Are all ads blocked or can users allow some or all?

"

The response is “ Ads and trackers are blocked by default. You can allow ads and trackers in the preferences panel.

As the following white-list knowingly exists in the code, that would make the above statement misleading by means of omission.

“TrackingProtectionService::TrackingProtectionService()
: tracking_protection_client_(new CTPParser()),
// See comment in tracking_protection_service.h for white_list_
white_list_({
“connect DOT facebook DOT net”,
“connect DOT facebook DOT com”,
“staticxx DOT facebook DOT com”,
“www DOT facebook DOT com”,
“scontent DOT xx DOT fbcdn DOT net”,
“pbs DOT twimg DOT com”,
“scontent-sjc2-1 DOT xx DOT fbcdn DOT net”,
“platform DOT twitter DOT com”,
“syndication DOT twitter DOT com”,
“cdn DOT syndication DOT twimg DOT com”
}),
weak_factory_(this) {
DETACH_FROM_SEQUENCE(sequence_checker_);
}”

Steps to Reproduce (add as many as necessary): 1. 2. 3.

  1. Go to FAQ page and find above mentioned Q&A:
    https://brave.com/faq/

  2. Go too Gethub showing snip of current code and notes:
    https://github.com/brave/brave-core/blob/master/components/brave_shields/browser/tracking_protection_service.cc#L33
    https://github.com/brave/brave-browser/issues/1108

3)Conclude that these two facts contradict, if end user, attempt to contain anger that you were mislead and the excuse is poor.

Actual Result (gifs and screenshots are welcome!):

Being tracked/mislead

Expected result:

Not being tracked/not being mislead

Reproduces how often:

Continuously

Brave Version(about:brave):

Current Live

Reproducible on current live release (yes/no):

Yes

Additional Information:

*1 New user 4 link limit to post. Edited links in example code to workaround.

If there is a hotfix for this, or something I as an end user can do too disable this feature, delete the white-list code, it wouldn’t be an issue. I don’t see anyway of doing that. If there is, please someone tell me.
Doesn’t matter if it is a ‘temporary’ fix so websites that depend on facebook & twitter plug-in functions will work. I would sooner not visit or use the website in question. Or, just not be lied too.

:wink:

This got moved to feedback despite it being a support/bug report. Maybe it is the format, kinda confusing since I followed the format direction from Brave to the letter. If I post in Support section again, directly requesting a way to remove, disable, all around fix the code, would that count as a support request enough to stay over there?

I have seen all that. It doesn’t change what my point is. I’m not looking for a deflection, I want a way to remove this from my Brave Experience. Is there a way to do that. No matter how inconsequential the Brave team believes these white-lists are, it is still allowing an unwanted connection to 3rd parties. If a website doesn’t function when blocked, I choose to unblock it, or not use it. This removes the choice.

Please track this issue for more info on what is being done.

Any kind of healthy discussion or feedback should go on this community thread so that team can review it.

I’ll keep this thread open for discussion

QA Engineer for Brave, cool, you can answer my very strait forward question.

Is there currently a way for the end user to remove this from their brave browser: Yes, or No?

Brave will figure out the in the future stuff. I want to know at this exact moment. I am unable to believe you are unable to answer that.

Not an the attack, I just want to know

No. Currently users cant remove it by themselves.

Thank you for your direct answer.

My only feedback on the subject for Brave Team, is that I myself see this as an important issue; So much so, that is is likely too prompt a reevaluation of my browser. I am not interested in being part of another, things that couldn’t happened just happened despite us saying it couldn’t, story. So I will be following Braves updates closely while I’m wading in on my own thoughts.

So this means that any other website out there that may also implement the same process as these 2 major services will have have to be added to this list in Brave. After all, one can not favour Twiter and Facebook over other sites which may implore similar means.

I have a follow up question.
When siteA requests to connect.facebook.com to download the sdk or any other .js file, does the request just go through and I download the js?
Also, since I am pinging connect.facebook, that means I am sending a TCIP packet of some sort correct? Would it just so happen that packet has my IP address, like how TCIP tends to work?

These are currently my two big concerns with this issue.

It would be a normal page request to download the sdk or any other .js files and since the request goes to the server it would just be a normal TCP request with the requester IP address.

For the Brave Team, this is where I would argue that this is a tracking issue.
Even though the 3rd party isn’t told from which website the request is coming from ( I believe that is the case,) if a user has a static IP, that becomes an identifiable data point. It may be little information: User IP is browsing a site that uses our plug in at time x, another request came that same day at time b. Vague or Not, a partial browsing profile can be obtained by collection of these data points. If a user were to slip up and visit or sign in at a site owned by that third party through another browser on the same system, or even network, that user is now connected to that IP, which has a browsing history that can now be combined with what ever history is held by the third party regarding that user.

This is still tracking, it might not be a “tracker” but it still gives a third party avenues to function in the same vain. Data is data, and Brave claims the user is supposed to be the ultimate controller of their own data. This white-list circumvents that for the convenience of growth. If Brave is willing to add unwarranted risk, no matter how minute, for the purposes to growing their user base and by extension their business, there is no sensible argument to say Brave would not do so in larger ways later for company gain.

This is a trust breaking or keeping moment for the user base who takes even the small security risks very seriously. I hope the team sees it as something important that needs to change sooner rather than later. As it is, I know of about 6 people that claim to have already dropped brave because of this, all early adopters.

I myself, am looking into how difficult it would be to edit that file in the open source to delete that terrible list and compile your code without it, turning off updates on install. That is an exceptional amount of work for me, considering this, to my understanding, could be made optional by hot-fix of a few lines of code. Even if it was real basic, and I had to change a 1 to 0 in a single text doc, in files. At least then it would be optional for those who truly care. If I can’t manage to figure out the compiling process, or can’t convince Brave to make the change. It’s a deal breaker for me.

1 Like

That’s a valid argument that you make. This is being discussed internally and a fix would be delivered soon. The issue that I linked above would be the place to check for updates.

1 Like

Worth a read https://brave.com/script-blocking-exceptions-update/

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.