4 ms·

It seems like the only real issue here is that a file:// URL can make a network request. Who could ever think that that would be a good idea?

aaronharnly 6y ago
People who were building next-generation networked computers in the late 1980s and 1990s?
zimpenfish 6y ago
> a file:// URL can make a network request. Who could ever think that that would be a good idea? Anyone with networked filesystems, I should imagine?
- rualca 6y ago
  >>Anyone with networked filesystems, I should imagine? You're either missing the point made by GP or being disingenuous. Please keep in mind that you need to explicitly mount a NFS before you're able to open it, and mounting a NFS not only requires explicit authorization but also only provides access to a specific file system mounted in a specific point following specific permissions. Accessing the whole internet through file:// without being prompted for permissions or consent or even awareness is an entirely different thing. For starters, the access is not explicit nor subjected to conditions.
Tepix 6y ago
No, the fact that .TXT files got interpreted as HTML is worse.
- kergonath 6y ago
  Rigidly interpreting documents depending on their file extension is worse than trying to figure out the type of a document before interpreting it. File extensions are a brittle and primitive system that does not fix any security issue.
  - lmm 6y ago
    File extensions are simple and, crucially, visible and understandable to the user. They're far better than any proposed alternative.
    - fouric 6y ago
      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.
      - lmm 6y ago
        > 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.
        kergonath 6y ago
        > Only in software that ignores the extension No, only in software that blindly follows file extensions.
        lmm 6y ago
        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.

aaronharnly 6y ago

People who were building next-generation networked computers in the late 1980s and 1990s?

zimpenfish 6y ago

> a file:// URL can make a network request. Who could ever think that that would be a good idea? Anyone with networked filesystems, I should imagine?

rualca 6y ago
>>Anyone with networked filesystems, I should imagine? You're either missing the point made by GP or being disingenuous. Please keep in mind that you need to explicitly mount a NFS before you're able to open it, and mounting a NFS not only requires explicit authorization but also only provides access to a specific file system mounted in a specific point following specific permissions. Accessing the whole internet through file:// without being prompted for permissions or consent or even awareness is an entirely different thing. For starters, the access is not explicit nor subjected to conditions.

Tepix 6y ago

No, the fact that .TXT files got interpreted as HTML is worse.

kergonath 6y ago
Rigidly interpreting documents depending on their file extension is worse than trying to figure out the type of a document before interpreting it. File extensions are a brittle and primitive system that does not fix any security issue.
- lmm 6y ago
  File extensions are simple and, crucially, visible and understandable to the user. They're far better than any proposed alternative.
  - fouric 6y ago
    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.
    - lmm 6y ago
      > 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.
      - kergonath 6y ago
        > Only in software that ignores the extension No, only in software that blindly follows file extensions.
        lmm 6y ago
        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.