To be perfectly clear the "my opinion" disclaimer really applies.
Please don't conclude I disagree with you, just that I don't think the
rest of Apple agrees with you or supports your viewpoint.
On Jul 4, 2008, at 12:43 PM, Shawn A. Geddis wrote:
/* Shawn's personal rant on this point follows */
FireFox is a complete stand-a-lone application which requires that
all of its Certs / Trust / Settings be performed within the
application - hence the _need_ to prompt _within_ the application
for Passwords / Certs. This means that even if you already have the
Certs / Passwords managed by Mac OS X, you have to duplicate your
effort to tell FireFox what to do with the exact same information.
Might be nice for Applications like FireFox to integrate with the OS
they are running on and take better advantage of the OS Security /
PKI services rather than needing to duplicate those same services.
I am a little surprised that so many IT folks who are "Central
Management" focused prefer an application that makes no effort in OS
integration and requires redundant effort to manage. Maintaining
good Security is hard enough without duplicating the required
efforts. In my opinion, It is very dangerous to be pushing all of
the security decision into the application that runs in user space.
It is much safer and better practice to rely on the security
enforcement of the OS.
Mac OS X provides a System-wide architecture for this which can be
set _once_ and safely relied on by ever single application that
leverages the corresponding Sec* APIs.
In this case the applications in question are only web browsers. I
only have two, so I'm afraid the argument isn't that strong.
Even conceding that argument, there are others: 1) Apple doesn't
support the industry-standard interface for smart-card and other
certificate stores, PKCS-11, and 2) the Keychain UI is inadequate, 3)
the centralized-selection philosophy you advocate is inconsistent with
other UI changes Apple has made recently. To expand on 1) a bit, I
can believe that tokend is a simpler, better API than PKCS-11, and I
couldn't care less. It's not the standard. To expand on 2) a bit,
there is no way a user could ever reasonably discover the Keychain
operations needed, *even*if* they looked in Keychain Access instead of
Safari because a "right-click" is required before you can even see it
exists. Also, the method for inspecting cert preferences bears no
relation to how they are set. To expand on 3) a bit, it wasn't too
long ago that Apple moved Internet Preferences items to the respective
Apple-supplied applications. Now you must start up Safari to set
Firefox as your default browser, Apple Mail to set Thunderbird, etc.
The change seems philosophically opposed to what you're advocating
(however logical it might be in terms of underlying function). Do
Apple's current Human Interface Guidelines properly address this point?
Generally, how is a user supposed to discover that a certificate
preference needs to be set in a utility they've never heard of, using
a GUI operation with a mouse button they don't have, if Safari never
tells them? User friendliness means not bothering people with what
they don't need to know, but conversely it also means you do need to
tell them what they do need to know, and you need to tell them when
and where they hit the situation where they need to know it.
Not only that, Applications do not need to attempt to get into the
security game and try to do security -- which frequently is one of
their last concerns. Safari is relying, as it should, on the
Security / Certificate management of the OS. That said, the OS is
performing all of the Certificate parsing, chain-of-trust
validation, confirming proper key usage, etc.
I agree with this, at least philosophically. I do think that Apple
could do a better job of following standard industry practice in how
they deal with PKI though.
/* Thus ends Shawn's personal rant on this point :-) */
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
