
Why to use Twitter, Facebook and Google Plus share links and not buttons - g-garron
http://www.garron.me/en/blog/provide-share-buttons-without-exposing-your-visitors.html
======
qxcv
If you still like the idea of buttons, but don't want to give up using the
vendor-supplied buttons themselves, you can use the "two clicks for more
privacy" jQuery plugin[0], which only loads the actual button when the user
enables it by clicking a greyed-out placeholder.

[0]
[http://panzi.github.io/SocialSharePrivacy/](http://panzi.github.io/SocialSharePrivacy/)

~~~
justadude
I'm also partial to Socialite JS [0] - it provides a similar mechanism, the
one I use is the hover option, this negates the need for clicking which I
think would confuse some users.

[0] [http://socialitejs.com/](http://socialitejs.com/)

------
ChrisNorstrom
I use WidgetBlock for chrome and since then sites have been blazing fast. I
mean it really helps to not have all those stupid share widgets load. It does
however break all the share buttons.

So using links instead of the widget codes is better for your site
(performance wise), privacy wise, and it degrades gracefully when people like
me use Widget Blockers.

------
packetslave
I don't have an opinion on the core of the article, but this bit at the end is
not the best advice from a user experience standpoint.

"And I am seriously thinking into serve my own copy of Twitter Bootstrap
scripts instead of serving them from the Google Network."

The point of using a CDN for common js/css is to serve it as close to your
users as possible as well as increase the change that they already have it in
their browser cache. Hosting it yourself just means your users have to make
more round-trips to wherever in the world your server lives.

BTW, Google Hosted Libraries doesn't currently include Twitter Bootstrap.
You're using NetDNA's BootstrapCDN.

~~~
g-garron
Sorry, you are right. it is NetDNA's

From the performance point of view is better to use that public CDN. But they
have control over the javascript, and they may change it at anytime. Maybe too
paranoid, so just thinking about it.

~~~
lazerwalker
If you're _that_ paranoid, it probably wouldn't be hard to set up a simple
cron job that downloads the CDN's copy and compares its hash against a known
local copy on a regular interval.

~~~
e12e
There's no guarantee that the cron script and the end user would be getting
the same data. So that's not really much help.

------
MJR
Facebook has stated that the sharer.php is deprecated.
[https://developers.facebook.com/bugs/252983554810810/](https://developers.facebook.com/bugs/252983554810810/)

It appears to have an unclear lifespan. While it has been fully replaced by
the Feed Dialog, it's still working now and is used all over the internet. I
can see the case where it won't see any further development or features, but
it's a tough call whether or not to incorporate the deprecated method or
accept possible risks of the current methods - Like button or Feed Dialog.

~~~
proexploit
The bug you referenced is from over a year ago and in fact the feature is no
longer deprecated. The documentation page [1] used to highlight the deprecated
status but has recently been updated and any mentions of deprecation have been
removed.

[1]
[https://developers.facebook.com/docs/reference/plugins/share...](https://developers.facebook.com/docs/reference/plugins/share-
links/)

~~~
MJR
Interesting, thanks for the link. When I implemented a share in an app
recently, this wasn't an option. I wish there was more version information on
the page. The only reference to a timestamp now is that this page was updated
a week ago.

------
jstsch
We've been using the same method for quote some time now. Not just for privacy
purposes, but also performance-wise all these scripts and iframes are a bit
much. Demo and code at
[http://simpleshare.schuttelaar.nl/](http://simpleshare.schuttelaar.nl/)

~~~
mxxx
Mmm, I've been in situations before where marketing absolutely insist on
packing the page full of sharing widgets, and it has a horrible impact on
clientside performance.

------
dougbarrett
Those networks can still track user habits by clicking the URL. In one acorn,
they will know they came from your site, any user agent information, screen
size (via JS on the social network site), if they are logged in they will
associate them going to your site even if they decide not to share the URL.

The only thing they aren't seeing is additional analytic data they're missing
out by not having there JS installed on your site, but its still enough data
that they can use on there end for targeting advertisements which is what they
are using this data for.

~~~
Nursie
>> Those networks can still track user habits by clicking the URL.

Isn't that kind of the point though - if I don't click the URL then
FB/Twitter/G+ etc etc don't get notified of my visit to a third party site
that includes their buttons. If I do, fine, I'm going there and they get the
info, but usually I don't.

------
grey-area
I've recently done this on some client sites - it's far neater than including
several sets of js each loading their own support libraries etc. The main
reason for doing it was speed (each button makes several requests for js and
assets), but it does also obviate serving multiple third-party js files, and
protects your users from tracking by Facebook etc. which some of them won't be
keen on. It's a shame that FB, Google etc insist on hosted js - a nicer
solution would just be a link around one dynamically generated image showing
the user the same information, though I guess that could still be used for
limited tracking by IP.

After trialling the standard js we decided to forgo the dynamic buttons for
speed, security and the privacy of our users and use locally hosted images of
the buttons or logos with a simple link to the social site. For the readers
it's very similar experience, but a much faster solution.

------
dfc
This seems like a great time to plug RequestPolicy:

 _" ReuestPolicy is a Firefox extension that improves the privacy and security
of your browsing by giving you control over when cross-site requests are
allowed by webpages you visit."[1]_

It is even better if you pair it with NoScript.[2] Whenever I toy with the
idea of switching to Chrome I am always end up sticking with iceweasel because
of the lack of equivalent RP+NS functionality in Chrome. If you are currently
using ghostery I highly suggest you switch to RP+NS.

[1]
[https://www.requestpolicy.com/index.html](https://www.requestpolicy.com/index.html)

[2] [http://noscript.net/](http://noscript.net/)

~~~
johnpowell
I used to use RequestPolicy and thought it was great and did what it said it
would. But it broke a lot of things like buying something on Newegg. I was
afraid to allow something and try again thinking I would be charged twice.

Ghostery, while not as strict seems like a nice compromise. My mom uses it and
she doesn't even notice it.

~~~
dfc
I think ghostery is probably the better choice for non-tech folks. You are a
better son than I am, I should install ghostery or my mother. For people with
a little time and basic knowledge of how the web works I think NS+RP is the
way to go.

------
nhebb
This is a great write-up with a simple solution - one that I recently realized
that I needed.

I put the AddThis button block on some of my article pages at the beginning of
May. I was getting less click-throughs to my product page, so I started
looking into possible causes. The Site Speed reports in Google Analytics
showed that my page load times had increased 2-3x. I profiled some of the
slower pages and found that the AddThis external call stack can be pretty
deep. After removing them, everything's nice and speedy again, and click-
throughs are back up to normal levels.

------
chanux
And for share counts
[https://gist.github.com/jonathanmoore/2640302](https://gist.github.com/jonathanmoore/2640302)

------
quackerhacker
I actually agree with this article...from an optimization standpoint. Whenever
I've had to integrate paypal, youtube, or even coinbase...I always add the
images to my static sprite sheet (to reduce http requests), and will serve a
post href link...instead of button code suggested.

Even before the whole tracking was exposed, I _always_ hated paypal's 1px
blank gif that is integrated in their button code.

------
yogsototh
I made a similar article recently. I provide a complete block which you could
copy/paste on your website directly. It uses javascript to create the right
link using the current url.

[http://yannesposito.com/Scratch/en/blog/Social-link-the-
righ...](http://yannesposito.com/Scratch/en/blog/Social-link-the-right-way/)

------
minimaxir
Another note: you can create realistic share buttons by fetching the Like
counts via JavaScript.

I run that on my own website and it works well.

~~~
g-garron
Can you give me your website url, please?

~~~
minimaxir
Whoops, it's in the profile. Sorry about that. (last time I linked directly to
my website in a HN comment as an example of the implementation it was accused
as self-promotion.)

It's not super advanced JS but it gets the job done.

------
tosbourn
Just wanted to chime in with my 2 pennies to say I agree 100% with this
article.

My feeling is that if social interaction is core enough that it needs to
appear on every single page of your site (or at least on core, highly
trafficked pages) then the common way of doing this sucks on two levels;

1) Depending on other websites to load content? Madness.

2) Depending on JavaScript to execute core functionality? Pointless.

I have solidified my thoughts better here:
[http://tosbourn.com/2013/01/development/replacing-social-
med...](http://tosbourn.com/2013/01/development/replacing-social-media-share-
buttons-with-non-javascript-counterparts/)

I have also written up how you can get the functionality without the JS in
this github repo [https://github.com/tosbourn/nojs-
socialshare](https://github.com/tosbourn/nojs-socialshare)

------
bhashkarsharma
I love how security expert Bruce Schneier
([https://www.schneier.com](https://www.schneier.com)) has implemented it.
This also gives you an ability to see how popular an article is (based on the
sharing numbers) if you want, which is another purpose these widgets serve.

------
olegp
There is one downside to share links vs. buttons: visitors can't see how many
times the page has already been shared.

At [https://starthq.com](https://starthq.com) we've opted for a half way
solution by confining the share buttons to individual iframes. This way we
don't prevent the tracking, but do contain their ability to break our page or
grab users' data.

------
quackerhacker
In regards to not tracking users...integrating a http request to Google for
JQuery, is still tracking users.

I always find this ironic about these articles _don 't track your users_, or
_prism is watching, let 's use mailvelope_, some of these pages that is
promoting privacy, integrates google analytics, have a share button, or some
type of off server request.

~~~
Encosia
The Google CDN serves its scripts from a cookie-less domain and with an
aggressive far-future expires header. Best case, a given user may only need to
make one request to Google per _year_ for a given script, and even when they
do there aren't any tracking cookies to make that request worth much at all in
terms of tracking. You're right that Analytics isn't great for privacy, but
their AJAX Libraries CDN is configured in a diametrically opposite way.

------
sage_joch
It occurred to me yesterday how powerful Twitter must be. They must have a
good portion of most peoples' web histories, which could sell for a lot in
certain markets. This is all just wild speculation, but I also wonder if they
made a data-sharing deal with CNN, given CNN's constant Twitter promotion over
the years.

------
jdangu
The discussion is also relevant for sharing widgets (addthis and friends). If
anyone is interested, I wrote about their behavior and how to circumvent them:
[http://www.j-ro.me/nixing-the-dataholic-sharing-
widgets.html](http://www.j-ro.me/nixing-the-dataholic-sharing-widgets.html)

------
proexploit
Your Facebook button says "Like", but it's a share. There's no liking
involved.

~~~
g-garron
Thanks, changing it now.

~~~
nuetrino
Now its not clear what the button does. Why not brand each link to match its
respective network?

Edit: Your WordPress permalink code looks fine by the way.

------
austenallred
In other words it's not buttons in and if themselves that should be avoided
(according to the author) but pulling in the widgets from FB, Twitter and G+.
You can host the same buttons on your end (really just a picture with a link)

------
ereckers
This is about the way I see it these days. Pulling 2, 3, up to 5 outside
scripts via sharing widgets is just too much. Much snappier to skip and just
link out as the example shows.

------
dotmanish
"and thus giving them the _possibility_ to track your visitors"

This is an understatement. There's no reason for them not to do it - it's
fodder for them.

------
acqq
An implementation that uses image maps without scripts:

[http://www.strchr.com/share_buttons](http://www.strchr.com/share_buttons)

~~~
g-garron
Thanks.

------
dotmanish
This applies to usage of Google Fonts as well, isn't it? Similarly, Adobe gets
the hold of site visitors via use.typekit.com

------
KaoruAoiShiho
[http://sharrre.com/](http://sharrre.com/)

------
idupree
The links to Facebook/Twitter/etc. should best be HTTPS, I think.

~~~
g-garron
Thanks for the advice. I will change them later.

------
hackerchic
I agree and have been replacing share buttons with an icon an link also

------
hartator
A small typo in the title: Javascript and not _java_ script.

~~~
ahoge
Which title? Anyhow, it's "JavaScript" with a capital 'S'.

~~~
g-garron
The title here in HN. It was originally "Don't expose your visitors to
tracking. Use share links instead of Java scripts"

It was then edited (by a moderator I assume) to reflect the actual title of
the post.

------
untog
...and find your click rates plummet.

Which is fine if you're OK with that cost. But a lot of users aren't going to
notice those links, let alone select them, copy them and paste them.

If I already have to copy and paste a link, why not the actual page URL?

~~~
aethr
Why wouldn't users be able to click links? He is simply providing URLs for
popular social sites that can be used in link hrefs to share the page being
viewed. Ie,

[http://facebook.com/sharer.php?u=http://url-of-the-
post](http://facebook.com/sharer.php?u=http://url-of-the-post)

You use this to make regular links that users can click, instead of buttons
loaded inside iframes, etc.

