stuartmorgan, would you mind taking a look at this, or help with assigning this to the right person?

In addition, there have been similar issues to this issue  bug 595514  and  bug 528505 .

This trick changes omnibox URL to chrome://version, but WebUI is not loaded. The page is blank and has no content. Chris do you see any security risks here? I personally think we can leave current behavior as it is (cancelling chrome://version is possible, but it's tricky and I'm not sure if it worth doing).

I can repro with that testcase "Address bar spoof" as you can see in the screenshot the address bar shows chrome://version but the page's hostname is https://bugs.chromium.org... 

I will upload a video of recording.

Deleted: WhatsApp Image 2016-12-01 at 11.56.19.jpeg 142 KB

	WhatsApp Image 2016-12-01 at 11.56.19.jpeg 142 KB View Download

On other platforms, clicking on chrome: or about: URLs in web content (PDFs and HTML) doesn't work. In theory, it could work yet still be safe, because such navigations should always incur a process swap (since the WebUI renderer has more privilege than a regular web content renderer).

What's the process swap situation on iOS? Does everything happen in the 1 sandboxed renderer process, or do we kill it and restart, or are none of the WebUI pages that work on iOS especially powerful? That's the crux of the issue, in my view. Powerful pages like chrome://settings don't seem to exist on Chrome for iOS anyway.

That said, the behavior on other platforms is strictly safer, and it seems like as long as it doesn't break legitimate functionality (and, it presumably doesn't, since such navigations don't work on any other platform?), we should harmonize Chrome's behavior on all platforms if it's not too hard.

#6: So the claim is that you can get a URL spoof to improve phishing attacks? Can you come up with a more convincing proof of concept (preferably attached as HTML/PDF/JS)? Thanks!

Steps to repro the "Address bar spoof":
1. Navigate to chromeUrls.pdf directly from this page (comment #0)
2. Click on "Chrome Settings" >> chrome://version (the page is blank)
3. Double tap to go back to this page
5. Double tap to go forward to chrome://version
6. Observe 

I can not reproduce the problem described in comment #9. On step 6 chrome://version page gets loaded. I use iPhone SE with iOS 10.1.1 and Chrome 54.0.2840.91.

srikanthg@, do you want to try reproducing this?

I tried on different devices and i can't repro either.
Followed the steps on comment#8 and comment#9 on iPhone7, iPhone6plus and iPhoneSE.

Actually this issue needs several attempts for repro the spoof.

Deleted: Recording Screen.mp4 2.2 MB

	Recording Screen.mp4 2.2 MB View Download

Assigning low severity because of the unreliability of the spoof based on comment #12. 

chromium.khalil@ can you still reproduce the problem with Chrome 61? A few fixes were landed for the relevant code, so this issue may be fixed already. I'm asking you for retest because I was not able to repro almost a year ago (comment #10).

Thank you!

This seems like fixed. No more of repro.

Thanks a lot for confirming!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot