Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #65.0.3325.181 and latest canary #67.0.3387.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

http://www.google.com@example.com is a URL for the example.com domain with an embedded credential for the user named www.google.com. There is no redirect involved.

This has historically been a common method to trick people into thinking they are going to one domain when in reality they are going to another. So Google Chrome will remove the username:password portion of the URL and only show the actual host you are visiting. This is correct behavior.

Going to www.google.com in your example is definitely the wrong thing to do.

I thought the report was asking for a warning when pasting in URLs like "http://www.google.com@example.com" (As the user may well be misled), which seems like a not unreasonable suggestion to me.  There is indeed no redirect involved there.

Hmm. I interpreted the report to mean that they wanted the browser to visit the google.com (the username portion). But I see your interpretation as well, and I agree that requesting a warning here isn't unreasonable.

We have mitigations for the spoofing aspect of embedded credentials (namely that we strip the credentials when displaying the URL in the omnibox). Let's let the omnibox folks decide what else to do.

Moving the issue out of Auth. The behavior mentioned in #0 under "steps to reproduce" is not a bug.

Basically dupe of 626951.

Between the existence of open-redirectors and the fact that the omnibox hides the userinfo upon commit, it doesn't feel like this feature request is especially worthwhile.

Bumping into the URL security queue, as deciding whether this is worthwhile depends on how often they think this is an attack vector.

It depends if we're worried about:

a) The example given here, where you think you're going to google.com but you're actually going to example.com. Or,
b) A case where you paste actual credentials into the URL, like https://username:password@google.com, leaking your credentials to the site.

I'm not sure where (b) comes up, so I'll just rule that out. Anything you put in a URL is obviously going to be leaked to the site.

For (a), I don't think this is an issue. We do not consider the contents of a URL pasted into the Omnibox to be any guarantee of where you'll end up (due to redirects, etc). The only thing you can be sure of is what you see in the Omnibox after the URL resolves, and that is already mitigated by hiding the username and password.

So this is a WontFix, from my perspective.