The Open Web can learn comment moderation from Instagram

Starting today, you can protect your account from unwanted interactions with a new feature called Restrict. Bullying is a complex issue, and we know that young people face a disproportionate amount…

Source: Empowering Our Community to Stand up to Bullying – Instagram

Bullying is about power and perception. When someone cyberbullies you, the idea that other people can see the comments and choose to ignore them, which makes bullying banal, or even someone else’s comedy, that idea is sometimes more hurtful than the comments themselves.

What’s interesting to me is that Restrict is a rehashing of a system that has existed since forever on the Open Web – comment moderation. The ability for a blog to not show a person’s comments has existed forever, and due to the lack of transparency and user-feedback in companies like Facebook and Google, has largely been ignored until they get to it.

However, Restrict is an improvement, depending on how they’ve implemented it. In blog comment moderation, the bully/poster sees and knows that their comment is under moderation. This gives them cause to go and continue their bullying on some other platform.

Restrict seems to make it so that the bully will not find out they are under review. This is a powerful tool, because the perception for the bully will be that other people saw their comment and ignored it, thereby removing the feedback loop that pushes them to bully more. Simultaneously, for the bullied, it will tell their subconscious that their community has not abandoned them in favor of the bully, because the community can’t even see the bully’s comments.

If this is how it’s implemented, and if it is successful, I’d say this is a good thing for the Open Web and for comment systems like Disqus and WordPress to also implement. Taking power from the bully means letting them think that their ‘hot takes’ have been ignored by bystanders. In this case, perception is power, and the bullied should be able to wield it.

Security vs Usability

I’ve come to a point where I do **not** update apps, plugins, software in general. I know that’s a regressive approach to safety, but safety can’t keep trumping usability all the time.

Source: My comment on Stephen’s Notebook

Every few days, I have a conversation about security vs usability somewhere. With my iPad Mini, I blindly trusted Apple to do the right thing and they’ve screwed me over. It’s a beloved device, destroyed completely by iOS 9.

So I’ve basically given up on this bullshit harp that companies sing of ‘security’ to shove software updates down our throats. Sometimes it’s their stupidity, and sometimes it’s just them being sinister. The new Microsoft is the old Microsoft. The benevolent Apple is an insidious Apple. Don’t get me started on Facebook, twitter, and Google. Gmail is just the latest casualty of our overzealous overlords.

Yes, security is a big problem. Yes, it needs constant vigilance. But just like national defense budgets, one key phrase doesn’t allow organizations to completely railroad people’s expectations, asks, hopes, and in this case, UX.

If you’re concerned that by not updating software, you’re living on the edge, restrict the things you do on that device, while keeping other devices that are completely updated and secured. Use only frequently updated third party browsers instead of the default options. Read up on the latest security scares on the Internet and just be aware of the situations you can get into. But most importantly – back up. Make frequent backups of things you care about. I don’t care if it’s as much as letting iCloud run its course every night, and Google Photos siphoning off your pics. Just do it so that if you brick your device, or get hacked, you’re not set back a hundred years.

99% of security is just keeping your eyes open.

Fixing Jetpack’s Stats module

Despite the hate that Jetpack gets for being a bloatware plugin, it is one of my favorite and the first step whenever I setup a new WordPress install. However, Jetpack does have a few irritating habits that I cannot overlook. One of these is the stats module. The module actually does pretty well, posting data to the wordpress.com dashboard and making it easy for me to quickly glance at the number of visitors I’ve had for the day.

However, every so often the module craps out and logs a large number of visits from crawlers, bots and spiders as legitimate hits, since those are not in the official list of crawlers, bot and spiders to look out for. To fix this, I went out to look for the list and to add to it. One quick GitHub code search later, I found that the file class-jetpack-user-agent.php is responsible for hosting the list of non-humans to look out for. What I found inside was actually a pretty comprehensive list of software, but one that definitely needed extending.

If you want to do what I did, find the file in your WP installation at –
/wp-content/plugins/jetpack/class.jetpack-user-agent.php

Inside the file, look for the following array variable –
$bot_agents

You’ll see that the array already contains common bots like alexa, googlebot, baiduspider and so on. However, I deepdived (meaning did a sublime text search) into my access.log files and found some more. To extend the array, simply look for the last element (which should be yammybot) and extend it as follows –
'yammybot', 'ahrefsbot', 'pingdom.com_bot', 'kraken', 'yandexbot', 'twitterbot', 'tweetmemebot', 'openhosebot', 'queryseekerspider', 'linkdexbot', 'grokkit-crawler', 'livelapbot', 'germcrawler', 'domaintunocrawler', 'grapeshotcrawler', 'cloudflare-alwaysonline',

Note that you want to leave in the last comma, and you want all the entries in lower case. This doesn’t actually matter, because the PHP function that does the string compare is case-insensitive, but it just looks neater. You’ll also notice that I’ve added the precise names of the bots, like ‘grokkit-crawler’ and ‘clousflare-alwaysonline’ but you can be less specific and save yourself some pain. This will, however, affect your final stats outcome.

Notes –

Some of the bots are pretty interesting. I saw tweetmemebot, which is from a company called datasift, which seems to be in the business of trawling all social networks for interesting links and providing meaningful insights into them. Another was twitterbot. Why the heck does twitter need to send out a bot? We submit our links to it willingly! Also interesting were livelapbot, germcrawler and kraken. I have no idea why they’re looking at my site.
Although Jetpack does not have a comprehensive list of bots, it still does a pretty good job. I found the main culprit of the stats mess in my case. Turns out, CloudFlare, in an effort to provide their AlwaysOnline service (which is enabled for my site), looks at all our pages frequently and this doesn’t sit well with Jetpack. I hope this tweak will fix this now.
Although this fix is currently in place, every time the Jetpack plugin gets updated, all these entries will disappear. That’s why this blog post is both a tutorial for you all and a reminder and diary entry for me to make this change every time I run a Jetpack update. However, if someone can tell me a way to permanently extend Jetpack, or if someone can reach out to the Jetpack team (hey Nitin, why don’t you file a GitHub issue against this?) it’ll be awesome and I’ll be super thankful!

Update – I was trying to be hip and did a fork of Jetpack and GitHub, made the changes and then tried to make a pull request. Turns out, I don’t know how to do that, so I opened an issue instead. It sits here.