Digital Preludes

II

Poor interoperability prevents File over app software from spreading.

When sharing files over email or messaging apps, we’re effectively limited to a handful of universally supported formats: images, word documents, spreadsheets, presentations, and PDFs. These traditional formats can’t natively handle structured data like machine-readable invoices or digital attestations. When you attach files in newer formats directly to messages, recipients face confusing previews and often don’t know how to open or interact with them.

Some developers have found a clever solution: embedding structured data inside commonly supported file formats. For instance, Inline XBRL embeds financial reports directly into HTML web pages. This works well in some contexts, but email clients block HTML files by default for security reasons, which limits the practical utility of this approach.

Portable documents offer a more promising path. PDF/A-3 (ISO 19005-3:2012) introduced support for embedding arbitrary files as attachments.

A compelling example is Factur-X, which applies this feature to embed EN 16931-compliant machine-readable invoice data within human-readable PDF invoices.

What makes this approach particularly powerful is that the human-readable pages can include instructions for recipients, explaining how to use specialized software to process the embedded data more efficiently.

Portable documents thus provide more than just a technical wrapper for structured data: they offer a standard embedded user interface. Anyone can read the document immediately with common software, while machines can automatically process the embedded data when appropriate software is available.

Introducing Areal, Are.na’s New Typeface

It only makes sense that a revival of del.icio.us (but better) now uses a revival of Arial (but better). Dinamo designer Johannes Breyer in conversation with the Are.na team:

Now that type software has advanced so much, and we can draw perfect curves and streamline so many steps, some of these elements of Arial feel like a human touch among today’s digitally-produced fonts. It becomes interesting and important again.

Java Card++ ?

In March 2025, Adam Gowdiak disclosed the first public eSIM compromise. His lab extracted private keys from a chip using malware in an eSIM profile – abusing a vulnerability in the Java Card platform. Longtime contributor Eric Vétillard reflects on an architectural root cause:

The real surprise is not that this has happened. It is that it took over 25 years for it to happen. The lack of on-card verification has always been a weakness in the Java Card story. Over the past 25 years, there have been a few attempts to address the issue, but the industry never adopted them. Isn’t a solution to this issue a bit overdue?

The weak spot is bytecode verification: normally a JVM checks applet code for illegal instructions, but Java Card leaves this to off-card tooling to save memory. That was fine when each card had one provider, but eSIM introduced multi-provider provisioning. Now one applet can spy on another.

New bytecode formats could make on-card verification possible, and this exploit may finally push the change. Until then, service providers should verify profiles server-side, and developers cannot take on-chip confidentiality for granted.