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!

And that bug would not be triggered by the execute bit, so an exploit would have a non-exe attack vector

Not if you're opening it in a text editor.

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.)

yep definitely hell banned :)

If you double click a malicious file disguised as a txt file, it won't necessarily open in a text editor.

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.

> Why would anyone want to have an executable txt file?

A shell script.

I meant to exclude scripts when I said txt/docx/html and likes. I understand I wasn't clear enough, that is my fault.

Named .txt?

Surely nobody with malicious intentions would ever try to trick you.

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.

Well, perhaps it is a bug. An addition to the Info.plist in the editor could say, "always safe to open this kind of file".