This is a terrible idea. If your browser, or anything else, is ever conned into downloading and opening a file, the quarantine is the difference between "what the fuck, why is an executable I've never launched before trying to launch?" and silently getting owned.
I download almost everything from the net - how else would I install? CD? Floppy? Telling me that it's downloaded from the internet doesn't do anything to identify that it's dangerous and so I ignore the warning.
Under what circumstance would I go "whoa, maybe it's dangerous this time"???
Mac's don't have auto-install .exe files. Yet we get warning for everything from JPEGs to TXT to DMG. Ridiculous.
The point is that you might not know you had downloaded the file, or that it was executing. Imagine you're surfing the Web one day and all of a sudden this warning pops onto your screen. It would be nice to know that something downloaded from the Internet is trying to execute itself.
In principle, you shouldn't be getting warnings for any of those formats. You should only be getting one when you launch an executable - it's a warning that the file you downloaded is an executable and not some random other file you can (barring vulnerabilities) open without trust.
I don't know why it cares about the executable bit(?) in this case, though.
I would love to not have to disable this, but it's buggy and I've had it up to here with pointless confirmations like "README.txt is an application downloaded from the internet. Are you sure you want to open this file in TextEdit?"
Under what scenario is it ever unsafe to open a text document in TextEdit? Under what scenario would you ever not completely ignore that warning?
A much more likely threat is a malformed jpg or pdf designed to exploit a decoder, in which case the executable bit is completely irrelevant. Warning the user about the executable bit protects them from nothing, unless Finder is preparing to execute the file itself. It is a warning that is always ignored, and pointless warnings only make the system less secure.
And working with multiple quarantined documents exposes more bugs.
It's not a thoughtfully designed feature. If they ever fix it I would gladly reenable it.
TextEdit could have a bug in its 'guess the character encoding' code that leads to a buffer overflow, or it could have a bug handling malformed UTF-8.
Its 'guess the character encoding' code also might have a 'wait a minute, this is RTF/PDF' feature.
Of course, Apple could trust its own apps, but I think they should not (why increase the attack surface?) and that would lead to complaints "why can't I tell this OS that my text editor can be trusted?".
I also think (but have no data on it) that this "open a .txt file you downloaded" check is very rare for 'normal' users. If they download at all, it is Word documents, PDFs, movies, and applications.
Isn't TextEdit sandboxed in Lion + Mountain Lion? If so TextEdit most likely cannot execute any non signed code or open a network connection... But of course sandboxing should only be used as a last resort. I am not a security expert - can anyone comment on that?
My .txt's open with Sublime, which is not Sandboxed (or maybe is, I don't know). They can't de-quarantine .txt's because the default is to open with TextEdit!
There's no way for LaunchServices to know, a priori, whether a given executable file's default app is going to perform a safe editing operation, or execute its contents.
Now, you could hardcode a list of "safe" apps, or add some kind of "I swear I'm safe" declaration to the app's plist, but that has its own set of problems. A one-time "this seems funky to me, are you actually intending to do this?" is a simple and safe default.
> There's no way for LaunchServices to know, a priori, whether a given executable file's default app is going to perform a safe editing operation, or execute its contents.
But in that sense an executable file isn't any different from a non-executable file, is it? The default app for the file could do equally dangerous things with a non-executable.
But the application doesn't _need_ to execute the contents for bad stuff to happen viz jpg and pdf encoder exploits.
Also, how many applications actually _execute_ (bare machine, vm's don't count) content? My guess is that few if any of the applications a user opens that isn't executed by finder itself is going to execute the file's contents.
I think they just want something to complain about and aren't actually on mac os. I've already seen a number of examples which are simply fairy tales. (Such as claiming they're being prompted when opening ordinary jpg files.)
That said, even the author notes that this is designed to be forked. It's not a script to run on one's own machine blindly, the idea being to exclude what is not to your taste/while demonstrating features which can't be changed inside the gui. (It's also very helpful if setting up multiple accounts.)
They could just as well automatically chmod the txt/docx/html file to remove the executable bitset. Why would anyone want to have an executable txt file? If one does want it, it's pretty safe to let them reset the bit manually afterward.
They would do a pretty bad job of harming me by addng and extension that makes me view the source of a malware script in TextEdit instead of executing it.
I agree. It takes a second to read what you're opening and another second or less to click "Open". It should at least be commented out and if someone really needs it, they are doing it on their own accord.