Digital Preservation Network Is No More

In Why Is the Digital Preservation Network Disbanding? Roger Schonfeld examines the demise of the Digital Preservation Network which was announced last month:

An initial announcement said directly that "After careful analysis of the Digital Preservation Network's membership, operating model, and finances, the Board of Trustees of DPN passed a resolution to affect an orderly wind-down of DPN," including committing to consultations with each member to ensure that content would not be lost in the wind-down. Shortly thereafter, messages came out from DPN's hubs, both individually including HathiTrust, and collectively, characterizing their operating and financial strength and ability to provide for an orderly transition. Because DPN was not itself directly preserving anything but rather a broker for preservation services by underlying repositories, it does not appear that any content will be put at risk.

Below the fold, I look at various views of the lessons to be learned.

Trust In Digital Content

This is the fourth and I hope final part of a series about trust in digital content that might be called:

Is this the real  life?
Is this just fantasy

  The series so far moved 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.
• The third part was Securing The Hardware Supply Chain, 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 this part asks whether, even if the certificate, software and hardware were all perfectly secure, we could trust what we were seeing.

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.