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.
>> 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.
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.
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.
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.
but the CDN provider might 'fingerprint' the script based on IP/frequency/headers etc and always return one version, whilst returning a different version to others... ? ;-)
I tried to use Google's AJAX CDN (because I was thinking the same thing you are) and have been burnt several times because of it. Occasionally, it won't serve your js files, leaving users with an indefinite 'Waiting on ...' message or a partially rendered and broken page. It's fixed if they refresh. If you use your own server, at the least there's a connection already established and the JS files will be served. My suspicion is that Google is prioritizing other traffic, and the free AJAX CDN is low on the list of services that should work flawlessly.
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.
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.
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.
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.
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.
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/
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.
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.
You can fairly easily use /dialog/feed "manually" instead of sharer.php if you're worried about the latter's lifespan – you just need to set up an app for your domain first since "app_id" is a required param (and also "next", which is a redirect URI on the same domain).
Example: http://antiprism.eu/en#share
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
There are two schools of thought for privacy enhancing technologies. The ghostery model is to try not to be disruptive and to ask as little as possible of the user. No script takes the other approach which is a "default block" and require the user to whitelist sites that she needs to work.
Right, and that will break a majority of websites out there, because they sniffed a fully capable desktop browser but the JS they sent as a result of the sniffing failed.
I completey agree. Default block does not work for a userbase that does not have the time or inclination to read the documentation and configure it to meet their needs.
I love how security expert Bruce Schneier (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.
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,
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.
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.
64 comments
[ 2.5 ms ] story [ 118 ms ] threadhttp://www.strchr.com/share_buttons
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.
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.
"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.
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.
It was then edited (by a moderator I assume) to reflect the actual title of the post.
Edit: Your WordPress permalink code looks fine by the way.
Even before the whole tracking was exposed, I always hated paypal's 1px blank gif that is integrated in their button code.
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.
I run that on my own website and it works well.
It's not super advanced JS but it gets the job done.
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.
[1] https://developers.facebook.com/docs/reference/plugins/share...
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.
[0] http://panzi.github.io/SocialSharePrivacy/
[0] http://socialitejs.com/
"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
[2] http://noscript.net/
Ghostery, while not as strict seems like a nice compromise. My mom uses it and she doesn't even notice it.
Default block doesn't work.
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?
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.
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.
http://yannesposito.com/Scratch/en/blog/Social-link-the-righ...