Clarify text for "Remove social media buttons" feature in new options page

[greiner]

Background

We're planning to allow users to easily opt-in to a feature that removes social media buttons. For that we'll be using Fanboy's Social Blocking List which, however, does more than that (e.g. hiding plain links to social media profiles) which is why we should change to feature description to reflect that.

The reason for bringing this up is due to this filter list causing unexpected behavior with popular projects such as FontAwesome (see ​GitHub discussion).

What to change

So far I see two options:

• Accurately reflect the behavior of Fanboy's Social Blocking List in the feature text for "Remove social media buttons".
• Swap out the filter list for the "Remove social media buttons" feature or use a variant of Fanboy's Social Blocking List that only blocks/hides official social media widgets.

[gameguy43]

from:
​https://github.com/FortAwesome/Font-Awesome/issues/1799#issuecomment-103689897

ThomasGreiner suggested this new copy (I think this is intended to be solution #1 in the bulleted list given in the "What to Change"):

---

Disable Social Media Buttons

Adblock Plus can disable social media buttons on websites, ensuring that social networks can’t create a profile based on the websites you visit.

Buttons used to share content on social media platforms such as Facebook, Twitter, Google Plus and others are placed on almost every website that you visit. Even if you don't click them, these buttons send requests to the servers of the social network which use information to create a profile based on your browsing habits.

---

Fanboy Social's list includes bootstrap-social buttons and font-awesome icons. These are commonly used to build share buttons and social login buttons "by hand." By "by hand" I mean these are not the fancy JS/iframe widgets that track you...these are vanilla hyperlinks that send you to the social media website if and only if you click on them.

That means that fanboy social, in many cases, blocks two types of things that are not covered by either the current copy or this new copy:

• non-tracking social share buttons that use font-awesome icons
• social login buttons. which are /always/ non-tracking, AFAIK

That second point has a huge effect. For websites, like mine, where social login is the only login method, the whole experience is fundamentally broken for users with fanboy social enabled.

Given the copy that people saw when they enabled fanboy social, this is a bug. They were not told that their ability to log into websites would be removed. They were only told share buttons would disappear.

I've tried emailing the list maintainers (​easylist.subscription@gmail.com) to ask them to remove font awesome and bootstrap-social from the list. They chose not to.

I strongly suggest solution #2 outlined by you above. I claim that vanilla "a href" tags that let people use facebook login (that are styled to include the facebook logo) are for the average person completely out of the scope of things they might imagine could possible be silently removed from the page by their ad blocker.

Instead, they're likely to just assume the site is broken. As my users have.

[gameguy43]

more info on bootstrap-social, fwiw:

​https://lipis.github.io/bootstrap-social/
​https://github.com/lipis/bootstrap-social/issues/50

pretty commonly used for login buttons on modern websites.

[greiner]

Thanks for the great summary!

Replying to gameguy43:

ThomasGreiner suggested this new copy (I think this is intended to be solution #1 in the bulleted list given in the "What to Change"):

The text that you mentioned is the one we currently have in the new version of our options page which is still under development. Therefore solution (1) would be to come up with some new text that would replace the existing one.

I strongly suggest solution #2 outlined by you above. I claim that vanilla "a href" tags that let people use facebook login (that are styled to include the facebook logo) are for the average person completely out of the scope of things they might imagine could possible be silently removed from the page by their ad blocker.

The question is whether it's already sufficient to change the text to clarify that such elements will also be hidden. If it isn't sufficient to change the text then the question becomes what most people expect it to do and how to get a filter list that reflects those expectations.

What was EasyList's response to your email?

[gameguy43]

Replying to greiner:

The question is whether it's already sufficient to change the text to clarify that such elements will also be hidden. If it isn't sufficient to change the text then the question becomes what most people expect it to do and how to get a filter list that reflects those expectations.

IMO, any text describing this block list, to avoid confusion, would have to say something like "WARNING: THIS WILL REMOVE YOUR ABILITY TO LOG IN TO SOME WEBSITES."

As background, here are some examples of confused emails I received from my users (before using a classname change on my bootstrap-social and font-awesome implementations to work around the fanboy social blocks):

---

I upgraded for the $29 offer yesterday and now I can access the full site from my phone (where I upgraded) but I could not access the full site from my laptop.

Can you please check what I need to do to get the full access from my laptop? I think I am logging in to both devices using the same account.

---

Why am i not able to login with my gmail account? I have already paid for this, and now i cant login???..

---

In both cases, the user had purchased access to my online info product from a browser with fanboy-social off, then moved to a browser with fanboy-social on and were surprised to find that they could not log in to the site anymore. (And they assumed it was a bug with my website).

What was EasyList's response to your email?

MonztA said (snippet):

---

Regarding Font Awesome icons: we had that discussion berfore, see ​https://forums.lanik.us/viewtopic.php?f=64&t=17545&p=65261

Regarding login functionality: you're right, this should never be removed by that list. What's the page where this is happening?

---

He then proceeded to un-block login buttons on the individual example sites I gave. I explained that I was advocating a general removal of bootstrap-social from the block list. Then he (she? I shouldn't assume!) said "I'll ask the other authors what they think about it."

That's the last I heard. That was 6/1/15. Just asked for an update, and included links to this page and the thread on the fontawesome github.

[gameguy43]

I just want to make sure I'm being very clear here:

All of the above, with the example confused emails from my users, is my argument for the claim that it is /not/ sufficient to change the text, and we should move on to isolating what people expected the list to do and adjusting the list to fit those expectations. :)

And my vote for what people expect the list to do: just what you imply in the original ticket: block only /official/ social media widgets. In other words, block only /tracking/ social media widgets. If the list is adjusted (or a new list is used) to do this, the copy you've proposed looks good to me :) Perhaps with an additional note that /some/ social media sharing buttons will /not/ be blocked, because they are not the kind that track you.

[fanboy]

Cheers for the Cc;

Often websites are using the font-awesome div's to wrap around social objects/social buttons/social images, which imo should be blocked (they are social elements after all). If you have a large twitter icon wrapped in fontawesome div(s), should or shouldn't it be blocked? All the user sees is the twitter social element, they wouldn't care how the website developer implemented it.

Making all the font-awesome stuff site-specific would just make the list much larger and management harder and water down the list. Which I could already then see websites-devs wanting whitelisting for any outer social divs to show the fontawesome stuff.

Keep in mind I whitelisted common fontawesome devel (jsfiddler/github/Anymore I need to add?) first-party stuff was fixed when it was reported.

My thoughts anyways.

[greiner]

I do see both pros and cons behind hiding all things social media:

• It ensures the cleanest experience without leftover fragments sticking around creating confusion (e.g. Facebook icons or some text referring to a Like button that was blocked).

• It breaks certain functionalities that don't send any data to social networks (e.g. ​plain login buttons or ​static links on my homepage to my social media profiles).

In the end it sounds like both approaches lead to a somewhat broken user experience so the question is which approach provides the most value to the user. I'll see what I can do to find some indicators that might help determining that.

@fanboy Thanks for helping out in this discussion.

The current approach seems to be blocking and hiding by default and unhiding where necessary. What about instead blocking by default and hiding where necessary? I could imagine that this might be a good compromise if it's doable.

[fanboy]

Or, legitimate uses of social div elements (fontawesome etc) such as a sign-in's or signup's to websites. Which we already fix situations, where it would hinder the ability of user to sign in.

[fanboy]

I fixed the appspot.com links, but the static social stuff on greinr.com seems fine to block here.

[fanboy]

From: ​https://lipis.github.io/bootstrap-social/

  <a class="btn btn-social-icon btn-twitter">
    <span class="fa fa-twitter"></span>
  </a>

  <a class="btn btn-block btn-social btn-twitter">
    <span class="fa fa-twitter"></span> Sign in with Twitter
  </a>

Might be happier if they removed the class social suggestion's of using the

btn-twitter
btn-facebook
btn-[....]
btn-social-icon

Then we can simply remove the fa-[elements] from the social list.

[fanboy]

I'm awaiting there response for a compromise: ​https://github.com/FortAwesome/Font-Awesome/issues/1799

While it would be relatively easy to remove the fontawesome "fa-[...]" from the social list to make it more specific. Its also wrapped in other generic social elements, which should be changed to avoid being hit by the social list.

I guess we could remove the fa-[...] elements regardless? then wait on font awesome plans/suggestions.

[fanboy]

​https://github.com/easylist/easylist/commit/74b092d8aadfe1a583956eaecd4a03347237afc2

Removed the font-awesome generic filters, going forward it'll be made specific. Havent heard anything from the Font Awesome guys as of yet.

[greiner]

Replying to fanboy:

​https://github.com/easylist/easylist/commit/74b092d8aadfe1a583956eaecd4a03347237afc2

Removed the font-awesome generic filters, going forward it'll be made specific. Havent heard anything from the Font Awesome guys as of yet.

Cool, thanks! I noticed that there are a couple of element hiding filters specifically for logins in there (e.g. ###getSocialLoginBox, ##.oneall_social_login, ##.social-login). Do you think those are safe?

[arthur]

@greiner
Removed ​https://github.com/easylist/easylist/commit/88318051ce4313e2b97e1644f199aa86bbfe0ae3

[greiner]

I'm closing this ticket since there have been no more complaints about this since those changes were made. Thanks again to everyone for the help.