kickaha | STANDING OVATION

<lmao>

Yeah, it sure is.

<sigh> I love my Mac...

First of all, I read that as "Standing ovulation". That took a second.

And, I just "upgraded" (hahahahahahha) to XP SP2 last night, which toasted my IE, hosed my firewall, and appears to have zorched a bunch of other stuff.

So. I'm seriously contemplating buying a Mac when we go to replace Todd's computer. Can a many-years Windows user learn to use one of them things? (I'm sure I can.) More to the point, can I train my not-computer-savvy hubby in one?

As a long time windows person who went Mac (at least partially), you can figure it out. In some ways, your hubby may have an easier time as it seems people with no background pick up Mac quickly. The rest of us have to untrain certain habits...

What f_x said. :)

The biggest problem you'll have is unlearning the workarounds you've had to get used to in Windows. Basically, you can try just about anything without fear of it breaking anything, and secondly, it almost always works the way you would expect it to.

Oh, and drag and drop is *ubiquitous*. Have a Finder window open to a directory with an image file in it? Drag and drop it to a mail window to add it as an attachment. Or to a Keynote window to include it in a presentation. Or to an iChat window to send it to someone else via IM. Drag text from one app to another, or drag an image off a web page and plop it anywhere. This works across the system, between apps from just about any developer, not just the company that produced one particular suite.

It's almost, *gasp*, fun.

No, actually, it is.

I gotta confess, I am not a Mac person, but they got me one of the new pizza-box style ones at work (the entire thing is contained in the monitor, which is about 2" thick). And I'm starting to like them. Admittedly, anything would be better than the ancient dying iMac with an itty-bitty screen that they had me using before; but I think even I could learn to love Mac. Not enough to shell out the $1600 + software that my new work machine costs (I'll stick with my $500 spyware-laden PC for home), but enough to be friendly with them.

How about a $500 non-spyware-laden Mac? ;)

http://www.apple.com/macmini/

Damn you, Apple pusher! :)

AFAIK MacOS and all the apps are still written in C++ or ObjC (or C or Pascal), which don't prevent stupid mistakes like buffer overflows. Until the world moves to verifiable safety and sandboxing (Java/.NET/Eiffel) is there any reason we can expect MacOS to remain secure once it draws substantial attention from malware authors? I don't think I'd run even OpenBSD without a firewall...

There are a couple of points I think you're trying to make here, and they are best considered as separate issues.

1) Language support for data structure safety
I'm not convinced that this is a long term solution. It is a *part* of the solution spectrum, but just as C can be written to be robust, Eiffel can be written to be full of holes. The language constructs can provide safe mechanisms such as guarded arrays for buffer use, but at the same time allow production of data structures that can, if improperly designed, result in utterly trashing said mechanisms by attempts to replace them. Silly? Sure. Possible? Absolutely. Probable? Have you *seen* some of the lousy code out there these days?

Essentially, language support for any idiom has to be an attempt to enforce policy to be worthwhile. (If it were merely a case of producing functionality, we'd still be using assembler - a Turing machine is a Turing machine is a Turing machine. If it's not functionality, and it's not policy, then it's just syntactic sugar.) For instance, object-oriented languages add one essential fragment above and beyond structs, file-based function gathering and static keywords: enforced memory allocation and data initialization as one atomic act. Otherwise it's just syntactic sugar that makes certain abstractions more clear. However, one can easily 'bypass' that policy enforcement by making a class with an empty constructor and an intended initializer method that the documentation states must be called before the object is used post-instantiation. Boom. You just lost any purpose for using an OO language.

Policy support to prevent programmer stupidity is problematic, and even adding direct language support in an attempt to enforce it is at best going to snag only a portion of the problem. It'll take care of the most common cases with developers making silly mistakes, but no language will ever truly be able to protect those who think they're uberl33t from themselves.

In a similar way, using libraries and frameworks to reduce potential problems is about on par with language support. Providing facilities in an API that are simple to use and ubiquitous performs the same general function as language support, and depending on the framework, can perform much of the same enforcement (abeit at runtime, not at compile time.) Of course, they can also be bypassed, so the question becomes "How well designed is the necessary support such that it is *so* easy to use and prevalent that no developer would seriously think about bypassing it except in extremely rare cases?"

Point being: language or library, proper support can be offered and utilized, or bypassed by a truly incompetent developer. The Cocoa frameworks offer some extremely nice idioms over the top of Obj-C that extend the security of data structures, and they are amazingly well thought out after going on 20 years of work on the core philosophies. Perfect? Nope. Better than everyone rolling their own C system? Yup. As good as direct language support? Debatable, depending on the language. (The Carbon API is less stellar in my opinion, but is being transitioned to layer over the same libraries Cocoa uses.)

(Holy crap, I have to send this in pieces. Cripes.)

2) Environment support for permissions safety
Task safety (deleting hard drive, renaming files randomly, other malicious acts) is something that is important, but best provided by user permissions in my mind. The real problem is one of social engineering... trojan horses, for instance, are nearly impossible to programatically defend against because it's never quite certain whether the task is one the user isn't aware of, or one they are trying to do on purpose. (Deleting a big chunk of their Documents folder, for instance - are they cleaning house, or did a trojan just get launched?) There are certain steps that can be taken to try and protect the user, but just as the developer can never be truly defended against themselves, neither can the user. Verification can be put into place, ("Are you sure you want to empty the Trash?") but more often than not, this ends up being in the way of the user after a time, and they grow to resent it. Resentment leads to click-through, click-through leads to accepting erroneous actions.

Verifiable programmatic task safety is a quagmire that I'm not positive will be resolved. The end user will always end up being the biggest hole in the system. The best we can hope for is making the obvious cases less destructive, or having the system adapt readily, such as sandboxing apps that start consuming resources rapidly. (Of course, even then it can get in the way - I had a research test run recently that was driving me nuts because yes, I really did want that one thread to be using 90+% CPU and requesting >600MB of RAM on a 512MB machine... it kept getting sandboxed and throttled back to <10%CPU when the vm determined it was a rogue process, while syslog filled with messages to that effect.)

In case you hadn't guessed by now, I don't believe that automatic verification or sandboxing is a panacea. :) Nothing can replace good design and proper idiom and pattern use, whatever the underlying technology. It is up to the designer of the system or language to facilitate that as much as possible.

With that being said, I've been quite impressed with the depth and breadth of security support design in MacOS X, from the user's interaction with the GUI down through the data structure security in the underlying APIs. Perfect? No. But given that it's gaining a nice reputation for being hard to get into, you would think that the malware folks would at least like a challenge. The best that anyone's been able to come up with so far is a couple of trojans that were rather clever, but the exploits plugged within a couple of days. I find it hard to believe that nobody is interested in making a name for themselves by being the first to crack an OS X box in a very big and public way.

Yes, I absolutely run a firewall. In fact, I run layers of firewalls from different vendors (an exploit on one won't propagate through), and I keep an eye on the logs. OTOH, I don't even *own* anti-virus software... there aren't any for it to take care of. Anti-virus software on the Mac is limited to the 37 viruses that were ever written for the original MacOS, and for people who want to be good citizens in corporate networks and not be a Typhoid Mary. Otherwise, it's a waste of money.

Between the open source core OS (Darwin) based on a number of other open source projects, the plethora of open source processes and apps included as major system services, and the strong security support at the API level for application developers, the only serious portion of the system that provide a home for hidden security holes are the frameworks themselves. While I concede absolutely that this is a concern, the obvious care that has been present in those frameworks for many years towards security is telling. The frameworks build on each other in well formed ways, and the developers at Apple do eat their own dogfood, using those same technologies. Either the security holes propagate, and you would expect to see many exploits across the system, or they are extremely unlikely to be present.

The sum of all of this is a mix of the many-eyes model of OSS for much of the system, with careful and critical design for those technologies which will be used by end developers. Both are useful and in my opinion necessary. Windows lacks the many-eyes, and Linux lacks the ubiquitous design. (Okay, Windows lacks that too - .NET is intriguing, but I remained unconvinced that they're going to pull off a quality design. They simply don't have the track record to inspire trust or confidence, and there are already enough questionable choices made in CLI to make me wonder.)

So yes, I think there are good reasons to believe that MacOS X will remain quite secure for quite some time. The basic fundamental user model is, IMO, simply more thoroughly thought out when it comes to security. Heck, when it comes to most things. It's not perfect, but it certainly is the overall best of breed I've yet to see from any OS.

Besides, I'd be thrilled for the MacOS to reach the marketshare where they become a serious target for the commercial malware producers. ;)

I just reread this. Dear god I didn't mean to type this much.

STANDING OVATION

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject