Is it time for a new Firefox thread yet?
-
@Onyx said:
Also, isn't it that NTFS is case sensitive but explorer refuses to admit it? I'm pretty sure it quite happily saved both "a.txt" and "A.txt" as two different files when accessed from Linux, but threw a hissy fit when I tried to rename those files in explorer.
By default NTFS is case-insensitive, but case-preserving. However, for POSIX compatibility, NTFS can be set to work in case-sensitive mode, but then having two files that differ only in case will confuse Win32 programs (some programs will be able to access both files, but some programs will only be able to access one of them - and you can't know which of the two files such programs will access beforehand).
-
I don't know how you can discuss that without even briefly mentioning how FUCKING STUPID the very concept of a case-sensitive filesystem is.
-
@Onyx said:
Also, isn't it that NTFS is case sensitive but explorer refuses to admit it? I'm pretty sure it quite happily saved both "a.txt" and "A.txt" as two different files when accessed from Linux, but threw a hissy fit when I tried to rename those files in explorer.
No. It's case preserving but not case sensitive.
Also, the GTK version of the standard dialogs (file open etc.) are one part why I consider it horrible even on Linux.
-
@blakeyrat said:
I don't know how you can discuss that without even briefly mentioning how FUCKING STUPID the very concept of a case-sensitive filesystem is.
We know. That's what makes you, you.
-
@boomzilla said:
@blakeyrat said:
I don't know how you can discuss that without even briefly mentioning how FUCKING STUPID the very concept of a case-sensitive filesystem is.
We know. That's what makes you, you.
You know what's even worse than a filesystem that allows you to name files whatever you want?
An operating system where the name of a file contains instructions on how to run it. I mean, what if someone renames a file?
-
@Ben L. said:
An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
-
@blakeyrat said:
@Ben L. said:
An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
You like Apple, then? Because the only thing worse than that is a filesystem that stores data on how a file is to be used that isn't in any way accessible using file IO.
-
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
-
@joe.edwards said:
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
If the content of a file isn't guaranteed to transfer reliably, you might want to use a different transfer medium.
-
@Ben L. said:
@joe.edwards said:
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
If the content of a file isn't guaranteed to transfer reliably, you might want to use a different transfer medium.
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.
-
@joe.edwards said:
@Ben L. said:
@joe.edwards said:
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
If the content of a file isn't guaranteed to transfer reliably, you might want to use a different transfer medium.
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.What is your OS needing to categorize files for? To generate thumbnails? Don't you need the content for that anyway?
-
@Ben L. said:
@joe.edwards said:
@Ben L. said:
@joe.edwards said:
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
If the content of a file isn't guaranteed to transfer reliably, you might want to use a different transfer medium.
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.What is your OS needing to categorize files for? To generate thumbnails? Don't you need the content for that anyway?
Use case: I want to sort my miscellaneous downloads folder by type so I can move MP3s into my Music directory.
Status: WONTFIX. Not a realistic scenario
Use case: I'd like to have some idea what program is going to launch when I open this file.
Status: WONTFIX. Take a chance, live a little.
Use case: I have a spreadsheet somewhere in my documents tree with my timesheet in it. I think I named it after the date or something. I'd like to recursively search for it.
Status: WONTFIX. Learn regular expressions, chum.
-
@joe.edwards said:
@Ben L. said:
@joe.edwards said:
@Ben L. said:
@joe.edwards said:
@blakeyrat said:
@Ben L. said:
The upshot of meaningful file extensions is that the filename is pretty much the only metadata guaranteed to transfer reliably across all network connections, filesystems, etc.An operating system where the name of a file contains instructions on how to run it.
Damn straight. That's a fucking terrible idea.
Oh... did you expect me to disagree? To paint me as some kind of hypocrite? Sorry.
If the content of a file isn't guaranteed to transfer reliably, you might want to use a different transfer medium.
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.What is your OS needing to categorize files for? To generate thumbnails? Don't you need the content for that anyway?
Use case: I want to sort my miscellaneous downloads folder by type so I can move MP3s into my Music directory.
Status: WONTFIX. Not a realistic scenario
Use case: I'd like to have some idea what program is going to launch when I open this file.
Status: WONTFIX. Take a chance, live a little.
Use case: I have a spreadsheet somewhere in my documents tree with my timesheet in it. I think I named it after the date or something. I'd like to recursively search for it.
Status: WONTFIX. Learn regular expressions, chum.
Use case: I like to make strawman arguments about Ben L. saying file extensions are bad and should never ever be used.
Status: INTENDED. File extensions are perfectly reasonable to use, but should not be directly used (or hidden) by computers.
-
@Ben L. said:
File extensions are perfectly reasonable to use, but should not be directly used (or hidden) by computers.
So what you're saying is the file extension doesn't actually have any effect? I don't even have to trick you with LOVE-LETTER-FOR-YOU.txt.vbs, LOVE-LETTER-FOR-YOU.txt should work just fine.
-
@joe.edwards said:
@Ben L. said:
File extensions are perfectly reasonable to use, but should not be directly used (or hidden) by computers.
So what you're saying is the file extension doesn't actually have any effect? I don't even have to trick you with LOVE-LETTER-FOR-YOU.txt.vbs, LOVE-LETTER-FOR-YOU.txt should work just fine.Well, sure, as long as I'm dumb enough to set the executable bit.
-
@blakeyrat said:
I don't know how you can discuss that without even briefly mentioning how FUCKING STUPID the very concept of a case-sensitive filesystem is.
This.@topspin said:
Also, the GTK version of the standard dialogs (file open etc.) are one part why I consider it horrible even on Linux.
This too. Very much so.@Ben L. said:
An operating system where the name of a file contains instructions on how to run it. I mean, what if someone renames a file?
I never write README files because of this.But seriously, both you are joe.edwards bring up good points. File extensions are great as a quick indication of what a file is, and are even essential for telling apart files of ambiguous types (textual, zip-based, etc.). But they are clearly insufficient on their own.
-
@Ben L. said:
@boomzilla said:
Isn't that why said OS defaults to 1) not showing you the extension by default and 2) not allowing you to change it in that mode, even when renaming the file? (<font style="font-family:Courier, monospace">I'm_not_a_virus_really.txt<font color="gainsboro" >.exe</font></font>)@blakeyrat said:
I don't know how you can discuss that without even briefly mentioning how FUCKING STUPID the very concept of a case-sensitive filesystem is.
We know. That's what makes you, you.
You know what's even worse than a filesystem that allows you to name files whatever you want?
An operating system where the name of a file contains instructions on how to run it. I mean, what if someone renames a file?
-
@Ben L. said:
@joe.edwards said:
assuming your interpreter actually honors the execution bit@Ben L. said:
File extensions are perfectly reasonable to use, but should not be directly used (or hidden) by computers.
So what you're saying is the file extension doesn't actually have any effect? I don't even have to trick you with LOVE-LETTER-FOR-YOU.txt.vbs, LOVE-LETTER-FOR-YOU.txt should work just fine.Well, sure, as long as I'm dumb enough to set the executable bit.
-
@ratchet freak said:
@Ben L. said:
@joe.edwards said:
assuming your interpreter actually honors the execution bit@Ben L. said:
File extensions are perfectly reasonable to use, but should not be directly used (or hidden) by computers.
So what you're saying is the file extension doesn't actually have any effect? I don't even have to trick you with LOVE-LETTER-FOR-YOU.txt.vbs, LOVE-LETTER-FOR-YOU.txt should work just fine.Well, sure, as long as I'm dumb enough to set the executable bit.
You must have a weird relationship with your machine if you're going to run LOVE-LETTER-FOR-YOU.txt through a shell instead of opening with less or more...
-
@joe.edwards said:
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.
The sad truth is that the content is the only thing that transfers even remotely reliably. All other metadata is rather suspect (because users; shit happens). The only common file type that you can't guess reasonably easily by automated inspection of the content is CSV; it looks identical to plain text to a computer…
-
@dkf said:
@joe.edwards said:
The content of a file isn't metadata, now is it? It's just data. And besides that, there are drawbacks to inspecting the content. Do you really want your OS opening each file in a directory possibly containing thousands of files just to figure out what type each one is? Or maybe it should just surprise you when you open one.
The sad truth is that the content is the only thing that transfers even remotely reliably. All other metadata is rather suspect (because users; shit happens). The only common file type that you can't guess reasonably easily by automated inspection of the content is CSV; it looks identical to plain text to a computer…
How about all the file types that are zip or XML files with a different extension (.jar, .xlsx, .docx, .svg, .xslt, app/web.config, etc)?
-
Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
-
@LoremIpsumDolorSitAmet said:
Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
Which is kind of what a file extension is?
-
@LoremIpsumDolorSitAmet said:
Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
The problem is with "universally understood". Apple's type/owner attribute combo was killer, solved all of the problems in this thread brilliantly. But it can't survive being sent to a shitty-ass Unix filesystem, and so after years of nasty Binhex hacks, now it's gone.
The lowest common denominator is always the shitty-ass *nix filesystem. If you can make it work there, then we can get to work on improving things. Given the state of the Linux community, good fucking luck.
EDIT: BTW, Apple's system was a lot better than MIME types, because it kept track of the user's preferred opener of the file as well as the type of the file. So you could have one csv that always opened in Excel and another that always opened in Access sitting right next to each other in the same folder without ever having to go into some file types dialog and tweak anything. Keeping track of JUST the file type is one thing, but it's much nicer to be able to say, "this is a log file, even though it's .txt always opening it in SublimeText instead of Notepad." So your proposed system should include that as well, or something better.
-
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
Good to know... I had a feeling someone had probably tried this before. Shame it didn't stick, but I wouldn't go blaming Unix for everything. Has DOS or Windows ever tried to do something better? At least Unix can sometimes infer the type of a file when it has no extension (by convention, it seems like several types of file, including executables and README files don't have extensions). It probably sniffs for magic strings at the start of the file as mentioned above.Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
The problem is with "universally understood". Apple's type/owner attribute combo was killer, solved all of the problems in this thread brilliantly. But it can't survive being sent to a shitty-ass Unix filesystem, and so after years of nasty Binhex hacks, now it's gone.
The lowest common denominator is always the shitty-ass *nix filesystem. If you can make it work there, then we can get to work on improving things. Given the state of the Linux community, good fucking luck.
EDIT: BTW, Apple's system was a lot better than MIME types, because it kept track of the user's preferred opener of the file as well as the type of the file. So you could have one csv that always opened in Excel and another that always opened in Access sitting right next to each other in the same folder without ever having to go into some file types dialog and tweak anything. Keeping track of JUST the file type is one thing, but it's much nicer to be able to say, "this is a log file, even though it's .txt always opening it in SublimeText instead of Notepad." So your proposed system should include that as well, or something better.
This 'opener' attribute sounds cool, but I think that should be handled by the operating system in some user config or cache, not by the file metadata. After all, this data is useless once moved to another machine with different software, or belonging to someone with different prefs.
-
@LoremIpsumDolorSitAmet said:
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
Good to know... I had a feeling someone had probably tried this before. Shame it didn't stick, but I wouldn't go blaming Unix for everything. Has DOS or Windows ever tried to do something better? At least Unix can sometimes infer the type of a file when it has no extension (by convention, it seems like several types of file, including executables and README files don't have extensions). It probably sniffs for magic strings at the start of the file as mentioned above.Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
The problem is with "universally understood". Apple's type/owner attribute combo was killer, solved all of the problems in this thread brilliantly. But it can't survive being sent to a shitty-ass Unix filesystem, and so after years of nasty Binhex hacks, now it's gone.
The lowest common denominator is always the shitty-ass *nix filesystem. If you can make it work there, then we can get to work on improving things. Given the state of the Linux community, good fucking luck.
EDIT: BTW, Apple's system was a lot better than MIME types, because it kept track of the user's preferred opener of the file as well as the type of the file. So you could have one csv that always opened in Excel and another that always opened in Access sitting right next to each other in the same folder without ever having to go into some file types dialog and tweak anything. Keeping track of JUST the file type is one thing, but it's much nicer to be able to say, "this is a log file, even though it's .txt always opening it in SublimeText instead of Notepad." So your proposed system should include that as well, or something better.
This 'opener' attribute sounds cool, but I think that should be handled by the operating system in some user config or cache, not by the file metadata. After all, this data is useless once moved to another machine with different software, or belonging to someone with different prefs.
That, and the possibility of "This is a .txt file. Open it with a VBScript interpreter."
-
@Ben L. said:
That, and the possibility of "This is a .txt file. Open it with a VBScript interpreter."
Oh, beautiful!
-
@PJH said:
Isn't that why said OS defaults to 1) not showing you the extension by default and 2) not allowing you to change it in that mode, even when renaming the file? (<font style="font-family:Courier, monospace;">I'm_not_a_virus_really.txt<font color="gainsboro">.exe</font></font>)
i think it's a combination of two things. If you hide the file extension it's less likely that someone will change it and then complain that their mp3 file won't play. Which is part of the basic concept of "we're going to hide the extensions because the average person is stupid and doesn't know, or need to know, what a file extension is -- just click on the file and we'll take care of it for you", combined with this weird mindset that Microsoft has where they never seem to spend very much time considering all the different ways that 'bad guys' will abuse things. Like <font face="courier new,courier">miley-cyrus-nude.jpg.exe</font> for example. @Ben L. said:An operating system where the name of a file contains instructions on how to run it. I mean, what if someone renames a file?
You're not talking about the name of a file, you're talking about the file extension. That's not just pedantic dickweedery, that's an important distinction. For many years, if you right click on a file in Windows and select 'rename' and then start typing, the only thing that gets changed is the file name, not the extension. In order to change the extension you have to move the cursor over and deliberately make that change, at which point Windows pops up a warning that changing a file extension may cause monkeys to fly out of your nose. So if you change an extension and it causes something to no longer work, that's your problem, not mine. @LoremIpsumDolorSitAmet said:Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
I've always liked using extensions to identify files because it makes the file type immediately obvious. As long as you can see the extension, there is no confusion or possible trickery. MIME types or some other type of metadata has the problem of (a) being non-obvious (b) sometimes just plain wrong (deliberately or accidentally).There's a page on Microsoft's website that contains a link to a text file (it's mentioned in the FxCop thread). When I click on the link, Firefox thinks it's a .jpg file. Hooray MIME types.
-
@Ben L. said:
That, and the possibility of "This is a .txt file. Open it with a VBScript interpreter."
If the VBScript interpreter opens a .txt file, it'll open a fucking window with a .txt file in it. (Or, more likely, you'll get a "this program doesn't understand this file type" error.) It won't attempt to run the script because the type is wrong.
-
@LoremIpsumDolorSitAmet said:
Good to know... I had a feeling someone had probably tried this before. Shame it didn't stick, but I wouldn't go blaming Unix for everything.
Even when it's actually Unix's fault? (And the short-sighted idiots who only used Unix and wrote the early Internet RFCs based on it without any flexibility.)
@LoremIpsumDolorSitAmet said:
Has DOS or Windows ever tried to do something better?
Nope, but by the time they had a decent filesystem to support it, it was apparent that it was pointless because of the same problem Apple faced.
@LoremIpsumDolorSitAmet said:
This 'opener' attribute sounds cool, but I think that should be handled by the operating system in some user config or cache, not by the file metadata. After all, this data is useless once moved to another machine with different software, or belonging to someone with different prefs.
No; if the "opener" code isn't recognized, the OS just uses the default opener, so it's harmless to pass that information along and beneficial in a lot of cases.
In Mac Classic, to override the "opener" code, you could just drag-and-drop the file onto the program you wanted to open it. (Or, obviously, use the File - Open dialog.) So it's not like it was some strict Nazi thing, it was super flexible.
-
@blakeyrat said:
If the VBScript interpreter opens a .txt file, it'll open a fucking window with a .txt file in it. (Or, more likely, you'll get a "this program doesn't understand this file type" error.) It won't attempt to run the script because the type is wrong.
Assuming the program checks the file type! Here we go again...@El_Heffe said:
I've always liked using extensions to identify files because it makes the file type immediately obvious. As long as you can see the extension, there is no confusion or possible trickery. MIME types or some other type of metadata has the problem of (a) being non-obvious (b) sometimes just plain wrong (deliberately or accidentally).
The idea is that file types would and should show prominently next to the file name wherever they are shown in Explorer or any other navigators, so you could easily see and change one or the other, but not both at the same time. If the wrong type is chosen by mistake then sure, an educated user can choose to fix it.There's a page on Microsoft's website that contains a link to a text file (it's mentioned in the FxCop thread). When I click on the link, Firefox thinks it's a .jpg file. Hooray MIME types.
-
@blakeyrat said:
Nope, but by the time they had a decent filesystem to support it, it was apparent that it was pointless because of the same problem Apple faced.
I'm not so sure... MS had to keep things backwards-compatible with their very own invention - the 8.3 filenames. I think if they could have avoided that, they migth have plowed on ahead regardless.@blakeyrat said:
No; if the "opener" code isn't recognized, the OS just uses the default opener, so it's harmless to pass that information along and beneficial in a lot of cases.
Sorry... I just don't like this idea at all. If every time I received a CSV file from my manager and it opened in Excel instead of my preferred text editor, I'd be turning that shit off real fast. Opener is a user preference. It's nothing to do with the file.In Mac Classic, to override the "opener" code, you could just drag-and-drop the file onto the program you wanted to open it. (Or, obviously, use the File - Open dialog.) So it's not like it was some strict Nazi thing, it was super flexible
-
@El_Heffe said:
just click on the file and we'll take care of it for you", combined with this weird mindset that Microsoft has where they never seem to spend very much time considering all the different ways that 'bad guys' will abuse things. Like <font face="courier new,courier" style="color: blue; text-decoration: underline; cursor: pointer;>miley-cyrus-nude.jpg.exe</font> for example.
Your link seems broken. I can't get it to work.
-
@LoremIpsumDolorSitAmet said:
Sorry... I just don't like this idea at all. If every time I received a CSV file from my manager and it opened in Excel instead of my preferred text editor, I'd be turning that shit off real fast.
So the first time you see the file spent 10 milliseconds dragging it to the text editor instead of double-clicking it. Is that seriously the worst complaint you can think of? Because it's fucking petty as shit.
@LoremIpsumDolorSitAmet said:
Opener is a user preference.
CSV is a bad example though. Consider something like ODF, where different openers could have different featuresets and munge the file in various different ways. (Or, hell, DOCX for that matter-- do you want a DOCX marked as being saved by Word to be opened with LibreShithole, ruining all the formatting?
In any case, I'm describing how a long-obsolete system worked. That's fucking moot. When you get the idiot Linux users on board to make their OS less shitty and wanna go revise all the internet RFCs to support proper meta-data, then the new system can work however you want. It can be powered by unicorn farts, because by the time you accomplish the groundwork to even start on it, we'll have definitely genetically-engineered unicorns to fart for you.
-
@LoremIpsumDolorSitAmet said:
Assuming the program checks the file type! Here we go again...
Let's invent hypothetical problems for a hypothetical environment that doesn't exist while ignoring the fact that an actual real-life system that was extremely similar didn't have the hypothetical problem!!!!!
Jesus, you're intolerable.
-
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
Um.. actually... that's exactly what you did. When Ben L said that forcing a file to be opened in an unusual program could be a security issue, you made up a hypothetical interpreter that is immune to this exploit. However, that doesn't disprove the original flaw.Assuming the program checks the file type! Here we go again...
Let's invent hypothetical problems for a hypothetical environment that doesn't exist while ignoring the fact that an actual real-life system that was extremely similar didn't have the hypothetical problem!!!!!
Jesus, you're intolerable.
OK, so maybe your example was concrete and referring specifically to the vba interpreter on Windows (which I've never used). Unfortunately, the general issue still remains. If other apps installed on the system will happily try to execute anything you give them, then the system has a security flaw, and it's not the fault of the program. That's why i'm saying that 'File opener' should be an explicit user choice.
-
@LoremIpsumDolorSitAmet said:
When Ben L said that forcing a file to be opened in an unusual program could be a security issue, you made up a hypothetical interpreter that is immune to this exploit. However, that doesn't disprove the original flaw.
I still don't see how it's a potential security issue honestly.
@LoremIpsumDolorSitAmet said:
OK, so maybe your example was concrete and referring specifically to the vba interpreter on Windows (which I've never used).
No; but it was based on my experiences of the AppleScript runner on Mac Classic. Which, I remind you, was an actual piece of software on an actual and popular OS and was used for a decade.
@LoremIpsumDolorSitAmet said:
If other apps installed on the system will happily try to execute anything you give them, then the system has a security flaw, and it's not the fault of the program.
I would argue it is the fault of the problem.
But more to the point, how does that differ from existing systems? OS X, Linux, or Windows? "If you feed an arbitrary file into a code running app, it'll attempt to run it." Well ok. So what? Sure it's not a good situation, but it's not any worse either.
@LoremIpsumDolorSitAmet said:
That's why i'm saying that 'File opener' should be an explicit user choice.
Fine; then in LoremOS you do that. Why the fuck are we discussing it?
-
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
When Ben L said that forcing a file to be opened in an unusual program could be a security issue, you made up a hypothetical interpreter that is immune to this exploit. However, that doesn't disprove the original flaw.
I still don't see how it's a potential security issue honestly.
You have two PDF viewers on your system. Adobe and Foxit. You prefer Foxit and use it for viewing PDFs.
Someone sends you a PDF with malicious javascript in it. You open it with Foxit. Nothing happens becuase not only have you turned off Javascript in Foxit, but it also doesn't have the buffer overflow the javascript is trying to exploit. Only Adobe Reader has that. You are happy.
Except now the file itself can dictate what program will open it. It picks Adobe Reader. The javascript is executed, and the exploit happens. Your security is compromised.
Extrapolate: There is a vulnerable program on your system that you either do not use, or are unaware that it even exists. I mean, how secure is MS Hearts 2013 anyways? You are sent a file that by name or appearance can trick you into thinking it is of a "known" file type. You open it, it picks how it executues. There's the security issue right there.
-
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
If other apps installed on the system will happily try to execute anything you give them, then the system has a security flaw, and it's not the fault of the program.
I would argue it is the fault of the problem.
But more to the point, how does that differ from existing systems? OS X, Linux, or Windows? "If you feed an arbitrary file into a code running app, it'll attempt to run it." Well ok. So what? Sure it's not a good situation, but it's not any worse either.
The difference is that if the OS or Filesystem determines what application opens a specific file, that is a choice made by user. If the FILE itself makes that determination, then that choice is made by the file creator. That is the security problem.
-
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
When Ben L said that forcing a file to be opened in an unusual program could be a security issue, you made up a hypothetical interpreter that is immune to this exploit. However, that doesn't disprove the original flaw.
I still don't see how it's a potential security issue honestly.
@LoremIpsumDolorSitAmet said:
OK, so maybe your example was concrete and referring specifically to the vba interpreter on Windows (which I've never used).
No; but it was based on my experiences of the AppleScript runner on Mac Classic. Which, I remind you, was an actual piece of software on an actual and popular OS and was used for a decade.
Like you said in the SQL injection thread, developers are stupid. If the onus is on the developer to check if the user accidentally launched the wrong file type, then some (more likely "most") programs will not check "am I interpreting a .txt file". I would even argue that it shouldn't be each application's responsibility to individually double-check the user's intent. The only thing that's going to result in is dozens of programs getting the problem subtly wrong in different ways or just general disagreements about what the policy should be.
Now imagine a world where a .txt file couldn't be mistaken for an executable script because it's a .txt file. What's that? We live in that world?
Are file extensions a perfect system? Not in any sense of the word. But they're better than most of the alternatives I've heard about.
-
Yep. Thanks guys. That's exactly the issue. I think this is a trick that could catch out even power users like ourselves, if it ever became a real thing... until we turned the feature off, of course. In a way, it reminds me of the good old 'autoplay' for removable media.
So yeah... Why were we talking about this, Blakey? Let me just check the notes... Ah, yes. Because you hate GTK.
Just kidding...
-
@joe.edwards said:
How about all the file types that are zip or XML files with a different extension (.jar, .xlsx, .docx, .svg, .xslt, app/web.config, etc)?
It turns out that they're much easier to tell apart, as there's usually quite a bit of additional metadata inside (e.g., .jar files have a META-INF/MANIFEST.MF file within them). The current crop of file-type identifying libraries/programs do a pretty good job with them. Similarly, the various XML subformats are not too hard to distinguish (many are in fact trivial to detect).No, it's the variations on plain text that are hard to distinguish. How do you tell the difference between plain old text, CSV and markdown? Pro-tip: virtually impossible, my friend, virtually impossible. Indeed, distinguishing plain and markdown is intentionally super-difficult; MD's designed to look virtually like plain text. CSV's just as bad; you don't know what the separator is, which of the various (incompatible!) quoting rules are in use, or what the data really means at all. And is that first line the column labels or just the first row of data? Ugh.
-
@Ben L. said:
That, and the possibility of "This is a .txt file. Open it with a VBScript interpreter."
How is this any different from just making a .vbs file?
-
@LoremIpsumDolorSitAmet said:
Blakey is, as usual, speaking from a position of profound and wilful ignorance. Linux filesystems have been perfectly capable of storing this kind of metadata for twenty years, as has NTFS. If you're going to rag on a shitty-ass lowest-common-denominator filesystem responsible for breaking everything it touches, the actual culprits are FAT32 and its predecessors.@blakeyrat said:
@LoremIpsumDolorSitAmet said:
Good to know... I had a feeling someone had probably tried this before. Shame it didn't stick, but I wouldn't go blaming Unix for everything. Has DOS or Windows ever tried to do something better?Fun debate. I've thought about this many times myself over the years... Of course if we could start over, we'd have a filename, and a separate, universally understood type attribute, which could be used like, or identical to, MIME types.
The problem is with "universally understood". Apple's type/owner attribute combo was killer, solved all of the problems in this thread brilliantly. But it can't survive being sent to a shitty-ass Unix filesystem, and so after years of nasty Binhex hacks, now it's gone.
The lowest common denominator is always the shitty-ass *nix filesystem. If you can make it work there, then we can get to work on improving things. Given the state of the Linux community, good fucking luck.
EDIT: BTW, Apple's system was a lot better than MIME types, because it kept track of the user's preferred opener of the file as well as the type of the file. So you could have one csv that always opened in Excel and another that always opened in Access sitting right next to each other in the same folder without ever having to go into some file types dialog and tweak anything. Keeping track of JUST the file type is one thing, but it's much nicer to be able to say, "this is a log file, even though it's .txt always opening it in SublimeText instead of Notepad." So your proposed system should include that as well, or something better.
-
@anonymous234 said:
@Ben L. said:
It's different because the user can see the file name and file type, but is most likely blind to what program is assigned to the file, so they'd believe it to open in Notepad etc., but it wouldn't, even if txt files usually did.That, and the possibility of "This is a .txt file. Open it with a VBScript interpreter."
How is this any different from just making a .vbs file?
-
@flabdablet said:
If you're going to rag on a shitty-ass lowest-common-denominator filesystem responsible for breaking everything it touches, the actual culprits are FAT32 and its predecessors.
Blame FAT16. There's also FAT12 but nobody used it for anything other than floppy disks in the past 30 years or so, so its restrictions are reasonable in the face of being OK for what it was designed for. FAT16 was FAT12 bloated to deal with HDDs and in almost the nastiest way possible. (Why the fuck was it necessary to make FAT16 be not kilobyte aligned? That brings back terrible memories! Augh!) FAT32 is FAT16 with extra crap bolted on top to try to hide the worst of the shit.
-
@Lorne Kates said:
@Yes. Read this. Oh mercy me read this said:
[Mozilla's] advancements in a revolutionary new open source language called
Rust... The Rust language will power Mozilla's new browser...Mozilla can't write a proper browser anymore. So rather than figuring out how to fix their shit-- they're going to write a brand new browsers-- written in a brand new language-- that they're writing.
Oh my god this article is April Fools come early. The pie-eyed optimism-- the buzz-word thick marketspeak-- calling "revolutionary"-- recoding EVERYTHING including the language the code is coded in-- thank God I'm not up for critiquing this shit line by line, or I'd die of comedy orgasm overload.
AND THEY CALLED THEIR LANGUAGE RUST! Why not "obsolete"? Or "decayed corpse pile"? AH! AH! AHHHHHHHHHH poof
At this point a shitty FOSS app produced by a shitty team that can't produce anything but shit deciding to do a full rewrite in a new language of their own shitty concoction is dog-bites-man. While C++ is a disaster, I almost guarantee Rust will be worse. In fact, I will make a bet: if Rust doesn't suck I will kill as many married gays as it takes to sate Brandon Eich's homophobia.
Remember when Microsoft called FOSS Communistic and people laughed? What those people failed to realize is that it had little to do with FOSStards thinking people shouldn't be paid for their work (although that is part of it); instead it's that 99.9999% of FOSS blows and when something half-way decent squeaks out like a fart during an abortion, the only place to go is down. Before long they're pulling a Year Zero just to try and distance themselves from the reek of failure. "The problem isn't really Mozilla or the failed FOSS model, the problem is the language" eventually morphs into "The problem isn't Rust's type system or the fact that our mothers drank non-stop through their pregnancies, the problem is 2 + 2 = 4". This is how re-education camps get started.
The irony, of course, is this is exactly how we got Firefox in the first place. Netscape decided to do a Scorched Earth Rewrite and it sank the company so badly that they ended up dumping the source onto the Internet, like millions of gallons of napalm being dumped on a child's birthday party. At some point somebody realized a web browser with an integrated website editor made about as much fucking sense as a Ford lugging around a Mexican factory in the trunk, and Firefox (nee Firebird (nee Phoenix)) ascended from the ashes of so many, many failures. So who knows what we might find in a decade hence when rummaging through the charred remains of Mozilla. Why, Rust might turn out to be the Language Of The Future! Or Google might finally realize its annual pity funding of the beleaguered 501(c)(3) is the biggest waste of cash since buying Marissa Mayer those fake tits* and finally pull the plug.
On the other hand, if Firefox had never caught on, the web might have remained a document publishing platform and we might have got a real platform for rich application development instead of spending our days trying to stitch together maintainable UIs from the mutilated remains of SGML; the retarded, bastard offspring of Smalltalk and Lisp; and a stylesheet language which lacks basic features like nesting into a simulacrum of an actual graphical environment, and our nights wondering if a career testing experimental drugs at the community college is really as dangerous as it sounds.
I for one wish Mozilla a Triumphant Thermidor. And be sure you don't miss tomorrow's guillotining in front of Mozilla's offices at 7:95 sharp.
(*Poor Larry Page--which of us doesn't know the pain of giving our heart, soul, money and penis to a woman only to see her run off with some Yahoo?)
-
@morbiuswilters said:
quite literally everything I had to say on the topic of Firefox
What he said.
@morbiuswilters said:I for one wish Mozilla a Triumphant Thermidor.
Dude, it's already Germinal. Do you really think they'll have something to show us in only 11 décades?
-
-
@Lorne Kates said:
@blakeyrat said:
@LoremIpsumDolorSitAmet said:
When Ben L said that forcing a file to be opened in an unusual program could be a security issue, you made up a hypothetical interpreter that is immune to this exploit. However, that doesn't disprove the original flaw.
I still don't see how it's a potential security issue honestly.
You have two PDF viewers on your system. Adobe and Foxit. You prefer Foxit and use it for viewing PDFs.
Someone sends you a PDF with malicious javascript in it. You open it with Foxit. Nothing happens becuase not only have you turned off Javascript in Foxit, but it also doesn't have the buffer overflow the javascript is trying to exploit. Only Adobe Reader has that. You are happy.
Except now the file itself can dictate what program will open it. It picks Adobe Reader. The javascript is executed, and the exploit happens. Your security is compromised.
Extrapolate: There is a vulnerable program on your system that you either do not use, or are unaware that it even exists. I mean, how secure is MS Hearts 2013 anyways? You are sent a file that by name or appearance can trick you into thinking it is of a "known" file type. You open it, it picks how it executues. There's the security issue right there.
This may be one of the dumbest arguments I've yet seen here, but here I go:
-
Why would your hypothetical OS/filesystem transfer the "Open with X" metadata? That's a user preference and seems like something you would never want to transfer (in fact, it should probably be a per-user preference, but anyway..) I mean, if you did for some reason transfer it with the file then a much simpler problem would be "What if the user doesn't have Adobe Reader installed?"
-
For everyone who is bitching about tricking the system into running executable code: this is a much more fundamental problem with modern OSes, which is that they make little distinction between files (data) and executable code. And what distinction they do make is trivial to flip (extension, executable bit). This is a terrible idiom. Executables and files should be treated completely separately. Yes, implementation-wise the executables will still live in a filesystem. But you know what doesn't have this problem? Smartphone OSes, because they don't treat apps and files as the same fucking thing.
-
I really like the idea of being able to have a different default launcher on a per-file basis. It seems like every modern GUI suffers from the problem of being application-oriented rather than data-oriented.
-
If anyone's rebuttal references a Unix, save us all some time and just go jump off a bridge. The shebang is not a good system, executable bits suck and BASH is an antediluvian religion, not a tool.
-
