Rants & Musings
These are my personal views, not related in any way to my employer's. Take it with a kilo of salt before judging anything that has been written here.
I present you next some of my favorite rants & musings for everyone's delight (I hope...).
Index (datetime format: [DD/MM/YYYY])- General thoughts on programming, 23/11/2024
- The perpetual spinning wheel of modern software development, 03/10/2023
- Claims & Evidence, 11/06/2023
- On dependability taxonomy, 09/04/2023
- Difficulties posed by cyber security, 03/04/2022
- Fearmongering, 03/11/2021
- Science is the most likely answer, 22/06/2020
- Clever title, 01/01/1970
"General thoughts on programming"
Today I noticed that I have been programming since 1996 and since then, I have been thinking about how to be a better programmer. Over these 28 years I have had some up and downs, some happy and (leider) a lot of sad moments. I cannot say I have chosen my career poorly, as I do enjoy programming a lot.
And every day I still think about that.
I started programming in PASCAL, then C, then Java, C++, Perl, and recently (as of 2022), Python.
I touched BASIC (Beginner's All-Purpose Symbolic Instruction Code), invented by John Kemeny. It is indeed a very odd "language", for example, to print some Fibonacci numbers one would "code" the following:
Source: tutorial on BASIC.Remember that quote from Edsger Wybe Dijkstra: "GOTO Statement Considered Harmful"? It stems from that code ;).
To add instructions between 10 and 20 one would create a new line and add a "15" with the new instruction. Can you see the host of issues that this "design" causes? Thank you, programming leaders of the world, for creating more useful programming languages over the years!!
Quote: | ||
"(in programming) there are basically three main (or meta) principles above all: KISS, DRY and No-Principle-is-Sacred." |
KISS=Keep It Simple, Stupid
DRY=Don't Repeat Yourself
I remember (vividly) coding in Turbo Pascal, then in Turbo C. What a joyful experience. Debugging. Understanding how things work.
Nowadays, programmming is a BEAST of its own: a plethora of libraries to attach to projects, several layers upon layers of things to worry, infrastructure issues (DevOps), embedding security early on, etc., etc. I wonder if as a field we will stabilise eventually into "something" that is prone from defects from the get-go, whatever language one uses to solve a problem. Only the future will tell, I guess.
Birmingham, 23/11/2024
"The perpetual spinning wheel of modern software development"
A recurring problem surfacing in today's society given its high reliance on software for performing a myriad of tasks is due to persistent defects finding its way into production environments.
Modern deployment practices forcibly push whole systems or sets of features into production with insufficient (sometimes minimal) observance to its non-functional properties, namely, performance, usability, or cyber security (Note: one may exhaustively debate whether naming this 'non-functional' is useful or totally useless; for the sake of this post, this is how the field calls these practices, the discussion can be reserved to other time. See "Non-Functional Requirements Are STUPID"↗ on YouTube by Farley).
On top of that, software usually depends on a significant amount of third-party API that are also amenable to failures, that were poorly tested, or that are shipped with (sometimes unwarranted/hidden) vulnerabilities.
These unwanted situations are complex to map and address with testing, as it involves a non-trivial amount of resources to complete in time.
Different software quality assurance tools are employed by organisations to prevent weaknesses reaching end-users and customers.
It is a fact that software development has always been difficult, permeated with hard-to-solve all-encompassing issues like heterogeneous teams skills levels, problems understanding requirements or persistent defects plaguing systems altogether, to mention a few concerns.
In terms of process, the sad truth is that however you call it (waterfall, agile, etc.), it was difficult to address and effectively tackle those impending issues. One difference though is that now, the cycles are way shorter. Let me explain. It is usual to go through all SDLC phases in a one or two weeks sprint.
In the early days one could see the sprint as being organised as a 6-months to 1-year long endeavour and, by the end, we would have a product with many features.
We decompose large systems into smaller chunks that one might call a feature and we think about all these individual features (trying to) operating together, orchestraded. And we shortened the sprint to one to two weeks (or days or even hours, in more performant teams, perhaps?) and we go through all the phases to ensure each feature is OK for execution whilst in production.
It's like we are changing the radius of the spinning wheel to move faster (more deliverables, however, it sacrifises overall software quality).
Let's suppose we're interested in securing the feature, so the next analysis is biased towards this attribute.
The steps in modern software development/delivery/deployment or DevOps (in all its shades↗) and assuming a sizeable Java-based project:
- Client has come up with (yet another) bright idea and he/she wants to become a feature in the system at hand. The teams try to understant what it is needed and start drafting some ideas and high-level requirements.
- Some back and forth between stakeholders adjust things here and there and all is ready to 'move on' forward
- Write code; integrate; test (a lot, across the board) feature, automated tests (white box, removing naive mistakes and perhaps more serious issues)
- Note: this is highly dependent on developer skills to ensure the code is according to specification/requirements and follow recommendations and best practices
- Then basic syntax check for dumb mistakes (eg, CheckStyle, finding dead methods, etc., this kind of stuff), basic SAST (sifting through the overwhelming number of false positives), using SpotBugs, and then some SCA (third party API and libraries analysis given software is more complex nowadays given the multitude of external things to be linked)
- You can start working on some threat models and abuse cases for your feature (or whole application) at this point, depending on your level of experience and familiarity with methodologies; some basic risk assessment might go together
- Then code review, perhaps commit to (main?) repository/branch/whatever (single? multiple?)
- Then more testing, quality assurance testing (secure testing/pentesting, performance/load testing, usability testing), another round of SAST+SCA, then DAST+IAST+WAF (if you can, or have the resources)
- Finally, you might have something releasable (a deliverable?), then deployment, canary release, rollback if needed, rinse and repeat
Feedback (and its frequency) have changed. Teams have changed. Technologies have changed. Sadly, humans have not changed (nor they will), and as the time of writing this post, AI has not replaced humans out of the mix (yet).
The field is ripe with fast-paced time-to-market demands meeting ever stricter deadlines. Short cuts. 'Clever' (to whom?) work arounds, bypassing (usually security) controls. Scripting. JavaScript (is this still a 'thing' in 2023?). Quick and dirty alternatives (those things that E. W. Dijkstra would not vouch over one's shoulder [1]).
If teams are conscious and independent/responsible, the fact that adding some security champions in the mix might improve quality. They could consider adhering to security standards and best practices, useful/maintainable design patterns, secure by design approaches, and accounting/balancing security, performance over usability. However, let's not bury our heads in the sand because in reality, across organisations, the ratio between soft. devs. to appsec professionals is 100 to 1.
I'm sorry, but I don't have an easy answer to these problems addressed here, because it takes time, organisational culture change, and budgetary decisions that make managers twitch in their chairs in discomfort every time they are mentioned.
[1] Quote: "I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself 'Dijkstra would not have liked this', well, that would be enough immortality for me.", by Edsger W. Dijkstra
Birmingham, 03/10/2023
"Claims & Evidence"
The Sagan Standard↗ state that "extraordinary claims require extraordinary evidence" (usually mentioned as ECREE). It was not originally created by him as other prominent scientific minds such as Laplace↗ employed earlier (1814).
ECREE is related to Occam's Razor↗ in the sense that according to such a heuristic, simpler explanations are preferred to more complicated ones. Was that a UFO or just an oddly shaped flying thingy? You tell me.
It's good to keep an open mind about things, however, to convince ME (aamof, anyone) of your extraordinary (oftentimes absurd and highly improbable) claim, please come with scientifically sound experiments and evidences to substantiate those ideas altogether, otherwise, it'll be dismissed as pure speculation or anecdote (ie, accounts regarded as unreliable or hearsay).
Nowadays, we are plagued with "flat Earthers", "homeopathy", "zen cures", "astrology" (this one is old though) and "reptilian lizard people", but let's stop now. I may be mistaken, but I've never seen any hard evidence substantiating any of these claims. Science, on the other hand, has provided many answers to our deep questions throughout our very own existence.
Claims backed up by science are simply 'out there', in the open, to be put to tests. If they fail, they are discarded and we as scientists start all over again with different assumptions to prove or refute any idea. And that's how I like my facts: scientifically sound, amenable to proof, and substantiated by other scientists.
Birmingham, 11/06/2023
"On dependability taxonomy"
I don't wish to start finger pointing anything, however, it frustrates me the overspread use of dependability concepts interchangeably, without any thinking.
It is not my intention to mandate the proper use of concepts, however, a basic understanding would suffice for explaining to broader audiences about overall system's quality.
An example is reliability. Because the word "reliable" conjures the sense that something is trustworthy or dependable (now it's even worst!), people use it interchangeably with availability.
In (formal) dependability, one can think of those desired system properties as one word each (you shall find more than one definition for these properties):
- Reliability: continuity
- Availability: readiness
"A fundamental difference between reliability and availability is that reliability refers to failure-free operation during an interval, while availability refers to failure-free operation at a given instant of time, usually the time when a device or system is accessed to provide a required function or service. Reliability is a measure that characterizes the failure process of an item, while availability combines the failure process with the restoration or repair process and looks at the probability that at a given time instant the item is operational independently of the number of failure/repair cycles already undergone by the item."
Trivedi, K. S., & Bobbio, A. (2017). Reliability and availability engineering: modeling, analysis, and applications. Cambridge University Press. |
Example with time: in this case, the reliability level is usually computed in terms of the amount of time it didn't work throughout a duration, eg, a year. We have 525,600 minutes in one year. Look at this list next:
- Not working 10 seconds per year: reliability is 99.999968% (6 nine's)
- Not working 60 seconds per year (1 min): reliability is 99.999810% (5 nine's)
- Not working 3600 seconds per year (1 hour): reliability is 99.988584% (3 nine's)
Vendors try to push reliability to customers, stating that they offer high-reliability. I guess they mean 6 nine's by that, ie, the system works almost all the time per year, admitting failures that take up to 10 seconds to resume to operational status.
Now think: can you say that your system provides reliability? If yes, how much? 6 nine's? 3 nine's? Are you really off-line for just one hour per year? Can you support this claim?
Example with other elements: you could employ the same reasoning for any other element, eg, number of yearly flights with no incidents, number of odd-shaped nails in a batch, and so on.
Availability and reliability both tackle failure-free operation of systems; the former on a given instant of time and the latter during an interval. Let's think about the system and the states it can assume: [Working, Repairing, Failure]. The Availability (A) is:
- A = MTTF / (MTTF + MTTR)
- where
- MTTF = Mean Time To Failure
- MTTR = Mean Time To Repair
Thus, availability is about computing the level of working time a system has. How to do this? You take a bunch of system's logs with time data and failure events (analogously the amount of time it remained working).
Then, proceed discovering where and when any failure events (transitions to the Failure state) happened, mark the current time (that it worked, eg, MTTF) and the time it took to come back to Working state (eg, you will be computing the amount of time to repair the system - MTBF).
When you do this process for all your failure events present in that log batch, you can compute your overall system's availability and tell your boss how you could work to improve it.
Not surprisingly, if we plug to the equation one year operation (525,600 minutes in one year) as MTTF (one failure per year), and it took 10 seconds (1/6 of one minute) to repair (MTTR), we will come up with the same value as before (A=99.999968%). What we usually have is not a single failure, but multiple failures/repairs pairs throughout one year. That's the reasoning on why it is more realist to compute availability, without loss of generality.
My point here is: whenever people refers to reliability perhaps what they really mean is availability. But again, this is just another rant.
Birmingham, 09/04/2023
"Difficulties posed by cyber security"
Reading more about the difficulties behind (almost any) cyber security effort, in this paper: "Seeking Foundations for the Science of Cyber Security" [1].
This is not at all surprising because cyber security turns out to be an extremely difficult problem, owing to many factors, such as:
- The scale of the cyberspace, where (potentially) billions of devices are interconnected and must be considered holistically;
- massive (in breadth/length) attack surfaces to observe
- on the TTP-based threat hunting white paper by MITRE [2] they discuss the Terrain: a triad with Time x Technology x TTPs
- The complexity of cyberspace in terms of the interdependence and interactions among its cyber-physical-human components;
- complex interconnections among elements
- The adversarial intelligence that attackers possess as skilled human beings which is on par with defenders;
- dynamic strategies to consider next attacks and matching mitigations
- The asymmetry between attackers who only need to identify and exploit a single vulnerability, and defenders who must seek to prevent or block each and every vulnerability;
- imbalanced attack-defense game, where attackers have sensible advantages over defenders
- automatic tracking, surveying, monitoring networks and systems for vulnerabilities (scanning ports, sniffing traversing packets, potential OS discovery through observed patterns, and so on)
- The difficulty in quantifying cyber security from a whole-system (rather than building-blocks) perspective;
- monitoring, identifying, confirming, etc. notable cyber security events are not a trivial task to engage
- incorporating dependability models is thus not trivial, also when modelling the effects of cyber-attacks across systems is difficult to map and to identify relationships
- The multidisciplinary nature of cyber security, technologically speaking, and especially the involvement of human beings as users, attackers, and defenders;
- the overall cyber security effort and posture involves a high number of stakeholders
- classic dependability deals with systems failures or defects inadvertently introduced by programmers or people working on top of the infrastructure whereas cyber security tackles issues arising in deliberately issues such as cyber-attacks or overwhelming the infrastructure to stretch resources to the limit to gain access and control and then installing malware or other footholds for later exploration
- so called repair models employed to tackle cyber security issues underpinning massive attack surfaces could be modelled as systems behaving in simple states, namely operating or failure
Let's not forget that current cyber-attacks do not necessarily follow a straightforward CKC set of ordered (or organised) actions/tasks; threat actors would try different Tactics, Techniques & Procedures (TTP) over time.
The observed time to compromise elements varies, as new footholds are established and then exploited, to circumvent detection or other protective measures.
In terms of quantifying cyber security, and modelling the consequences of attacks [3], one could ponder that understanding and keeping the infrastructure updated are hard tasks to achieve.
On top of that, systems are organised in multiple layers, there is a fundamental lack of institutional knowledge being passed along (making simple configurations problems more frequent), cyber-attackers exploring Zero-Day attacks by understanding patching events from vendors, multiple potential points of access across the infrastructure (huge attack surfaces, as mentioned), sheer device heterogeneity (actually, this helps cyber security, only difficulties are coping, updating and patching a wide range of systems with different requirements).
References
[1] Xu, S., Yung, M., & Wang, J. (2021). Seeking Foundations for the Science of Cyber Security: Editorial for Special Issue of Information Systems Frontiers. Information Systems Frontiers, 23(2), 263-267.[2] Daszczyszak, R., Ellis, D., Luke, S., & Whitley, S. (2019). TTP-based hunting. MITRE CORP MCLEAN VA.
[3] Nicol, D. M., Sanders, W. H., & Trivedi, K. S. (2004). Model-based evaluation: from dependability to security. IEEE Transactions on dependable and secure computing, 1(1), 48-65.
Birmingham, 03/04/2022
"Fearmongering"
I was once very young (in the 80's early 90's) and I still remember people and the media going crazy and talking about the "hole on the ozone layer". That's how all started for me. We were suppose to protect ourselves specially around 11am to 14pm, and they would track the hole in (near) real-time and report it constantly over the tele.
What is fearmongering?
"Fearmongering, or scaremongering, is the action of intentionally trying to make people afraid of something when this is not necessary or reasonable."
Cambridge Dictionary↗ (on-line) |
From that onwards, I heard about the disastrous consequences of the "Millenium Bug" (or Year 2000 Bug, or Y2K) that, let's take a moment to digest, was widely discussed in both 1999 AND 2000! Nowadays people talk about the "Climate Emergence", and the nefarious consequences to future generations and so on.
That crisis was obviously averted.
Look, I am a scientist, I believe in science (yes, yes, I know this is not a widely accepted stance), and I trust science in my daily life encounters with almost everything I interact in my daily routine. I understand the difficulties of learning complex phenomena and provide evidence and facts, however, I think that this 'catastrophe mode' will take us nowhere.
Over the years, we came to understand that scientists tackled the Ozone Layer problem through sensible reductions of chlorofluorocarbons (CFC) gases in the atmosphere, among other actions. And for the Y2K bug, computing scientists worked head on to modify systems to cope with it, with no massive problems to users. If we, as humanity, have a problem, we should try to first understand it (really understand it), reason about it, devise experiments to confirm/refute our hypothesis, and act on it, diminishing its impact to the populace. Let's wait and see.
Now, let's do some fearmongering of our own.
Our next computing related crisis is set to happen on Tuesday, 19 January 2038, by 03:14:07, where the latest time since 1 January 1970 systems may store using a signed 32-bit integer will be set, in what it's called the "Year 2038 Problem" (or "the epochalypse"↗). Well, we have 17 years (as of 2021) to either stop using this outdated 'technology' altogether or update systems (somehow) so they don't stop working when that fatidic timestamp arrives.
Birmingham, 03/11/2021
"Science is the most likely answer"
The collapse of Arecibo’s dish and the institutional neglect over a wide timeframe has got me thinking about science.
About its advances in the past 20 to 30 years. About our lack of understanding on how the brain or consciousness work, whether we are alone in the vast infinite universe or if other species live and breathe in Earth-like (or not) planets.
Another example concerns the ocean’s floor; I learned that it is not thoroughly mapped as of today. We have gaps in knowledge about Mars, and Venus is like a mythical place where odd things happen.
Space in general is a huge (infinite) unknown variable.
Sadly, to this day, many people somehow still think Earth is flat, the horoscope is somehow based on facts for a lot of people, socialism is communism, centre is left, left is alt-left, and viruses are secretly bio-engineered to harm specific populace or track the movement of 90 years old ladies from Coventry.
In times of uncertainty and difficult to grasp science facts, the easiest, superficial, not based on evidence explanations are accepted and embraced as the only truth and if you don’t go along, then you’re not my friend or like-mind belonging to my hive.
God did this, the oracle predicted that, a divine intervention occurred there, a miracle, unexplained activities, unknown flying objects (regardless of improving resolution, bystanders insist on using outdated cameras and shimmering hands), and so on.
For our sake, in many situations Occam’s Razor provides the perfect explanation. Sadly, this is not true in our confirmation biased new world order.
Although it is often boring, people seem to prefer more ‘colourful’ explanations with no basis in reality. Those ‘explanations’ are more like hallucinations or weird dreamlike situations.
To my complete dismay, relentlessness and sleepless nights, a lot of today’s efforts in Research & Development in big companies are directed to product advertisements (not surprisingly the F and G in FAANG+M are fundamentally ad-oriented enterprises).
Buzz Aldrin professed "You promised me Mars colonies. Instead I got Facebook." How sad. That (weird) social network owner and visionaire extraordinaire is now a billionaire.
Some Internet based companies main focus is to ‘discover’ and ‘research’ new ways of targeting products to consumers, tailored to their posts and attached to their personal world views and moral standpoints.
Does society need that? Maybe the capitalist society thrives and feeds on exactly that. The result is a large amount of distracted and unproductive people always needing the next gadget to fulfill their frivolous desires.
Social networks are ripe of posts of successful stories only. Not many of those are depicting stressful situations, humiliating stepping stones, people bullying you around, or any difficulties throughout harsh life paths. Only good things, people laughing and having a good time abroad or in restaurants - these things have been debated to exhaustion, so I won’t bother.
Searching stuff around it’s the same. It is a version of what is expected, curated by some tailored algorithm that knows everything about you. It’s the same for the news, it shows and presents world views of someone else’s, based on things someone wants you to watch.
In the current Internet you can’t exactly find what you are looking for, just a glimpse of some company sponsored data piece a piece of software puts in front of you to digest.
The difficulty is and has always been about asking the right questions. Especially in a world plagued by ChatGPT (added excerpt on 9/4/23). Remember that we, as researchers, should embrace difficult to grasp ideas and try to explain and justify those to broader audiences with abstractions and useful artefacts that convey ideas and outcomes.
Scientific results with the wrong questions end up at the Limbo of Oblivious Papers - those that will be certainly retrieved in searches but never actually read or referenced by others.
How to escape such inevitability? How to make relevant remarkable things? How to build novelty on top of other people’s work? How to actually capture the interest of audiences? How to influence other people? How to impact and change prevalent conceptions?
There are no easy answers to any of these questions. There is no overarching framework, mindset or model that fits all. And that is what science is all about. The systematic pursuit of knowledge and the truth. Diffusing ideas to broader audiences. Asking and trying to answer good relevant research questions that impact human’s livelihoods.
This process though must be conducted with sound and solid research combined to firm ethical grounds.
Paying close attention to all research phases, hypotheses, designing experiments, choosing metrics, measuring, collecting, and commenting results and observations.
Never disregarding your scientific integrity, since, at the end of the day, it is your reputation on the line.
Whenever you are pleased with what you achieved, then it's time to stop your contribution and suggest improvements so other researchers may use your work to advance other techniques and ideas.
Birmingham, 22/06/2020
"Clever Title"
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
More content and ranting away.
Dividing content with horizontal rules.
Finally, ending it and adding a date.
Birmingham, 01/01/1970