Chrome blocks HTTP auth for subresource loads

We had a website in Production Environment http://www.example.com. It's Page Construction related static subresource (css, js, jpg, gif & png) are being served from http://eimg.com. Why two separate domains? To serve the static content from cookieless domain.

For it's development we had a development environment at http://dev.example.com and subresource at http://dev.eimg.com. Both these development environment domains are password protected by HTTP Basic Authentication.

Issue:

On http://dev.example.com the static subresources are being served from http://dev.eimg.com. Both are password protected by HTTP Basic Authentication.

Everything works okay with Firefox & MS Internet Explorer. On accessing the Development Environment Website it asks for password twice. Once for http://dev.example.com and another for http://dev.eimg.com.

But, the Chrome does not ask for the second Password (for http://dev.eimg.com) and issues http status 401. Thus, blocks all content from dev.eimg.com and renders the page without stylesheet and page construction images.

Google-Chrome Developers say:

This behavior is an intentional change as a phishing defense. Sites shouldn't be doing this kind of authorization cross-origin. If you need to allow this behavior, launch chrome with the --allow-cross-origin-auth-prompt flag.

Read: http://code.google.com/p/chromium/issues/detail?id=91814

Further Read: http://blog.chromium.org/2011/06/new-chromium-security-features-june.html. It says:

Chromium 13: blocking HTTP auth for subresource loadsThere’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img> tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance. To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.

Do you wish to see List of Chromium Command Line Switches?
http://peter.sh/experiments/chromium-command-line-switches/

Possible Resolution:

Let’s remove the Auth from the dev.eimg.com.
Pros: Issue would be resolved.
Cons: Google-Images may get the images from dev.eimg.com and index it in Google Images. This would cause duplicate images content for Search Engines (development - dev.eimg.com & production - eimg.com).

But, I do not see it as a significant duplicity threat, because only Page Construction related images and JS / CSS / images / sprites are served from this sub-domain.

Hope, this post helps anyone encountering the similar situation. BTW, I totally agree with the Chrome's implementation of defense against Phishing.