blocking google.com domain CRIPPLES Chrome browser?

Discussion in 'privacy general' started by inka, Aug 31, 2011.

Thread Status:
Not open for further replies.
  1. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    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.
     
  2. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    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.
     
  3. x942

    x942 Guest

    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.
     
  4. vasa1

    vasa1 Registered Member

    Joined:
    May 1, 2010
    Posts:
    4,152
    Interesting ... only 1 response in ~ 9 hrs :D

    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.
     
  5. x942

    x942 Guest

    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.
     
  6. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,854
    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.
     
  7. x942

    x942 Guest

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

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,854
    No, only what's in my signature. Chrome from portableapps.
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  10. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,854
    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.
     
  11. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    How are videos more dangerous?
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  13. x942

    x942 Guest

    @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 :p

    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.
     
  14. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    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.
     
    Last edited: Sep 2, 2011
Loading...
Thread Status:
Not open for further replies.