OS X. For disk images, and I believe real programs, there are a small number of scripting things that can be done (display a license agreement, open a.pkg in the Apple Installer), but they do not allow arbitrary code execution without the user's express permission.
Well, there you go. I had simply assumed that since loading up disk images or putting CDs into my OS X machines would trigger actions, that they were using something equivalent to autorun. However, after some research, it appears they don't. My bad, I apologise.
If you receive a file (well, technically a bundle) called `Brittany Spears.mp3.app' and the.app extension is hidden then you will automatically be warned that you are running an application, not playing an MP3 when you double click on it in mail.
Your example is not the best because OS X's bundles are directories, not files - so you wouldn't be able to attach one to an email.
Again, I think this whole "hiding extensions" thing is blown way out of proportion, and that even if they weren't hidden there would be little difference, as so few users look at extensions to identify filetypes (or even know which extensions are which filetypes).
Java seems to work, the occasional VM bug aside.
I don't think that's a fair comparison, since ActiveX and Java are doing different things. By "code" I meant it in the same context as ActiveX - ie: executable binaries.
You do not need full access to the system to have a rich web experience. Being able to save and load files from a specific per-app location would be a nice addition to the default Java security settings, but the `default to letting any control have full access to my system' that ActiveX gives you is ludicrous. Why does a little web control need to be given full access to my home directory?
It doesn't, and I doubt that's what it was really meant to be for. My understanding is ActiveX was supposed to be used for delivering applications and only from trusted sources. The problems from ActiveX stem from its abuse, rather than what it was designed for - and turning on suitably restrictive zone permissions, or simply avoiding it altogether except for trusted providers, makes it pretty much safe.
And I don't agree it's a problem with the "Windows security model" either - it really does nothing more than make a fairly common action (downlading bianries and running them) easier - I don't think you can call that a flaw in the security "model".
Also, ActiveX runs in the context of the current user. It only has access to the things that user does.
hmm, it would be realy interesting if this was brought back again.
Back ? UIs have been moving more and more away from being application-driven and towards being document-driven for the last 25+ years. Methinks you never really used computers before the 90s:).
today its to much focus on what apps one use, not what one want to do.
I think you've got that backwards. Interfaces today are *very* much document-centric, not application-centric.
That many users treat them mostly as application-centric, is not the fault of the interface, but the person who taught them how to use it.
Even with 80386 though, PCs were inferior to Macs, because there was no proper 32-bit protected-mode O/S for 80386 (unless you count expensive Unix).
Firstly, there was OS/2 and Windows NT or more esoteric choices like NeXTSTEP. Not to mention that as of Windows/386 (ca. 1988) the OS was becoming "32 bit".
Secondly, MacOS didn't have protected memory at all (until OS X, ca. 2000) and wasn't "32 bit" until System 7, in 1991 (and then only on "32 bit clean" Mac hardware).
In technical terms, DOS-based Windows and "Classic" MacOS were basically neck and neck in terms of technical features until Windows 95 (and Microsoft had the advantage of Windows NT for "pro" users, whereas Apple had nothing).
MS users would have to wait until Sept 1995, almost 10 years after the 386, for a true 32 bit operating system.
This is not correct. Their first choice would have been OS/2, followed closely by Windows NT. Not to mention that as of Windows/386 (ca. 1988), DOS-based Windows was starting to become "32 bit" (was using >640k RAM, could pre-emptively multitask DOS boxes, etc).
DOS-based Windows was always an evolving product. To say "Microsoft users" didn't get any 32-bit goodness until Windows 95 is simply wrong.
Indeed - and a text based interface can have alot of graphics - as long as it is text (keyboard, not pointer) input driven.
I'd still call that a GUI.
To me, the best way of describing the difference between a CLI and a GUI is that with a CLI you tell the computer way to do and with a GUI you select one or more operations the computer gives you to choose from.
From a usability perspective, a CLI requires you to know what you want to do/and how to do it/ before you can use it, only offering reactive feedback. A GUI helps you figure out how to use it based on proactive feedback.
IMHO, an 80x25 text-based interface, which is just a bunch of menus, is still a GUI.
You keep asking this question over and over, so I guess I'll answer you.
That's because most people saying it are just repeating the slashdot mantra, and don't really have any clue what they're talking about. Like those who, for example, keep saying having the default user as Administrator is some sort of design problem that needs a complete rewrite to fix.
* Auto-run. Why should putting in a CD cause arbitrary code from that CD to be executed?
Same reason we double click icons now instead of flipping switches on the front of a case - because it's *easier*.
Incidentally, is there any remotely mainstream platform out there now that *doesn't* "auto-run" freshly inserted removable media ?
The option to hide the extensions of file names. So users see files named "BrittanySpears.jpg.exe" as "Brittany Spears.jpg". This "small" issue (which has not been fixed) cost businesses millions of dollars. If it weren't for this problem, you could kiss Code Red, etc. goodbye.
It's a configuration option, trivially changable - ceertainly not a design or "model" fault. And if you seriously think the vast bulk of users even know what file extensions are, let alone which extensions match up to which filetypes, let alone what actually happens when those files are opened, you're living in a dream world.
Identifying filetypes by extensions is an ugly hack. They're unintuitive, inconsistent and insecure. Their only redeeming feature is that they're mostly cross-platform.
The Shatter vulnerability. Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages. There is no mechanism for authenticating the source of a message; a message sent from a malicious application is indistinguishable from a message sent by the Windows kernel.
Ah, at least now we're getting into something that's at least a design issue. A pity it's a problem that's largely the responsibility of the application developers, has had workarounds developed and requires an attacker to get the user to execute code for them (at which point, it's mostly a matter of semantics).
Added to that, it's in parts of Windows that are being deprecated in the next version.
Microsoft has declared this vulnerability unfixable.
Actually I think they've said it's pretty much an application developer issue since, essentially, it's a matter of input validation. In other words, it's like saying unix is inherently insecure because of the root user. Sure, it's true at a certain technical level, but in practical terms it's not a big issue.
ActiveX. Any Active X control downloaded over the web might be a trojan or virus. So there are websites than will shut down your computer, install software, etc.
So might any executable code you download off the internet.
This problem is inherent in the design of ActiveX and cannot be fixed.
Indeed. That whole problem of people being able to delete stuff with 'rm' ? That's inherent to the design of rm and "can't be fixed" either.
Various brain-dead network protocols and standards, like NetBui.
That would be NetBEUI, meant to be used for small unmanaged networks that was deprecated about seven years ago ?
NetBEUI was designed to be a fast, efficient protocol to make plug-and-play type "no configuration necessary" networking trivial. It did that quite well. It was never meant to be for networks bigger than a few dozen machines, nor routable networks. It's also been obselete for a very long time. Heck, I don't think it's even been/installed/ by default since Windows 95 (and certainly not since Windows 98).
Criticising Windows because of NetBEUI in 2005 is like criticising OS X because of Localtalk. Not to mention I don't see why NetBEUI is "brain dead" in the first
Microsoft could make their software so secure that anti-virus programs are not a neccessity on Windows.
No, they couldn't. Nor could anyone else.
You can't "secure" a device specifically designed to execute arbitrary instructions from arbitrary third parties - at least not for any meaningful definition of "secure".
Imagine if Judge Jackson's original ruling had stood. It said that MS had to be split into two wholly independent companies: one for the OS, and another for all applications.
Yeah, having the technically incompent justice system decide on the legal definition of an "application" would have been a *really* good idea.
We would quite possibly have MSOffice (and all sorts of other apps) for Linux today, because the apps division would only care about selling their apps as widely as possible.
If Microsoft thought they could make money off Office on Linux, they would. After all, they make Office for OS X, and that's a hell of a lot closer to a Windows replacement than any version of Linux on the market.
Apple is controlled competition. Apple appears to be bound by a secret agreement to 'compete' only in a non-competitive way, i.e. stay in their high margin niche and milk it for all it is worth, but to never again hit double digits in units sold. Basically, Apple is 'token competition' to keep the DOJ happy. (Think Token on South Park.)
According to the antitrust trial, Apple and Microsoft don't compete in the same market. That makes Apple irrelevant to "keeping the DOJ happy".
Microsoft extended its contract with Apple to keep Office current on Macs NOT for the unit sales, but because, at the time, they were litigating the monolopy case in court. They needed Apple to stay alive to keep up the pretense that they were engaging an open market without recourse to any monopoly (which was nonsense - they lost).
Your idea would make more sense if Apple were considered to be in the same market as Microsoft during the anti-trust case.
Bill also invested a bunch of cash in Apple at the same time for the same reason: Bill needed Apple alive, not crushed, so that Microsoft could make a case against a finding of monopoly.
Ah, you really don't know what you're talking about. Microsoft's investment in Apple was pocket change to both companies. It sure as hell didn't "keep Apple alive".
Why should Microsoft build applications for an operating system directly competing with their own?
Maybe you should ask them why they make Office for OS X ? It's a hell of a lot closer to a "direct competitor" to Windows than any version of Linux is.
You can not secure a single Windows system in the span of an hour or two...unless you have already done the work and have a pretty good custom tool kit and you know your environment.
The problem is, most people, even technically adapt people, are not capable of protecting themselfs from the host of worms and exploits being used out there today. the blame lies squarely on MS's shoulders.
Running a Windows machine sans viruses, worms and other malware is trivial for technically adept users.
Now we have another protection racket (err, application) from Microsoft to protect us from what is ultimately Microsoft's fault: an operating system that at it's core was designed in such a way that security was an afterthought.
This made me suspicious that you had no idea what you are talking about.
Instead, why doesn't Microsoft use the principles of Occam's Razor and not let applications have direct access to the kernel?
Slashdot Mirror
Well, there you go. I had simply assumed that since loading up disk images or putting CDs into my OS X machines would trigger actions, that they were using something equivalent to autorun. However, after some research, it appears they don't. My bad, I apologise.
If you receive a file (well, technically a bundle) called `Brittany Spears.mp3.app' and the .app extension is hidden then you will automatically be warned that you are running an application, not playing an MP3 when you double click on it in mail.
Your example is not the best because OS X's bundles are directories, not files - so you wouldn't be able to attach one to an email.
Again, I think this whole "hiding extensions" thing is blown way out of proportion, and that even if they weren't hidden there would be little difference, as so few users look at extensions to identify filetypes (or even know which extensions are which filetypes).
Java seems to work, the occasional VM bug aside.
I don't think that's a fair comparison, since ActiveX and Java are doing different things. By "code" I meant it in the same context as ActiveX - ie: executable binaries.
You do not need full access to the system to have a rich web experience. Being able to save and load files from a specific per-app location would be a nice addition to the default Java security settings, but the `default to letting any control have full access to my system' that ActiveX gives you is ludicrous. Why does a little web control need to be given full access to my home directory?
It doesn't, and I doubt that's what it was really meant to be for. My understanding is ActiveX was supposed to be used for delivering applications and only from trusted sources. The problems from ActiveX stem from its abuse, rather than what it was designed for - and turning on suitably restrictive zone permissions, or simply avoiding it altogether except for trusted providers, makes it pretty much safe.
And I don't agree it's a problem with the "Windows security model" either - it really does nothing more than make a fairly common action (downlading bianries and running them) easier - I don't think you can call that a flaw in the security "model".
Also, ActiveX runs in the context of the current user. It only has access to the things that user does.
OS/2's Workplace Shell is generally considered the best example.
Back ? UIs have been moving more and more away from being application-driven and towards being document-driven for the last 25+ years. Methinks you never really used computers before the 90s :).
today its to much focus on what apps one use, not what one want to do.
I think you've got that backwards. Interfaces today are *very* much document-centric, not application-centric.
That many users treat them mostly as application-centric, is not the fault of the interface, but the person who taught them how to use it.
Firstly, there was OS/2 and Windows NT or more esoteric choices like NeXTSTEP. Not to mention that as of Windows/386 (ca. 1988) the OS was becoming "32 bit".
Secondly, MacOS didn't have protected memory at all (until OS X, ca. 2000) and wasn't "32 bit" until System 7, in 1991 (and then only on "32 bit clean" Mac hardware).
In technical terms, DOS-based Windows and "Classic" MacOS were basically neck and neck in terms of technical features until Windows 95 (and Microsoft had the advantage of Windows NT for "pro" users, whereas Apple had nothing).
This is not correct. Their first choice would have been OS/2, followed closely by Windows NT. Not to mention that as of Windows/386 (ca. 1988), DOS-based Windows was starting to become "32 bit" (was using >640k RAM, could pre-emptively multitask DOS boxes, etc).
DOS-based Windows was always an evolving product. To say "Microsoft users" didn't get any 32-bit goodness until Windows 95 is simply wrong.
I'd still call that a GUI.
To me, the best way of describing the difference between a CLI and a GUI is that with a CLI you tell the computer way to do and with a GUI you select one or more operations the computer gives you to choose from.
From a usability perspective, a CLI requires you to know what you want to do /and how to do it/ before you can use it, only offering reactive feedback. A GUI helps you figure out how to use it based on proactive feedback.
IMHO, an 80x25 text-based interface, which is just a bunch of menus, is still a GUI.
Note that this is a very different thing from making them *want* to kill.
Nobody has presented anything to refute this.
Did his statement offer anything more than opinion ? If not, there's nothing to refute.
That's because most people saying it are just repeating the slashdot mantra, and don't really have any clue what they're talking about. Like those who, for example, keep saying having the default user as Administrator is some sort of design problem that needs a complete rewrite to fix.
* Auto-run. Why should putting in a CD cause arbitrary code from that CD to be executed?
Same reason we double click icons now instead of flipping switches on the front of a case - because it's *easier*.
Incidentally, is there any remotely mainstream platform out there now that *doesn't* "auto-run" freshly inserted removable media ?
The option to hide the extensions of file names. So users see files named "BrittanySpears.jpg.exe" as "Brittany Spears.jpg". This "small" issue (which has not been fixed) cost businesses millions of dollars. If it weren't for this problem, you could kiss Code Red, etc. goodbye.
It's a configuration option, trivially changable - ceertainly not a design or "model" fault. And if you seriously think the vast bulk of users even know what file extensions are, let alone which extensions match up to which filetypes, let alone what actually happens when those files are opened, you're living in a dream world.
Identifying filetypes by extensions is an ugly hack. They're unintuitive, inconsistent and insecure. Their only redeeming feature is that they're mostly cross-platform.
The Shatter vulnerability. Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages. There is no mechanism for authenticating the source of a message; a message sent from a malicious application is indistinguishable from a message sent by the Windows kernel.
Ah, at least now we're getting into something that's at least a design issue. A pity it's a problem that's largely the responsibility of the application developers, has had workarounds developed and requires an attacker to get the user to execute code for them (at which point, it's mostly a matter of semantics).
Added to that, it's in parts of Windows that are being deprecated in the next version.
Microsoft has declared this vulnerability unfixable.
Actually I think they've said it's pretty much an application developer issue since, essentially, it's a matter of input validation. In other words, it's like saying unix is inherently insecure because of the root user. Sure, it's true at a certain technical level, but in practical terms it's not a big issue.
ActiveX. Any Active X control downloaded over the web might be a trojan or virus. So there are websites than will shut down your computer, install software, etc.
So might any executable code you download off the internet.
This problem is inherent in the design of ActiveX and cannot be fixed.
Indeed. That whole problem of people being able to delete stuff with 'rm' ? That's inherent to the design of rm and "can't be fixed" either.
Various brain-dead network protocols and standards, like NetBui.
That would be NetBEUI, meant to be used for small unmanaged networks that was deprecated about seven years ago ?
NetBEUI was designed to be a fast, efficient protocol to make plug-and-play type "no configuration necessary" networking trivial. It did that quite well. It was never meant to be for networks bigger than a few dozen machines, nor routable networks. It's also been obselete for a very long time. Heck, I don't think it's even been /installed/ by default since Windows 95 (and certainly not since Windows 98).
Criticising Windows because of NetBEUI in 2005 is like criticising OS X because of Localtalk. Not to mention I don't see why NetBEUI is "brain dead" in the first
Then MS announces their free software:
2. Windows: 120$ + "free" antivirus: $0 + Symantec: $20 = 140$
People realize they don't need symantec:
3. Windows: 120$ + "free" antivirus: $0
And since we just took over a profitable market:
4. Profit
This example falls apart as soon as we remember that those "addons" to Windows don't actually raise the price.
How ?
Only on Slashdot would you see a default installation of OpenBSD described as "usable" (in comparison to Windows, no less).
No, they couldn't. Nor could anyone else.
You can't "secure" a device specifically designed to execute arbitrary instructions from arbitrary third parties - at least not for any meaningful definition of "secure".
What's wrong with it ?
And what do you think they should have done differently with the /design/ ?
Technically speaking, since always. Or are you forgetting Word and Excel were on MacOS first ?
Yeah, having the technically incompent justice system decide on the legal definition of an "application" would have been a *really* good idea.
We would quite possibly have MSOffice (and all sorts of other apps) for Linux today, because the apps division would only care about selling their apps as widely as possible.
If Microsoft thought they could make money off Office on Linux, they would. After all, they make Office for OS X, and that's a hell of a lot closer to a Windows replacement than any version of Linux on the market.
According to the antitrust trial, Apple and Microsoft don't compete in the same market. That makes Apple irrelevant to "keeping the DOJ happy".
Your idea would make more sense if Apple were considered to be in the same market as Microsoft during the anti-trust case.
Bill also invested a bunch of cash in Apple at the same time for the same reason: Bill needed Apple alive, not crushed, so that Microsoft could make a case against a finding of monopoly.
Ah, you really don't know what you're talking about. Microsoft's investment in Apple was pocket change to both companies. It sure as hell didn't "keep Apple alive".
Maybe you should ask them why they make Office for OS X ? It's a hell of a lot closer to a "direct competitor" to Windows than any version of Linux is.
s/Windows/Linux/
Running a Windows machine sans viruses, worms and other malware is trivial for technically adept users.
This made me suspicious that you had no idea what you are talking about.
Instead, why doesn't Microsoft use the principles of Occam's Razor and not let applications have direct access to the kernel?
And this confirms it. You are clueless.
How many "average people" actually /pay/ for Office ?
What choices and freedoms do you feel you are lacking that are directly attributable to Microsoft ?
What _can_ you do inside a video game that's illegal ?