Instagram: Countering Herd Mentality, Hype and Bots

Recently, Instagram has removed two notable features from its app; the like counter, which displays the total number of likes of any given post, and the following page. This wasn’t due to the GDPR or any security or privacy concerns.
Rather, it is an attempt by Instagram (and Facebook) to counteract the popularity contests that exist all over social media. Consider influencers that hype up products. If they pay enough people to gain traction on their products, they will eventually gain many likes on their posts.

By applying the herd model, if you see that a post has been liked by many of your friends and has a extremely high like count, there is a very high percentage that you would also like this post, even if you are impartial to the actual content. Why? If the post is about something you are not familiar with, you would trust the post because of two factors:

  • a high like count implies this post is trustworthy and many people like the content, so the content must be good
  • friends believe it is also a good post, and you trust your friends
Followers make more honest decisions without social pressure

What Instagram has done partially shuts down herd mentality completely. For one, removing the like count on posts lowers the chances of information cascade because at first glance, it is difficult to tell how many people like and agree with the post (of course, Instagram still shows a list of all users that have liked the content, but it requires additional actions). As the user, you will be more likely to trust your own instinct and make your own decisions on the content of the post without being affected by what others have said (unlike the maj-colour urns) because you cannot see how many people “agree” with the post. Secondly, by removing the following page, it also prevents you from viewing what your friends have liked, which also reduces the chances of information cascade. Herd mentality is stronger when it involves people you know because there is more inherent trust. Lastly, this also counteracts the issue of botting (creating “robot” accounts that don’t follow a typical human’s usage) for likes, because increasing a hidden like counter provides no incentive for promoting a post, unless the content is well-liked.

This trend shows that more social media platforms should follow Instagram’s new model of hiding metrics that may encourage herd mentality so that people can express their true thoughts and feelings without being pressured socially by others. It encourages users to evaluate the information presented and respond appropriately.

Source: https://techcrunch.com/2019/11/14/instagram-private-like-counts/

Breaking the internet with 11 lines of code

Nowadays, web apps are extremely complex and are often comparable to native applications. Yet in the Javascript ecosystem, these apps are dependent on various modules that serve as a small cog in the wheel of the app and these modules live on the repository known as npm. Over time, developers become dependent on these modules (sometimes regardless of simplicity) to address issues or features in the application, which results in an application’s codebase with a dependency graph similar to the following:

Large, entreprise applications may have hundreds if not thousands of dependencies and it only takes one to break to bring the application down. In fact, a similar scenario happened recently with the infamous left-pad module, bringing down Node and Babel.

npm creates a single point of failure that makes it extremely susceptible to attacks/failures
The npm repository of JavaScript modules creates a single point of failure for most, if not all JavaScript-based applications in the world. Why is this so? Whenever a module (let’s call this A) is used as a dependency for a web app X, this creates a directed edge from A to X. However, modules can also use other modules as dependency, so another module B may also have A as a dependency, creating another directed edge from A to B. Therefore, a web app Y may not directly depend on module A, but if it utilizes module B and module A is removed or changed maliciously, Y will encounter failures (at the build step or even during runtime) or be susceptible to the malicious attack. To determine these modules, we consider them as nodes in a graph and find the nodes that act as bridges, which can be done by looking for nodes with the highest betweenness.

Developers should make it a goal to minimize the applications dependencies to retain greater control of application stability and security
Over time, a popular library that includes various modules may become extremely fragile since only one of its modules failing would break the entire library. This is why developers should minimize the use of modules, especially for simple functions. For example, writing a small wrapper for native ES6 Fetch API should be preferred over Axios (~6 dependencies) because it is a simple function that should not require many dependencies.

In extreme cases, dependencies can be updated and injected with malicious code without developers from knowing, then every application that uses the module is affected, which causes another cascading effect. One example of this is the event-stream module that started to steal cryptocurrencies’ private keys to wallets. One way to prevent this from happening is to verify packages using some sort of hash to guarantee a package’s validity. Otherwise, we have to hope that bad code doesn’t leak into these modules.

Thank god for git right?

Inspired by: https://medium.com/graph-commons/analyzing-the-npm-dependency-network-e2cf318c1d0d