Social share buttons that don't allow the social sites to track your users
github.com
github.com
embedding remote content like tweets or videos without compromising your privacy.
We also had a lot of customers who didn't know that the internet existed outside of "the blue 'E'". With those ones I usually helped get Firefox installed.
To me it seems like this function is not something the page should provide buttons for. Just like it offers no buttons for saving, bookmarking, printing, resizing, scaling, scrolling etc. That is stuff you do with the page. Not something the page does.
People do of course share those articles, but they don't seem to look for or trust web page share buttons. Even I rather copy/paste the URL into Facebook myself while on a desktop/laptop, or use my browser's built-in sharing functionality on a mobile device. This is all anecdotal but also based on data from hundreds of millions of page views.
Correct, mainly because "normal" users didn't know how to copy/paste URLs or didn't bother to, supposedly. If desktop browsers had gone in the right direction, they'd have added a "share:" scheme (similar to "mailto:").
In the past, desktop browsers kind of tried to provide such features with the concept of the bookmarklet [1]. The idea was that users would drag&drop a link to their bookmark toolbar to add functionality to their browser. I think it is still used by some Read-It-Later style collection services, but mostly has been replaced with browser extensions.
They managed multiple search engine options just fine and mobile browsers implemented sharing without issues. I don't see a pressing need for user configuration (websites with share buttons don't allow this either), it would have meant potential additional revenue also for Mozilla & Co.
OTOH, they failed to fix "mailto:" for webmail ...
AFAIR toolbars added sharing buttons early on.
<a href="https://www.facebook.com/.../share" target="_blank">
<img src="share_button.png">
</a>
?Edit: You could probably hack around this with some CSS, but only relatively recently and browser support could be a challenge.
(In this specific case, it will most likely only ruin analytics. However, it's a good habit to use POST when you don't want automated access. E.g. if the social media also didn't implement their end properly and used GET requests for submission, the bot or crawler or whatever will fall through two layers of checks and your social media may be filled with gibberish, this scenario is however mostly theoretical. In general, you don't want a URL can modify state related to your core business logic. See HN's infamous "This Submission Upvotes Itself")
I was discussing this in another HN thread recently and my mind hadn't switched out yet :)
All the major platforms allow you to pass through titles and other data to pre-populate the share box.
https://www.stavros.io/posts/scourge-web-analytics/
It uses plain links (no JS) for the social buttons, and writing that article was actually what urged me to remove social buttons from my site.
Shariff is cool, but there's really no reason to use JS just for some social buttons, so what I ended up doing was just using its CSS and visuals and nothing else. This has been working very well, the buttons are fully functional (even with JS off!) and quick to load.
I wish Shariff had a no-JS mode.
This, when it is doable, of course provides no tracking (until/unless a user clicks the share button anyway) with no need for "two clicks" -- the remote site receives no network traffic at all unless you click the button, it's just an ordinary static link.
I have generally been able to figure this out for major social network sites, either from documentation, third-party documentation, or watching HTTP requests made by the 'official' JS solution. I guess it's possible it violates the "ToS" of the remote site to do this, although I'm not sure ToS can really restrict my linking to the site with a URL. I guess this technique could be more subject to breakage, if the remote site changes it's URL patterns, and the "official" (JS/tracking) solution from the remote site is updated, but I'm not using that.
So there are potential downsides -- but I'm curious which of them (or something I'm not thinking of) leads people to a more complex (and slightly worse UX) solution like this, instead of just using static URLs.
This also has the advantage of working in places that don't allow embedding JavaScript, like Github README files.
Dependencies
jQuery
jQuery cookies plugin (optional)
uglifyjs (for build.sh)
uglifycss (for build.sh)
extend (for build.sh)
https://github.com/QuadrupleA/private-secure-sharing-buttons
It just needs a stylesheet and vanilla JS - so no dependency on jQuery and node.js, no build shell script required, and makes no external HTTP requests (uses simple SVG icons embedded in the JS).
Why feed the beast after it bites you?
One was to speed up the load time of the site, another was to limit social button tracking all users for the sake of the very small minority of users who use them.
Our reason for keeping them was that people were sharing/saving anyway and this gave us a little more control vs something like the Pinterest browser plugin which users might use to save/share.
The point of the other solution is to save all that.
Come on. Surely there's like a plugin to Django or whatever that could do this. You're serving the dang article from some database with some server logic, after all.
Convenience is a massive selling point. It's the same reason Dropbox is a thing rather than "hurr durr build your own FTP server, it's cheaper and more effective".
Sure, it's cheaper. But count the 2 hours you have to spend debugging and making it work, then maintaining the server...
Personally, I have other things to spend time on. Things like, you know, building a product, rather than maintaining a contraption that fetches social stats from the very convoluted social APIs.
Ever tried to get your Instagram follower count via their API? Good luck doing that without access tokens or some hack.
This is maybe just me, but I believe that as engineers, we have a duty to consider ethical ramifactions of the things we are building. Saying "I'm going to do the easy solution, and I don't care about what kind of tracking I'm exposing my users to" shouldn't be acceptible behaviour any more.
But I won't spend hours of engineering time building a share button system because there's other priorities. Say spending that time building a "delete account" button.
There's other more relevant ways to build privacy conscious features than to focus on a share button.
Also, you underestimate share button providers by saying they aren't a consumer product. Your average WordPress user doesn't know (or care) about building share buttons.
This got to pole position on HN, then some mod flagged it as spam, It’s spirit was relevant then, and it’s spirit is relevant now. Fully GDPR compliant.
That’s like selling guns while complaining about bullets.
1. Social Media has become a necessary Evil if you are in the marketing of any kind.
2. I don’t care about the business model of social media sites as that is not my business, I am happy just to provide the options for readers to share if they care and I use a simple sharing (without tracking).
Do you have experience with this? My understanding is that there's still trivial work arounds (See chrome extension "Buster") or services where you pay to have a human go through it for pennies.
If somebody is targeting your site then your captcha will be useless no matter what.
I got 0.9 and then 0.3 after refreshing.