It's not clear why you say "https://google.com@facebook.com will not work" as this works just like using an IP literal address.

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Is-Chrome_s-support-for-userinfo-in-HTTP-URLs-e_g_http_user_password_example_com_considered-a-vulnerability

Just to be clear here, the "address bar" (omnibox) does not show the misleading userinfo information (unless you manually enter it yourself).

Hi 

i read all of the comments on the report you mention 
so i came to Answer of your some Questions

your 1st question :  screenshot_1 : 

as in my report i am not showing  attacker.com here first i grab the ip and then converted into decimal 

the decimal value redirecting victim to attacker.com  victim will not see the attacker.com in attacker Url which is https://yahoo.com@@@@@@@@@@@@@@@@@@@@@@@@@@2649756707/ 
victim Can't judge the decimal numbers 
https://yahoo.com@2649756707/ 
Hope you got my point

wait wait wait....!

Your 2nd Question was : You said 
"An attack that starts with asking a user to type a complicated string into the omnibox is one that's already fairly mitigated........ " 


The Answer is  NO.. ! victim will not be ask to type 

then How right ?
 
attacker can Use Secure platform to spoof or trick victim 

again How right ? 

here is POC : 
1-  

https://hackerone.com/redirect?signature=bfe204b21b2931b7b4faeda749151a2d5d6d3c38&url=https%3A%2F%2Fyahoo.com%402649756707%2F

as you can see hackerone is a secure platform and here it got vulnerable due to browser vulnerability 
when you will click on proceed you will redirect to facebook.com or attacker.com 
but as shown it in the URL that you will redirected to yahoo , then statement will goes wrong due to link is redirecting to fb.com or attacker.com


the above link have both answers  
-victim do not need to type 
-attacker.com is not displaying at any place still redirected to attacker.com 

so victim can be trick by this 
browser is responsible for the hackerone.com or any other secure site 


Hope Yo Got My point 

So what Should be Happen here ? 


the solution to prevent from  this attack 

1- Block '@' from address bar after url as like other special character are invalid only @ is working for this. 


Hope helpfull info and you will open this again

thanks
Regards
Tayyab Qadir 

Deleted: Screenshot_1.png 62.8 KB

	Screenshot_1.png 62.8 KB View Download

As explained in the FAQ: 
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Is-Chrome_s-support-for-userinfo-in-HTTP-URLs-e_g_http_user_password_example_com_considered-a-vulnerability there is no spoofing vulnerability here. The Chrome omnibox always shows the correct domain, and there is no other browser UI surface that is a trusted security surface.

The use of @ in a URI delimits the user info (username and password) from the host; in your attack scenario, you're sending a username of e.g. "google.com" to the site hosted at IP address 2649756707.