Securing The Hardware Supply Chain

This is the third part of a series about trust in digital content that might be called:

Is this the real life?
Is this just fantasy?

We are moving down the stack:

• The first part was Certificate Transparency, about how we know we are getting content from the Web site we intended to.
• The second part was Securing The Software Supply Chain, about how we know we're running the software we intended to, such as the browser that got the content whose certificate was transparent.
• This part is about how we can know that the hardware the software we secured is running on is doing what we expect it to.

Below the fold, some rather long and scary commentary.

Meta: Impending Blog Slowdown

So far this year, I've been averaging 1.8 posts/week, but this rate can't be maintained for the near future. I'm sorry about that, but quite apart from grandparent duties over the festive season, there are several reasons:

• Certificate Transparency and Securing The Software Supply Chain each took quite a lot of research and thought. The promised hardware follow-up looks like it will take significantly more.
• I've been asked to write a report on using cloud storage for preservation. I will start on this after the New Year, and expect it will take only slightly less work than Emulation and Virtualization as Preservation Strategies.
• I've been consistently critical of the prospects for decentralized Web applications such as Solid, decentralized storage services, and decentralized social networks. I need to find some time to try them out for myself and report on the experience, as Andreas Brekken did for the Lightning network.

So the 40-odd draft and note-form posts in my queue will just continue to gather dust for a while.

Securing The Software Supply Chain

This is the second part of a series about trust in digital content that might be called:

Is this the real life?
Is this just fantasy?

The first part was Certificate Transparency, about how we know we are getting content from the Web site we intended to. This part is about how we know we're running the software we intended to. This question, how to defend against software supply chain attacks, has been in the news recently:

A hacker or hackers sneaked a backdoor into a widely used open source code library with the aim of surreptitiously stealing funds stored in bitcoin wallets, software developers said Monday.

The malicious code was inserted in two stages into event-stream, a code library with 2 million downloads that's used by Fortune 500 companies and small startups alike. In stage one, version 3.3.6, published on September 8, included a benign module known as flatmap-stream. Stage two was implemented on October 5 when flatmap-stream was updated to include malicious code that attempted to steal bitcoin wallets and transfer their balances to a server located in Kuala Lumpur.

See also here and here. The good news is that this was a highly specific attack against a particular kind of cryptocurrency wallet software; things could have been much worse. The bad news is that, however effective they may be against some supply chain attacks, none of the techniques I discuss below the fold would defend against this particular attack.

Software Preservation Network

The Software Preservation Network has two major interrelated achievements under its belt already:

• Best Practices in Fair Use for Software Preservation
• A Preservationist's Guide to the DMCA Exemption for Software Preservation

Below the fold I look at both of them.

Blockchain: What's Not To Like?

I gave a talk at the Fall CNI meeting entitled Blockchain: What's Not To Like? The abstract was:

We're in a period when blockchain or "Distributed Ledger Technology" is the Solution to Everything™, so it is inevitable that it will be proposed as the solution to the problems of academic communication and digital preservation. These proposals typically assume, despite the evidence, that real-world blockchain implementations actually deliver the theoretical attributes of decentralization, immutability, anonymity, security, scalability, sustainability, lack of trust, etc. The proposers appear to believe that Satoshi Nakamoto revealed the infallible Bitcoin protocol to the world on golden tablets; they typically don't appreciate or cite the nearly three decades of research and implementation that led up to it. This talk will discuss the mis-match between theory and practice in blockchain technology, and how it applies to various proposed applications of interest to the CNI audience.

Below the fold, an edited text of the talk with links to the sources, and much additional material. The colored boxes contain quotations that were on the slides but weren't spoken.

Update: the video of my talk has now been posted on YouTube and Vimeo.

Irina Bolychevsky on Solid

Although I'm an enthusiast for the idea of a decentralized Web, I've been consistently skeptical that the products proposed to implement it have viable businesses. Two months ago, in How solid is Tim’s plan to redecentralize the web?, Irina Bolychevsky (@redecentralize founder and self-described "product person") made related points. Below the fold, some commentary.

Selective Amnesia

Last year's series of posts and PNC keynote entitled The Amnesiac Civilization were about the threats to our cultural heritage from inadequate funding of Web archives, and the resulting important content that is never preserved. But content that Web archives do collect and preserve is also under a threat that can be described as selective amnesia. David Bixenspan's When the Internet Archive Forgets makes the important, but often overlooked, point that the Internet Archive isn't an elephant:

On the internet, there are certain institutions we have come to rely on daily to keep truth from becoming nebulous or elastic. Not necessarily in the way that something stupid like Verrit aspired to, but at least in confirming that you aren’t losing your mind, that an old post or article you remember reading did, in fact, actually exist. It can be as fleeting as using Google Cache to grab a quickly deleted tweet, but it can also be as involved as doing a deep dive of a now-dead site’s archive via the Wayback Machine. But what happens when an archive becomes less reliable, and arguably has legitimate reasons to bow to pressure and remove controversial archived material?
...
Over the last few years, there has been a change in how the Wayback Machine is viewed, one inspired by the general political mood. What had long been a useful tool when you came across broken links online is now, more than ever before, seen as an arbiter of the truth and a bulwark against erasing history.

Below the fold, some commentary on the vulnerability of Web history to censorship.