How do I disable zone markers for downloaded files, so that Explorer stops being a nag about running downloaded files and just trusts me to do the right thing?


My Little Program about manipulating the zone identifier for downloaded files appears to have struck a nerve with commenter Tess, who launched into some sort of diatribe about how Microsoft should stop being a busybody and warning users about opening files that they downloaded.

You are welcome to disable the feature if it offends you so.

In the Group Policy editor, go to User Configuration, Administrative Templates, Windows Components, Attachment Manager, and enable Do not preserve zone information in file attachments.

For bonus points, you can set a bunch of other policies to make your computer even more dangerous. Here's a list of them. For example, if your goal is to create the most insecure deployment of Internet Explorer, you can set Inclusion list for moderate risk file types and Inclusion list for low risk file types both to *.*, and then on top of that, set Launching applications and unsafe files to Enabled (not secure) so that Internet Explorer never warns you about running anything.

Welcome to 1995. Enjoy your stay.

Comments (43)
  1. Joshua says:

    Feeling brutal?

    The warn opening is a good thing. No, I don't want to open the 500mb doc file you linked to (you != Raymond in this case).

  2. xpclient says:

    Unfortunately even if the policy is set, it depends on the app which is copying/downloading that file to respect that policy setting. Latest Mozilla Firefox for example doesn't respect it. Thankfully I use IE. :)

  3. alegr1 says:

    If I wanted to make my computer less secure, I would make it hide file extension in email attachments. What are you saying? It's already default? Sorry.

  4. Mordachai says:

    Personally, I much preferred the Windows 98 lack of warnings and "busybody"-ness.  Honestly, I was just fine with a virus scanner telling me if something was amiss, and otherwise the OS not asking me to confirm something that I am not honestly qualified to answer (it feels more like a cover-thy-ass approach from MS – "well, YOU clicked open it even after being warned of the potential…"  Everything has the potential… give me tools that actually look at that file to see if it actually is dangerous – keep databases on files that prove to be dangerous, etc., but blind "are you sure?!" type confirmations (repeatedly) I find to be … less than honest and/or useful.

  5. Nichilist says:

    Just a little while before 1995 the problem these warnings are trying to solve was no problem. Computer wouldn't simply run anything by just clicking them and people had to know beforehand which program they needed, launch that and open the file from there.

    I know catering to ignorant people helps microsoft and it's cousins (apple, first in line, in fact double click is their idea I think), and perhaps give an illusion of being better out to those ignorants, but that's not a road I approve we going on (for more than 20 years now)

  6. Adam says:

    @Nichilist

    I'm sure September will end any day now.

  7. Medinoc says:

    The big problem with the zone identifier thing is that some files gain more power locally than on the web: HTML pages that now execute in the Computer zone instead of the Web zone, etc.

  8. Anonymous says:

    I know of a certain PDF reader application that tries very hard to behave this way:

    – it installs a Browser Helper Object (aka IE plugin)

    – if you disable the BHO, the documents will still auto-open due to BrowseInPlace registry entry (ActiveX Document)

    – if you delete the BrowseInPlace registry entry, the PDFs will still autodownload and auto-open due to EditFlags set to FTA_OpenIsSafe (0x00010000)

    – if you delete the EditFlags for .PDF, there are still many more similar file types used by this application and registered in the same way

    Last but not least, it also makes some of its registry keys read-only and sets the Owner SID on those keys to SYSTEM.

  9. Medinoc says:

    Unfortunately not all browsers save the "Mark Of The Web", and for a file without, the only options available to the user are all-or-nothing: The Information Bar will show the user is a "more secure than the web, but nothing works" option, a "more dangerous than the web" option, but no "just do as if it were on the web" option which is what the user wanted in the first place (but not what a local WebBrowser-using application wants).

    Firefox is a browser that neither injects a "Mark Of The Web" in the web page contents nor in an alternate data stream when you save a web page.

    Also, it sounds like disabling zone preservation disables the mark of the web as well, right? If yes, it's a further argument that disabling it is shooting self in the foot.

  10. Karellen says:

    @Adam: 7497 days in, and counting…

  11. Jim says:

    @Nichilist: File associations existed at least as far back as Windows 3.1. I remember File Manager listing files whose extension had an associated program as pieces of paper with writing on them, whereas files without an associated program were represented as black pieces of paper. Just how far back before 1995 are you talking?

  12. Rob says:

    Raymond, zone identifiers are sometimes useful, but more often than not they're annoying.  .chm files are unusable unless you find and clear them (and I had a colleague who had actually copied a file off of a USB thumb drive which was evidently formatted with NTFS, because it STILL had a zone identifier, and I had to walk him through clearing it).  As a developer, jQuery is really bad, too.  Since jQuery revs frequently, it never gets to the point where SmartScreen decides it's a legitimate file, and since its extension is .js, which is executable via WSH, IE thinks that I want to run it instead of copying it.  Thus IE blocks it and makes it rather hard to get to as opposed to other files (which are easy to "Open Folder" to).

    There has to be some design in the middle.

  13. Joshua says:

    Ah how the world would have been different if the document-action for an EXE file was open in debugger (or in absense of debugger open with properties).

    Sure I'd have put execute in the actions but it wouldn't have been the default. Open document and execute program really shouldn't occupy the same mental action space.

    In '95, most users would need the latter case only for programs on removable media anyway. All others would have shortcuts.

  14. Max says:

    @Rob: Automate your jQuery updates with a package manager of your choice, such as npm, NuGet, bower, or what have you.

  15. Nico says:

    > Welcome to 1995. Enjoy your stay.

    This got an lol from me.  Reading the post I kept thinking "this sure sounds familiar".  The only thing missing is an ActiveX dialog prompt that says "Do you want to install and run "YOUR COMPUTER REQUIRES AN UPDATE TO SEE THIS PAGE-CLICK YES TO CONTINUE" signed on 5/13/2001….."

    The "mark of the web" doesn't bother me, but I wonder how much it has actually helped prevent problems.

  16. KapilK says:

    @Joshua – Then we would not have enjoyed the delicious autorun.inf functionality.

    Ofcource, not having the .EXE execute by default would have meant a difficult transition from Windows 95 to NT based OSs and Microsoft would have lost some money. Screwing over the security of users vs making a few billion dollars – I'm not sure I'd side with the users either.

    I guess in that scenario only MSI installers would be the official way to create files blessed with the execute bit (other than the user manually doing it and propagation via NTFS compatible compression formats). Also would have been cool if MS had documented the MSI standard back then to allow for greater adoption.

  17. Miff says:

    And of course, this isn't an option at all if you have a home version of Windows that lacks gpedit.msc. msdn.microsoft.com/…/ms815238.aspx doesn't include this crucial setting sadly.

  18. yuhong2 says:

    I wonder why Outlook still don't have UI for Level1Remove.

  19. Joshua says:

    @'k: It's not permission based. Right-click -> run would have been the way to execute a program given its .exe file.

    In my worldview, autorun.inf would have only worked for CD-ROMs. (not CD-RW media)

  20. Dylan says:

    @Joshua: If you use an old CD-ROM drive, can it even tell if a CD-R is writable?  Or even worse, look at the U3 devices that pretend to be a CD-ROM.

  21. RangerFish says:

    Is there a way to set or clear the zone identifier on a batch basis? Say, for every file in a folder.

    That would probably go a long way to quelling any objections to zone identifiers without having to resort to switching them off.

    While I get why they exist, there's thing Microsoft could do to make the experience better.

  22. Medinoc says:

    (whoops I submitted early)

    Ordinary people don't understand that, *nor should they have to*. Principle of least astonishment says that if I open something from the web, it should be just like it was on the web.

    This is why disabling the preservation of zone identifiers is a dangerous thing.

  23. Mike Dimmick says:

    @Medinoc: "HTML pages that now execute in the Computer zone". Since XP SP2/Windows Server 2003 SP1, the Local Machine zone has been locked down – it is now (by default) *more* secure than the Internet zone. See for example blogs.msdn.com/…/understanding-local-machine-zone-lockdown-restricted-this-webpage-from-running-scripts-or-activex-controls.aspx .

    XP SP2 was released nearly 10 years ago (August 2004).

  24. Medinoc says:

    Similarly, is there any way in Office (such as Word) to see the code of a document's macros *before* unlocking the document?

  25. Maurits says:

    > Is there a way to set or clear the zone identifier on a batch basis? Say, for every file in a folder

    Sure, just set up a FileSystemWatcher for the folder in question, and remove the zone identifier from files as they show up.

  26. Joshua says:

    @Dylan: By checking for ISO9660 filesystem w/o growth records. This kind of filesystem is probably too difficult to directly infect and too rarely made by casual users anyway (CD-R and CD-RW would normally use extendible records).

  27. KapilK says:

    @Joshua: How is right-click run any better than double-click run?

    Like I said the best thing is to not have a .EXE extension at all. Explorer parses files which have the executable bit set and loads up the icon if the file is valid. By default, files not created by an installer will never have the executable bit set.

    [What's to prevent somebody from just setting the executable bit on any file they want? -Raymond]
  28. @k says:

    Go away back to Unix world please. Users dont want to set their files executable to run them. And anyone can create an installer that makes themselves executable in that case so you're back to square one.

  29. voo says:

    @1995 had some…: So you're saying a technique that limits the social engineering vector is not on the radar when looking at OS-level exploits to circumvent the need to actually social engineer an attack? Color me surprised.

    How often do you think "hide known file extensions" turns up in MS' patch notes or in security bug descriptions? Also not a single time? So does that mean you don't gain any additional security from seeing "foo.doc.exe" instead of "foo.doc" either?

  30. Azarien says:

    @voo: The solution is simple: Windows shouldn't hide multiple extensions, or even block execution of such files.

  31. Joshua says:

    @'k: It's simply the most sensible way to make sure .jpg.exe infects nobody by accident. Permission systems are just too heavyweight for W95.

  32. Anon says:

    This is OK when it is one file… but compressed files will retain this flag across all files which are uncompressed from that file. Which can lead to a support nightmare.

  33. DWalker59 says:

    "If I wanted to make my computer less secure, I would make it hide file extension in email attachments."

    If I wanted to make MY computer less secure, I would hide file extensions by default in Windows Explorer.  Oh, wait….

  34. 1995 had some good rap let me tell you says:

    In 1995 my parents' Windows machine could go for three weeks without becoming infested with adware, so I'm not personally seeing the payoff from the "one more msgbox" play.

    In 2014 any file a home user is likely to open *did* come from the Internet unless they created it themselves locally, so it's hard for me to see how one could find value in that "Security Warning" unless they suffer from Stockholm Syndrome.

    Just take a look at any security researcher's blog, or any penetration tester's presentation, or any anti virus company's teardown of the latest browser exploit kit or banking trojan, or any Microsoft write-up of this month's patched security bugs, or any of the more detailed write-ups that show up later in the tools that exploit them like metasploit… and see how many times "zone identifiers" come up. It's just not on that radar because it doesn't even exist in the same spectrum of what's really going on out there. ("out there" being my parents' computer in the next three weeks.) Even in the unlikely event that this dialog enters into an infection's workflow, I think we all know the only outcome from that step: Not reading the prompt and clicking "YES OF COURSE DUH" just like the user has been trained to do by years of opening files to get things done. (As you have blogged!) We'll see an NSA slide someday that says "At this point, the user could defeat the implant by opting to *not* open the file. LOL MOVING ON."

    Raymond you are my programming hero, originally for the way your mind handles machines but later for the way it handles people. Your patience inspires me, as does the fireworks display when it runs out. I wince though when you engage a rant that's washed up on your shore that you don't deserve but geez *somebody* does. Especially when it's inappropriate, inarticulate, off-topic, rude, and right.

    In retrospect, I should have just abbreviated this to "you are my programming hero", because that was the most important part. I use hand gestures when describing your existence to others! I always look forward to reading your writing.

    [So I'm not allowed to respond to a diatribe with a counter-diatribe? Trying to figure out what the rules are. -Raymond]
  35. yuhong2 says:

    Personally, I do wish that MS would change the default to show file extensions by default.

  36. Cesar says:

    @Joshua: read-only media can also be malicious (see for instance the Sony Rootkit).

  37. Josh says:

    @Joshua: A 500mb doc file is nothing, actually <1% of my available ram. There's no excuses why it shouldn't open just fine.

  38. KapilK says:

    [What's to prevent somebody from just setting the executable bit on any file they want? -Raymond]

    I already excluded this use-case in an earlier comment. It is reasonable to assume it means "I know what I'm doing" vs. a novice user randomly double clicking .exe attachments, etc.

    @ Joshua

    > Permission systems are just too heavyweight for W95.

    Oh, I was talking about the transition to a sane OS design (NT) from the W95 world of "Hey Bob I just left this note for you to let you know that I parked my lawnmower in your fridge to cool off the engine and I borrowed your company credit card to purchase a private jet for Jack. We're cool right?"

    >And anyone can create an installer that makes themselves executable in that case so you're back to square one.

    No, you are not back to square one. (1) Novice users are protected from spammers attaching executable files to emails (2) Browser bugs delivering drive-by malware no longer are able to run the malware (3) having an central MSI model of installation allows the OS to have a more rigid model in dealing with dependencies. (4) requiring MSIs to be digitally signed leaves a digital trace back to the s/w author.

    Note that tinkerers and power users can still execute whatever they want just by setting the execute bit so it doesn't burden them too much.

    I'm sure this is nothing new to most people on the Windows dev team. Its rather that the business concerns override the security concerns.

    [I guess I don't see how you can make it so only MSI can set the executable bit. If you have Full Control over a file, you can set any bit you want. That's what Full Control means. Or are you saying that nobody has Full Control any more? -Raymond]
  39. KapilK says:

    >[I guess I don't see how you can make it so only MSI can set the executable bit. If you have Full Control over a file, you can set any bit you want. That's what Full Control means. Or are you saying that nobody has Full Control any more? -Raymond]

    Its not the MSI per-se that sets the executable bit. Its the OS part (Windows Installer Service I presume) which parses the MSI data structures, unpacks and installs all the stuff that sets the executable bit (on files explicitly specified in the MSI tables as requiring it)

    A user ofcource should be able to manually set the bit, but like I said – its reasonable for the OS to assume the user knows what hes doing in that particular scenario.

    There are other alternative models with creative use of things like software restriction policies but that is another topic.

    [But if the user can set the bit, then malware running as the user can set the bit, too. -Raymond]
  40. Katie says:

    If an application couldn't run because the execute bit wasn't set, then presumably Windows would have to pop up an error along the lines of "this file does not have permission to execute," and give instructions on where to find the "executable" checkbox. How is this different than the zone security warning letting you know that the file isn't trusted, but you can run it anyways and mark it as safe if you want to?

  41. Joshua says:

    [But if the user can set the bit, then malware running as the user can set the bit, too. -Raymond]

    The intended result is a program that managed to get itself downloaded incidentally doesn't start.

    Unfortunately it doesn't do much for security without the other Unix tradition that removable

    media is mounted by default w/o execute permissions (noexec). The Windows culture wouldn't put

    up with that half so there's not much point.

  42. KapilK says:

    @Joshua

    >Unfortunately it doesn't do much for security without the other Unix tradition that removable media is mounted by default w/o execute permissions (noexec)

    How does it not do much? No email attack vector. No possibility of drive-by malware binaries. No fake 'download this codec' malware, etc, etc. Yes, you can inject shellcode after exploiting memory bugs – but that's going to be there no matter what you do – till our code become 'provable'. And these days most executable memory pages are read-only and with the IP-on-stack check, you eliminate most vectors.

    I'm curious as to where you have your bar set at if knocking down so many attack vectors 'doesn't do much'.

    >The Windows culture wouldn't put up with that half so there's not much point.

    What exactly would be the problem? Users downloading plain .exes and running them is not a mainstream usecase anymore. The .exe files will almost always come from installers.

Comments are closed.