When I first saw an analysis of Microsoft Recall, I was puzzled. Recall is the new feature that lets you recall anything you did on your Microsoft Windows workstation. You can get back to websites you visited or presentations you worked on by merely describing them. This feature is quite useful. I always thought Microsoft did not put smart enough search features; so now they did. What puzzled me still was not why the feature is needed, but why it is built the way it is. It just seems too inefficient.

Recall is based on taking snapshots, yes, screen-grabs, of your computer screen once every few minutes or so, while you’re working, storing them, processing them using AI, and using the resulting information to understand what you are working on, so you can recall it later. Really?! Is this the most efficient way to get what we want? What happened to good old indexing of data, like all search engines do? Does Google take graphic screen-shots of what web pages look like on the screen just to throw tons of expensive AI cycles on them to extract a textual description of what they are about?

It’s only when I started thinking of what could be the real motivation behind the Recall feature, that I could finally understand this design decision. No, it has nothing to do with security.

This book was written of respect to Bill Campbell, a football coach that became a coach to executive teams in Google, Apple, Amazon, Twitter and Facebook. This guy is more anonymous than he should have been given the number of high profile executives that used his services to great success.

I found myself inspired to think of where should the World Wide Web go in utilizing Artificial Intelligence.

I would like to tackle this from the information security front. Like many security people who grow up, I also start seeing security as a problem that goes beyond technology. I’m not referring now to non-technical solutions to solve technical security problems (like user awareness training), but the other way around: the non-technical security risks to people and societies that may call for technical solutions.

The first decade or two of the Web was devoted to making this information highway faster, more accessible, and support advanced information provisioning use-cases (audio, video, interaction, etc.) The following decade or two were devoted also to increasing the amount and diversity of that information and its sources, with Web 2.0 and user-generated content replacing the traditional waterfall model. The upcoming years should, in my opinion, be dedicated to improving the Web in areas that emerged as challenges by our successes of the first 30 years.

TL;DR: A useful read for the inquirer. Just as good as the summary for the practitioner.

I finally got to read The Checklist Manifesto by Atul Gawande. This is years after I read the CapitolReader summary of the book, which is one of many summaries of this book. I became excited with the idea presented in the book by just reading the summary. The main idea is that the simple mechanism of checklists can be used to improve performance, and safety, in many areas from surgery to construction. Checklists are a useful mechanism to guarantee that known wisdom is put to use when needed, even at times of stress and cognitive overflow. After all, the challenge is often not the know-how we don’t have but the vast amount of know-how we do have but fail to use when needed.

After reading the summary I became an advocate of checklists. I use them wherever I can. I even wrote my own software that generates different instances from master checklists for different uses, some as simple as travel packing and preparations.

The book by Atul Gawande is interesting and well-written. Slightly to my disappointment, however, reading the book does not add much on the pragmatic creation and use of checklists. It mostly covers the experiences and evidence of the uses of checklists in different areas, as well as research into their usefulness. It is an educating read on the study of the merits of checklists, but perhaps less of a guide for checklists practitioners.

When we hear of a new way in which artificial intelligence (AI) can risk humanity, or even just move someone’s cheese, the debate often changes to whether or not we should pause AI development until some impact analysis is carried out, or some regulation kicks in.

I do not think that pausing AI development is even a plausible option to be considered. History has shown that technology never stops. We have tried this in areas that are much riskier for humanity, and without much success. We should accept that Humanity is insufficiently consensus-driven, and the stakeholders in AI technologies have too many easy ways to bypass bans, and too many good reasons to do so. Yes, there is serious lobbying promoting this pausing option, but I would argue that most is for pausing productization, rather than development, and is, to a notable extent, led by players who are just late in the market and need some time to catch up.

I finally got to read the book “Getting Things Done” by David Allen. I have read quite several books on time management and related topics, so I was almost surprised that it took me so long to get to this particular one, which is considered by many as a classic. I got to this book more or less by mistake. A while back I started using a command-line task management tool called TaskWarrior, another old Linux tool that has been known to anyone but myself for decades. This tool referred to the “Getting Things Done” methodology that was taught in the book, so I ended up reading the book as well, out of appreciation for some of the features that were inspired by this book.

I am not going to summarize this book now, nor the GTD methodology. There are dozens of write-ups about it by now. I am also not going to describe that TaskWarrior program, because this would not be the best use of your time or mine. Instead, I will discuss my most important findings: those relatively novel ideas of task management that I adopted from either the book or the software, or even just from my own experience with the two (even if not directly taught by any of these). So it’s not really a book review, but just my own takeaways that were either written in the book or were somehow inspired by the book, or by the software that I am using.

Blockchains, DeFi, DAO, and Web 3.0 in general, all carry the message of decentralization, and particularly of decentralizing financial systems. Decentralization means, for the most part, eliminating the trusted authorities that are involved in various types of transactions. Those transactions could be agreements (to be facilitated by decentralized smart contracts) and the transfer of funds in general (to be facilitated by Bitcoins and alike). Centralization of financial services is considered evil, because the middlemen often have their own incentives, and even when they don’t, they often charge a lot for their essential role in the system. As we move into the decentralized era, we have smart contracts, which enforce themselves using machine code, without a trusted executor, and Bitcoins, which carry value and can be transferred between people without them having to trust any specific or state-owned service provider. Nice.

This post is neither for nor against decentralization. As I see it, nothing can be said against what is essentially an option. A decentralized system is considered as such because it does not require a centralized authority, not because it does not allow one to exist. If you find that you really miss a middleman, then you can always appoint one. If you want the state bank to manage your Bitcoins, then nothing would prevent that. You get an option, and having options is always good.

This post discusses how suitable the current decentralized financial systems are, considering the world they operate in. My take, as the title may disclose, is that while decentralized systems are an excellent idea and a worthy option, their current implementation suffers from shortcomings that we will just have to fix before they can become mainstream. There are many shortcomings, of course, and who am I to even enumerate them, so I will focus on one: the decentralized systems today assume too much perfection; it’s not that they don’t work well — it is that they don’t fail well.

I recently read the book Decisive by Chip Heath and Dan Heath. This is one of the better growth books I’ve read lately, because it nicely combines scientific truths with actionable guidelines. Most growth books are either purely motivational, repeating shallow inspirational mantras with small tweaks, or they present solid logic that explains how things could be better, just without much hints on how one can put this logic into practical use. This book, on the other hand, explains well-substantiated pitfalls in our decision-making logic and also offers simple mental hacks to help us overcome those pitfalls. I also liked that each chapter concludes with a single-page summary that makes it easy to recap what was taught and the conclusions of each chapter. I find this immensely useful because I’m the type of person who reads very little each day, and not every day, so reading a single chapter can sometimes take me weeks.

The rest of this post lists my key takeaways from this book.

I recently read a good essay by Alex Gantman titled: “A Corporate Anthropologist’s Guide to Product Security”. It’s a year old, but I did not notice it before, and in any event, its contents are not time-sensitive at all. If you’re responsible for deploying SDLC in any real production environment, then you are likely to find much truth in this essay.

Every company that has both development teams and security teams also enjoys a healthy amount of tension between them. Specifics of the emotions involved may vary, but quite often security guys see developers as: not caring enough about security, focusing on short-term gains in features rather than on long-term robustness, and all-in-all, despite best intentions, still not “seeing the light”. Developers, in turn, often see their security-practicing friends as people with overly intense focus on security, which blinds them to all other needs of the product. They sometimes see those security preachers as people who maintain an overly simplistic view of the product design, and particularly of the cost and side-effects of the many changes they request for the sacred sake of security.

People of both camps are to a certain extent right, and to a certain extent exaggerating and not giving the other side enough credit. And yet, it doesn’t even matter where the truth lies, nor if there is truth at all. What matters is that there are two groups that are both essential for product success, and which should work towards a common goal: a product that has many appealing properties, including security.

The rest of this post presents tips for proper collaboration between security and development teams, specifically where it comes to setting and implementing security requirements. Due to my default affiliation with the security camp, the actions I prescribe are targeted primarily at the security people, but I hope that both developers and security practitioners can benefit from the high level perspective that I try to convey in the following five tips.