Optimizing for "simple" for the sake of robustness is exactly backward.
> visible and understandable
False. Something is neither visible nor understandable if it's misleading - which file extensions are. There are absolutely no guarantees that a file extension will match file contents, and that assumption can cause security risks - like in this article.
An actually good alternative is to encode file type as metadata, instead of inside the file contents or file-name, and then configure viewers to display it. That, while not "simple", is also visible and understandable to the user, while simultaneously being safe.
> There are absolutely no guarantees that a file extension will match file contents, and that assumption can cause security risks
Only in software that ignores the extension.
> An actually good alternative is to encode file type as metadata, instead of inside the file contents or file-name, and then configure viewers to display it. That, while not "simple", is also visible and understandable to the user, while simultaneously being safe.
Metadata can be just as wrong as a file extension, and is generally far less visible.
The problem is that the text editor ignored the extension of the txt file. That's what lead to unsafe behaviour - the user thought the file was fine to open because the extension was txt, and improving users is not practical.
The exact same thing would happen with metadata - indeed file extensions are just a form of metadata - if the metadata says this is a text file but the application ignores it, we would have the exact same issue.
> They are also trivial to get wrong, can be mangled when the files are moved around, and are easy to use as an attack vector.
On the contrary, they're the only kind of metadata that doesn't get mangled when files are moved around, and they're far less of an attack vector than other approaches. Of course you can set the wrong file type, but no approach avoids that problem.
