Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is the alternative? If you don't trust the information that is sent with the file, do you expect the user to decide on the format of each file?

The file type is an inherent pair of the file content, and must move together. Otherwise your images and documents become only a meaningless set of bytes. The information that "this is a png image" is as much a responsibility of the machine that is sending you the file as the pixel data.

Also, yes, accepting random data from a network is a big security risk. It's up to your OS to handle that data in a secure way, but this is not done by removing the "this is an executable" mark.



The obvious alternative is to have metadata about file in a separate descriptor, which could be saved either in first N bytes of the file, or in the file allocation table itself. However implementing this in this age would be impractical as it would break interoperability with every other (still alive) OS out there.


> have metadata about file in a separate descriptor

Maybe that metadata could be stored in the file's name, like "<filename><separator><format identifier>" or something?

ducks


> However implementing this in this age would be impractical as it would break interoperability with every other (still alive) OS out there.

It's deeper than that, although this is a very good point.

Who teaches the OS what file types exist? How is that updated?

You could rely on the OS vendor, but that's a bottleneck, especially for a consumer-focused OS where most of the applications (and, therefore, most of the application file formats) are not created by the OS vendor, or entities working in concert with the OS vendor. You could have a great new file format and a great new application and be unable to use it, or get anyone else to use it, because the people behind the OS haven't caught up yet, or because the OS updates haven't percolated out yet.

You could trust the application vendors to do it, which is a security hole: The ScuzzyTech Hyper Word Processor really, really wants to open your word processing documents, so it can synergize your monetization with microtransaction-based leveraged technologies. Therefore, all of your Normalcore Text Documents are now ScuzzyTech Hyper Word Documents only to be opened by the ScuzzyTech Hyper Word Processor, because the ScuzzyTech code helpfully updated all of your filetypes and, therefore, file associations.


You and the other people in this discussion are well on the way to reinventing extended attributes, used for exactly this purpose back in the late 1980s and 1990s in OS/2.


I'm all for a metadata standard that would enable filetype independent fields to live and move with your data.

That said, this gives you no security benefit at all. It's basically the same thing we have now, but done correctly.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: