This post is not meant to increase paranoia. It's meant to reduce the amount of paranoia from people that are naturally paranoid (like those running as non-admin with the mistaken idea that it protects you from something that running as admin (but not root) on OS X doesn't).
The very, very recently released Mac OS X 10.4.7 update installs something called "VerifiedDownloadPlugin.plugin" inside /Library/Internet Plug-Ins/. This file is not malware, despite its name.
On Windows, it's very common for malware (spyware, ad-ware, trojans, et cetera) to use inconspicuous names such as Windows Genuine Advantage, SystemService, or ShellHelper so they do not raise a red-flag when people see them and they will not attempt to uninstall them. The problem is that "VerifiedDownloadPlugin" has such a name. It seems to have the intent that it was named to make the user feel "safe". The other issue is its location, /Library/Internet Plug-Ins. These plugins are loaded into applications that either load netscape style plugins or applications that use WebKit and turn on plugin access (like Safari). Because these files load into browsers and browsers are made to contact websites on the internets, no one would notice if these plugins are spyware and use your browser process to send data "home". Most software based applications for extremely paranoid people that ask on a per-application and per-connection basis automatically exclude browsers due to the sheer amount of traffic going through them. So hiding in /Library/Internet Plug-ins/ would be a good place for this type of malware.
Granted, I have no idea whatsoever what VerifiedDownloadPlugin.plugin is actually for, but it was included in the Mac OS X 10.4.7 updater. The 10.4.7 updater also includes Quartz Composer.webplugin which has a name that says a lot more about what it is for. This is the kind of name that VerifiedDownloadPlugin.plugin should have.
Update: As Ryan points out and I thought I was imagining, the executable bundle itself is only 8,200 bytes and doesn't actually appear to contain any usable code. It links to the Foundation and AppKit frameworks (both part of Cocoa), calls no symbols, and has 1 STR# resource that repeats "Verified Download Plugin" twice and one empty STR# resource. In fact, it has all the markers of malware in the simple fact it appears to do nothing. The project name is "SecureDownloadAgent," for whatever reason.
This second beta of the APE 2.0.1 installer has a much more final version of the symlink permissions fix for the Mac OS X problem described here. It also has the following "fixes":
- The APE installer now makes sure the symlinks in the APE framework have the correct permissions. This is to work around a bug in Mac OS X in which the system respects the permissions on symlinks when the documentation explicitly says they are ignored (see http://www.unsanity.org/archives/000463.php for more information).
- The APE Preference Pane now correctly shows the icons for APE Modules with icons. Not all APE Modules actually include icons. For example, Shape Shifter does not include one.
- APE Modules can now be installed for "this user only" by double-clicking on them even if ~/Library/Application Enhancers/ does not exist.
- For Developers Only: The APEToolsID of an application can now be used to only affect specific applications by adding a APEMatchInfo key to the APE Module's Info.plist. This was needed to target applications made with the Qt framework.
You can get it at http://www.unsanity.net/beta/ape-201b2.zip.
PD Tweaker for Parallels Desktop, Yo!
The awesomely awesome Drew Thaler has released PD Tweaker 1.0. PD Tweaker is an APE module that fixes what amounts to a massive performance bug in Parallels Desktop with regards to how it saves and how it caches its save files and hard disk images. The main PD Tweaker page explains the bug and the fix a lot better than I could, especially since Drew is much smarter than I.
Of course, the source code to PD Tweaker is available on the PD Tweaker page. I also just love the comments on Drew's blog post.
If no one noticed, some of the fixes in APE 2.0.1b2 were specifically for PD Tweaker. While APE has had the ability to target and only load specific modules in specific applications for a while, it requires the target application to have either a CFBundleIdentifier or a CFBundleName. However, one of Parallels Desktop's included applications, ImageTool, is a Qt-based application (Qt, not QuickTime) and, by default, Qt applications have neither of these. The far, far majority of applications do, in fact, you can almost assume that all applications have a CFBundleIdentifier and that ImageTool is an exception to the rule. Since one of the two PD Tweaker target applications has neither of these Info.plist keys, there needed to be another way to identify this application. Enter APEToolsID. APEToolsID is a happy little string generated by APE to identify an application based on its metadata. This has been in APE for quite a while and this works irregardless of anything placed in the target application's Info.plist as the APEToolsID generator McDealie keeps falling back until it can get some kind of metadata, even if that metadata is just a path. However, before APE 2.0.1b2, there was no way for APE Modules to target this in their Info.plist. Now there is. Rejoice, the three of you that ever needed this before on a passing whim.
That Leopard Screenshot
Everyone has seen that screenshot of Leopard, right? I wonder what Ceiling Cat thinks of this, as he watches you defecate.
Sigh.
We've received a lot of complaints/emails/oddly worded love letters from users that have said APE just doesn't work at all (or some APE Module doesn't work at all). Until recently, we've had no idea the cause of these problems. Oddly, the number of people reporting the problem got much higher once APE 2.0 was released. Please, please remmeber that if someone is having a problem, the chances of them reporting it is nearly 90%. Whereas if someone is not having a problem, the chances of them reporting it is nigh 0%. I mean, why bother to email someone if everything is working A-OK, right? Luckily, some of these users had a console (/Applications/Utilities/Console) log containing some APE error messages, specifically, the error -43. Error -43 is fnfErr or File Not Found. Since the section of the APE code that wasn't running correctly uses a lot of BSD and CoreFoundation APIs, neither of which return usable errors like fnfErr this error could only be coming from one point in the code. In order for that error to be returned, the code path must hit an impossible case, or so I thought (I'm not the brightest cookie in the dryer). If that part of the code was hitting this error, then how could APE have even ran any code at all? I mean, this was being logged by aped but aped can't be launched if the APE framework cannot be found. Turns out that these few machines with the impossible case were the "key" to finding the issue.
If you look at the Anatomy of a Framework documentation McDealie you can see that most (if not all) Frameworks have symlinks in their root directory pointing to the actual folders in the current version of the framework (since frameworks can contain more than one binary incompatible version). According to the lstat documentation symlinks do not have their own permissions, owner, modes, or group. They take the permissions of the parent folder or the target item (depending on which documentation you read). Therefore, there was no need for the APE installer to create these symlinks with special permissions. However, turns out there's this happy little bug in Mac OS X 10.4.x in which the permissions of symlinks are actually respected and on these particular computers, there was no read access to the symlinks which means they couldn't be resolved which then meant APE wouldn't work at all.
You can easily confirm this bug for yourself if you so desire. Open the terminal (/Applications/Utilities/Terminal) and type:
cd ~/Desktop
umask 0777
ln -s textfile.txt symlink.txt
umask 022
echo "blah blah blah" > textfile.txt
ls -AFl *.txt
When you issue the last command, you'll notice an error that says ls: symlink.txt: Permission denied if you're on Mac OS X 10.4.x. If you're not on 10.4.x, it will correctly show it is a link to textfile.txt. The odd part about this is that double-clicking on the symlink in the Finder correctly opens the original file. Go figure, the Finder does what it's supposed to do.
Once a symlink is made, its permissions cannot be changed. Even if you try to use something like chmod, the changes will not stick. Mac OS X does not support things like lchmod (despite what the symlink documentation says). That means the only way to fix these broken symlinks is to destroy them and create them anew.
How to tell if you're affected by this bug.
If you have a non-working APE install and think this symlink bug might be the reason why you cannot use APE, there's a super quick and easy way to find out if your thought is based in reality. Open the terminal (/Applications/Utilities/Terminal) and type:
ls -AFl /Library/Frameworks/ApplicationEnhancer.framework/
If you are affected by the bug, then ls will list the permissions for the symlinks as lrwxr-x---. If you are not affected and APE is correctly installed, it will list them as lrwxr-xr-x (the 'l' means "symlink", a 'd' means "directory"). Notice how the last 3 characters are r-x in the working version and not ---? That means that people that are not the owner (root) or a member of the group owner (admin) can also read the symlinks. If the permissions are wrong, there's an easy fix.
So how do I fix it?
There's a simple fix to this. Simply download the APE 2.0.1b1 Installer, install it, and log out of Mac OS X. When you log back in, all should be well and APE should work again. You can confirm that the permissions on the symlinks are correct by using the above command in the above section in the above paragraph above what I just said. You do not need to install this if you are not having a problem with APE functioning. Please note that this installer does not change the version of APE listed in the Application Enhancer Preference pane.
If this does not fix APE not working and you are not logging in as root, then please email us along with the output of the above command showing the permissions on the symlinks. Remember, this bug only makes APE not work at all, it has no other side-effects. However, if your goldfish dies, you can go ahead and blame that one on APE.
Recently Rouge Amoeba, purveyor of fine cosmetics, published some numbers and experiences about their new product release, Winfoil. (apparently, some type of combination cosmetic/UV/extraterrestrial protection cream. I've yet to try it)
It's a matter of conditioning
We got talking about how it would be interesting to look at conversion rates on our products. That was yesterday. Not one to slack, Paul posted the dirt today.
I like Paul, but I don't like him staring at me for extended periods, so without further ado and bad jokes, here is Unsanity's conversion rates for May 2006:
It's a matter of fact.
| CTM | FC | FM | LX | MeMa | MM | SS | Silk | WSX | XND | |
|---|---|---|---|---|---|---|---|---|---|---|
| Conversion Rate: |
3.1% | 10.4% | 5.4% | 4.0% | 4.7% | 2.9% | 2.3% | 3.7% | 6.2% | 3.3% |
I'll leave it as an exercise to the reader to match up those acronyms to our various products. :)
What does all this mean? Well, not a whole lot from what I can tell. There are so many factors that influence these numbers that it's hard to get a really clear picture. May was definitely not our best month on record. We just barely started getting our products Universal-ized and that surely has had an impact on our conversion rates.
Interestingly, FontCard seems to sell itself quite well. I think a large part of the reason for its successful conversion rate is the niche it targets. Generally, professionals are the people who download and use it. They tend to pay for the software that makes their lives easier a bit more readily. ShapeShifter on the other hand has a fairly low rate. Why? Basically it's the opposite of FontCard. It's basically just a fun product. It's also our most pirated product. That may also influence the conversion rate numbers.
Finally, just so you don't base too much on these numbers, I've checked various time periods and it's quite amazing to see how much they vary. So this is just us, one small mac developer, for one 30 day period. Take what you will from it.
That said, it is fun to look at, let's see more developers get on board and post their findings!
I kind of thought this was funny. A website on the internets was talking about Microsoft's Get the Facts campaign about reasons why someone should switch from Linux to Windows Server system. They have a bunch of Case Studies that attempt to show how companies have made successful switches from Linux to a Windows Server solution. Granted, I have little experience with Windows server, but one of their case studies "caught" my eye.
One of the biggest issues arose when Envirotactics fell prey to the Blaster virus. The firm was susceptible because its Linux system had no critical updating mechanism or centralized virus protection. The virus shut down the company's system for a full workday. "Downtime costs us between $5,000 and $10,000 a day, not to mention the frustration it causes," says Chris Neuffer, President of Envirotactics. "That's a lot of revenue for a small business."
Why is this amusing? The Blaster worm (W32.Blaster.A) is a Windows worm that only infects/targets Windows systems. It takes advantage of a security exploit in Windows. It can only infect systems running Windows 2000 and Windows XP. Systems running an alternative like Linux, BSD, or Mac OS X cannot be infected. I say infected instead of affected because this worm did affect these Operating Systems. The sheer amount of infected Windows machines caused a drain on the internet as infected systems went out searching for new victims. In this way, it is very similar to the Code Red worm before it as machines, firewalls, and routers would get the request, process it, and reject it (or crash in the case of Code Red).
So why is Microsoft saying that a company switched from Linux to Windows because they were hit by a worm that only infected Windows systems? Someone suggested it was Microsoft trying to state that because Linux has no antiviral solutions and cannot do Patch Management for Windows client. The case study site fails to note that if the clients had not been using Windows, the Blaster worm would not affected this company nearly as badly as it had. In this way, it is very similar to the fake switcher story that Microsoft has posted before. In fact, this current Linux case study may be fake as well.
Many people have accused the "Get the Facts" campaign as being FUD. Whether this accusation is true or not is not for me to say.
This is a quick post to summarize and re-post the links to our Universal Binary products.
The following products have been publicly released in final Universal form:
Application Enhancer
Chat Transcript Manager
FontCard
FruitMenu
Menu Master
Mighty Mouse
ShapeShifter
Silk
Xounds
Cee Pee You
ClearDock
ShadowKiller
Smart Crash Reports
WindowShade XThe following products are available in PUBLIC BETA Universal form:
Dock Detox 1.3b1
Update: Moved FruitMenu out of beta.
Update 2: Xounds 2.4 is now a Universal Binary.
Update 3: WindowShade X updated to 4.1b2 and ShapeShifter 2.4b3 listed.
Update 4: ShapeShifter 2.4b4 listed.
Update 5: FruitMenu 3.6.2b1 and WindowShade X 4.1b3 listed.
Update 6: FruitMenu 3.6.2 and WindowShade X 4.1 moved out of beta.
Update 7: Mighty Mouse 1.3b1 listed.
Update 8: FontCard 1.3.3b2 listed.
Update 9: ShapeShifter updated to 2.4b5.
Update 10: FontCard 1.4, Mighty Mouse 1.3, and ShapeShifter 2.4 moved out of beta.