![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
iWeb markup
Todd Dominey complains about inelegant markup generated by Apple's new iWeb application, and for his effort he gets a batch of fairly ignorant personal insults from stone Apple fanboys.
The objections are mostly along the lines of "John Q. Public doesn't care about that semantic web crap." But it is precisely because most people don't care about these issues that their tools ought to try to take care of them. We use machines to do the things we don't want to spend a lot of time worrying about.
When you drive a car, you don't spend much time worrying about the mechanics of the engine or the physics of road handling, and if someone started explaining that stuff to you your eyes might glaze over. But you do want the car not to spin off the road and burst into flames. In the days when amateurs were using the first version of Microsoft Front Page, the users certainly didn't care about validation or lean markup. But they did notice that their pages broke on browsers other than Windows IE and were horrendously slow and didn't work well with search engines, and they didn't know why.
I shouldn't be too hard on iWeb; it sounds as if it is at least producing valid code that generally works on modern browsers, which is a definite step up. But wouldn't it be great if amateurs using entry-level tools could have nicely-constructed markup too, without even having to sweat it?
The objections are mostly along the lines of "John Q. Public doesn't care about that semantic web crap." But it is precisely because most people don't care about these issues that their tools ought to try to take care of them. We use machines to do the things we don't want to spend a lot of time worrying about.
When you drive a car, you don't spend much time worrying about the mechanics of the engine or the physics of road handling, and if someone started explaining that stuff to you your eyes might glaze over. But you do want the car not to spin off the road and burst into flames. In the days when amateurs were using the first version of Microsoft Front Page, the users certainly didn't care about validation or lean markup. But they did notice that their pages broke on browsers other than Windows IE and were horrendously slow and didn't work well with search engines, and they didn't know why.
I shouldn't be too hard on iWeb; it sounds as if it is at least producing valid code that generally works on modern browsers, which is a definite step up. But wouldn't it be great if amateurs using entry-level tools could have nicely-constructed markup too, without even having to sweat it?
Re: Is it smugness?
However, after contemplating your reply, it seems the real concern is not with the Mac operating system, but with manual security policies.
It doesn't matter whether I live in a house made of sticks or a fortress of stone padded with locks and guards, if I elect to invite a stranger in without checking his credentials, he could be malious. This is a user education problem, not a strength of the operating system problem.
As for the Mac, I don't view that the OS is 'teaching' me to type my password, but instead I have always viewed the question as "this application is requesting more access to this system than others, if you trust it -and- think it needs it, then I need your authorization to sign off before continuing." I wish Windows did this, it doesn't.
A potential solution is also to have a cryptographic check via a trusted certificate authority. However, I've rarely seen a user pause in their tracks when an originating source is challenged by such a system.
Both Apple and Microsoft do have this PKI feature, but it's seems to be a case where when the system wants help protect you, uneducated users view it as getting in the way and turn it off or ignore it. The Bruce Schneier security experts of the world demonstrate that even this pushes user diligence back on to the certificate signers (who have made gross mistakes before).
In the end, I agree with you, malware is a problem, on any platform, even my Texas Instrument calculator, but it's not because of the platform, it's because of the user practice. Some install implementations are more loosey-goosey than others, and I'd rather have the capability than not. Security is always going to be inversely related to conveinence, and those that very security as getting in the way are always going to be more at risk.
As such, I suspect the real problem is not smugness, but that people are talking past each other, hear the word "security", and that trigger word makes them think they're on the same page.
Re: Is it smugness?
Yes, which is why it worries me that OS X is so causally asking for admin passwords. Because so much of this hinges on the user doing the right thing, you have to be really careful about how you design the system, and what you make the user accustomed to. It worries me especially that OS X never explains why a program wants the admin password.
What might help is finer-grained access control, and forcing each program to ask permission for each specific admin-level resource it needs, and having the OS explain what those resource are, and what damage they can do. It wouldn't fix the problem, but it would help.
Of course, in the end, you don't even need admin access to install spyware. Putting a bundle in a user's ~/Library/Input Managers/ will give it access to the internals of every program the user runs. There are any number of wide-open methods of attack for spyware if you can just get the user to run a single file.
All of this has equivalents on Windows, but the Windows also now has an infrastructure for dealing with these things. There are spyware detection programs, there are application firewalls that monitor outgoing connections, and so on. OS X lacks most of this, mostly because it's not needed yet. But when spyware creators decide to target OS X, there will be a whole lot of trouble.