Thanks for the report. I understand why seeing, for example, "chromereleases.googleblog.com" in the address bar is not ideal, but there are a few mitigating factors here. First, Chrome indicates that it is a filesystem connection and not a security connection. Secondly, unless you already possess to ability to put arbitrary content onto the users filesystem, they will most likely see an error or some useless content. 

estark@ what do you think?

Please open it in chrome normal mode. Because filesystem is disable in incognito mode.

Thanks, I opened it in normal mode. I don't think there is a security vulnerability here, as it does show that it is a filesystem URL. That being said, we should track this as a feature bug because it brings to mind a few options that could make these dialogs easier to understand for our users:

1) Adding the not secure badge to filesystem URLs
2) Hiding the untrusted part of the URL

We are aware of the spoofing risks posed by pseudo URLs such as filesystem. Please see  bug 594215 .

I agree in this particular case we should probably have dropped the part before @, but I think it's better to solve the problem by doing something more substantial instead (e.g. block navigations to these urls, or simply drop the filesystem scheme and show origin instead or some such)

This may have gotten fixed by  Issue 809062 .

 Issue 809062  has been merged into this issue.

 Bug 809062  is a duplicate of this one and we decided it's a medium severity security bug, so adding back the labels here. The fix will be  bug 811558 .

Fixed by  bug 811558 .

Hi meacer, is this bug possible to get a reward and CVE number？

Commit 54400200 initially landed in 68.0.3416.0

I'm afraid the VRP panel declined to reward for this bug. Many thanks for the report. It will get a CVE when Chrome 68 goes stable.