There’s been a fair amount of chatter about OS X 10.4.7 adding “phone home” capabilities to Dashboard. When we talk about “phoning home,” we’re usually talking about a secret process that transmits information back to a central location, possibly putting personal information at risk. fetchadvisory, though, does nothing of the sort.
What It Really Does
Every eight hours, a process called fetchadvisory is launched. In short, this process verifies the authenticity of your installed Dashboard widgets. How does it do this, though?
OS X has a nice little UNIX utility called tcpdump that’ll help us figure out this riddle. The following command opens up your interface and listens for anything to or from www.apple.com. If you want to make sure that it’s not communicating with another host (it’s not), you can leave off the host www.apple.com part.
$ sudo tcpdump -ien1 -A host www.apple.com
password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes
Open up another Terminal window and execute the fetchadvisory process.
$ /System/Library/CoreServices/Dock.app/Contents/Resources/fetchadvisory
tcpdump, over in the first Terminal, will start spewing the stream. By default, tcpdump only shows raw tcp cruft, but the -A flag displays the ASCII translation. Along with some basic TCP headers and other overhead, you’ll see the following two HTTP GET requests.
GET /widgets/widgetadvisory-5 HTTP/1.1
GET /widgets/parser.info HTTP/1.1
No cookies appear to be shared, no query strings that give away any information. Congratulations, you’ve actually given away less information to Apple than you would when directly visiting the Apple webpage.
... apart from the obvious fact that I don’t have to visit Apple’s web site three times a day, this contact with Apple will let them know that someone at my IP address is using X.4.7. And at the end of the day that’s information which I don’t mind revealing voluntarily but which I don’t approve of being sent away without me knowing.
In addition you (and the rest of the internet) claim:
(bq)In short, this process verifies the authenticity of your installed Dashboard widgets.
How do you come to that conclusion? Has anybody seen that ‘verification’ happen?
It reveals you are running 10.4.7 or higher. Which, consequently, you reveal to everyone whose site your browse daily with the User Agent string from your browser if you use Safari (it gives the version of WebKit and/or Safari).
the point is that it’s not transmitting any personal data back to apple. the term “phone home” is usually used to mean that the application is collecting information and sending it back. this is not – it’s getting a small file from apple.
A minor note:
sudo tcpdump -ien1 -A host www.apple.comThe en1 part should be changed for whatever network interface you use. en0 is more common for built in ethernet.
While it doesn’t bother me in the slightest that it checks, it would be nice to have the option to turn it off. Perhaps put it in the Software Update preference pane along with it’s preference to automatically check for updates?
Does anyone actually know what it does when it finds an ‘invalid’ widget is installed? How does it decide if a widget is invalid? – With such a vague description (posted a while after 10.4.7’s release) to a non-technical user it could do just about anything. The unknown scares people. Hence all this discussion on the internet. A similar sort of issue arose with the iTunes mini-store as I recall…
Modifying a stock Apple widget doesn’t seem to cause any messages about ‘invalid’ widgets – anyone know how to make a widget invalid to see what it actually does?
This should solve the “problem” (haven’t tested but I assume removing the executable bit is hardcore enough):
1. Open Terminal
2. sudo chmod 644 /System/Library/CoreServices/Dock.app/Contents/Resources/fetchadvisory
3. Enter your password
To change back
1. Open Terminal
2. sudo chmod 755 /System/Library/CoreServices/Dock.app/Contents/Resources/fetchadvisory
3. Enter your password
Actually, the other way to do this, and this has been floating around in various places, is to just tell
launchdto not load the process.sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plistTo make it work again:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plistThis doesn’t alter the program, but tells
launchdto just not use it anymore.