Like the folks at TidBits, I found it slowed down my computer significantly when indexing my drive. However one can turn it off using the System Preferences panel it installs. Like that I can let it index stuff at night.

Press Command twice and a search panel shows up, which will show the first 10 results. To see more, your browser will be opened to display the results as page that looks like google’s generic search page, so it’s running a small web server.

It runs as root, and does not respect your update statistics settings

Google Desktop installs itself as root: the index is at /Library/Google/Google Desktop/Index/(some directory which only root can access). This means it can access anything on your machine and do anything it likes. It doesn’t need to and on a first date, I don’t trust anything that much. Every user on the machine will have their content indexed, even if they don’t agree. You could say that Spotlight also runs as root, but people using an operating system written by Apple do have to trust Apple.

Even more bothersome: I told it not to upload statistics to Google. Their Privacy Policy says:

If you choose to enable Usage Statistics on Google Desktop, it allows Google Desktop to send crash reports and to collect a limited amount of non-personal information from your computer and send it to Google. This includes summary information, such as the number of searches you do and the time it takes for you to see your results, and application reports we’ll use to make the program better.

Well I didn’t, but Little Snitch tells me that a program called StatsUploader wants to talk to dc-in-f99.google.com every 30 odd minutes so. I happen to trust Little Snitch as I used it to help me make sure that Find It! Keep It! wasn’t loading anything from the Internet (unlike most other “internet page saving solutions”, such as those that use WebArchives).

It silently installs an Input Manager

Find It! Keep It! crashed, and the crash started neither Apple’s CrashReporter nor my built in CrashReporter which is extremely odd. Given my past bad experience with Input Managers, I used Find It! Keep It!’s input manager panel to see whether I had acquired a new one. Indeed I had. It lurks in /Library/InputManagers/GoogleModLoader.

Now this bothers me. I did NOT agree to have an InputManager installed. InputManagers in /Library/InputManagers are loaded into EVERY application running on the computer for every user. So what the #!$! does it do? Simply runningcd /Library/InputManagers/GoogleModLoader/strings GoogleModLoader.bundle/Contents/MacOS/GoogleModLoader
in the Terminal tells us that it loads modules.

Further investigation using OTX shows that indeed it crawls a Google/Mods directory and loads modifier bundles into the applications specified by the key GoogleModTargetApplications in some dictionary somewhere. It also appears to do a fair amount of stderr, debugging, pthread and system logging.

If you attach gdb to a running copy of Safari, you can see that SafariSearchResults.gmod and SafariWebHistory.gmod from /Library/Application Support/Google/Mods/ are now loaded by typing info sharedl. One thing they do is to add a new item to your google searches: “About 34 results stored on your computer”. I’m guessing that SafariWebHistory allows pages you just visited to be found with google desktop.

Nevertheless, Input Managers should not be installed silently. They can easily cause system instabilities and this particular mechanism could be diverted by third parties to install unauthorized gmods in a place no one knows about: a big security risk. Given the furore over Unsanity’s Smart Crash Reporter, I’m surprised Google installs this. It’s not like anybody worries about Unsanity’s secret plans of world domination.

It also installs a Kernel Extension

Again kernel extensions aren’t something that should be installed silently as they could very easily impact the system’s stability.
For instance, it includes the nice message “socred_fini() failed, which is a known bug with Apple’s socket filters. Sorry but you have to reboot”.cd /Library/Google/Google\ Desktop/GoogleDesktopDaemon.bundle/Contents/Resources
sudo strings GDFSNotifications.kext/Contents/MacOS/GDFSNotifications
I’m have no idea what its doing with the sockets, but a guess would be that they might need something like that to inform Google Desktop when a file changes to reindex it or for their snapshot capability.

Conclusion

I’m disappointed. I was going to look into Google’s open API to speed up searching the Find It! Keep It! Database for those users using Google Desktop. I think I’ll wait.

Hopefully future versions of Google Desktop will respect user preferences, clearly request the right to install any Input Managers and allow paranoid people like me to give it limited permissions (eg: a single user’s permissions). Alternatively they could release its source code, as they have done with MacFUSE so that we know what it’s doing. In the mean time, I’m uninstalling it.

Hi Jess, I saw that. Problem is that it was a thing called StatsUploader contacting Google, and I neither enabled Stats or “desktop integration”. In fact I checked they were disabled. Are you suggesting that StatsUploader is checking for a new version? That should be Google Updater’s job.

Why are you surprised it installed a kernel extension? It’s doing the same thing Spotlight does to get filesystem update notifications from the kernel so it can index new and changed files and know when files it has indexed are deleted.

As for the input manager, I don’t know if there was another way to do what they wanted to do to get the seamless google.com / google desktop integration, but I guess they decided that was the best way to do it.

If Google hadn’t done these things their product wouldn’t have been very seamless, automatic, it would have taken way more system resources to keep the index up to date and people would have complained that it bogged down their system and wasn’t user-friendly enough.

Yes I am surprised and concerned. I did not expect that installing an indexing tool to be that invasive. I don’t think you realize how easy it is to make a mistake in a kernel extension or Input Manager and suffer strange instabilities afterwards.

When I was an engineer at Cyrix, NS, and then AMD, we debugged software and chips: the more subtle chip bugs only appear when running other people’s software. Windows 95 & 98 had its bugs, but many of the issues weren’t Microsoft’s but due to bad drivers, bad extensions etc. I certainly don’t want to see OS X ending up unstable.

I’ve read Amit Singh’s Mac OS X internals book and know that a kernel extension is a mechanism through which you can get file system notifications, but I don’t know that’s what Google is doing here because I didn’t reverse engineer it.

As I said, IF they NEED a kernel extension to do this, then they should provide its source code. After all there aren’t any secrets about how to make one that hooks into the filesystem: the full source is in Amit’s book. If one can rebuild the same thing from the source code and one can look at its source code, if there is a problem someone somewhere will find it.

Now to the input manager: I don’t believe they need it. They could be an HTTP/S proxy just like privoxy and provide the same UI effect and record of history. That kind of solution would work with any browser, not just Safari and Camino. Furthermore the Input Manager should have been installed only in the directory of the user who wanted it, not system wide.

The ultimate question is one of trust, and whether if every software developer did this, the users would benefit.

* Do you trust Apple who have unit-tests for their OS, who test the hell out of it internally and with other people, who have the full source code and the people who wrote it? And despite that my MacBook Pro grey-screens (blue screen a la Mac) once a month.

* Do you trust the Google Mac team who must have reverse engineered some of Safari to make their Input Managers? who have tested it on many machines, but not as many as Apple? Apple doesn’t — otherwise they wouldn’t be defeaturing Input Managers in Leopard.

* Do you trust the next guy that comes along and does the same? Why not? They many have tested it more than Google’s Mac team. They may even have tested their extension with other people’s extensions!

The reason for avoiding adding stuff to the kernel, for not inserting foreign code into other people’s programs is stability. Installing an application should not require root privileges and when it does, it should be forthcoming about why it does.

If you feel safe with it, and you understand the implications, please enjoy it. As to your mother, since you mention her in your blog, yes she should be asked. If she doesn’t understand the ratio of risk to benefit, she’s not consenting to it and it would be wrong for her to suffer any consequences were some to arise.

To your “no good deed” comment, this is Google’s first Beta. A Beta is a request for feedback. My feedback is please make a less invasive solution. Work with Apple to make the APIs you need from Spotlight open to everyone, or reduce people’s risk by being more forthcoming about what you’re doing.

I’ve been wondering whether this is not somewhat a culture clash

On PCs people seem to accept software taking over and doing its thing. For user friendliness no warnings are displayed: see no evil, hear no evil, do no evil. But then they’re unhappy when the computer blue screens. This is the environment in which Google Desktop was born.

On Macs, some people prefer to be told and hand out their root password reluctantly, while others apparently prefer the “I trust you” route.

On Linux, most people wouldn’t dream of installing a closed source daemon let alone kernel module, and if they did install it, they’d disassemble it first.

I think our fundamental disagreement is that I don’t think the question is how we would feel if every software developer did this. We are willing to let developers of certain software packages use capabilities we don’t think every app writer should. For instance in Linux (at least in the past) X required low level hardware access and crazy privileges even though Linux users would cry bloody murder if their spreadsheet program tried that.

Obviously if possible we should avoid giving code dangerous capabilities (input managers) but having an input manager isn’t really the problem. The problem is allowing inputmanagers to be installed at all. If Google doesn’t install their input manager it doesn’t make it any harder for the malware writer to install their own input manager.

I don’t think the proxy solution is not a good one. For one this would confuse many users, especially those who use their own proxies. Without horrible hacks these proxies would show up in all the other pref panes. In effect Google desktop is providing OS level functionality so it needs to install code that gives it OS type access.

It’s ultimately your choice whether or not GDesktop is important enough you are willing to let it do these things. For some Linux users X is simply too dangerous to system stability.

Kernel Extensions:

Once again one just has to decide based on past performance and knowledge of the company whether you trust them to provide a kernel extension and if this functionality is worth an extension. It is no different than deciding whether to install a new kernel update for apple adding a new feature. Publishing the source might be one way to gain people’s trust (not many though) or they can just wait and let the lack (or not) of kernel failures speak for itself.

–

Warning Mother:

Your response here simply doesn’t make sense. Should apple have never provided spotlight or other OS enhancements because they could never explain the security/stability implications to the normal end user?

Obviously people like my mother should have the opportunity to avail themselves of new software features even if they wouldn’t understand the internals or the risk to their system. This software is labeled beta in big letters and isn’t being aggressively promoted. Admittedly it would have been slightly better for Google to provide an advanced/developer explanation of what they were installing. However, if this functionality requires a kernel extension the right answer is NOT to tell people who don’t know what a kernel is that they don’t get these features because they can’t make informed consent.

–

In short I (and I think other comments) are reacting to the tone of your post. You could have said: It’s a shame you had to make use of input managers and kernel extensions. If you could remove these capabilities I would be very interested in using it. However, the tone instead sounded like you were calling Google out for doing something bad.

If they really could have provided the same functionality without using these features without causing other problems then sure it’s fair to criticize them. However, if this is the only way to do it surely we are better off for having the option.

Of course ultimately one would prefer a nice API that lets one provide the functionality in a secure manner. Though any API which lets one do what GDesktop does would be a security risk no matter what. However, it is not clear that apple would be very amenable to encouraging competitors to spotlight/making spotlight look incomplete or if they would be willing to put in the work without some evidence that customers want more than spotlight. By releasing a beta Google can check the level of interest and give some of us more choices and hopefully over time work to get an API for their needs.

This doesn’t mean I’m an uncritical fan of GDesktop. For instance I think their decision to hitch a ride on spotlight indexing wasn’t the best. At the very least they should improve their interface for removing things from the index. However, I just object to the berating, rather than suggesting, tone and criticism of google’s choices when it isn’t clear the same thing could be accomplished in another way.

Google Desktop is NOT providing OS functionality, but Application level functionality and should be staying over there. OS functionality is limited to memory management, file system and hardware drivers. In the case of X and Linux, it didn’t even include graphics drivers (something with which I disagreed — hence my work on KGI).

There is an API for filesystem notifications in user space. Amit Singh, the Author of http://www.osxbook.com/software/fslogger/ works for Google, so they could have used that. Yes it requires root permissions which is still a concern to me.

I disagree that a proxy is a bad solution. Installing it can be automated with Applescript. Passing stuff through it to another proxy can be done. People who understand enough to install a proxy will grok it. People who don’t won’t notice the difference. A sysadmin could debug it because expected things are changed. It would be a very rare sysadmin who looks for kernel extensions. And in the worst case scenario: the system loses its internet connection.

Tone? To berate is to censure severely or angrily according to Google’s define service. I did not censure severely or angrily. I said I was disappointed. I am. I wanted to use it and recommend it because I find Spotlight slow. With 26 years of programming experience from the firmware level to the Application level, I can’t in good faith recommend it. I’m judging using my competence in the field. You can judge based on reputation if you like, but I think that’s a weaker metric.

So to conclude. Yes it could be done differently. Yes I do like Google and No, I’m not using their Mac Desktop software. Yes, I’d like them to set a good example and use the simplest and safest implementation. Their software is a guest on my computer, not the host.

Funny that you mention otx(no caps, btw) and Unsanity’s SCR in the same section- otx also uses SCR, but only when the user agrees to it. Installing input managers is a serious decision that the user should be informed about.