Don’t Sell Out Your Users

As a profession, we spend a lot of time thinking of the best ways to protect our users’ data and their privacy. In fact, most sites have exhaustive Privacy Policies detailing what information they collect and what they may do with it. That’s why I find it bizarre that many of these same sites have chosen to hand over their users’ browsing habits to third parties such as Twitter, Facebook, and Google without considering the implications.

You see, any time you add third party widget code—a “tweet this” button, for example—a request is made to that third party’s server in order to retrieve the required snippet of JavaScript. When that request is sent, information is sent to the server in the form of headers and (as is often the case) cookies. The headers usually contains general information about the browser being used, referring page, etc. and don’t generally pose much of a threat, but cookies are another matter altogether.

When a user visits a site—say, Facebook—she is typically cookied by that site. Browsers give a user some modicum of control over what sites can set a cookie, so she could have opted out of receiving Facebook’s cookie, but most users don’t know enough to or don’t know how to opt-out of cookies. Once that cookie is in place, it is directly associated with a specific domain (e.g. facebook.com or one of its hostnames). As long as that cookie is active, it remains on the users’ computer and accompanies any requests sent to the specifed domain. That means when this user visits a web page that includes a Facebook-supplied “Like” button, for example, Facebook can identify who she is (via the cookie) and what she’s looking at (via the request headers) without her even clicking the “Like” button. As she moves from page to page across the web, Facebook—or Google, or Twitter, or Pinterest, or AddThis, or any other service with decent distribution of its widgets—can effectively track her movement and build up a profile of her interests or browsing habits without her even knowing.

Now I’m pretty certain none of these companies started out wanting to track their users in such a manner, nor am I convinced many of them actively are (though I would not put it past Google or Facebook), but I think you can agree there is certainly potential for abuse here.

So what are we to do? Including buttons that easily allow our users to share content on their favorite social networks is extremely helpful for attracting more eyeballs to our content; it would be a shame to lose that opportunity. I agree, but just because a company offers a widget to make it simple for you to set up the button doesn’t mean you need to use it. Thankfully it isn’t really that difficult to host “share” buttons yourself, you just have to know how to do it.

Below is simplification of the current markup we use to achieve this in our blog. At present, we’ve chosen to support only four social networks: Twitter, Facebook, LinkedIn, and Google Plus.

To trigger a share via Twitter, we use Twitter’s “tweet intent” URL: https://twitter.com/intent/tweet. We then supply several key-value pairs as part of the query string:

1. The referer (our page) as original-referer;
2. Any text we want included in the tweet—e.g. the title of the page—as text (n.b. be sure to replace spaces with “+”);
3. the page to share as url; and
4. (optionally) a Twitter account handle you’d like the tweet to appear “via”.

Facebook seems less complicated, but it’s really not. Sure, the URL is simple—http://www.facebook.com/sharer.php with the URL supplied as u in the query string—but to control what Facebook displays when your page is shared, you need to add some meta tags that describe the page as an OpenGraph object. Here’s a sample from this blog post:

This set of meta tags establishes this post as an “article” with a title, description, and a canonical URL, which ensures it is displayed in Facebook properly. Facebook maintains pretty decent documentation on OpenGraph and the pieces they support and they also have a handy testing tool you can use to see if everything is making it to them properly. (It’s also worth noting that, using the debugger, you can also force Facebook to update any previously cached content from a given URL.)

Rounding out the pack are LinkedIn and Google Plus. Both use OpenGraph like Facebook does, but LinkedIn only supports a subset of OpenGraph tags—og:title, og:url, and og:image (though only if the image is wider than 150px and taller than 80px)—and Google Plus would prefer you use the ridiculously convoluted attributes defined by schema.org, but will fall back to OpenGraph or basic meta title and description tags if necessary.

Now that the HTML links are working properly (you did test them, right?), you need some buttons. There are tons of options out there, but if you like the ones we are using, you can download a layered PSD from us and tweak to your heart’s content. If, however, you want to go image-less, you could use one of the many great icon fonts out there (like IcoMoon). Whatever you do, just don’t link to images on a 3rd party site because then you are falling back into the same trap again because image requests also pass along headers and cookies.

And there you have it: a fully-funcitonal set of sharing tools that requires no JavaScript and doesn’t sacrifice your users’ privacy.

If you want to take it a step further, it’s pretty easy to add a tiny bit of JavaScript to make the links trigger a popup when there’s enough real estate (after all, you probably don’t want to do that on mobile). Here’s the jQuery code we currently use on this site for that purpose:

As you can see, with just a little bit of effort (and maybe a bit of research), it’s easy to protect your users. Please consider doing it on your own sites.