Some iconic 9/11 news coverage is inaccessible due to the end of Flash support

When I took a film exhibition class and we had a class on showing older films, I was surprised to hear that old analog 35mm film was considered the gold standard of archival formats for film preservationists.

The reason why digital formats, formats where the data is not liable to degrade over time, are not considered better is because “the formats keep changing”.

Of course you can encode your media in a lossless format, carefully choose open formats over bespoke proprietary formats, transcode as needed for the latest codecs, and if all else fails, play it in an emulator, which can run the proprietary codec.

Most people in the public, artistic professionals, and the journalists, are at the application level. They want to plug something in and have it just work. If you say you have to put thought into how you do something, it’s equivalent to saying it’s too hard and you basically can’t do it.

Besides, why should they hire you and me to play this media? They basically didn’t have this problem for decades with film/video. Then we, as technologists, come in with new wiz-bang toys that break compatibility every few years. If they’re being uncharitable, they see us as coming in with solutions to problems our industry imposed on them. I can see how technology could even be seen as racketeering. For journalists, technology has been bad for the business model and imposes new costs. Not a great look.

As such, it sounds like the "lost" content the article discusses is lost in the sense that nobody is preserving it, not in the sense that something is preventing it from being preserved.

You make it sound like this is inevitable. It's the byproduct of a bunch of other decisions, only some of which are intentional. As you say, mainframes. If we wanted to secure longevity, we could. Unfortunately, this churn is very profitable for a lot of the people who, given a free market, decide whether we will do that or not.

- The document should be archived to a place where people actively manage the archives. Servers and domain names may vanish, long term backups are incredibly hard, we need something robust managed by dedicated experts.

- use pure text, encoded in ascii UTF-something. These encodings are widespread and unlikely to vanish, or many things would be inaccessible anyway.

- use simple HTML, with medias (images, videos, sounds) embedded in a standard way using img, audio, video, possibly object tags. HTML is widespread, and it's still relatively easy to build a web engine that will render this into an exploitable result. At worst, one can skim through an HTML code or search for keywords in it, even if it's not perfect.

- using the XHTML syntax might help: it's way easier to re-build an XML parser than a complete HTML5 parser with all the weird rules

- The document should render legibly with JavaScript disabled so we don't require our lineage to maintain a JavaScript engine or run some sort of emulator with outdated software.

- The document should render legibly with CSS disabled. At worst, building a simple HTML engine will probably still be easy to do.

- The document should render legibly without any custom font that might not be exploitable in the future

- If you can't help requiring CSS, use simple CSS directives. This may increase the chances for our lineage to be able to rebuild a simple web engine with just the necessary stuff to render the old documents;

- if you can't help using Javascript, all the important resources should at least load at page load (except for images / videos / medias if they are lazily loaded using the lazy HTML attribute or something of the sort). It will probably ease archival a lot. It should not be necessary to run your code to figure out how to retrieve all the document's dependencies.

- anything animated by custom code is more likely to be inaccessible in the future. Sometimes it's necessary, but the document without those parts may still be valuable for future historians. It may help describing those parts in the text of the document so at least historians will be able to know that something is missing and what.

- don't use anything relying on a closed specification. Ideally use widespread standards only. Open but not widespread standard will probably not be re-implemented by historians.

- if HTML or something similar like DocBook is not used, an easy to re-implement subset of PDF is probably ok. Many things are only available in PDF so historians will probably have to find a way to manage PDFs. PS might be ok too.

- text in Unicode is probably way better than text embedded in images or drawn as shapes in vector formats. In the future, people might not use the same alphabets as the ones we are using today, recognizing our letters and signs will be probably hard for them. At least Unicode would provide them a way to render our letters in a standard, unique, easy to manage way.

CDNs are another aspect to consider: they can vanish, losing dependencies of your document. The document should be archived before this happens.

The problem with complex Javascript code: as long as web engines are well maintained, we are probably good. We can hope that backward compatibility will be kelp, but the more the document uses complex / advanced features, the more it is likely to use an API that will be deprecated and then removed. It has already happened. Try using -moz-border-radius today for instance.

But even with web maintained engines, complex code will probably make it harder to handle the document for archival and consulting (one thing an historian may want to do is search for keywords in an archive. But if the content appears only when some complex code is executed, it may be difficult to manage).

We also cannot assume that web engines as we know them today are going to be maintained forever. A revolution might happen. Applications could move from the web to another runtime, making the maintenance of a browser engine expensive and overkill. A new format adapted to documents could appear. Or a new way of producing, transmitting and viewing content.

Unfortunately, it's very hard and costly to implement a Javascript engine with all the features provided by the web engine + a full web engine with all the whole CSS feature set from scratch. We'd better make the life of our future historian easier by not over using the features we have today to write documents.

Microsoft and Apple hated it because the plug-in was a top vector for malware on their OSes. Browser vendors, so Microsoft and Apple plus Google and Mozilla, hated it because it was a top vector for malware in their browsers and forced their hand with respect to plug-in APIs. Apple triply hated Flash because it's performance on the Mac was terrible compared to Windows. That was the status quo before the iPhone was released.

Flash Lite on early smartphones was barely Flash. It was more an ActionScript 3 runtime with a limited version of Flash's drawing engine. It couldn't play arbitrary SWFs on the web.

The Flash plug-in Adobe eventually released for Android was also pretty awful. It had terrible performance and was a battery killer. SWFs designed for WIMP desktops also worked for shit on touchscreen Androids. The plug-in was terrible at translating touch events to click and drag events. It demonstrated pretty clearly every argument Apple made about keeping it off the iPhone.

Adobe was not a capable steward of the Flash plug-in/runtime. What little effort they devoted to the plug-in was focused almost entirely on the Wintel platform with all others being effectively ignored.

Adobe killed Flash by a thousand tiny cuts from mismanagement and lack of interest. Their business model for the past two decades has been rent seeking on products they bought with Photoshop money and then stuck in maintenance mode. They were only interested in Flash insofar as it would allow for more rent seeking.