My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 5719: SetInternetZoneIdentifier does not respect the SaveZoneInformation policy
21 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  Apr 2011

  • Only users with Commit permission may comment.

Sign in to add a comment
Reported by, Dec 19, 2008
Chrome Version       :
URLs (if applicable) : N/A
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
Firefox 3:
         IE 7: OK

What steps will reproduce the problem?
1. Open Internet Explorer, browse to, right-
click on putty.exe and save it to the Desktop.
2. Open the Properties of putty.exe. Note that there is a security warning 
about the source of the file and there is an "Unblock" button.
3. Open Google Chrome, browse to the same page, and save the same file 
4. Open the Properties of putty.exe. Note that there is the same warning 
and Unblock button.
5. Open the Group Policy editor (gpedit.msc), browse to User Configuration 
| Administrative Templates | Windows Components | Attachment Manager.
6. Enable the "Do not preserve zone information in file attachments" 
policy. Note that this has the effect of setting the 
ments\SaveZoneInformation key to a DWORD value of 1 (which means *don't* 
save zone information).
7. Open Internet Explorer, browse to the same page, and save the same file 
8. Open the Properties of putty.exe. Note that there is no warning and no 
Unblock button.
9. Open Google Chrome, browse to the same page, and save the same file 
10. Open the Properties of putty.exe. Note that the warning is still 
present, as is the Unblock button.

What is the expected result?
The downloaded file should not be marked unsafe.

What happens instead?
The downloaded file is marked unsafe. The SaveZoneInformation policy is 
ignored by Google Chrome.

Please provide any additional information below. Attach a screenshot if 
Google Chrome uses SetInternetZoneIdentifier (bottom of
.cc) to attach the zone information to the downloaded file. It should 
instead use IAttachmentExecute::Save (

For more information about the SaveZoneInformation key, see

Note that reading the SaveZoneInformation key directly is most likely _not_ 
a good solution in the long term, since it is Microsoft's implementation 
detail and may change without notice, particularly in, for example, Windows 

13.7 KB   View   Download
Dec 19, 2008
Thanks for your detailed report.  You seem to have a clear idea how we should fix 
this issue.  Would you be willing to provide a patch?  Thanks!
Status: Untriaged
Labels: -Area-Misc Area-BrowserBackend
Dec 20, 2008
Sorry, I didn't mean to sound like a jerk. I was hoping that someone who had already 
set up the development environment could write one to avoid my spending the time 
setting it up for a 5-line patch. At the very least, I wanted the issue to be in the 
Dec 20, 2008
Ok.  I'll take a look at it.  I thought you might enjoy writing the patch yourself.  
Jan 14, 2009
(No comment was entered for this change.)
Labels: -Type-Bug -Pri-2 Type-Feature Pri-3 Mstone-X
Jan 21, 2009
(No comment was entered for this change.)
Status: Assigned
Apr 25, 2009
(No comment was entered for this change.)
Labels: os-win7
Apr 25, 2009
(No comment was entered for this change.)
Labels: -os-win7 OS-Windows
Dec 16, 2009
Not sure if this is related enough to be in the same issue, but if you try to run the 
blocked exe file directly from the chrome download bar or download page, it will just 
pause for a few seconds and then do nothing without any notification or warning. 
Expected behaviour would be to receive the same message you tyhat get when you attempt 
to run the file directly from the file system ("Windows cannot access the specified 
device, path, or file. You may not have the appropriate permissions to access the 
Dec 16, 2009
I have been seeing the few seconds pause, then the Security Warning showing me the code 
signer. When I run them directly I get the same warning, but much quicker. I don't 
think I've ever gotten "Windows cannot access the specified device, path, or file".
My best guess so far has been that the pause is related to code signing verification, 
but I have no evidence to back that.
Dec 17, 2009
Labels Update:

Replace Area-BrowserBackend by Area-Internals
Labels: -Area-BrowserBackend Area-Internals
Jan 27, 2010
I have been trapped by this problem for long time.
So I modified as following:

bool SetInternetZoneIdentifierDirect(const FilePath& full_path) {
  std::wstring path = full_path.value() + L":Zone.Identifier";
  HANDLE file = CreateFile(path.c_str(), GENERIC_WRITE, kShare, NULL,
                           OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    return false;

  const char kIdentifier[] = "[ZoneTransfer]\nZoneId=3";
  DWORD written = 0;
  BOOL result = WriteFile(file, kIdentifier, arraysize(kIdentifier), &written,
  BOOL flush_result = FlushFileBuffers(file);

  if (!result || !flush_result || written != arraysize(kIdentifier)) {
    return false;

  return true;

bool SetInternetZoneIdentifier(const FilePath& full_path) {
	ScopedComPtr<IAttachmentExecute> attachment_services;
	HRESULT hr = attachment_services.CreateInstance(CLSID_AttachmentServices);
	if (FAILED(hr)) {
		// We don't have Attachment Execution Services, it must be a pre-
		// Windows installation, or the thread does not have COM initialized.
		return SetInternetZoneIdentifierDirect(full_path);

	// This GUID is associated with any 'don't ask me again' settings that the
	// user can select for different file types.
	// {2676A9A2-D919-4fee-9187-152100393AB2}
	static const GUID kClientID = { 0x2676a9a2, 0xd919, 0x4fee,
	{ 0x91, 0x87, 0x15, 0x21, 0x0, 0x39, 0x3a, 0xb2 } };


	hr = attachment_services->SetLocalPath(full_path.value().c_str());
	if (FAILED(hr))
		return false;

	hr = attachment_services->Save();
	return SUCCEEDED(hr);

However, when debugging, attachment_services->Save() failed and returned 0x800c000e.
After analyzing for a while, the file "full_path" is generated by calling 
GetTempFileName(...) API. So calling IAttachmentExecute::Save on a temporary file 
won't success.

Attach is modified
5.3 KB   View   Download
Jan 27, 2010
There is some information to that effect in the MSDN page for
IAttachmentExecute::Save [1]:

"IAttachmentExecute::Save should always be called if the local path declared in
IAttachmentExecute::SetLocalPath is not the path of a temporary directory."

No idea what should be done if the path is in fact in the temp directory though.

One (very ugly and hacky) idea is to apply Save() to an empty file elsewhere on the
filesystem, then copy over the alternate data streams. Then the question becomes,
where do we place this file?

I will dive into the Save() internals tonight, maybe I can find a way to coax it into
doing what we want.


Jan 27, 2010
I wonder what IE does if I try to save a downloaded file in the temp directory..
Jan 27, 2010
In fact,save() will fail on temperory file, because the file is created by GetTempFileName() API.
Jan 27, 2010
I'm concerned by the error case for creating CLSID_AttachmentServices (this is more aimed toward the 
Chromium developers *hint hint, nudge nudge*):

HRESULT hr = attachment_services.CreateInstance(CLSID_AttachmentServices);
if (FAILED(hr)) {
  // We don't have Attachment Execution Services, it must be a pre-XP.SP2
  // Windows installation, or the thread does not have COM initialized.
  return SetInternetZoneIdentifierDirect(full_path);

If FAILED(hr) indeed is most likely due to pre-XP SP2, why manually mark the file as unsafe? Pre-XP 
SP2 means no one will be around to pick up on the ADS anyway.

I'm inclined to make the failure mode of all of this a no-op, comments?

Jan 27, 2010
From reading Mozilla usage of CLSID_AttachmentServices 
er.cpp), it seems that ->Save() also invokes anti-virus scanners registered with the 
shell (whereas writing the ADS manually does not) -- just something to keep in mind.
Jan 27, 2010
mailwangkun, I have tried saving a file to the temp directory using IE and the zone 
identifier is set properly. What makes you think this is the reason for the error?

I tried the attached code and could not reproduce error 0x800c000e. Can you give a 
standalone program that reproduces it?
355 bytes   View   Download
744 bytes   View   Download
Jan 28, 2010
just change the file extension to .tmp.
It's all about the file extension, no matter what the path is.
Once the file is ended with .tmp, you will get the lovely 0x800c000e :)
Jan 28, 2010
The 0x800c000e error can be avoided by calling SetSource.

Here is a patch against r37376 which solves this bug. Tested on Windows XP SP3 with a 
file ending in .tmp (corner case; see discussion above) and with the group policy both 
enabled and disabled.

Regarding the change to SaveFile, I wasn't sure whether to use url or final_url. 
5.3 KB   View   Download
Jan 29, 2010
I've tried that patch, it really works:)
In SaveFile(),  I think using final_url is better. In 
src\chrome\browser\download\save_types.h, it says final_url means "Final URL of the 
saved resource since some URL might be redirected."
But maybe url or final_url will not affect the result, the "pszSource
" in IAttachmentExecute::SetSource is used  as the primary zone determinant.
Jan 29, 2010
I also think calling AnnotateWithSourceInformation() in DownloadFile::Open is not so 
In my opinion, calling AnnotateWithSourceInformation() in 
DownloadFileManager::OnFinalDownloadName, after download->Rename(full_path) is better, 
just like the way OS_MACOSX does.
Jan 30, 2010
I assigned this 'enterprisy' bug to you. There is a patch so should be easy to fix.

I think it could be Pri-2.

Feb 1, 2010
(No comment was entered for this change.)
Labels: Enterprise
Feb 7, 2010
Any news on this?
Feb 8, 2010
Not sure why it's assigned to me :)

Cronos586, can you submit your patch for review on  If it fixes the 
issue, we can land the patch and this may be resolved.
Feb 8, 2010
The patch is at . It's currently running through 
the trybots. Maybe one of the people on this bug can take a look?
Apr 8, 2010
Adding new label.
Labels: Feature-Enterprise
Apr 21, 2010
(No comment was entered for this change.)
Labels: -Enterprise
Oct 12, 2010
What's the current status of this issue? The issue was reported in 2008 and the current Chrome version (tested 7.0.544.0-dev) still doesn't respect the policy settings.

There is a patch, but I don't see why it hasn't passed the trybots yet.

So please, could anybody explain to me, what's the current status is? Please look into this issue, thanks ;-)
Oct 13, 2010
Issue is still sitting in codereview; I don't have time to look at it in the near future.
Dec 24, 2010
Please remove this annoying bug!
Jan 22, 2011
I can't believe it's been 2 years... this bug drives me insane!
Mar 23, 2011
Any news? Chrome 10 still litters in My Documents folder.
Mar 25, 2011
Why this critical BUG is called 'Feature'?

Chromium designers are thinking long and working hard to invent - "Hey, after so many days of contests we decide to add amazing new feature: to follow Microsoft well-known rules which are created long time ago for users usability. After our best developers will implement this hardest Feature all Internet will say: Wow, Chromium developers be able to do such unbelievable discovery and hardcoding!!!". Do you think that way?

gwilson... or cronos... or dhw... or someone with proper rights - please if you do not have time to take care about this critical bug (in 2-3 years you already have not) then make it unassigned, to other developers can see it in the common list of issues to do. Chromium has about 100 changesets per week so I think someone will find time to fix this p0 bug... well it's not a crash, let it be p1 bug.
Mar 25, 2011
Still not sure why this was assigned to me in the first place.
Status: Available
Owner: ---
Apr 23, 2011
This is getting quite annoying. When will this be fixed? It's been over 2 years and still nothing.
Apr 25, 2011
Marking this with some new tags to see if the Downloads folks could help here.  It's worth noting that there was a patch for this up in comment 26...
Status: Untriaged
Labels: Feature-Downloads
Apr 26, 2011
+danno, you might be interested in making Chrome obey Windows Group Policy (consider adding yourself to auto-CC list of Feature-Enterprise label).

There is a user-submitted patch for this, and Glenn's version at (Glenn, what was the problem with that one?).
Apr 26, 2011
(Chrome does obey group policy for some settings, see

The 590001 patch above probably does the trick but was abandoned and probably 'bit rotted'.  Someone probably just needs to clean up that patch and land it, I'm guessing.

Apr 26, 2011
This bug is not related to the Chrome Enterprise feature set. However, it's been languishing for quite some time now and it is vaguely enterprise related, so I'll try to find an owner who can verify the change and land the patch.
Apr 27, 2011
(No comment was entered for this change.)
Status: Started
Apr 29, 2011
The following revision refers to this bug:

r83502 | | Fri Apr 29 04:38:12 PDT 2011

Changed paths:

Use the IAttachmentExecute service to set the Zone.Identifier stream,
when available. This is used to mark files as untrusted, because they were downloaded from the internet.

The DownloadTest.CheckInternetZone browser test was failing previously because
the Zone.Identifier stream created by the IAttachmentExecute service uses \r\n
for newlines, and the test was checking for \n.

See also, which this should close.


Review URL:
Apr 29, 2011
(No comment was entered for this change.)
Status: Fixed
Oct 12, 2012
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-Internals -Feature-Enterprise -Feature-Downloads Cr-Internals Cr-Enterprise Cr-UI-Browser-Downloads
Sign in to add a comment

Powered by Google Project Hosting