Re: More on apps, shelf space

In article <1241kp6scjp3ee8@xxxxxxxxxxxxxxxxxx>,
"Dan Johnson" <danieljohnson@xxxxxxxxxxxx> wrote:

"ZnU" <znu@xxxxxxxxxxxx> wrote in message
news:znu-B04C78.10575114042006@xxxxxxxxxxxxxxxxx

[snip]

Moreover, Apple actually knows how to lay out a dialog. The user don't
have to read the full text; the essentials are all in one bold sentence
at the top. And the button the user clicks is not a generic 'Yes'
button, as one so often finds in Windows.

Yes, it is a nicer dialog that your standard Windows Message Box;
and one of the keys to warnings being effective is that they must be
short; user's are *not* going to read war and peace in a dialog. :D

But I do not think the short, bolded message is going to convey
enough understanding of the problem to the user that he can
intelligently chose whether or not to continue.

This dialog violates a cardinal design principle (for most users): it
asks the user a question the user does not know how to answer.

Look, this is silly. The operating system itself cannot determine
through any plausible technical mechanism what software the user should
trust. This determination must rest with the user. Yes, it is a serious
a problem that many users don't know enough to make such determinations,
but it hardly seems useful to criticize Apple's approach, since, unless
someone invented artificial intelligence last night, there effectively
*is* no approach other than letting the user decide.

[snip]

The system can change its rules based on who is running the app. For
instance, it can find apps in, say, ~/Applications, which would allow
each user to install apps that they trusted, but those apps wouldn't be
automatically trusted when other users were logged in.

This is more sensible; but not all that helpful for Apple specifically,
since they sell consumer computers which do not usually have
a lot of users; if there's only one compromising that one is enough. :D

Still, this could be part of a compromise system that worked better
than the registry.

Bundles *in a specific place or places* are autodetected. The
central database is the Spotlight index which can be rebuilt if
corrupted (which is where this beats the registry).

You really need installers for this to work, since each bundle
must be deposited in the right place. But that's a good idea
anyway, and the registry requires this no less.

I don't see why you need installers for this. For any given software
package, the user would only have to drag one bundle to the correct
location, and instructions could be provided, as they often are now,
right in the window on the disk image containing the software.

There's no reason why the user would have to e.g. install an app in one
place, and a Spotlight plug-in in another, and an Input Manager in a
third. The system could trust Spotlight plug-ins and Input Managers that
resided in application bundles installed in trusted locations for
applications.

The drawback of this system is that it isn't compatible with
existing apps, program launchers, etc.

Microsoft designed their object model so that it would be easy
to retrofit to existing programs. They do not need to be moved
to any particular place, nor factored into libraries, or rewritten
in a particular language or to use a particular memory model.

It seems to me our clever compromise will not be compatible
with many popular apps. But I think it would work other than that.

The locations this system would trust are already the locations that
these sorts of files almost always get installed at, so compatibility
wouldn't be that much of an issue. It's true that if an app like
RealPlayer also had a browser plug-in in its application package that it
expected other browsers to discover through this mechanism, browsers
which hadn't been updated wouldn't find that plug-in. But this kind of
thing is a very rare case on the Mac platform.

I think Microsoft's solution works well (when it actually works): you
run an "installer" program and it registers the software in the
registry. This makes the decision to trust a given app explicit; the
mere fact that an app was included in a download does not mean the OS
will try to execute it.

So, running an installer (which could, of course, be installing
anything) makes the decision to trust an app explicit, but confirming
that you trust the app in a dialog that specifically warns about the
risks of untrusted code is... what? Not explicitly making a decision to
trust an app?

I don't buy it.

I think most users are not going to understand what they are being
asked by your warning. They are being asked to trust an
application- but which one?

The obvious answer is probably the wrong one. If they think they
are opening a Photoshop document, presumably it is *Photoshop*
they need to trust. But of course Mac OS X only asks if it *isn't*.

Huh? OS X explicitly tells the user which application is being launched
and offers an explanation of the security implications of running an app
that shouldn't be trusted.

The installer case is a little easier. The user just doubled clicked
"setup.exe" or "program.msi" or something. It is *that thing* they
are being asked to trust- the icon they just downloaded from
www.hackers-r-us.com.

And at no time does Windows explain to the user what the security
implications of running the software are.

[snip]

--
"Those who enter the country illegally violate the law."
-- George W. Bush in Tucson, Ariz., Nov. 28, 2005
.

Loading