We Tried to Keep Plaintext Only in Memory. Microsoft Word Said No.

A reporter attempted to open an encrypted .docx file in Microsoft Word without ever writing the decrypted document to disk. The ideal scenario involved decrypting only the requested bytes and keeping the plaintext in memory, eliminating the need for a temporary .docx file. The Windows Cloud Files API seemed like a perfect solution, enabling placeholder files whose content is provided on demand.

The reporter built a test where the placeholder contained no document data, and the real bytes were kept in memory and served when Windows requested them. When Word opened the file, it worked, but Windows had written the hydrated contents to disk. The reporter then tried streaming mode, which successfully returned the plaintext without creating a normal file on disk.

However, Word experienced an error when trying to open the file. Word's behavior required a representation of the file that could be backed by a Windows section object or memory mapping, which Windows couldn't create over temporary streamed responses. This issue wasn't just a Word quirk; the storage model itself was incompatible with the application's expectations.

The reporter's compromise involved hydrating the plaintext file, opening it in Word, keeping it hydrated for the active session, and dehydrating it when the session ended. This solution worked, but it changed the security model, ensuring the plaintext existed on disk only during a controlled working session and was removed afterward.

The experiment highlighted that cleanup isn't just a matter of cleanup when dealing with plaintext; it becomes part of the security model. The larger lesson was that the original idea of plaintext existing only in RAM was ideal, but software you don't control might make assumptions incompatible with this architecture. The safer practical model involves creating a temporary protected working session with explicit cleanup and crash recovery.