You might just be killing the decoy
![]() ![]() |
Is it possible the folks at google are much smarter than us greasehackers? I see there are several places where they have event listeners embedded in their code. I suspect (but have not gotten beyond their obfuscation to prove it) that they probably intercept any broken onMousedown events and still send them back to their servers. The fact that you can change the innerHTML to alter the END RESULT behavior in no way prevents them from knowing: a) that you have a mouse event, b) what button was pressed, and c) on what link that event was attached to -- unless you change the href and defeat yourself at the same time. I for one, think that superficial attempts to circumvent their tracking will probably fail, while giving the appearance of success. If anyone is patient and sophisticated enough to delve into what their event listeners do (sorrowfully, I am not), then please prove me wrong. This is not just a hunch. I did notice that once when I fiddled with this, it broke their code producing an error message coming from their event handler: "a.something". Also, attempts to overwrite their clk function thusly: unsafeWindow.clk = function(){return} also fail, which seems to prove that an event listener is acting to restore their desired behavior. If you think about it, they almost have to have such an ironclad tracking system, since they get PAID for sponsored clicks. In fact, just the fact that such a tracking method could be written nearly proves that it has been. They're not about to let greasemonkeys like us cheat them out of their primary revenue stream!!! Anyone know how to put a trace on the "killed" click event to see if it still goes back to a google server? |
![]() ![]() |
Another way to test this would be to track a paid adword combination by paying for a completely unthinkable word combination. If the hacked onMousedown event fails to trigger a paid click, then we will know it works. |
![]() ![]() |
Shiver... what a horrorful thought that they go that far! While devel'ing the script I did simple proxomitron http logging to see if the /url tracking call is gone (it was) but as I also was unable (with my simple proxomitron setup) to sniff on the traffic that the "spooky iframe results pages" produced, I might as well be missing the backup event handlers... I hope that these backups are only applied to Adwords hrefs (this script doesn't filter them) - doing the same for the click-tracking on plain search results would qualify them for the "big brother is watching you" award batch. |
![]() ![]() |
Unfortunately, I think the big brother approach is most likely: they are probably tracking the natural results as well. They get "paid" for these clicks in a more indirect way - by "improving" their search results. But the potential for side benefit abuse, including to intelligence communities is undeniable. Google has claimed that they have recorded every search ever performed since their inception. That includes the ip addresses of all search requests. More than spooky! |
![]() ![]() |
--Some statistics-- On the google search page client side javascript, there are a total of 43K bytes of tight, optimized obfuscated code. This would be over 120k if not obfuscated! Additionally there are: 9 calls to onMousedown events (one or more of these could be re-instating your removed code) Like the self-replicating agent in the Matrix (reloaded), they can easily anticipate and defend against attacks on their own turf, including re-instating hacked variables and functions. And we are playing in their matrix when we piggyback using Greasemonkey against 43k bytes of highly sophisticated, optimized and obfuscated code. I suspect that the best way to defeat them is to remove ourselves from the matrix altogether. That is -- to turn off javascript for their search pages. This can be conveniently done using a little-known add-on called Script Skipper. Unlike the popular (and cumbersome) "NoScript" add-on (which uses an opt-in white-list), this uses an opt-out blacklist to defeat scripts on a site basis. It operates prior to page load, which is something I wish Greasemonkey could do. Unfortunately, it officially works only with Firefox 2.0, but still worth checking out. One of the great things about Script Skipper is that Greasemonkey will still work on an affected page! So you are free to alter the tracking urls without fear of a back door. In the end however, all attempts to defeat Google's all-seeing eye are futile, unless a proxy server is involved. In order to serve your results at all, your ip address is handed over on a silver platter. Is it really so important that they know the specific sites visited when they already know the primary terms you are searching for? |
![]() ![]() |
Your indepth analysis convinced me that it would be best to remove this script from Greasemonkey again. It claims to be quite effective while it is very probable it is not - which makes things even worse. Google is just too spooky to be beaten with a few lines of code. A responsible improved functionality of the script would be to steer the user away from big G altogether. Do you agree that it's safer to remove this script? |
![]() ![]() |
While your sense of ethics is impeccable, I would not remove it. In spite of everything said, we still have not proven that it does not work. Also, it does serve an educational purpose (this thread included). If you are worried about misleading people, just put in a disclaimer and a reference to this thread. Personally, I would love to see someone more knowledgeable than we are responding to our comments (maybe an insider). It is possible that I'm paranoid and/or giving google too much credit! I will eventually test it using the adwords procedure and report the results here. So please leave it up at least until that time. Besides, in combo with the Script Skipper, it will certainly work, so your work is not in vain. BTW, I was not picking on you. I wrote a google script Google Static Nav Bar and found myself knee deep in all this same stuff. |
![]() ![]() |
I agree - for now and until we have more solid testing results, I'll keep it up. Further, I added the disclaimer (and a request to help us inquire) to the description. I did not understand it as "picking on me". I was just, as you said, worried to mislead people. And I released the script here to get input! So thanks for being a critic. |
![]() ![]() |
UPDATE: I just ran the google search page through MS Script Editor and set a breakpoint on clk() function. Then I clicked on a search result link. As I suspected, it went directly to the linked page, bypassing the clk function altogether. This proves that at least under the testing circumstances (IE7), the onMousedown event never gets triggered. There is definitely an intermediary event handler on the click event. This also explains why overwriting the clk function by way of: unsafeWindow.clk = function(){return} does nothing. It appears that the clk function is either a backup - or more likely - a total decoy. The trackers are obviously still active through another hidden function triggered by an onClick event captured from an eventListener. Unless used for a more obscure browser, or as a legacy fallback, the onMousedown event is a total facade. Well, in the spirit of mythbusters, I guess Google's clicktrack onMousedown event code is now: BUSTED! Please double check my findings for verification and I still suggest that you leave some version of your script online so that others searching on this topic will find this thread and be forewarned. |
![]() ![]() |
I did a similar test with Mozilla/Firefox while devel'ing the script, and as you found for IE: at least the href's onmousedown is blocked. I tend towards thinking that Google does multiple layers of catching events just to be sure any possible browser sends some sort of response. Let's hope, at least. We've been talking about turning off JS on the search pages. I an attempt to do just that I modded the source code and just in a hack'ish sort of way added a routine to simply skim all < script > code from the page. Comments welcome: does this effectively disable registered events? Is the Greasemonkey execution early enough to make it work? And another todo: clicking the previous/next buttons results in a call to /csi? Shouldn't an effort to counteract click-tracking take care of that too? Anyway, I can't see easily how it gets fired: it's not in the href's and the < script > tags are emptied by the updated code... |
![]() ![]() |
They're running multiple setTimeouts and setEventListeners. You can't destroy those by simply replacing the <script> tags, because they are already running before you get there and any references to functions contained in already running functions will keep them in memory. They have a setTimeout() func that's always active on the page, keeping all that stuff alive. Again, they have us beat before we even start, unless we can clearTimeout() on that and also kill their eventListeners. It may be doable, but not without a lot more effort.One of my biggest gripes about Greasemonkey is there is no option to pre-process the raw html before scripts start running. So GM is useless for saving the time eaten up by all the initializing code - including ad code. Many scripts are out there for removing ads but they still take time pulling those ads into the page to begin with (even when ads are ajaxed, those processes cannot easily be interrupted). This is why I value the Script Skipper add-on so much, since it actually turns off JS before it ever gets a chance to do any work on the page. (BTW, it does this by selectively turning off the javascript in a FF setting). So your best way to prevent code from ever running (and continuing to run) will be to use Script Skipper in conjunction with GM. |
![]() ![]() |
Okay, mostly what I expected. Wasn't that convinced even while I did this < script > removal hack... Thanks paka! ...
Applied to Google, the hidden redirects are gone. Although on the first try I did, I saw creepy 1x1px .gif files appearing, with tracking-id names served by /verify? - couldn't replicate this so far. They really know every trick in the book! For educational purposes, I won't remove the script right now. But in my Greasemonkey it is inactive from now on and replaced by Script Skipper. |
![]() ![]() |
Well just an idea. But instead of playing on Google's terms, or killing all scripts (which I had been doing with NoScript), what about just extracting the desired info (URLs and descriptive text, etc.), then totally replace the page (with a window.open() or something) and remake the page from scratch with just plain links and text but still a look-alike? I know it's not a nice surgical strike as would normally like to do with GM. But then if what we have is a handful of medical trainees vs. the top surgeons in the world, we might not want to have such a duel. Or... Could just try *asking* Google what would be a nice way to do it, as long as we guarantee to make certain all advertising tracking stays fully in place. They may actually be willing to cooperate rather than lose ad links through a more blunt force approach. |
![]() ![]() |
Squirrelly: Not a bad idea. That is essentially what clipland has attempted with this script. Unfortunately, to fully accomplish this, there needs to be a convenient way to turn off scripting. Greasemonkey is the wrong tool for this since it gets to the page too late to stop the bleeding (embellishing your medical analogy). And NoScript - from what I've read about it - seems to be the wrong tool entirely as it doesn't even allow surfing the "real" internet - since it turns javascript off indiscriminately for all sites except for those you specifically opt to allow it. This is overkill, to say the least. The Script Skipper add-on is the right tool, since it turns off scripting only for sites that you specify. It turns JS off before the page loads, which is important since we don't want to wait for lots of useless scripting, which primarily serves google, not us. However, it doesn't kill the cookies, so tracking is still possible. For that, you can simply use the built in cookie manager within Firefox, and disallow google.com & www.google.com. I have not seen any downside to it except that user preferences (such as number of results per page) are not retained. Signing in, of course is not an option at all if you don't want to be tracked. Quoting an earlier post: "In the end however, all attempts to defeat Google's all-seeing eye are futile, unless a proxy server is involved. In order to serve your results at all, your ip address is handed over on a silver platter. Is it really so important that they know the specific sites visited when they already know the primary terms you are searching for?" So unless you have a truly dynamic ip address (not common in broadband) you need to resort to something like anonymouse.org as a proxy server which will hide your ip address. Then google cannot even attempt to build a profile on you, since you don't exist. |
![]() ![]() |
Thanks, Paka. Yeah Script Skipper sounds like a good app. For me though NoScript is actually better, as I *do* want to block scripts for *all* sites except those I need it for. There is security, but even more so for nuisances. I often go to all sorts of random pages when researching something with Google or such. And a bunch of the places with forums or answer sections also have some of the more annoying ads, pop-up media, hover and click junk, and stuff that slows the page down. So it really cuts down on all that. And just a click to turn on scripting for a page permanently, or just for that visit. But enough promoing other tools. :-) What I'm here for is hopefully something for GM. I already use GM and NoScript. I would actually like to reenable Google in NS, but just don't much care for them tracking each page I go to. I know they'll track the searches themselves, and would rather they didn't, but overall I'm okay with that. Maybe that's weird, donno. :-) To me, with the terms I usually use, that's much more general, and they can have very little idea just what particular sort of content I'm looking for. But when they track the individual pages, then that's a lot more personal, and I feel uncomfortable with it. So you're saying that's what Clipland is trying here, and I do need to spend some time checking out the script.. but it doesn't sound like what I was talking about. What I've heard is modifying the existing page, which does have the scripts and everything running, yes. What I'm talking about is fetching the content of that page, but then scrapping the page all together for a new generated one of your own, which then won't have any scripts or triggers running. Then fill it in to look like the Google page. If I get a chance, I'll see if can doodle up a very simple version. But I am glad this is being addressed here. I had seen other GM scripts for Google like this, but they don't bring up these important issues, or say if they've addressed them (which I'd assume means they didn't). Thanks again! |
![]() ![]() |
Squirelly said: But google only uses plain links these days. They have abandoned the links which start with "google.com?" and gone to standard links. So there is no need to "remake the page from scratch" if you use Script Skipper as suggested. Without their javascript, there is no tracking of clicks. |
![]() ![]() |
There is another greasemonkey script that claims to stop tracking of results, GoogleMonkeyR. You might want to look at that. Due to the way it works, some of the advanced features don't work with script blockers though. |



