meejah
commented
3 years ago My understanding, possibly misguided, is that operating systems also open files based on their extension instead of based on their content. This would mitigate concerns that a PNG file would automatically be opened as an executable.
Not precisely .. for example on Linux, if you set the "executable" bit on a file and then try to run it (e.g. in a terminal, or double-clicking in certain GUI programs) then the OS will try to run it. If it turns out that there was a valid ELF file in kitty.png then it'll work.
Further muddying the waters, it's possible to create files that are in fact several valid formats at once -- e.g. see research here: https://fahrplan.events.ccc.de/congress/2014/Fahrplan/events/5930.html
So, determining the "type of a file" seems like a simple problem but is in fact pretty complex. (And unfortunately, the weird edge/failure cases are likely to be the security-relevant ones we're interested in).
It's maybe useful to discuss why we want to display different icons.
If the point is to "do whatever the OS does" then we should use OS-specific APIs to figure out an icon (instead of hard-coding our own list).
If the point is to give the user confidence about what kind of file they're receiving then we should use some sort of "format validation" library or similar (so that we don't tell the user that foo.png is a picture if it's actually a Java program or shell-script instead).
I think a hard-coded mapping of "extension -> icon" is bound be be wrong / incomplete / out-dated and probably gives the user confidence that they shouldn't have (e.g. "the software says it's an image, so that's safe") or even give them unfounded fears (e.g. "the software didn't find an icon for foo.jpe so that's maybe malware").
Improvement
Improve the sender/receiver's experience, by displaying an icon relevant to the file type that they are expected to send/receive. This can help them by confirming they're sending what they expect to send, or help them by aiding their understanding of what kind of file they would be receiving.
Existing behavior
At the moment, users see a general file icon at various stages of the send/receive flow. Namely, on:
Example:
While users are presented with useful metadata, namely filename/extension and file size, not everyone is familiar with what file type extensions mean. Operating systems generally provide more information, by showing an icon belonging to the specific file type.
New behavior
We should display a relevant icons for commonly used file types.
As a first pass, we can use the categories of files with associated file types listed below.
The to be used icons can be added to this issue later.
The file types/groupings listed below are informed by these resources by Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types https://developer.mozilla.org/en-US/docs/Web/API/File/type
Audio:
Image:
Video:
Document/text:
Compressed/archive:
Other/General file (every other file extension, including...):
Risks/tradeoffs
The icon we would display would be based on the file extension, as opposed to the actual file type (based on the content of the file). This extension can be manipulated. This means that if someone sends a malicious executable but renames it to .png, the receiver could think they are receiving an image as opposed to an executable. My understanding, possibly misguided, is that operating systems also open files based on their extension instead of based on their content. This would mitigate concerns that a PNG file would automatically be opened as an executable.