Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Replace tracking social buttons with versions that don't track you #312

Closed
PeterJensen opened this issue Jan 25, 2016 · 8 comments
Closed
Assignees

Comments

@PeterJensen
Copy link

On TMZ there seems to be a missing FB like button. See attached screenshot:
tmz

@bgiesing
Copy link

@PeterJensen This and the FOX News one is because it's blocking third-party cookies (also means Disqus (and other commenting systems), Social Buttons (Facebook, Twitter, G+), etc. also get blocked.)

The only solution is to disable it for that site by right-clicking the tab.

@diracdeltas
Copy link
Member

Yep, this is a known side-effect of blocking third party resources. Test site: https://sharemenot.cs.washington.edu/Test%20Installation.shtml

Long term, we could replace those buttons with versions that don't track you, like Privacy Badger / ShareMeNot.

@bbondy bbondy changed the title Missing Facebook Like button? Replace tracking social buttons with versions that don't track you Jan 25, 2016
@bbondy
Copy link
Member

bbondy commented Jan 25, 2016

Updated title.

@lukemulks
Copy link
Collaborator

FYI - I'm rolling this issue into a parent initiative that I'm working on for social media network ads (w/in networks, and in embedded widgets and SDKs in the larger Web) - Tracking that initiative here for reference: #7678

Note: The focus for the initiative will be on stripping tracking wherever possible, while retaining functionality, but we may ultimately resort to button replacement if testing proves that is the only solution that will fully cover off.

@lukemulks lukemulks self-assigned this Apr 1, 2017
@lukemulks
Copy link
Collaborator

I've investigated this issue following the release of v0.14.0, and am no longer observing the issue as reported. Social networking buttons are displaying and clicking through as expected for both foxnews.com and tmz.com.

I've also been checking social media button functionality with Brave Shields activated across several other domains, and am observing consistency with what has been observed for foxnews.com and tmz.com.

  • Part of the cause is that FB/Twitter and other 3p social widgets have updated the way that they've functioned after ad blocking support increased.

  • Another reason this is less of an issue (visually) is that FB in particular has had several updates to the way they handle social tracking between when this original issue was opened, and now.

Screenshots of TMZ.com with the social media buttons displaying and functioning w/Shields up as expected.

TMZ: Shields up, showing FB tracking blocked and buttons displaying:
chrome-social-buttons-03312017-tmz

TMZ: Shields up, showing post-click share behavior for FB and Twitter share buttons:
chrome-social-buttons-03312017-tmz-onclick

Foxnews.com HP, displaying the social buttons w/Shields up and tabs that load on click to share:
chrome-social-buttons-03312017-foxnews-hp

Foxnews Politics section, displaying social buttons w/Shields up and share widget (post-click):
chrome-social-buttons-03312017-foxnews

Additionally, I dug into the Facebook ad and marketing API documentation, and applied the custom filters to block tracking, remarketing and audience tracking events that take place with the current FB embeds (outside of Facebook.com):

There are a couple of noteworthy items:

  • Some publishers may be running functional, but deprecated social widgets. I tried to apply the filters above to be flexible enough to cover those cases. If any instance arise, are discovered or reported, we'll handle them on a case by case basis.

  • There may be some instances where the social widgets are applying a form of tracking that is hidden within the core functionality of the widget, or applied using experimental or veiled to bypass traditional measures for observing in network traffic (switching to protocols not exposed in dev tools, making requests from disk cache, etc.). While we hunt for these things, if they are discovered we'll also handle case by case.

I'm going to close the issue at this point, but can open a new one and reference this issue if needed in the future.

@diracdeltas
Copy link
Member

reopening this since we may want to implement sharemenot after all

@diracdeltas diracdeltas reopened this Apr 4, 2018
@tildelowengrimm tildelowengrimm added this to the 0.24.x (Nightly Channel) milestone Apr 4, 2018
@tildelowengrimm tildelowengrimm added post-v1 We don't expect to be able to resolve this before releasing v1.0 with Brave Core (instead of Muon). priority/P3 Major loss of function. labels May 15, 2018
@alexwykoff alexwykoff modified the milestones: 0.24.x (Nightly Channel), Backlog (Prioritized) Jun 12, 2018
@alexwykoff
Copy link
Contributor

@lukemulks please migrate to the Brave core repos as needed 😄

@tildelowengrimm
Copy link

Moving to the new codebase: brave/brave-browser#534

@bsclifton bsclifton removed this from the Backlog (Prioritized) milestone Jul 13, 2018
@bsclifton bsclifton added wontfix and removed wontfix labels Jul 13, 2018
@bsclifton bsclifton added open-in-brave-core and removed post-v1 We don't expect to be able to resolve this before releasing v1.0 with Brave Core (instead of Muon). labels Aug 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants