For an error in the file upload,
I am forced to change the logic of the bug.

The executable will be in the domain from where the attack is launched.
In my example, from localhost (http://127.0.0.1/bug-chrome/ChromeSetup.exe)

Also I upload the new modified files (index.html and index1.html)
Deputy new video:

https://drive.google.com/file/d/0B5G3cbs08P16ZTBuSUVWaXEzdzg/view?usp=sharing

Sorry, let them re-examine the case of error.
Thank you very much.

Deleted: index.html 85 bytes

index.html 85 bytes View Download

Deleted: index1.html 358 bytes

index1.html 358 bytes View Download

For downloading the executable file occurs while loading the page of Google, I've made a change in the second iframe index1.html:

<iframe src='about:blank' url='https://www.google.es/chrome/browser/desktop' onload='top.location=this.getAttribute("url")' style='position:fixed;top:0;left:0;width:100%;height:100%;box-sizing:border-box;border:0'></iframe>

If you consider that this is a valid vulnerability I can clear this issues  658128  and create a new one with clear writing and and consistent data.

Thanks and sorry for bothering.

I can improve the appearance of the page with this url:

https://www.google.com/intl/es/chrome/browser/thankyou.html?oneclickinstalled=0&extra=betachannel&installdataindex=defaultbrowser

Iframe:

<iframe src='about:blank' url='https://www.google.com/intl/es/chrome/browser/thankyou.html?oneclickinstalled=0&extra=betachannel&installdataindex=defaultbrowser' onload='top.location=this.getAttribute("url")' style='position:fixed;top:0;left:0;width:100%;height:100%;box-sizing:border-box;border:0'></iframe>

Video:

https://drive.google.com/file/d/0B5G3cbs08P16aFFtakZNSWpaODA/view?usp=sharing

Related to Issue 121259

Also Issue 355810

I see that this debate is not new but it worries me greatly.
Look at the misleading result in this example:

http://www.finanser.es/test/bug-chrome.html

This behavior certainly doesn't seem ideal. I'm going to reclassify it as a bug to be consistent with the other related issues we already have open.

Thanks!!

Even we can make it more credible, requesting authentication Google:

http://www.finanser.es/test/bug-chrome.html (second link)

Adding asanka and jialiul for thoughts. I'm not sure if this is a logic bug (i.e. we're supposed to be hiding the download shelf after the redirect but aren't) or a UX problem (i.e. we need to figure out a way to indicate that a download did not come from the site that you're currently on).

The download shelf is WAI insofar as it being visible across a redirect. The shelf is is a browser level UI surface (e.g. it isn't affected by tab switches) and can display downloads that originated from any tab in the browser session including those that have been closed. It's definitely a problem if users are perceiving a download on the shelf as having been initiated from the origin in the omnibox.

Mismatches between the resource origin and the interface origin (using definitions at https://html.spec.whatwg.org/multipage/semantics.html#downloading-hyperlinks) are quite common. I'd argue that indicating a mismatch between the two would be too noisy and would be difficult to interpret given that the interface origin of a download doesn't necessarily have any relationship to the origin being displayed on the omnibox.

Security-UX folks: Do you think addressing issue 121259 would be sufficient to address this case?

Adding Origin to the Download Shelf will help a bit, although I expect most users will overlook it. 

For the next stage of HTTPBad, I think it's likely that we're going to want the download shelf to indicate whether the downloaded resource or originator was transmitted over HTTP.

I think we should address this via issue 121259 as suggested in comment 12. We might need to think how to make it noticeable in dangerous situations; maybe there are some heuristics we can use to make the origin more or less noticeable depending on the situation.