blocking google.com domain CRIPPLES Chrome browser?

The title is phrased as a question in order to invite you to test and confirm (or refute) my observation.

test:
Block outbound connections to the google.com domain (windows HOSTS file, or proxy)

result:
The browser becomes "crippled" ~~ unable to even display an html document residing on the local drive.
Further, it's unable (refusing!) to even display an imagefile drag-n-dropped onto the browser window.

I found an identical result when I tested the latest "official" Chrome broswer, the "PortableApps Chrome" build, and several recent Chromium Win32 builds.

 

additional (probably not relevant) details:

-- testing environment is WinXP SP3 + Sandboxie

-- Chromoting extension ( Google-flavored remote terminal client ) disabled, per browser settings.


FWIW, I also tested SRWare Iron browser. As I expected, it's unaffected.

 

I used to block google and never had this issues. I would report it as a bug. If you don't like it you can always compile chromium yourself. This has other benefits as well such as enabling and disabling features by default and it will run better on your hardware in some cases.

 

Interesting ... only 1 response in ~ 9 hrs

I don't use Chrome or its "derivatives" or Chromium but would certainly be interested in knowing what users of these browsers see now and not what they have seen in the past.

Compiling a browser from source is an excellent idea but may not be possible for quite a few Wilders' forum members, self included.

 

Very true. It is also much easier on Linux than windows. I can confirm the issue exists on Windows 7 Ultimate and Mac OS X with up to date chrome and chrome developer. Personally I use Firefox mostly and use chrome for videos only as it's more secure.

 

Posting this on Chrome 15.0.865.0 with google.com redirecting to 127.0.0.1 in my HOSTS file. Seems to work fine.

 

Strange. May I ask if you are using sandboxie or anything related?

 

No, only what's in my signature. Chrome from portableapps.

 

Do you have DNS Client enabled? If so, did you clean you DNS cache?

P.S: I didn't test this, but just wondering if you cleaned your DNS cache.

-edit-

Anyway, I'm not surprised if it happens. If users block Google Analytics, Chrome/Chromium extensions won't install either, at all.

 

I do have it enabled but it doesn't matter, at least on Win7. I tried to access google.com which errored. I guess I could try again with flushing if you're really interested.

 

How are videos more dangerous?

 

Flash in Chrome is more secure than Flash in Firefox.

EDIT:

By the way, disable things in your options like "Report anonymous crash statistics" or "Use a prediction web service" blah blah all those. They make calls to Google often and obviously if you block google you're going to break it.

 

@J_L:

Exactly Right. Thanks HM. Chrome Sandboxes Flash so it is far more secure. I use Ff for day to day browsing. All plugins off, permanent private browsing. and standard add ons like noscript and such. On windows I sandbox Chrome as well, and place EMET on both of them for extra protection. Sadly Mac OS X doesn't have such solutions

Nothing different, Disabling DNS Pre-Fetching fixes the issue how ever. Provided this could be unrelated to the OP's issue and be something I am running. If this doesn't solve his issue I would assume it's merely a coincidence that this accord for me too.

 

Thanks, but short of supplying command line startup arguments... I had "turned off" every "helper feature", via the settings panels.

Thanks for the feedback. From the outset, I had elected to disable the browser's DNS prefetch feature.

I use DNSKong (from www.pyrenean.com)
Yes, it performs caching... but stopping/restarting it (to purge cache) didn't resolve my Chrome -based browser issue.

Tests both with sandboxie in the equation, and not, yielded the same "dead in the water upon browser startup" result.

I was chagrined to find that although I haven't asked the browser to "autoupdate", have disabled the chromoting extension, and whatever else I might do in an attempt to guard my privacy... upon startup the damn browser IMMEDIATLEY performs a callout to google.com ~~ that's why I added the domain block, until I could determine what/why the callout occurred.

By monitoring the request headers (via proxomitron), I discovered the callout @startup is retrieving the google favicon. Via wireshark, I verified that the returned stream "yeah, looks like an icon file header, followed by a few kb of data". Same data each time, across the various browsers placing requests... so, l'll grant that it's an "innocous" request, and that it returns a valid ico ~~ vs steganographically-encrypted GUID or session identifier. Okay, it's a garden variety favicon, but ( ref http://panopticlick.eff.org ) the callout request still creates a trackable fingerprint.

The fact that the browser's inability to retrieve a favicon "cripples" the app can be considered innocuous? By design ( I won't guess whether by poor design or malicious design) that favicon is apparently needed (at startup) in order to populate the app's window dressing ~~ and is displayed at the search bar, for GoogleSearch. Perhaps the same "stalling, crippling" would result if the browser were unable to retrieve favicons for (provided in the distro, but I removed, via settings) the other listed search providers? Even if that's the case (I'm not planning to reinstall and retest), I'll pointedly wonder: Why does the app forbid removal of Google as a "search provider"?!? During setup, I had attempted to remove all of them. Google was listed first, and its entry was the first I attempted to remove. Noooo, could not remove the GoogleSearch entry. I was able to remove the entries for Bing and Yahoo, and I did so.

Yes, but, respectfully... that's irrelevant.

Although I agree that build-it-yerself might provide benefits (and insight)...
Where does "rational ignorance" reasonably kick in? Slogging through browser sourcecode, that's an awfully deep rabbit hole.