I happen to prefer having PDFs, disk images and a few other things open automatically, without my having to: 1) locate the tiny download window, 2) scroll down in it to the file I just downloaded, 3) click on the tiny "Show in Finder" button, and 4) double click on the file in the Finder.
OK, that's what Firefox does better, then.
When you download, it opens the download window for you, scrolls down to the file as it's downloading, and you can just double-click on the file to open it.
That way you get convenience and security.
How about letting me do this?
How do you feel about entering your password when you install applications?
Safari has exactly that same ability. Double click on the little icon and it opens for you, click on the magnifying glass it shows the file. Which I guess shows how I could (and have done) open those files w/o having that option checked.
Oh. Right. It's been too long since I used it. I'm addicted to the Flashblock extension, but that's another kettle of user interface goodness.:)
It's doing it exactly the same, and that's more of why I don't "get" this "open safe files" thing.
As for the plugin, well, Acrobat sucks dirty swamp water through used oil filters, but the PDF Browser plugin on the Mac mostly just hooks in to the native PDF support in Quartz. It works pretty well. And of course I can always use alt-click and download the PDF if I feel like it.
Dashboard does not present a prompt before running a privileged widget that is one of the Library/Widgets folders, including our auto-installed widgets.
If a widget contains a native Mach-O executable, Safari will present a warning before downloading the widget. However, because widgets in ~/Library/Widgets can run shell commands with the widget.system() call, this protection is easily defeated.
And then, even if they fix this, are users going to refuse to allow what appears to be a system-provided widget to run?
When Dashboard encounters two or more widgets with the same bundle identifier, it only displays the last one loaded. And -- you guessed it -- widgets in ~/Library/Widgets are loaded after the system-supplied widgets in/Library/Widgets.
And finally, a sandboxed environment is one in which dangerous things are not possible. Not one in which dangerous things are only possible if a user approves them. And Dashboard's "sandbox" is the latter kind of environment, not the former.
It was primarily to those who do prefer that setup that I was addressing that sentence
And it was to those that I was addressing my question, because I honestly don't get it.
I do find it useful to have pdfs opened for me without sloshing through my download folder
That's not been a problem for me for a long time...
% ls "~/Library/Internet Plug-Ins" PDF Browser Plugin.plugin
But in any case Firefox does it better, by letting you see the file in your download manager and open it from there. That makes it something that's under your control again.
[The only mistake Apple made is] Automagically moving the downloaded widged directly into the dashboard widgets folder.
That's the NEW mistake they made.
The other mistake is the one they made in Safari 0.9 that they haven't yet fixed, and that is to let Safari "open safe files" automatically.
What more do you want apple to do besides prompt the user and ask if they would like to install a downloaded widget?
I want them to do less than that, actually. I want them to just download the widget and wait until the user chooses to install it, or not, and in the meantime leave it sitting in their Downloads folder not bothering anyone.
Because dialog boxes asking users to confirm actions just annoy the user and train them to automatically answer "yes" when a dialog comes up. I see it happen all the time on Windows, some of my users have been infected after reflexively answering "yes" multiple times. NOBODY, though, has ever been infected after manually opening a downloaded virus more than once... because it's more of a deliberate conscious act than clicking on a "yes" button in a dialog you just want to get out of the way.
If it doesn't have any custom javascript (such as a search widget that submits a form through safari), then it doesn't bother checking to see if it's okay.
And that's not OK, because Dashboard isn't really a proper sandboxed environment. It is too dangerous for Apple to treat it as the same kind of sandboxed environment as Safari, it's a general purpose application platform and installing a widget should be treated as the same kind of serious action as running an application is.
Isn't this the same major (and irrevocable) mistake that Microsoft made when they let the ActiveX genie out of the bottle?
No, not quite. While it's a step along the dark path it's a long way from ActiveX, for a couple of reasons.
First, it's not QUITE autoexecute. It's close enough that a naive user could easily step off the cliff, it doesn't actually push them over. It can be avoided if you're wary.
Second, it's not irrevocable. Apple can disable "open safe files" and remove the code from Safari that autoinstalls widgets without breaking anyone's software. It's not like these capabilities are core elements of a desktop-browser integration like ActiveX is in Microsoft.
Dashboard isn't the problem, if it's treated as "a new way to write applications" and the token attempt at sandboxing doesn't lead Apple to take it lightly.
One simple solution, is obviously to turn off "Open Safe Files" in Safari, but that does make life a bit more difficult
How do you figure? What does "Open Safe Files" do for you that it's worth even a little risk? Even if it was entirely safe I'd turn it off because it's annoying to download a file and end up with two or three extra icons on my desktop because Safari ran Stuffit which unpacked it and then mounted the DMG inside... or if I configure Stuffit to delete the original now I've lost the file I actually downloaded.
OK, you like that automatic step, it doesn't annoy you, but why is it so important that not having it makes life "more difficult"? I'm not trolling, I honestly don't understand why this is considered a good idea, let alone something important enough to risk the inevitable future security probblems to keep?
They should. If they didn't have an "open safe files" mechanism, there wouldn't be any rationale for having the browser pop up a warning dialog like this. Not only wouldn't there be a potential for silent exploits from "opening safe files", but they wouldn't be training people to ignore warning dialogs!
If you were in charge of security of a Mac house, you would know better than to install 10.n.0 of any new OS X release on any of your company's computers.
It doesn't matter. 10.3.9 still has all the other problems I mentioned. Apple has been putting bandaids on symptoms instead of fixing the deeper problems since their security "fix" last June.
Oh, yes, compared to what Microsoft has been doing it's a tiny little problem. But they're applying the same technique to fixing the problem that Microsoft did, and its that technique that I'm concerned about.
They only get complete system access after the user has acknowledged that the widget is being run for the first time.
1. That's not true. There is an attempt at a sandbox but it doesn't apply to Widgets that were installed through the hole in Safari and even if it did there's a hole in the sandbox you can drive a Perl interpreter through.
2. It wouldn't matter if they did, because confirmation dialogs aren't enough. Opening a document or other object in an unsandboxed environment must require an explicit request by the user. Having it appear in that environment with no indication that it came from an untrusted source is not good enough.
According to the reports, they are sending huge patches that combine many fixes without any documentation.
"According to the reports" they're guilty of high crimes and misdemeanors.
You can see exactly what they're providing by going to opendarwin.org and looking at the source code to what they're releasing. Yes, you, right now. Go and download WebCore. It's not just "huge patches that combine many fixes", it's a complete source tree that you can build yourself. And it's significantly different from KHTML by now... that was inevitable.
They have tried to mark the "Apple Unique" sections. They have used a compatibility layer as much they could. They have more than complied with the spirit of the GPL: the problem isn't that they're behaving in an antisocial way, it's that their code base is too far from the original one, and their environment and goals are so different.
Use The Source, Luke. Some folks at Nokia did, and the Gnome people have a similar project. What Apple released is good enough for two separate groups to take it and backport it to X11 when they're not even using the same X11 toolkit that Apple started from (and are using as the base for their glue code). The KHTML team could do the same thing, but their goals are different so there's no reason to demand they do.
And it's the people who WERE demanding it that started this whole mess. Not Apple. Not KDE. Not Nokia or Gnome. No, it was the folks on Slashdot... that's where the blame lies.
You and me, too.
I know where I contributed to the bad blood, after the "Acid Test" announcement. Oh, not deliberately, and I didn't say anything unpleasant, but I didn't know how far Safari had diverged and I thought Safari and KHTML were tracking pretty closely so I was one of the many people pointing to the patches on "Surfin' Safari".
If we were a Mac house, and I was in charge of security, I would be seriously considering banning the use of Safari at this point.
It's not the slam-dunk that it was for Internet Explorer back in the '90s, when I managed to get IE and Outlook banned just in time to dodge the flood of viruses that resulted from Microsoft's broken security model. The individual problems in Safari and LaunchServices are not nearly as obviously bad as Microsoft's security zones, but they're of the same nature.
This is what Apple really needs to do:
1. Treat Dashboard widgets just like they treat executables. They're not "safe files". It's great that they have isolated the extensions that make dashboard work so they're not available in arbitrary Webcore applications, that's an absolutely critical advantage over Microsoft's HTML control, but when run in Dashboard they have all the same capabilities as local apps and need to be treated like any other applications.
2. Taking this a step further, they need to treat all downloaded files as dangerous, and ensure that no files are opened by an application where they're not sandboxed without the explicit request of the user. In practice, the only way to ensure this is to not pass them to ANY application that hasn't been registered with the browser (for example, as a plugin).
3. This means that LaunchServices shouldn't be used by Webcore or in any other context where there's the potential of an untrusted object being passed to an application, except by the explicit request (not merely confirmation) of the user. A separate database should be provided for applications that ARE prepared to accept untrusted documents or other objects.
This third step would actually increase convenience, because then you could write "safe viewer" apps that provided a strong sandbox instead of having to depend on every application figuring out whether they needed to sandbox a document based on what they could guess, so you could have viewers for files that currently can only be downloaded.
They really ought to post an advisory urging users of their shiny new operating system to turn off the ``open safe files after downloading" preference in Safari.
That would be a start.
Better would be to quit shipping Safari with that option turned on by default.
Best would be to take that capability out completely, because it's inconvenient as often as it's convenient and it creates an opportunity for exploits that doesn't need to be there.
It only makes sense that it would have limited functionality because it is designed to teach those with no exposure whatsoever to computers how to use one.
It's designed for no such thing. It's designed to give Microsoft a little extra cash flow without actually providing a useful OS that might cannibalise sales to people who are willing to pay for legit copies of Windows.
Not running on a P4, limiting the number of concurrent applications? A naive user needs not these things.
The free parts of OS X amounts to a pretty mediocre Unix.
The free parts of OS X are at the very least of mixed quality, but it's not the Darwin kernel that makes it interesting, it's the whole approach to UNIX system configuration and administration they're developing. They're moving away from the gratuitously complex "netinfo" but rather than simply going back to the conventional '60s mainframe-era collection of ad-hoc text files and scripts that every other UNIX system uses, they're designing a system that's browsable and explicitly managable by both scripts *and* humans. It's not traditional UNIX, but it's still basically a UNIX approach with small, separate and understandable tools instead of some kind of alien non-UNIX environment under the covers like the one NeXT flirted with and the ones IBM and Microsoft have embraced in AIX and NT.
Whether they can bring it all together, I don't know, but each new version of Mac OS X and Darwin has been a slightly better iteration of this same ongoing design. I'm very interested to see how it'll play out.
And if you can't see it, if all you see is the pipes and gears and loose cables and springs, well, sorry...
ActiveX is dangerous technology and should be turned off by default (they did it in winxp sp2).
No they didn't. They only blocked it for the Internet Zone, and they only require confirmation even there. They can't turn it off completely because then Software Update, some Control Panel applets, and other tools that depend on ActiveX components wouldn't work.
Which means that it is still true that if you can get the applet into the "local zone", the HTML control will happily launch it. This is not a bug... a bug can be fixed. This is a design flaw, fixing it will require significantly modifying what has become a core API in Windows. And unlike Java, you can't turn it off.
find me some recent IE exploit that allows remote installation of ActiveX without user confirmation
User confirmation isn't a high enough barrier to propogation. manual installation is barely enough, but it is better than confirmation. I spent years doing Windows support as part of my job, and a lot of people around here still think it is. I still get users coming to me saying they "clicked OK again", but I've never had anyone explicitly download and install an attachment twice.
And preventing remote installation isn't enough, if there's a vulnerability in a widely used existing ActiveX applet it can be used, even if that applet was never intended to be run from the browser. For example, here's an ironic one:
SYM04-009 May 20, 2004 Symantec Norton AntiVirus 2004 ActiveX Control Vulnerability
Apple doesn't want users changing the UI appearance.
That's really amazing. You made that point, I agreed that you were right, you made it again, OK, I'll agree with you again. You can make it a third time, and you'll get nothing but agreement from me. What you haven't done, though, is establish how "what Apple wants" is relevant, when I'm only talking about "what Apple does", and what Apple does is provide the functionality and make sure that the majority of the developers out there support it.
Apple can want anything, but it's what they do that matters.
WTF do you think X11 resources are, exactly?
Pretty good customization tools for the pre-theme era. Themes are more than just tweaking the colors and fonts of the user interface, a theme is a new skin for the whole user interface. The closet thing to themes Athena Widgets got was when people coded up new versions of them like Xaw3d. And by that time it was too late, really, because Xaw was already being supplanted by horrors like Motif.
the difference is that if you use Qt, theming is well supported from the bottom to the top, and no application can get past it.
Unless they don't use Qt widgets.
with OSX, if you use carbon/cocoa, theming is a hack, not officially supported at all, and apps can get past the theming.
Only if they don't use Carbon/Cocoa widgets.
The only difference is:
On the Mac, only a few applications out there don't use native widgets (and most of those are old applications or ports from Linux or Windows). Not only that, but most of the toolkits that don't use native widgets still use the native theme. There's only a few applications out of all the many available that won't follow the theme.
Under X11 most applications are not written for Qt or any other single toolkit. So only a few applications will follow the theme, unless you restrict yourself to only using applications using that toolkit. So you have the choice of using only a subset of the non-too-great selection of X11 applications that happen to follow your theme, or you end up with a user interface displaying half a dozen themes at once.
apple is the complete antithesis to ui theming
Apple invented UI theming.
They might not want you to use it, but they haven't removed it, and they don't try and stop you from using it, and they have enough influence over their developers that it just automatically works for most apps. KDE wants you to be able to theme your X11 environment, but they don't have the ability to force people developing to other toolkits to follow their theme, so it only works for the apps that happen to use their own toolkit.
An end user does not want content to be blocked b/c of security issues.
That's another advantage of Firefox. Because the design is safer, there's fewer cases where it has to block content that might be dangerous.
Re:Got my father switched today
on
Firefox Promo Videos
·
· Score: 2, Insightful
And ActiveX is harmful how exactly?
The whole point of ActiveX in the MS HTML control is to allow a remote site to load and run a native executable without you having to decide whether to run/install/download/whatever.
Of course that has turned out to be a horribly bad idea, and they've wrapped ActiveX in so many layers of protection that downloading and installing a program is INFINITELY easier than figuring out how to configure IE to let you use ActiveX the way it was intended.
The problem is, all those layers of protection don't include "making ActiveX disabled by default", because it's *also* how Windows implements a lot of the features of Windows Explorer. So if someone can figure out how to convince the HTML control that their remote exploit's really an ActiveX applet installed by Windows Explorer, locally, it'll happily run it. then they can do anything.
Microsoft regularly fixes this, usually in a way that breaks someone's software or adds another annoying dialog to train you to ignore annoying dialogs. And just as regularly someone finds another hole, and Ad-Aware or Symantec has to figure out another signature to detect another virus or spybot...
Slashdot Mirror
I happen to prefer having PDFs, disk images and a few other things open automatically, without my having to: 1) locate the tiny download window, 2) scroll down in it to the file I just downloaded, 3) click on the tiny "Show in Finder" button, and 4) double click on the file in the Finder.
OK, that's what Firefox does better, then.
When you download, it opens the download window for you, scrolls down to the file as it's downloading, and you can just double-click on the file to open it.
That way you get convenience and security.
How about letting me do this?
How do you feel about entering your password when you install applications?
Safari has exactly that same ability. Double click on the little icon and it opens for you, click on the magnifying glass it shows the file. Which I guess shows how I could (and have done) open those files w/o having that option checked.
:)
Oh. Right. It's been too long since I used it. I'm addicted to the Flashblock extension, but that's another kettle of user interface goodness.
It's doing it exactly the same, and that's more of why I don't "get" this "open safe files" thing.
As for the plugin, well, Acrobat sucks dirty swamp water through used oil filters, but the PDF Browser plugin on the Mac mostly just hooks in to the native PDF support in Quartz. It works pretty well. And of course I can always use alt-click and download the PDF if I feel like it.
According to this page:
And then, even if they fix this, are users going to refuse to allow what appears to be a system-provided widget to run?
And finally, a sandboxed environment is one in which dangerous things are not possible. Not one in which dangerous things are only possible if a user approves them. And Dashboard's "sandbox" is the latter kind of environment, not the former.
And it was to those that I was addressing my question, because I honestly don't get it.
I do find it useful to have pdfs opened for me without sloshing through my download folder
That's not been a problem for me for a long time...But in any case Firefox does it better, by letting you see the file in your download manager and open it from there. That makes it something that's under your control again.
Some day real IBM thinkpads will be collectors items, since Lenovo is outsourcing them to Acer.
IBM doesn't market PCs any more.
[The only mistake Apple made is] Automagically moving the downloaded widged directly into the dashboard widgets folder.
That's the NEW mistake they made.
The other mistake is the one they made in Safari 0.9 that they haven't yet fixed, and that is to let Safari "open safe files" automatically.
What more do you want apple to do besides prompt the user and ask if they would like to install a downloaded widget?
I want them to do less than that, actually. I want them to just download the widget and wait until the user chooses to install it, or not, and in the meantime leave it sitting in their Downloads folder not bothering anyone.
Because dialog boxes asking users to confirm actions just annoy the user and train them to automatically answer "yes" when a dialog comes up. I see it happen all the time on Windows, some of my users have been infected after reflexively answering "yes" multiple times. NOBODY, though, has ever been infected after manually opening a downloaded virus more than once... because it's more of a deliberate conscious act than clicking on a "yes" button in a dialog you just want to get out of the way.
If it doesn't have any custom javascript (such as a search widget that submits a form through safari), then it doesn't bother checking to see if it's okay.
And that's not OK, because Dashboard isn't really a proper sandboxed environment. It is too dangerous for Apple to treat it as the same kind of sandboxed environment as Safari, it's a general purpose application platform and installing a widget should be treated as the same kind of serious action as running an application is.
Isn't this the same major (and irrevocable) mistake that Microsoft made when they let the ActiveX genie out of the bottle?
No, not quite. While it's a step along the dark path it's a long way from ActiveX, for a couple of reasons.
First, it's not QUITE autoexecute. It's close enough that a naive user could easily step off the cliff, it doesn't actually push them over. It can be avoided if you're wary.
Second, it's not irrevocable. Apple can disable "open safe files" and remove the code from Safari that autoinstalls widgets without breaking anyone's software. It's not like these capabilities are core elements of a desktop-browser integration like ActiveX is in Microsoft.
Dashboard isn't the problem, if it's treated as "a new way to write applications" and the token attempt at sandboxing doesn't lead Apple to take it lightly.
One simple solution, is obviously to turn off "Open Safe Files" in Safari, but that does make life a bit more difficult
How do you figure? What does "Open Safe Files" do for you that it's worth even a little risk? Even if it was entirely safe I'd turn it off because it's annoying to download a file and end up with two or three extra icons on my desktop because Safari ran Stuffit which unpacked it and then mounted the DMG inside... or if I configure Stuffit to delete the original now I've lost the file I actually downloaded.
OK, you like that automatic step, it doesn't annoy you, but why is it so important that not having it makes life "more difficult"? I'm not trolling, I honestly don't understand why this is considered a good idea, let alone something important enough to risk the inevitable future security probblems to keep?
They should. If they didn't have an "open safe files" mechanism, there wouldn't be any rationale for having the browser pop up a warning dialog like this. Not only wouldn't there be a potential for silent exploits from "opening safe files", but they wouldn't be training people to ignore warning dialogs!
If you were in charge of security of a Mac house, you would know better than to install 10.n.0 of any new OS X release on any of your company's computers.
It doesn't matter. 10.3.9 still has all the other problems I mentioned. Apple has been putting bandaids on symptoms instead of fixing the deeper problems since their security "fix" last June.
Oh, yes, compared to what Microsoft has been doing it's a tiny little problem. But they're applying the same technique to fixing the problem that Microsoft did, and its that technique that I'm concerned about.
They only get complete system access after the user has acknowledged that the widget is being run for the first time.
1. That's not true. There is an attempt at a sandbox but it doesn't apply to Widgets that were installed through the hole in Safari and even if it did there's a hole in the sandbox you can drive a Perl interpreter through.
2. It wouldn't matter if they did, because confirmation dialogs aren't enough. Opening a document or other object in an unsandboxed environment must require an explicit request by the user. Having it appear in that environment with no indication that it came from an untrusted source is not good enough.
According to the reports, they are sending huge patches that combine many fixes without any documentation.
"According to the reports" they're guilty of high crimes and misdemeanors.
You can see exactly what they're providing by going to opendarwin.org and looking at the source code to what they're releasing. Yes, you, right now. Go and download WebCore. It's not just "huge patches that combine many fixes", it's a complete source tree that you can build yourself. And it's significantly different from KHTML by now... that was inevitable.
They have tried to mark the "Apple Unique" sections. They have used a compatibility layer as much they could. They have more than complied with the spirit of the GPL: the problem isn't that they're behaving in an antisocial way, it's that their code base is too far from the original one, and their environment and goals are so different.
Use The Source, Luke. Some folks at Nokia did, and the Gnome people have a similar project. What Apple released is good enough for two separate groups to take it and backport it to X11 when they're not even using the same X11 toolkit that Apple started from (and are using as the base for their glue code). The KHTML team could do the same thing, but their goals are different so there's no reason to demand they do.
And it's the people who WERE demanding it that started this whole mess. Not Apple. Not KDE. Not Nokia or Gnome. No, it was the folks on Slashdot... that's where the blame lies.
You and me, too.
I know where I contributed to the bad blood, after the "Acid Test" announcement. Oh, not deliberately, and I didn't say anything unpleasant, but I didn't know how far Safari had diverged and I thought Safari and KHTML were tracking pretty closely so I was one of the many people pointing to the patches on "Surfin' Safari".
How about you?
If we were a Mac house, and I was in charge of security, I would be seriously considering banning the use of Safari at this point.
It's not the slam-dunk that it was for Internet Explorer back in the '90s, when I managed to get IE and Outlook banned just in time to dodge the flood of viruses that resulted from Microsoft's broken security model. The individual problems in Safari and LaunchServices are not nearly as obviously bad as Microsoft's security zones, but they're of the same nature.
This is what Apple really needs to do:
1. Treat Dashboard widgets just like they treat executables. They're not "safe files". It's great that they have isolated the extensions that make dashboard work so they're not available in arbitrary Webcore applications, that's an absolutely critical advantage over Microsoft's HTML control, but when run in Dashboard they have all the same capabilities as local apps and need to be treated like any other applications.
2. Taking this a step further, they need to treat all downloaded files as dangerous, and ensure that no files are opened by an application where they're not sandboxed without the explicit request of the user. In practice, the only way to ensure this is to not pass them to ANY application that hasn't been registered with the browser (for example, as a plugin).
3. This means that LaunchServices shouldn't be used by Webcore or in any other context where there's the potential of an untrusted object being passed to an application, except by the explicit request (not merely confirmation) of the user. A separate database should be provided for applications that ARE prepared to accept untrusted documents or other objects.
This third step would actually increase convenience, because then you could write "safe viewer" apps that provided a strong sandbox instead of having to depend on every application figuring out whether they needed to sandbox a document based on what they could guess, so you could have viewers for files that currently can only be downloaded.
They really ought to post an advisory urging users of their shiny new operating system to turn off the ``open safe files after downloading" preference in Safari.
That would be a start.
Better would be to quit shipping Safari with that option turned on by default.
Best would be to take that capability out completely, because it's inconvenient as often as it's convenient and it creates an opportunity for exploits that doesn't need to be there.
It only makes sense that it would have limited functionality because it is designed to teach those with no exposure whatsoever to computers how to use one.
It's designed for no such thing. It's designed to give Microsoft a little extra cash flow without actually providing a useful OS that might cannibalise sales to people who are willing to pay for legit copies of Windows.
Not running on a P4, limiting the number of concurrent applications? A naive user needs not these things.
If you're worried about Apple learning where you live, get the files from opendarwin.org instead.
Yeah, really nice guys with community interest at heart.
Where, precisely, did I say they were nice guys?
The free parts of OS X amounts to a pretty mediocre Unix.
The free parts of OS X are at the very least of mixed quality, but it's not the Darwin kernel that makes it interesting, it's the whole approach to UNIX system configuration and administration they're developing. They're moving away from the gratuitously complex "netinfo" but rather than simply going back to the conventional '60s mainframe-era collection of ad-hoc text files and scripts that every other UNIX system uses, they're designing a system that's browsable and explicitly managable by both scripts *and* humans. It's not traditional UNIX, but it's still basically a UNIX approach with small, separate and understandable tools instead of some kind of alien non-UNIX environment under the covers like the one NeXT flirted with and the ones IBM and Microsoft have embraced in AIX and NT.
Whether they can bring it all together, I don't know, but each new version of Mac OS X and Darwin has been a slightly better iteration of this same ongoing design. I'm very interested to see how it'll play out.
And if you can't see it, if all you see is the pipes and gears and loose cables and springs, well, sorry...
No they didn't. They only blocked it for the Internet Zone, and they only require confirmation even there. They can't turn it off completely because then Software Update, some Control Panel applets, and other tools that depend on ActiveX components wouldn't work.
Which means that it is still true that if you can get the applet into the "local zone", the HTML control will happily launch it. This is not a bug... a bug can be fixed. This is a design flaw, fixing it will require significantly modifying what has become a core API in Windows. And unlike Java, you can't turn it off.
find me some recent IE exploit that allows remote installation of ActiveX without user confirmation
User confirmation isn't a high enough barrier to propogation. manual installation is barely enough, but it is better than confirmation. I spent years doing Windows support as part of my job, and a lot of people around here still think it is. I still get users coming to me saying they "clicked OK again", but I've never had anyone explicitly download and install an attachment twice.
And preventing remote installation isn't enough, if there's a vulnerability in a widely used existing ActiveX applet it can be used, even if that applet was never intended to be run from the browser. For example, here's an ironic one:
Apple doesn't want users changing the UI appearance.
That's really amazing. You made that point, I agreed that you were right, you made it again, OK, I'll agree with you again. You can make it a third time, and you'll get nothing but agreement from me. What you haven't done, though, is establish how "what Apple wants" is relevant, when I'm only talking about "what Apple does", and what Apple does is provide the functionality and make sure that the majority of the developers out there support it.
Apple can want anything, but it's what they do that matters.
WTF do you think X11 resources are, exactly?
Pretty good customization tools for the pre-theme era. Themes are more than just tweaking the colors and fonts of the user interface, a theme is a new skin for the whole user interface. The closet thing to themes Athena Widgets got was when people coded up new versions of them like Xaw3d. And by that time it was too late, really, because Xaw was already being supplanted by horrors like Motif.
the difference is that if you use Qt, theming is well supported from the bottom to the top, and no application can get past it.
Unless they don't use Qt widgets.
with OSX, if you use carbon/cocoa, theming is a hack, not officially supported at all, and apps can get past the theming.
Only if they don't use Carbon/Cocoa widgets.
The only difference is:
On the Mac, only a few applications out there don't use native widgets (and most of those are old applications or ports from Linux or Windows). Not only that, but most of the toolkits that don't use native widgets still use the native theme. There's only a few applications out of all the many available that won't follow the theme.
Under X11 most applications are not written for Qt or any other single toolkit. So only a few applications will follow the theme, unless you restrict yourself to only using applications using that toolkit. So you have the choice of using only a subset of the non-too-great selection of X11 applications that happen to follow your theme, or you end up with a user interface displaying half a dozen themes at once.
apple is the complete antithesis to ui theming
Apple invented UI theming.
They might not want you to use it, but they haven't removed it, and they don't try and stop you from using it, and they have enough influence over their developers that it just automatically works for most apps. KDE wants you to be able to theme your X11 environment, but they don't have the ability to force people developing to other toolkits to follow their theme, so it only works for the apps that happen to use their own toolkit.
"no application can get past it."???
Most don't even notice it's there.
An end user does not want content to be blocked b/c of security issues.
That's another advantage of Firefox. Because the design is safer, there's fewer cases where it has to block content that might be dangerous.
And ActiveX is harmful how exactly?
The whole point of ActiveX in the MS HTML control is to allow a remote site to load and run a native executable without you having to decide whether to run/install/download/whatever.
Of course that has turned out to be a horribly bad idea, and they've wrapped ActiveX in so many layers of protection that downloading and installing a program is INFINITELY easier than figuring out how to configure IE to let you use ActiveX the way it was intended.
The problem is, all those layers of protection don't include "making ActiveX disabled by default", because it's *also* how Windows implements a lot of the features of Windows Explorer. So if someone can figure out how to convince the HTML control that their remote exploit's really an ActiveX applet installed by Windows Explorer, locally, it'll happily run it. then they can do anything.
Microsoft regularly fixes this, usually in a way that breaks someone's software or adds another annoying dialog to train you to ignore annoying dialogs. And just as regularly someone finds another hole, and Ad-Aware or Symantec has to figure out another signature to detect another virus or spybot...