VULNERABILITY DETAILS
Everything can be seen in the reproduction case

VERSION
Chrome Version: Regular stable release, fully updated
Operating System: Tested and works on Windows, IOS, and Android

REPRODUCTION CASE

The smallest case in which the issue manifests:
aa:a@attacker.com
Paste this into the Chrome url bar and it will take you to attacker.com

http://google.com@attacker.com
This looks like a real url now and still takes you to attacker.com

Now, here is the way that I imagine this would be used in the real world:

https://www.google.com/maps/place/Bateaux+Parisiens/@48.8590407,2.2955756,18z/data=!4m12!1m6!3m5!1s0x47e66e2964e34e2d:0x8ddca9ee380ef7e0!2z0K3QudGE0LXQu9C10LLQsCDQsdCw0YjQvdGP!8m2!3d48.8583701!4d2.2944813!3m4!1s0x0:0x195c12658ef8df0c!8m2!3d48.860385!4d2.293565

This is a long and valid url to google maps.

https://www.google.com/maps/place/Bateaux+Parisiens/@48.8590407,2.2955756,18z/data=!4m12!1m6!3m5!1s0x47e66e2964e34e2d:0x8ddca9ee380ef7e0!2z0K3QudGE0LXQu9C10LLQsCDQsdCw0YjQvdGP!8m2!3d48.8583701!4d2.2944813!3m4!1s0x0:0x195c12658ef8df0c!8m2!3d48.860385!4d2.293565@attacker.com

Now, @attacker.com was added to the url at the end, but it takes you to google.com

This is because the url contains slashes. Slashes in the protocol (https://) are fine, but in the actual site link they cause the url to resolve correctly.

To get around this, we replace all of the slashes in that url with a very similar unicode character (or just not use them all together, we just want a long url so we don't cause suspicion by the @attacker.com at the end of the url). This unicode character is the division slash: ∕

So now, because the url doesn't have slash characters, if we open it we get to attacker.com

https://www.google.com∕maps∕place∕Bateaux+Parisiens∕@48.8590407,2.2955756,18z∕data=!4m12!1m6!3m5!1s0x47e66e2964e34e2d:0x8ddca9ee380ef7e0!2z0K3QudGE0LXQu9C10LLQsCDQsdCw0YjQvdGP!8m2!3d48.8583701!4d2.2944813!3m4!1s0x0:0x195c12658ef8df0c!8m2!3d48.860385!4d2.293565@attacker.com

It is worth noting here that we get a connection error because attacker.com does not serve https. The protocol specified at the beginning of the url string specifies the protocol of attacker.com . This information might be important.

http://www.google.com∕maps∕place∕Bateaux+Parisiens∕@48.8590407,2.2955756,18z∕data=!4m12!1m6!3m5!1s0x47e66e2964e34e2d:0x8ddca9ee380ef7e0!2z0K3QudGE0LXQu9C10LLQsCDQsdCw0YjQvdGP!8m2!3d48.8583701!4d2.2944813!3m4!1s0x0:0x195c12658ef8df0c!8m2!3d48.860385!4d2.293565@attacker.com

Now this loads fine without errors because it is using http.



POSSIBLE ATTACK SCENARIOS
In my opinion, this is a serious issue with the potential to greatly increase the efficiency of phishing schemes. An attacker can craft a url that looks like the url to a Google login page or a banking website but leads to their own malicious website. They would then send the link to their target through email, Skype, sms or any other media. 

My thought is that it makes users of Chrome on mobile devices specifically vulnerable to this because they are less likely to notice the url bar once a page has loaded. An attacker can spam hundreds or thousands of phone numbers through sms or messengers like Whatsapp or Telegram masquerading as a bank telling its customers that their account has been frozen and needs confirmation. The url will be near impossible to tell as a fake one and many users will click it. If the browser that opens it on their phone is mobile Chrome, they will get to the attackers website and in the haste and worry of the moment many users will provide their banking information.

This behavior by Chrome may also defeat the security measures of various filtering systems. For example, a forum or corporate portal may allow users to share links only to trustworthy websites to protect privacy and security. Because of this behavior, a system that for example allows users to only share links to google.com will let http://google.com@attacker.com go through. This will make the security issue even worse because the users used to the filtering system would be completely certain that urls can only lead to google.com and will trust the forged url more.

When attacker.com opens, the user can see that they are on attacker.com from the url bar. However, even if everyone noticed what site they were on after it loaded, sometimes just opening a website is all an attacker needs. Once the victim opens the link, the attacker can get information about their ip, browser and even use something like BeEF (The Browser Exploitation Framework) with a pop-under window to pivot into their network and for example exploit an iot device or router.