Chrome 19 doesn't respect basic auth details embedded in the URL

This technique is widely abused by phishers. Most browsers detect such phishing attacks and warn the user for it (see example in Safari 5).<p>Firefox might do a better job on this subject: it performs a HEAD request first, to see if the website actually requires authentication. If not, the user receives a warning to make the user aware of a potential phishing attack they might have been trapped into.

HTTP URIs never officially supported this syntax anyway: <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2" rel="nofollow">http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2...</a><p>The userinfo component is supported according to the URI generic syntax, which FTP URIs follow, but HTTP URIs don't. See the sadly still not obsolete RFC1738: <a href="http://tools.ietf.org/html/rfc1738#section-3.1" rel="nofollow">http://tools.ietf.org/html/rfc1738#section-3.1</a>

<a href="http://support.microsoft.com/kb/834489" rel="nofollow">http://support.microsoft.com/kb/834489</a><p>I remember reading about Microsoft stopping supporting that option actually. The reasoning being that it could be used for sending users to malicious sites.<p>"malicious users can use this URL syntax together with other methods to create a link to a deceptive (spoofed) Web site that displays the URL to a legitimate Web site in the Status bar, Address bar, and Title bar of all versions of Internet Explorer."<p>I'm wondering if this was the reasoning for doing so in Chrome.

I get it if Chrome developers want to stop spoofing of malicious urls like <a href="http://veryfamouswebsite.com:pwd@malicioussite.com" rel="nofollow">http://veryfamouswebsite.com:pwd@malicioussite.com</a>. However, I prefer the Firefox way: FF prompts you if you want to login with the username specified in the url.

Wow, BasicAuth is quite unusable these days. Disallowing BasicAuth in typed-in urls is just one side. The other thing is that I can't use BasicAuth to download files on Android[1] (and that bug is 4 years old)<p>[1]: <a href="http://code.google.com/p/android/issues/detail?id=1353" rel="nofollow">http://code.google.com/p/android/issues/detail?id=1353</a>

While I understand their concern, it is none the less quite a useful feature for testing.<p>Firefox warns users if they are authenticating to a site with a small message and asks them to confirm. This prevents pretty much all of the phishing attacks that people have been talking about without removing a potentially useful feature.

I think it's worth mentioning that "IE 7/8/9: OK" is not correct according to this: <a href="http://support.microsoft.com/kb/834489" rel="nofollow">http://support.microsoft.com/kb/834489</a><p>I would be curious to know who actually uses this type of auth in their browsers these days.

Ah! In many company (I have seen it in huge and tiny companies) this will break their SSO 'systems' :) Intranet pages covered with links to internal systems like this are rather normal.

This may be slightly OT but having the auth in the url has some benefits when using a handler for certain file types. The Android Browser violates this if you go to a site requires auth and then links to video/audio. When the media player is passed the url, the credentials are lost and the media fails to play.

To me is just a security feature. IN ANY CASE you should not provide credentials via URL.

This is good: it's totally insecure to pass auth credentials in plain-text URLs.

Not nice of google to try to change the ways of the web without prior discussion. Some people may store these URLs in bookmarks for convenience. What's next? disallow the javascript: protocol maybe?

Since Chrome's addressbar functions as both a search input and an address bar, is it possible they're doing this to prevent usernames and passwords from being continually added to Google's search history logs? I see both sides of the argument for allowing or removing this functionality ... but the fact that user input from the omnibar is passed along to Google in real-time changes things and potentially opens up Google to receiving usernames and passwords to sites they have no business having access to.

Based on the potential security/privacy implications of supporting this, I think Google did the right thing by deprecating this.

Reason for this everybody is overlooking:<p>Usernames and passwords can be added to links to resources (and images) which aren't necessarily protected by authorization, and in that sense can be used as a "cookie" of sorts to track users irrespective of cookie settings. It's a bit hokey, but I've heard of it being done before (more than once, actually). Try it on your Web server, and dump the headers for your image request after you serve this:<p>&#60;img src="<a href="http://cookiedata@example.com/image.gif&#62" rel="nofollow">http://cookiedata@example.com/image.gif&#62</a>;