Useless password prompts

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.10.2004, space aliens observed JolinWarren saying:a
>I have thought this for quite a while now -- the password prompt
>appears so frequently and there is so little information as to why a
>password is needed, that requiring a password is effectively useless.

Have you tried clicking the "Details" button? Not *that* helpful, but it
does give some additional information. Contrary to what some have said
in this thread, applications most often don't just "get admin rights"
and can then do whatever they want. Applications can ask for and receive
very specific rights (this was explained recently in MWJ:
<http://www.macjournals.com/>).

Frankly, I don't see the "useless password prompts" problem at all. On
my machine, the password prompt doesn't appear frequently at all. It
appears mainly when I install an application (although there's a problem
in that the installer often doesn't care about whether it actually needs
the password to install the application, it just asks for it anyway) and
when I change preferences that affect all users. This keeps others using
my Mac from installing stuff into global folders and from changing my
settings - nothing wrong with that.

I never enter the password reflexively because I always *know* when the
password panel should appear.

lucas

- --
"Wine makes a man more pleased with himself; I do not say that it makes him more pleasing to others."
  -- Samuel Johnson

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2

iQA/AwUBQYLIFrXYdom/dB2cEQItZwCg/zhSYcY4DhrjXPWEXd3rUrkgscEAoM/T
aKwF6j1QBPuPhNUmCYDs3Vko
=II3/
-----END PGP SIGNATURE-----

At 7:41 AM -0700 2004/10/29, Nigel Stanger wrote:

>Of course, if you're the only person using the machine, there's nothing
>stopping you from installing applications into the Applications folder in
>your home directory. They should work just as well there as anywhere else.
>Applications only need to go into /Applications if you want them to be
>available to multiple users. In typical fashion, of course, some installers
>don't give you this option :(

        But keep in mind that performance is apparently inferior for
applications not on the root volume, which is non-obvious and was not
the case with Classic. This is due to the way Apple has implemented
prebinding. Feh!

                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

--On Friday, October 29, 2004 7:41 AM -0700 Sander Tekelenburg
<tekelenbeuronet.nl> wrote:

> At 07:40 -0700 UTC, on 2004/10/28, kevinv wrote:
>> c) Reduce the things that need an admin password for. For example, why do
>> I need an Admin password to renew a dhcp lease in the Network preference
>> pane? This is a common troubleshooting step when moving between a lot of
>> networks without rebooting. Any user should be able to do this.
>
> I disagree. Changing the network settings affects the entire machine and
> thus every user. If another user is logged in from a remote location
> he''ll be kicked off. Or if through FUS another user is logged in locally
> and downloading something, that download will be killed.

Sorry, I wasn't clear. I think the Renew DHCP Lease button should be
available but not the other settings. It's already possible to refresh DHCP
leases several ways without needing a password (sleep/wake, reboot, if on
wireless turn off the airport card then turn it back on.) Having the
button available doesn't lessen security, unless you also disable the other
methods.

>
>> Same with
>> changing Energy Saver options.
>
> You don't want anyone to able to allow the machine to go to sleep if you
> want it to remain available as a server or for remote users to log in.
>

In my experience, on desktop/laptop client machines at least, this is a
rare need -- and once set most people don't go mess with them, even if they
can, because they know it's acting server (otherwise they may just shut it
off.) Far more common is the presenter that needs to disable sleep mode
during a presentation to keep the computer from going to sleep during a
particularly long slide, but wants more aggressive settings when in the
hotel room. Giving a laptop user admin privs just to be able to set the
sleep mode seems more dangerous than having to train some users not to mess
with the settings when using a computer as both desktop and server.

There is an alternative, although it may be too restrictive. The Mac
Accounts panel actually supports 3 account types: Admin, Standard and
Limited. Under the Limited account you can remove access to all the
control panels. I have an account called Visitor that can run any
applications but can not launch System Preferences at all. So on the
server machine I would probably make all the other users more limited than
even a Standard account, while allowing Standard accounts to change the
settings.

>> If entering the password is something that
>> occurs only occasionally then I would think more about it when asked.
>> Windows XP has a Power Users group, users in this group have more control
>> than regular users, but aren't full admins.
>
> Yes, maybe that's an idea. Then again having yet another level of users
> would probably be even more confusing to many people.
>

Agreed. Unfortunately the secure way of doing something is rarely the easy
way to do something.

>> One thing I would like to see is more drag and drop installations.
>> Dragging a new/upgraded app to the Application folder requires a
>> password, but nothing is run, just files moved. Then whne I double-click
>> the app it is run as my regular account, a non-admin user.
>
> Yeah, but then the point is that the app in question does not need Admin
> rights anyway. If it does, it doesn't matter if it uses an installer, or
> if it executes an install script on first launch as some apps do. So I
> don't think drag&drop has anything to do with this.

An installer app will always need the Admin password so it can copy itself
to the Applications folder. On a drag and drop the user knows what is
happening -- files being copied to the folder listed, no mysterious files
appearing in /Library/StartupItems. Providing the password to an
application it is impossible to know what is happening in addition to
copying files to the Applications folder.

Kevin

Bizarrely, I still encounter installers that prompt me for a password even when all it's doing is copying files into /Applications, which I already have permission to write to anyway. Now _that_ is just plain stupid.

Of course, if you're the only person using the machine, there's nothing stopping you from installing applications into the Applications folder in your home directory. They should work just as well there as anywhere else. Applications only need to go into /Applications if you want them to be available to multiple users. In typical fashion, of course, some installers don't give you this option :(

Have to agree with you there, why do they prompt for things they can do anyway? What are they doing asking for the password if they don't actually need it? And if you are surrounded by people staring at your screen when you have to type in a password to do something mundane like change an IP address at a conference (happens OFTEN) you are guaranteed to have somebody notice your password eventually. You already typed it in when you logged in as ADMIN earlier, so why is it needed again?

What is to stop me from taking a screen snapshot of a legitimate installer, making an AppleScript which displays that screen snapshot, even duplicating the buttons, and asking somebody for an admin password which I can then wreak havik with. Nothing. I could even do it with a well-designed web-page. I might try it now just as an experiment. Incidentally, AppleScripts DO NOT give you details when they ask for passwords. Just a small window with an input box and a button. So if anybody uses AppleScript they are always at risk of typing the password into the wrong window.

I don't believe the password collection duties should EVER been given to the application itself, but that is just my opinion. You just need one sloppy programmer and all your efforts are wasted. There are so many instances of passwords appearing in log files, cache files, even in plain view in preferences. It would be better if OSX handled the requests in its own way, THEN gave access to the programs, not the other way around. If I have somebody around to fix the TV, I don't give them the keys to my house, but I will open the door for them.

If OSX had a central 'warning' system to let you know when stuff was being accessed (obviously you can tell it which applications to ignore) then that would be much better. Almost like the 'ZoneAlarm' security program available for Windows - it sits there doing nothing until 'BING - A program has tried to access Port 1028 - Will you allow this?' Maybe if the system had a central application which was launched every time an application NEEDED access, then I could see that the other application had been launched and could give the installer permission only when necessary.

A standardised log system for software installs would be brilliant and VERY EASY with the installer program Apple uses. The worst culprits tend to be Apple themselves. I installed Final Cut Pro and afterwards every time I logged in it gave me a message 'Starting Q-Master Services' - Now what the heck is THAT?!? Nothing to do with single-user movie editing, so why is it now a start-up item? How do I remove it? No idea. If Apple can do it anybody else can.

David

On Nov 2, 2004, at 11:35 AM, Sander Tekelenburg wrote:

> At 07:41 -0700 UTC, on 2004/10/29, Nigel Stanger wrote:
>
>> Of course, if you're the only person using the machine, there's
>> nothing
>> stopping you from installing applications into the Applications
>> folder in
>> your home directory.
>
> Even (or maybe _especially_) when you are not the only user can it
> make sense
> to do that.
>
>> They should work just as well there as anywhere else.
>
> Unfortunately some don't. Not sure why. For instance, Gilder Pro only
> runs in
> an Admin account. If someone knows how to fix that I'd love to hear
> it. (I
> already tried setting permissions of everything in its package to 777,
> but
> that didn't help.)

Here's a tip that just showed up at MAC OSX HINTS
<http://www.macosxhints.com> yesterday which allows Photoshop Elements
to run as a non-admin user:

  Here's how I got Photoshop Elements 3 to run as a non-admin user. This
assumes your short user name is me, and your admin user's short user
name is admin_user. Open Terminal, and type the following (don't enter
the $; that's the prompt character):
$ su admin_user
Password: Enter your admin_user password
$ sudo chown -R me.me /Applications/Adobe Photoshop Elements 3
Password: Enter your admin_user password
$ sudo chown -R me.me /Library/Application
Support/Adobe/PhotoshopElementsHelp
$ exit

  PS Elements 3 will now run quite normally as a non-admin user...

It may or may not work for other applications. I haven't tried it yet
and it was posted anonymously.

Regards,
Don Bennett

"If OSX had a central 'warning' system to let you know when stuff was being accessed (obviously you can tell it which applications to ignore) then that would be much better. Almost like the 'ZoneAlarm' security program available for Windows - it sits there doing nothing until 'BING - A program has tried to access Port 1028 - Will you allow this?'



I've been using "Little Snitch" which does just this, and I'm frequently amazed at the apps that "Phone Home" during the course of their start up and sometimes during their process. Innocuous apps such as Apple Help and StuffIt, to name but a few. "Help" perhaps to access the main database, but I fail to see why StuffIt Expander wants to contact Alume. As for the Password request, I bow to the previous observations, but would say that Apple states that they keep matters of security completely to themselves, unless some element of their system is proven, with their subsequent confirmation, to be faulty or insecure, and they still won't issue a statement untill a corrective patch is issued. I doubt that we will change them.



[Apple Help is checking for updated content, and I suspect most others are checking for updated versions. -Adam]

Chris

All of these password problems are compounded by the fact that many
applications (some of which are effectively defunct, such as Corel
Draw) fail to work properly when run from a non-admin account. Like it
or not, most developers seem to assume that their apps will be run by
an admin user.

--Nik

--On Tuesday, November 2, 2004 8:35 AM -0800 Sander Tekelenburg
<tekelenbeuronet.nl> wrote:

> Unfortunately some don't. Not sure why. For instance, Gilder Pro only
> runs in an Admin account. If someone knows how to fix that I'd love to
> hear it. (I already tried setting permissions of everything in its
> package to 777, but that didn't help.)

Works fine for me. In fact it works for me logged in with the Limited
account I have on my powerbook for relatives to use specifically to play
games (set to "Some Limits" with the Preferences Panel turned off.)

I have a folder in Applications called Games. I have a Glider Pro folder
in that folder.

Games folder is set to my admin account as owner, staff as group. Only the
admin user has write.
the Glider Pro folder has my normal user set as the owner, and the group is
set to the my username too (frequently in unix when a user is created a
group with the same name is created.) The owner has write, everyone else
read and excutable.

The Glider Pro.app has the same owner/group and is read/write for the user,
group and other. I think what I did was cd to the Glider Pro folder and do:

chmod -R ugo+rwX Glider\ Pro.app

note the capital X, this will set the excutable bit on directories so users
can open the directory, but will not set the excutable bit on regular
files. This keeps regular files from becoming excutable, which would be a
(small) security problem. You can't do this using numerical mode of
setting permissions.

Not sure why this worked for me and not you.

Kevin

At 08:41 -0800 UTC, on 2004/11/02, Kevin van Haaren wrote:

> --On Friday, October 29, 2004 7:41 AM -0700 Sander Tekelenburg
> <tekelenbeuronet.nl> wrote:
>
>> At 07:40 -0700 UTC, on 2004/10/28, kevinv wrote:
>>> c) [...] why do
>>> I need an Admin password to renew a dhcp lease in the Network preference
>>> pane? [...]
>>
>> [...] Changing the network settings affects the entire machine and
>> thus every user.[...]
>
> Sorry, I wasn't clear.

No, my bad. I didn't read careful enough :)

[...]

> The Mac
> Accounts panel actually supports 3 account types: Admin, Standard and
> Limited. Under the Limited account you can remove access to all the
> control panels. I have an account called Visitor that can run any
> applications but can not launch System Preferences at all.

Are you sure?... Indeed the Accounts pref pane gives the impression you can
limit access to specific apps, including System Preferences. But in reality a
Limited User can still launch System Preferences. He can do so through the
Input Menu. And if that user's default language isn't american, there is no
way to ensure the Input Menu won't be available.

Of course you can disable the Input Menu for that user (if his default
language is american), but I doubt that that fixes the underlying design. If
you look at the text in the Accounts pref pane under "Simple Finder", the
crucial word appears to be "directly". I haven't tested this, but I wouldn't
be surprised if a Limited User with access to Script Editor could launch any
application.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

At 8:41 AM -0800 11/2/04, Kevin van Haaren wrote:
>There is an alternative, although it may be too restrictive. The
>Mac Accounts panel actually supports 3 account types: Admin,
>Standard and Limited. Under the Limited account you can remove
>access to all the control panels. I have an account called Visitor
>that can run any applications but can not launch System Preferences
>at all. So on the server machine I would probably make all the
>other users more limited than even a Standard account, while
>allowing Standard accounts to change the settings.

You can also *remove* a preference pane from
/System/Library/PreferencePanes, and put copies into users'
~/PreferencePanes.

It's a great trick to use for those users who insist on having Admin
rights, even though you know damned well they'll hose their Network
settings. Poof!, no Network settings for you.

--
Andrew Laurence
atlaurenuci.edu

--On Friday, November 5, 2004 8:26:13 AM CST -0800 Sander Tekelenburg
<tekelenbeuronet.nl> wrote:

>> The Mac
>> Accounts panel actually supports 3 account types: Admin, Standard and
>> Limited. Under the Limited account you can remove access to all the
>> control panels. I have an account called Visitor that can run any
>> applications but can not launch System Preferences at all.
>
> Are you sure?... Indeed the Accounts pref pane gives the impression you
> can limit access to specific apps, including System Preferences. But in
> reality a Limited User can still launch System Preferences. He can do so
> through the Input Menu. And if that user's default language isn't
> american, there is no way to ensure the Input Menu won't be available.

[after a little bit of testing] setting an account to the Simple Finder
mode does remove the System Preferences... option from the Apple menu, but
as you point out you can open the System Preferences window by going to the
Input menu and selecting Open International... and then clicking the Show
All button. You can also get there if the Battery icon is showing and you
select Open Energy Saver....

However once in System Preferences most of the panels are grayed
out and unselectable (and no way to click a key icon to gain access via a
username/password.) The Energy Saver pane is one of the inaccessible
panes and when you use the Battery icon in the menu toolbar to jump to it,
you are taken to the full system preference pane instead.

If your user is in the "Some Limits" mode instead of the Simple Finder
mode, the System Preferences option is under the Apple menu (even if
you uncheck the Open All System Prefrences option) but using it has the
same grayed out panels as above.

(heh, I was just getting ready to test some of what you mention below about
the Script Editor when I found out that by default there is a link to the
System Preferences in the Simple Finder by default unless you turn the
option off.)

> I haven't tested this, but I
> wouldn't be surprised if a Limited User with access to Script Editor
> could launch any application.

Yep, this is true. The limited user is not securely prevented from
launching other applications, they are just removed from the user
interface. If you have access to the Script Editor (on by default for a
limited user) or the Terminal (off by default) you can run any application.

Kevin

On Nov 2, 2004, at 08:35, Sander Tekelenburg wrote:

> At 07:41 -0700 UTC, on 2004/10/29, Wilcox, Curtis wrote:
>
>> An easier option would be for all installers to generate a log which
>> spells out what it did.
...
> Agreed, but I doubt the OS could enforce this...

The OS knows when a program touches files and could retain a completely
accurate record. The OS could record when a file is created, deleted,
or modified in "interesting" locations. For example, anything under
/System, /Library, or /Applications. Or, it could keep a record of any
and all files that are altered by any program that prompts the user for
admin privileges. The overhead of keeping this record should be low,
since these kinds of alterations occur infrequently.

In fact, the OS could even arrange to keep a backup of every file the
program alters while it has admin privileges, providing a means to undo
an installation. (This could be done without too much overhead,
although I won't go into the details here.)

The real question is: How much time does the typical user want to spend
looking at the records of changed files, and how would they decide when
to undo an install? How would you know when a program is malicious (or
just dangerously buggy)? At what point should you just use a backup
program?

One thing that might help is if the OS had a more detailed means of
granting permissions. Once a program has admin privileges, it can do
virtually anything. It might be more useful if you were prompted to
allow particular actions, such as "install an application", where the
OS would only allow the program to alter files in locations typical of
applications. Programs that want to install more sensitive kinds of
files would have to ask for additional permissions, and when you are
prompted for a password the OS could both let you know more
specifically what you're granting permission for and enforce it.

I'm certain that a few meaningful categories of installation could be
identified and associated with the alteration of particular files and
folders. It should be rare that some program requires broad permissions
to alter files everywhere, and the prompt for that could have a
flashing red light and a siren.

In fact, I've heard Tiger will include a more fine-grained permissions
system, but I don't yet know how that will affect what users see.

In the meantime, do regular backups. :-)

--
Chris Page - Software Wrangler - Dylan Pundit

At 8:26 AM -0800 11/5/04, Andrew Laurence wrote:
>You can also *remove* a preference pane from
>/System/Library/PreferencePanes, and put copies into users'
>~/PreferencePanes.

Arrrrgh!!

That should be ~/Library/PreferencePanes.

(hangs head in shame)

--
Andrew Laurence
atlaurenuci.edu

On Nov 2, 2004, at 08:41, Chris Pepper wrote:

> But keep in mind that performance is apparently inferior for
> applications not on the root volume, which is non-obvious and was not
> the case with Classic. This is due to the way Apple has implemented
> prebinding. Feh!

You'll be glad to hear that the need for prebinding is going away.
Prebinding is a way to make loading programs faster, and someone
(brilliant) has figured out how to make loading faster without it.
Prebinding may still offer a slight performance improvement, but the
"penalty" for storing applications on other volumes should be reduced
enough that you won't notice the difference. (Keep your fingers
crossed.)

--
Chris Page - Software Wrangler - Dylan Pundit

--On Tuesday, November 9, 2004 9:23:42 AM CST -0800 Chris Page
<tidbitschris-page.org> wrote:

> The OS knows when a program touches files and could retain a completely
> accurate record. The OS could record when a file is created, deleted, or
> modified in "interesting" locations. For example, anything under /System,
> /Library, or /Applications. Or, it could keep a record of any and all
> files that are altered by any program that prompts the user for admin
> privileges. The overhead of keeping this record should be low, since
> these kinds of alterations occur infrequently.
>
> In fact, the OS could even arrange to keep a backup of every file the
> program alters while it has admin privileges, providing a means to undo
> an installation. (This could be done without too much overhead, although
> I won't go into the details here.)

Windows XP has a feature called the System Restore that kind of does this.
A restore point can be created manually, or by an installer, and then
whatever changes you make can be rolled back.

This was immediately abused by virus and spyware writers, they tuck
themselves into restore points too, so that rolling back gets you the still
infected versions. The first instruction in many virus uninstalls on
Windows XP is to turn off System Restore....

<http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/systemrestore.mspx>

I'd bet Apple could do a better job (oh and creating Restore Points is
slow....)

Kevin

At 09:23 -0800 UTC, on 2004/11/09, Chris Page wrote:

> On Nov 2, 2004, at 08:35, Sander Tekelenburg wrote:
>
>> At 07:41 -0700 UTC, on 2004/10/29, Wilcox, Curtis wrote:
>>
>>> An easier option would be for all installers to generate a log which
>>> spells out what it did.
> ...
>> Agreed, but I doubt the OS could enforce this...
>
> The OS knows when a program touches files and could retain a completely
> accurate record.

Sorry, I should have been more clear what I meant. I was thinking in terms of
"I doubt the OS could know which application is an installer" (where "doubt"
is probably an understatement ;)).

> The OS could record when a file is created, deleted,
> or modified in "interesting" locations. For example, anything under
> /System, /Library, or /Applications.

Right. And you could take it even further by having something like that blow
a whistle when something important appears to have been changed. In fact,
under Mac OS X 10.1 and 10.2 a third-party Preference Pane "CheckMate"
offered something very much like that. It would checksum certain important
files and regularly verify that checksum. Indeed often you updated the OS it
would warn that something was changed about those files. Unfortunately it
stopped working (for me) in Mac OS X 10.3.

[...]

> In fact, the OS could even arrange to keep a backup of every file the
> program alters while it has admin privileges, providing a means to undo
> an installation.

Wouldn't there be a risk of backing up files that you do *not* want backed up
because they may contain sensitive information? (passphrases, network
activity, shell history)

[...]

> The real question is: How much time does the typical user want to spend
> looking at the records of changed files, and how would they decide when
> to undo an install?

I don't think the typical user is important (assuming he even exists ;)). Of
course it's not worth spending resources on developing and implementiung
something that only 1 or 2 users care about (unless they are called Steve
Jobs ;)). But it may be when a few thousand users would care, even when they
are not 'typical' users. In fact, maybe even *because* they are not 'typical'
users, if for instance they are sys admins or the security expert whose
advise counts in a company's decision whether or not to replace their 'puters
with Macs.

> How would you know when a program is malicious (or
> just dangerously buggy)? At what point should you just use a backup
> program?

I think it depends on your aim. If 'all' you want is to make sure your
system's integrity is not violated, the ability to revert to a known to be
good backup will probably suffice. But that won't teach you what was the
cause of the (potential) violation. Thus it won't help you prevent it from
happening again. (Well, other than staying away from whatever it was that
seems it may have been the cause.)

> One thing that might help is if the OS had a more detailed means of
> granting permissions. Once a program has admin privileges, it can do
> virtually anything. It might be more useful if you were prompted to
> allow particular actions, such as "install an application", where the
> OS would only allow the program to alter files in locations typical of
> applications. Programs that want to install more sensitive kinds of
> files would have to ask for additional permissions, and when you are
> prompted for a password the OS could both let you know more
> specifically what you're granting permission for and enforce it.

Right. Making a distinction between permissions to dump something in
/Applications, or in /System/Library/Extensions would probably be nice.

But how could you implement such a thing in a manner that doesn't make things
too complicated for Joe Average when he really does want some kext installed
to drive his new USB device? Another passphrase-protected layer...? Might be
the right/best way, but it might also annoy too many users.

I suppose you could make it optional. Sort of like the option to create a
passphrase-less account and logging into the first created account without
requiring a user/passphrase combo.

> I'm certain that a few meaningful categories of installation could be
> identified and associated with the alteration of particular files and
> folders. It should be rare that some program requires broad permissions
> to alter files everywhere, and the prompt for that could have a
> flashing red light and a siren.

Are you saying the OS can know what specific files an application wants
access to before it grants it that access? I had the impression that you tell
the OS you want the rights of a certain user or group, and the OS simply
verifies your rights by requiring the relevant passphrase.

[...]

> In the meantime, do regular backups. :-)

Always good :)

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On Nov 11, 2004, at 10:10, Sander Tekelenburg wrote:

> Are you saying the OS can know what specific files an application
> wants access to before it grants it that access?

Right now the permissions system only allows you to control things by
owner and group, which is too course-grained for installers (and,
actually, other types of programs). For example, in order to install a
driver you have to grant the installer admin privileges, which allows
it to alter anything on your hard drive. Even if the installer is only
installing something for the current user, it has access to all of the
user's data.

Instead, the OS could grant processes more specific permissions, like,
"permission to add files to /Applications/ but not to alter any files
there that belong to other applications", or "permission to install a
driver". Once the user grants that permission, the OS can ensure that
the process only has the ability to read and write files and folders
that are marked as appropriate for that action.

The basic issue is that there is currently only one set of permissions
for a given file or folder, but different programs should have
different access restrictions. Finder should be able to see and alter
anything the current user has access to do, but a word processor should
really only need access to its preferences and a few folders like
~/Documents/ and ~/Desktop/, and the OS could prevent it from reading
or writing other files. In the current system, both programs have
complete access to whatever the current user has access to.

--
Chris Page - Software Wrangler - Dylan Pundit

I don't know if this is a known problem; does anyone else get LOTS of "Confirm access to keychain" prompts in Safari after installing Apple Security Updates? It seems to happen pretty much every time I install a new update, whether it's Safari related or not. I'm still using Jaguar (Panther won't recognize my second-monitor video card; any info on that would be appreciated too. I'm hoping to upgrade to a faster G4 soon so it doesn't seem worth getting a new card for the current one). I get the prompts on pretty much any page with form fields, and it sure does get annoying after a while!

Anybody else? Thanks! Albo

At 11:17 AM -0800 2004/11/17, albo wrote:
>I don't know if this is a known problem; does anyone else get LOTS of
>"Confirm access to keychain" prompts in Safari after installing Apple
>Security Updates? It seems to happen pretty much every time I install a
>new update, whether it's Safari related or not. I'm still using Jaguar
>(Panther won't recognize my second-monitor video card; any info on that
>would be appreciated too. I'm hoping to upgrade to a faster G4 soon so
>it doesn't seem worth getting a new card for the current one).
>I get the prompts on pretty much any page with form fields, and it sure
>does get annoying after a while!

        I eventually gave up and started giving Safari my keychain
password. I wonder if it's actually succeeding when you (presumably)
enter yours, or just trying and failing continually. Have you tried
deleting your keychain, and turning off auto-complete in Safari?

                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

Quick follow up on this topic about making sure your installations are
somewhat safer by identifying what files are being installed. Turns out
the Apple Installer actually has this feature already. According to Mac OS
X Hints:

<http://www.macosxhints.com/article.php?story=2004111800484285>

Under the File menu during an installation is a Show Files option that will
show all files to be installed and where they are going.

Not sure if the Vise Installer has a similar feature.

Kevin