Javascript Array’s functions, push and pop is intuitive, but shift and unshift are not.

Push and pop are simple they treat that array as a stack, and the last element is considered to be top of the stack. So, whenever a push and pop is performed its performed on top of the stack,i.e. at end of the array.

let x = [1,2,3,4,5]
x.push(6) //returns the length of the new array -> 6
console.log(x) //[1,2,3,4,5,6]
x.pop() //returns the popped element of the array -> 6
console.log(x) //[1,2,3,4,5]

Whereas, shift and unshift, assume the first element of the array to be the top of the stack.

shift() and unshift() are just pop and push, applied on a reversed Stack.

Now, if any noob(like me) would see it his/her perception would be to assume that push and pop are for arrays assumed as a stack(LIFO), whereas shift() and unshift() are for arrays assumed as Queue (FIFO)

let x = [1,2,3,4,5]
x.noobShift(6) //would have returned the length of the new array -> 6
console.log(x) //[6,1,2,3,4,5]
x.noobUnshift() //returns the dropped element of the array -> 5
console.log(x) //[6,1,2,3,4]
//noobShift & noobUnshift is how I assumed the JavaScript's shift() and unshift() function to work.

But, that’s not the case, I was picturing it all wrong in my head.

How .shift() should be pictured:

x=               [1,2,3,4]
x.shift()        <-shift the array by one place to the left
          1[2,3,4] <= the new state of Array with 1 out of place
          x.shift() returns 1, and x becomes [2,3,4]

How .unshift() should be pictured:

x=               [1,2,3,4]
x.unshift(0)      -> shift the array by one place to the rigt
    0[1,2,3,4] <= the new state of Array with 0 ready to be inserted
    x.unshift() returns 5, the length of updated array, and x becomes [0,1,2,3,4]

I have always felt that visualizing a concept, helps create a better picture. After all, “If a picture is worth a thousand words, a video is worth millions”, at least. Hope, this helps.

You are a Coder, not a Liar, Thief or Vandal

But the question is how would you prove your Innocence? Who would you blame and Who would you trust?

Words like ‘Security Threat’, and ‘hacked’ can spread chaos in any boardroom or meeting. Security is no joke in the IT industry, it is taken very seriously. Companies spend millions of Dollars to Test their systems for bugs and vulnerabilities.

But yet it happens, the bugs (intentional/unintentional) somehow make through the rigorous rounds of testing and scrutiny. And depending upon the severity and size of the bug, it is later discovered. But by then its too late.

What follows next is an intense round of finger-pointing, and it ends on someone, it has to. Because if there was a slip off someone has to take the blame.

In a very recent case of ‘Florida Ransomware Hacking’, on June 10, Brian A. Hawkins, former Information Technology Director of Lake City, the northern Florida city, was on the receiving end. The city was forced to shell out approximately half a million dollars. He was being blamed for the Ransomware Attack and the long time that it took in recovery.

Following which Mr Hawkins filed in Columbia County state court on Aug. 9 raises the inevitable question of liability: When hackers wipe out a city’s computer system, who is to blame?

Who is to Blame?

Its a question that has been pondered upon by the whole Computer Science Community since its Inception. Who is to blame when something goes wrong? When things fail, and a known or unknown vulnerability is exploited. What do you do? Where do you look for the bug?

And more importantly how to find it and then fix it? So that such incidents can be prevented in the future. We are not the first ones to ask such questions, Ken Thompson in 1938 also had a similar question and he had an answer as well.

Kenneth Lane Thompson (born February 4, 1943) is an American pioneer of computer science. He designed and implemented the original Unix operating system while working at Bell Labs. He is also credited with the invention of B programming language, the direct predecessor to its popular counterpart the C programming Language. He also presented the backdoor attack now known as the Thompson hack or trusting trust attack.

“Reflections on Trusting Trust” is a famous speech, given by him in 1983, published in Communications of the ACM journal in August 1984
Volume 27 Number 8. This was his acceptance speech after receiving Turing award “for their development of generic operating systems theory and specifically for the implementation of the UNIX operating system”.

There he put forward a question, “To what extent should one trust a statement that a program is free of Trojan horses? ”. In a programming world where a library is just one `npm` away. How does one ensure the security of the code?

In 1983, during the time Ken gave this speech. Unix was everywhere and the C compiler was the central piece of software for these systems. Almost everything went through the C compilers and they were a single point of failure and for the obvious reasons very Lucrative for the hackers.

So basically if you would write your program in C, you would compile your Source code with a C compiler, made in C, to create a binary file which would then be executed in your system, which again is written in C. This is what Mr Thompson described as the “chicken and egg” problem that arises when compilers are written in their own language.

So all that a person has to do is infect your Compiler, and instruct it to include malicious code in every binary file that it creates. And every code going through the infected compiler would be an infected code. So a program to subtract 2 numbers would subtract 2 numbers and few files as well.

No amount of Source code review will reveal the problem in such cases. Because the tools that one automatically assumes to be correct can actually be corrupted. This problem is pretty severe, not because it is complex or anything, but because the problem exists at a place where no one would expect it to be.

Problems like these, even after so many years of existence and testing, still exist in compilers of many languages. Convenience over Security is a common norm now. One thing that everyone needs to realize is that Trust was scarce back then and is still Scarce now.

Aleksey Shipilëv on Twitter

Current status: following up on rare compiler bugs like there *is* tomorrow.

Conclusion

Who is to blame?

The programmer using the trusted Compiler? Bad Design? Unix? and, Who to Trust? Ken Thompson has an answer:-

“The moral is obvious. You can’t trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.” — Ken Thompson

When it comes to security you can’t trust anything or anyone, but yourself, but that’s impossible to do so. In this world, you always have to Trust someone. You need to trust the people you work with. The developers, designers and everyone involved with a compromised or buggy software has to share the blame.

To what extent should one trust a statement that a program is free of Trojan
horses? Perhaps it is more important to trust the people who wrote the
software. — Ken Thompson

The Programmers/Coders/Software Engineers, need to realise that they are the first line of defence against such threats and bugs, and a small misstep could result in loss of Millions of Dollars and in worst cases Loss of Lifes. Software Engineering is a serious job and it should be treated like such.

Testing is a crucial part that ensures that Code Quality and a less buggy system, and still Testing is the most under-rated and neglected part of the Software Industry.

“A clever person solves a problem. A wise person avoids it.”
 — Albert Einstein

References:

https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
https://softwareengineering.stackexchange.com/questions/184874/is-ken-thompsons-compiler-hack-still-a-threat
https://en.wikipedia.org/wiki/Ken_Thompson#cite_note-22
https://www.nytimes.com/2019/08/22/us/florida-ransomware-hacking-it.html
https://www.zdnet.com/article/second-florida-city-pays-giant-ransom-to-ransomware-gang-in-a-week/