Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Apple

Apple To Patch Dashboard Vulnerability 99

Posted by Zonk from the spackle-makes-a-world-of-difference dept.
bonch writes "Apple has quickly patched a previously reported security hole that allows websites to auto-install potentially malicious widgets without prompting the user. The fix is one of over three dozen miscellanous fixes to be included in OS X 10.4.1, code-named 'Atlanta', and may appear by the end of the week. Users will now be prompted before a widget downloads to their hard drive."
This discussion has been archived. No new comments can be posted.

Apple To Patch Dashboard Vulnerability More

Apple To Patch Dashboard Vulnerability

Comments Filter:

  • Come again? (Score:2, Interesting)

    by Abberlaine ( 709428 )
    Why Atlanta?

  • They should post an advisory (Score:5, Insightful)

    by mithras the prophet ( 579978 ) on Friday May 13, 2005 @11:20AM (#12520046) Homepage Journal

    It's pretty stupid that Apple's policy prevents them from discussing the issue before they have a patch for Safari. 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. Considering that it's now established that malicious widgets can replace the Apple-supplied widgets, run with full user privileges once activated, and execute arbitrary binary code [columbia.edu], Apple really owes it to its users to warn them.

    • Re:They should post an advisory (Score:5, Informative)

      by allgood2 ( 226994 ) on Friday May 13, 2005 @11:36AM (#12520238)
      Apple's already warned users about the "run safe files" function before. The warning indicated that average users should turn the function off, unless you ONLY downloaded files from known, "safe" sites. I had thought that they had released an update that had switch the default in Safari to remove the check from the "open safe files" box, but either Tiger changed that, or I was wrong.
      • The warning indicated that average users should turn the function off, unless you ONLY downloaded files from known, "safe" sites.

        So, shoudln't Apple have provided this function already in off as default? Lucky me I use Firefox.
      • The problem with turning off "open safe files" is that Apple's definition of safe files is too broad. It lumps executable code in with things like movies and sound files. The result is that with the option disabled you have to manually open music samples at online music stores, the same for clips downloaded from NPR. You have to manually open PDF files and downloaded images. It really makes web browsing a lot more inconvenient.

        The right thing to do is to not consider widgets to be "safe", and it looks

    • Re:They should post an advisory (Score:4, Insightful)

      by goombah99 ( 560566 ) on Friday May 13, 2005 @01:29PM (#12521583)
      When I have downloaded application containing widgets they all came packaged as Zip files. the OS warned me that the file I was downloading contained an application. Safari then unzipped and the widget was autoinstalled into the dashbar. The first time I ran it it said this is the first time you are running this and gave me a warning dialog before executing it.

      So really I had my warnings. If you are worried that people get inured to click through warnings then you might as well worry about people running any application they downloaded.

      The only thing that was even vaguely troubling was that it was never stated the item would be auto-installed in the dashboard. Thus even though I was not in danger of running something I did not ask for, I was in danger of installing something in the dashbar I did not understand that I was approving when I allowed it to unzip.

      So the advisory you want is pretty pointless. if people dont listen to the warnings of their own computer then why an advisory. The advisory is more likely just to make people needlessly fearful.

      • Re:They should post an advisory (Score:4, Interesting)

        by NaugaHunter ( 639364 ) on Friday May 13, 2005 @05:01PM (#12524152)
        The only thing that was even vaguely troubling was that it was never stated the item would be auto-installed in the dashboard.

        It's only 'vaguely troubling' because you aren't used to it being done. Installing known files for the user is a good idea in concept. The problem is leaving safeguards so the 'bad files' don't get installed.

        They are kind of caught between a rock and a hard place here. They want to move forward and make things easy for the user to get and install without needing to understand how things are done, but they still need to prevent 'bad things'. And yes, power users want to control every step and don't mind decompressing and moving files by hand, but they are trying to get the more casual user with the 'It just works' paradigm.
      • The problem that was expressed by the earlier Slashdot article about this (or was it a MacSlash article)... anyways.

        The guy said himself, it's unlikely to cause the widget to actually do anything harmful. But rather it would just be annoying.

        He gave an example, and even a sample widget. The widget was simply just the goatse guy as the icon for the widget.

        Now, considering that you can't uninstall, delete, or otherwise remove widgets without manipulating the files directly, I call that pretty damned anno
    • 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.
    • Apple users aren't the kind of people who read security advisories. Most Apple users not only don't know what one is, they don't know where to go look for one. At best Apple could send email to registered users, but given how many hackers/phisers are sending out fake emails from ebay, paypal, banks, and Microsoft, there's no reason to expect anyone to trust emailed advisories.

      The real problem here is not Apple's handling of the advisory. It's that Apple created a culture where users aren't supposed to worr

  • A suggestion for improvement (Score:5, Interesting)

    by MobyDisk ( 75490 ) on Friday May 13, 2005 @11:42AM (#12520304) Homepage
    I think that when a company releases a patch for this type of thing, they should also make the patch report attempts to abuse the exploit. That would make it possible not only to secure against the exploit, but to catch the black hats who try to use it.

    So if a site tries to use the Mozilla/XPI script exploit to install a rogue extension, Mozilla should send a report to mozilla.org. Then they can blacklist the site, or even pursue legal action.

    This would be GREAT for anti-spyware programs. When someone tries to auto-install spyware on to IE, Microsoft could get a report and the spyware company would feel the wrath of a monopolistic giant crushing them.

    • Re:A suggestion for improvement (Score:5, Interesting)

      by amichalo ( 132545 ) on Friday May 13, 2005 @11:50AM (#12520389)
      Good idea but difficult to implement.

      I think that when a company releases a patch for this type of thing, they should also make the patch report attempts to abuse the exploit.

      One problem is that many of the exploits rely on a series of steps being taken, some of which may be perfectly acceptable but in concert, create the exploit.

      If forinstance, an exploit overflowed a buffer with an infinite loop, an Apple patch may rewrite that piece of code so it cannot create that infinite loop scenario. All of a sudden, the exploit code no longer exploits anything, but there is no way to know that it would have since the code has changed.

      I don't know about other programmers, but I find creating good error handling routines to be one of the most challenging aspects of software development because you have to plan for every eventuality, be it expected, malicious, or just a bug.

    • Re:A suggestion for improvement (Score:1, Insightful)

      by Anonymous Coward
      It would be awfully difficult to do in this case. It's kind of tough for the software to tell, without actually running it, if a simple Dashboard Widget is intended to be malicious.

      If you wrote a code to watch for such a thing, you would probably be so flooded with false positives that the detection system would be rendered useless.

    • Re:A suggestion for improvement (Score:5, Insightful)

      by geoffspear ( 692508 ) * on Friday May 13, 2005 @12:00PM (#12520485) Homepage
      If I'm not mistaken, the "exploit" in question is the same technique used by many download sites (including, e.g., Sourceforge) to serve files. You navigate to a web page which displays HTML content and then triggers a download of a file while the page is being displayed.

      In Safari, if the file happens to be a widget, it gets installed for you so you can activate it from within Dashboard. If it's a disk image containing an application, the disk image gets opened (in Tiger, with a warning) so the user can take the right steps to install the application.

      There are substantial non-abusive uses of this technology and, right now, basically one abusive use of it (sending a file that will auto-install without having the website actually ask the user if he/she wants to install it.)

      It's perfectly legitimate to have a site that contains a "Download my widget" link which sends the user to a page like this. Whether the widget can be harmful or not is irrelevant; there's nothing Apple can reasonably do to prevent someone from distributing malicious software to users who trust the person distributing it and intentionally install it.

      Removing the auto-install of widgets, replacing it with a "Are you sure you want to install this widget" dialog, is the reasonable solution, and brings it in line with how Safari acts when any other executable is downloaded.

      • AFAIK the only way of autoinstalling is to put the widget in a zip set to unzip to the correct location, in which case you DO get a warning about the zip containing an executable.

      • Re:A suggestion for improvement (Score:1, Funny)

        by Anonymous Coward
        I don't know about you, but golly gee that sure sounds like ActiveX controls.
        • It's nothing like ActiveX controls. A remote site can't cause code to execute without user interaction.

          Installing the widgets in a directory that Dashboard uses to make them available for use within its GUI without asking the user is definitely a bug (the one that's being fixed in the patch that's the subject of this article), but it's not as harmful as some people have suggested, and it's really not much different than offering a normal executable for download, and then sticking it somewhere that the use

      • Ah, but the problem is not that. The problem is that Safari automatically *opens* these widgets, which in turn installs and runs them. Thus, just visiting a page can install and run a widget on your system, which can, in turn, download other software and run that too. Pretty big freaking hole.

    • "Microsoft could get a report and the spyware company would feel the wrath of a monopolistic giant crushing them."

      This brings up the brain-bending picture of Bill Gates as the Monopolistic Green Giant talking to Sprout...

      "Gee, Mr Giant!" cried Sprout. "How was I to know my computer had a virus that caused it to attempt to violate thousands of browsers? Is there any way we can settle out of court?"

      (background chorus) "Owe Owe Owe -- Green Giant!"

    • I think it's a good idea, but doesn't really make sense for this particular issue. As I recall, the issue is that the default for Widgets when downloaded is to install them. Though this doesn't present a real security risk (widgets can't access local files and report back), it presents an opportunity for websites to autoinstall advertisements.

      So I don't think there is any real "offending code". The whole thing of a download commencing when you visit a page is used for a lot of download sites (instead of

  • great! (Score:3, Insightful)

    by sootman ( 158191 ) on Friday May 13, 2005 @01:04PM (#12521292) Homepage Journal
    now if they'd quit bugging me every time I download a .dmg we'd be set!
    • You can always switch to Firefox.

    • now if they'd quit bugging me every time I download a .dmg we'd be set!

      Try Taboo [ocdev.com]. It's a free little app that a) warns you before closing a window that has tabs open, and b) disables the nag when downloading a .dmg file.

    • 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!

    • On a somewhat related note, I wish they'd add some kind of option to turn off the finder warning when one changes extensions of files in. Seriously, its pretty ridiculous to have to hit the confirm button EVERY SINGLE TIME I change (or add) and extension to a file. the worst part is that the "keep (current extension)" button is the default button; I cant just hit return. I have to use the mouse and click on the "change' button , or hit tab,tab,space. *GRRRR* very annoying!

  • Worst-case scenario for Dashboard malware? (Score:3, Insightful)

    by yardbird ( 165009 ) * on Friday May 13, 2005 @01:33PM (#12521636) Homepage
    What's the worst that a malicious widget can do? Presumably it has access to the network, so it could be a DDOS client (as someone mentioned above). What can widgets do locally?
    • But then it would be a feature, not malware :)

      Seriously though it could do anything any script or application could do; use your imagination. It could delete everything in ~/ - that would not be fun. It could send emails to everyone in your address book announcing your engagement to Michael Jackson.

  • 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 Appl

    • Re:If we were a Mac house... (Score:5, Informative)

      by remahl ( 698283 ) on Friday May 13, 2005 @02:21PM (#12522218)
      when run in Dashboard they have all the same capabilities as local apps and need to be treated like any other applications.

      They don't actually. They only get complete system access after the user has acknowledged that the widget is being run for the first time.

      • 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 r
        • http://developer.apple.com/documentation/AppleApp l ications/Conceptual/Dashboard_Tutorial/Security/ch apter_10_section_1.html#//apple_ref/doc/uid/TP4000 1340-CH210 [apple.com]

          Everything else I would say has already been said by others. Yes it's a problem if Safari copies widgets to ~/Library/Widgets.

          In my opinion installation of Widgets should be handled in very much the same way as installation of screen savers. You double click it where-ever it is and are prompted 'install for you or for everybody', it asks you
          • Yes, I've seen that link. If all the "widget security model" means in Dashboard is that it pops up a one-time dialog, it shouldn't even be enforced by Dashboard. All it does is create an illusion that widgets are somehow "safer" than other classes of applets... and Apple themselves have already fallen for the illusion.

            As I understand it: whether you declare these flags in your plist or not, you can't open a Widget in an arbitrary WebCore environment and get any of these rights. Only Dashboard or another fr
            • Only Dashboard or another front end that adds the same capabilities to its instance of WebCore can give you those rights. And THAT restriction is the important one, from the point of view of real security. Does that fit with what you know?

              Yes, I think we agree. I think the one addition to point out is that Dashboard will only honor requests in the code for certain methods of the widget object based on the security level specified in the plist. The document I referenced explains this as: if you try to widg
              • I think the one addition to point out is that Dashboard will only honor requests in the code for certain methods of the widget object based on the security level specified in the plist.

                Yeh, this is Dashboard's pseudo-sandbox. What I'm getting at is that this pseudo-snadbox doesn't actually provide any useful security, because most widgets require additional rights to function so allowing a widget those extra rights is a normal operation that someone is going to expect to do when running a widget. Addition
                • So again, we're on the same page.

                  For example, there's no reason to distinguish "running an embedded Cocoa component" and "making a system() call" because both of these grant you full local-user control.

                  Well there's no reason for 'average folks'. You and I can both tell the difference between a 'do shell script' and running a plugin and is this: It's trivial to open up the bundle and looking at the script for system calls (plain text and all) vs. trying to determine what a widget or web plugin does befor
                  • You and I can both tell the difference between a 'do shell script' and running a plugin and is this: It's trivial to open up the bundle and looking at the script for system calls (plain text and all) vs. trying to determine what a widget or web plugin does before running it (arguments of decompiling, etc aside).

                    It's REALLY AMAZING how close the kind of Javascript that some virus writers write is to binary. Really. I've seen whole applications encrypted and wrapped up with an obfuscated decryption routine
    • 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. I never install a new version of X until at least 10.n.3.
      • 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

  • Learn from ActiveX? (Score:3, Insightful)

    by lbya ( 880645 ) on Friday May 13, 2005 @04:49PM (#12523986)

    Actually in my mind this Dashboard security hole, while perhaps minor, is one of the most disappointing things Apple has ever done. The line continues to blur between surfing and running code -- or between documents and executables -- and this trend, while important, of course presents serious, inherent security challenges, since it places the user in a passive position with respect to the code being executed on their computer. It's disturbing that Apple apparently didn't think much at all about that very well-known issue, before creating an auto-install, auto-execute system for Javascript apps with file system access.

    Isn't this the same major (and irrevocable) mistake that Microsoft made when they let the ActiveX genie out of the bottle? If Apple is going to walk into the same traps that Microsoft walked into years ago, it makes me question the purpose of OS X. Plus as an invention Dashboard isn't even as useful as ActiveX.

    • Re:Learn from ActiveX? (Score:5, Insightful)

      by argent ( 18001 ) <peter@slashdot . ... t a r o nga.com> on Friday May 13, 2005 @05:42PM (#12524621) Homepage Journal
      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.

    • Re:Learn from ActiveX? (Score:4, Insightful)

      by ciroknight ( 601098 ) on Friday May 13, 2005 @08:06PM (#12525832)
      You are blowing things way out of porportion.

      First of all, the VERY first patch to this new operating system, 10.4.1, will fix this bug. Developers can't always catch everything, and honestly, I wouldn't even have thought about it, so I can't blame Apple for not thinking about it. I'm just happy to know when my laptop arrives with Tiger installed that the very first thing that will happen is it will patch all of the holes they let slip in 10.4.0.

      Second of all, deadlines like this are vicious. If you ask me, they rushed the release of Tiger a bit just to counteract some of the press Longhorn betas and Longhorn reviews were getting, and to help the sells of Mini Macs. So some of the things they released were a little broken.

      Lastly, you said it yourself. Dashboard isn't even as useful as ActiveX, and is entirely deniable. You can turn it off and not ever use it if you choose, making any bugs like this completely null to you. ActiveX quickly became something that wasn't deniable; if you weren't running ActiveX, your bank's website would refuse to do business with you. Now doesn't that mean a flaw in ActiveX is a lot more critical than a flaw in some easily ignorable post-it note board?
  • One simple solution, is obviously to turn off "Open Safe Files" in Safari, but that does make life a bit more difficult, so, for those who want to have their cake and eat it too (at least on this issue) I found it blindingly easy to add what I think should be closer to the default behavior - and it's not dependent on Safari.

    1. Run "Folder Actions Setup" (in the Applications/Applescript folder).
    2. (if it's not already on) Turn on "Enable Folder Actions".
    3. Click the (+) button below the folder column to add

    • Why? (Score:2)

      by argent ( 18001 )
      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 ac
      • Well, the original of this was written primarily with my MUG mailing list as the primary audience, many members of which are not slashgeeks. It was primarily to those who do prefer that setup that I was addressing that sentence. I myself go back and forth on that setting. Sometimes it is useful (though now in Tiger, possibly less so, since Safari 2 has native PDF support) I do find it useful to have pdfs opened for me without sloshing through my download folder, but most of the time I'm actually with you on
        • 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 i

          • Well, now I don't get it.

            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.

            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. So, how exactly is Mozilla/FF doing this any better? (not trying to dis

            • 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, Acr

    • Well your configuration is a good step, it could be better. I'd recommend changing the permissions on you existing widgets so that they cannot be overwritten by a malicious version (which you would then have to find and replace).

      • I'm not on my Tiger machine atm, so I can't check the perms, but IIRC the Apple supplied widgets are in the /System/Library/Widgets folder which I think already takes an admin password to change anything in. I'll check it out later, but I think what you might be referring to is the fact someone else turned up that identically named widgets in the ~/Library/Widgets apparently take the place of standard widgets in the /System/Library/Widgets folder in the widget "dock" - I haven't actually played with this pa

        • Ahh, I did not realize it was a problem of co-existing widgets with the same name. I haven't installed Tiger yet, as I'm still waiting for Cisco to fix their VPN client. Thanks for the clarification.

          • Actually, I just checked on my system, here's a listing (and I was wrong, it's /Library/Widgets not System/Library/Widgets.


            iMac:/Library/Widgets ka-klick$ ls -la
            total 16
            drwxrwxr-x 17 root admin 578B May 11 21:33 .
            drwxrwxr-x 53 root admin 1K May 5 00:03 ..
            -rw-rw-r-- 1 ka-klick admin 6K May 11 21:33 .DS_Store
            drwxr-xr-x 12 root admin 408B May 4 06:16 Address Book.wdgt
            drwxr-xr-x 12 root admin 408B Mar 23 19:49 Calculator.wdgt
            drwxr-xr-x 12 root admin 408B May 4 06:16 Calen

  • The only real mistake Apple made is... (Score:4, Interesting)

    by berndtj ( 848650 ) on Friday May 13, 2005 @05:44PM (#12524641)
    Automagically moving the downloaded widged directly into the dashboard widgets folder. Some of the responses here are suggesting that widgets in general are a securtity risk, well, so is every other application that you've installed on your machine. The assumption is that you won't install a malicitious application, well the same applies. It is up to the user to decide if an app is safe to install. What more do you want apple to do besides prompt the user and ask if they would like to install a downloaded widget? Yes, this is an issue right now, but I don't think this current issue, which will be fixed as mentioned above, makes Safari and Dashboard a security risk.
    • [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.
      • 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.

        Let Safari? How about letting me do this? 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.

        • 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 conv
  • Users will now be prompted before a widget downloads to their hard drive.

    Another problem, besides "auto-install on download" is that Dashboard's "warning" to a user on newly-installed widget launch is a simple yes/no proposition without any indication of the access sought by the widget.

    It would be nice to see Apple adopt something similar to Amnesty Widget Browser [mesadynamics.com], which presents the following dialog [yumahouse.com] on newly-installed widget launch.
    • Dashboard's "warning" to a user on newly-installed widget launch is a simple yes/no proposition without any indication of the access sought by the widget.

      The fact is, Dashboard shouldn't be doing this check at all. The check implies that Dashboard is a "safe" environment, and it's not any such thing, so all it does is provide an illusion of security that encourages people to treat Widgets cavalierly... and it's truly ironic that the first victim of this illusion is Apple themselves. Same thing with Amnest

Slashdot Top Deals

Without life, Biology itself would be impossible.

Close