|Home » Industry Watch
Apple Apps Like To Phone Home. Ours Don't.
We won't let them.
There's a big difference between Apple's and everyone else's apps and ours. Those other apps phone home every time you launch them. Ours do not. Those other apps need approval from Apple just to launch. Ours don't need anyone's approval - other than yours. (After all, you launch them, so you - and only you - should get to decide.)
That's the simple truth.
Those other apps are bulky and crash-prone. Ours are lean and mean. Like you've never seen. (Believe us, we've been around long enough to know.)
Apple's so-called 'file manager' (SRSLY, WTF) is a wayward Shrek that crashes all over the place. Ours hasn't had a single memory leak, runtime error, hang or crash in over twenty years.
It just works.
Apple's so-called 'file manager' has been so bad that it forces cold system reboots. That's right: so you have to power down and restart the entire system. This for a file manager, an application. Apple's application.
Ours just works.
'The Apple rep comes and shows off all this dazzling hardware to the admins. They're impressed! Then they ask him to launch the system file manager. They get one look - and they walk away.'
What happened to Apple?
What happened to Apple, you may ask.
Nothing, some might tell you. They've always been that bad. But the super-duper hard-core real crash-and-burn super-decline started just after the announcement of the iPhone in 2007. Their bug reporting division had been overwhelmed with millions of tickets, and they finally told everyone 'we're not following up on any more bugs right now, but try our new OS version when it comes out, that might be better'.
Backtracking a bit: Things started innocently enough. Like doing a chown 0:0 / chmod 777 on everything in the system. Until of course everything starts crashing and people start posting their crash dumps online and the whole world gets to see Apple naked - with the wacky permissions they have on their system files.
But there must be a good reason, posts the redoubtable Groober! There was! For, starting with the next OS iteration, safe permissions kicked back in again.
Only three releases got loose. They caught it. Almost in time.
Oh well. Time to regroup.
So Apple regrouped with code-signing. Great regroup, sheer genius. So you can cryptographically 'seal' an application bundle. Except the reference to the seal, located in the binary headers, can be removed, and then no one notices there's supposed to be a seal, and so nobody misses it. Or looks for it. Sheer genius.
A challenge to all the hackers out there. (Are there are any on Apple platforms?)
Hack our CLIX and prove it and you'll get a free lifetime licence to our ACP. CLIX uses a genuine cryptographic seal that really works (and doesn't phone home).
We saw what was going on. And we shared that information. Almost fifteen years ago. Except no one noticed. Only a few smart guys. Computer guys. The same with iPod_Control years earlier. Duping 98% of your customer base is good enough. That's how to calculate!
That's all? No. It doesn't stop there. Would that it would. Or could. But it doesn't. And can't. For, to verify the authenticity of the code-sign seal, one has to climb up the certificate chain to the root. And that root's in California. Cupertino. Or maybe the Carolinas today. At any rate, it's a server (servers) owned and operated by Apple Inc.
Wait a minute, you say. (Some 2% say it.) So does that mean... ?
The answer's 'yes'. They may have a caching system, if one can devise such a caching system, although evidence points to no caching. When they had one of those huge system updates and - you remember? People couldn't get their applications to launch? Oh to be a fly on the wall that day.
Except ours. Our apps launched. Our software worked. We verified this through the reports we received, some from some pretty accredited network gurus. Everyone else's software just stopped working. Ours did not. Our software kept working.
To paraphrase an Egyptian, 'It just works - it keeps on working'.
When you launch an app on an Apple system, the launch services read off the binary headers. If they find reference to a 'code sign' section, they pick up the offsets named in that section, scoot to those offsets, read off the 'CodeResources' data on disk, then try matching up what you have with what you should have.
(This means they have to recalculate all those checksums. For Apple's Xcode, that's nearly half a million disk-reads and calculations. Just to launch.)
But they also have to verify your certificate, embedded in your binary, which should be an exact copy of Apple's own root certificate, and doing that really slows things down. For, to do that, the launch services in your system have to phone home.
And that takes time. That's what causes the bottleneck. For it's now that your launch services have to verify that the seal is legit so your app can launch.
But hang on, for there's more.
Those launch services of yours can of course send lots of additional data to the Apple Mother Ship when the line's open, right? True. And why not? You certainly can't stop it!
You never know what they send. Apple's firewall stops you from controlling the ports they use. Egress firewalls like Little Snitch have had a tough time with Apple. Apple want to control your system. They don't like you trying to control it. You only bought the thing, remember? You don't really own it too!
You see? They do. Your location. Your system settings. Your MAC number. Your running apps. The names and contents of your document files. They see anything they want.
Oh so they told you they're not peeking at 'so-and-so'? And you believed them? You had to take their word for it, didn't you? That sounds reassuring.
Remember when someone leaked how Microsoft concocted a way to physically damage the hard drives of clients with expired licences? Think back to the turn of the Millennium. Back then. It made a big stir, to say the least. Remember?
Thank goodness Microsoft came to their senses and never used that on people. But yes, that technology does exist. A technology to destroy a hard drive by remote control. Or perhaps some other component today. Anything's possible with today's technology.
Can Apple do the same as Microsoft? And really follow through on it? Perhaps something a bit more merciful, a bit more 'Mac-like'? Of course they can. As things stand today, you need Apple's permission to reinstall your system, as but one example. What if they decide they don't want to let you do that? They have already demonstrated they can stop your applications from launching...
And remember how, starting with Leopard or Snow Leopard, you no longer had to authenticate to install system updates into protected areas? These foreign objects, in the form of a download, suddenly appear in your system, and they're automatically authorised to go anywhere they please? They no longer had to ask your permission.
Great feeling, isn't it?
Same thing here. It's nice to know your system is integral. That no foreign power, no nasty bit of malware, can make headway onto your system, even if it somehow downloads.
You can stop things like that on a system without backdoors. You can't stop it on an Apple system.
Talk is cheap at Apple. Oh, they're trying to protect you. From everyone but Apple. (Against Apple you are defenceless. Suck it up, fanboy.)
You need to start doing the research. (Don't think 'Microsoft'. Don't even think it. Leave this page right now if you even thought it.)
You need to ask around. You need to see how 'free' systems handle updates. Do users have to authorise and authenticate? Can anything in the system be modified without your knowledge and consent? If not, then it's a reasonable bet that you'll be safe.
[Unix systems consistently ranked the most secure in the world do not have 'code-sign' or any 'phoning home'. Why is that, do you think? For they've seen what Apple did, and they've discussed it, and they discarded it. And they're still more secure than Apple. Why is that?]
And don't forget that no vendor can ever guarantee that a remote-controlled update like Apple's will not fall into the wrong hands. We've seen time and again how IT monsters - Sony being one example - have had to eat dirt after being hijacked.
Sorry, but we've seen Apple 'blow it' time and again. Too many times to count, unfortunately. And, frankly, you shouldn't be on an Apple system anymore unless you have a very good reason for doing so. You don't relinquish control of your personal property - your personal confidential data - to Apple or anyone. You just don't do it. You have to have full control. Just like in the old days. When systems were still secure. And honest.
Our ACP software isn't controlled by Apple. It never has been. It never will be. Our ACP software just works.
Our ACP software also uses traditional menus, so opening and saving files works like it always has, like it's supposed to work. And there are no special compartments in your file system that are off limits just because Apple said so. We make sure of that.
Perhaps you're part of the 98%. Perhaps you're one of the sheeple who had to rip tunes all over again each time you got a new iPod. One of the sheeple who couldn't share tracks with a friend because Apple said you couldn't. Even though the tracks were right there on your iPod, you couldn't find them.
ACP users have always been able to find them.
ACP users aren't burdened by all the lies and nonsense tossed the way of the 98% by Apple.
ACP apps don't phone home. ACP apps just work. Better.
Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.
All Content and Software Copyright © Rixstep. All Rights Reserved.