Assistant program?

John Richard Moser nigelenki at comcast.net
Mon Aug 22 19:54:28 UTC 2005


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

ugh this mail is ugly, how much of my reply is redundant. . .

It looks like we're pretty much 'arguing' the same side of the same
issue, let's try doing something useful?  :)

Matthew Paul Thomas wrote:
> On 21 Aug, 2005, at 2:50 PM, John Richard Moser wrote:
> 
>>> ...
>>> Matthew Paul Thomas wrote:
>>>
>>>>
>>>> On 20 Aug, 2005, at 12:55 AM, John Richard Moser wrote:
>>>
>>> ...
>>>
>>>>>> The basic idea is to give applications an interface to a daemon to
>>>>>> have it supply assistive support to new users; primary function of
>>>>>> course is to deliver security concerns.
>>>>
>>>>
>>>> I don't understand the "of course" part. The help system in the Grand
>>>> Theft Auto games is an excellent example of the kind of just-in-time
>>>> help you are talking about, but its prompts aren't "security concerns"
>>>> (at least, not in the sense of computer security).
>>>
>>>
>>> Ideally your apps are easy to use anyway;
> 
> 
> Usability is not a single axis, and after a certain point, making
> something more learnable for beginners makes it less efficient for
> experts. Very little software ever reaches that point (which is probably
> why many usability people handwave over the conflict), but that's why
> even with optimally usable software you'll still need a help function.
> Just-in-time proactive advice would work better than passive help, and
> that's true for all kinds of help, not just security. ('Using a table
> works better than lining up text with spaces. To make a table, choose
> "Table" from the "Insert" menu.')
> 

Agreed.  But users hate proactive help; security is -important-
(remember "hot topics" include identity theft, viruses, _spyware_, and
spam these days; most of that is a security issue) and the user has to
be convinced that the assistant is there to help, rather than to mimic
Clippy and just piss people off with useless junk.  Thus, start small.

It will eventually be more useful if it works, I'm sure.  :)

>>> the user is still going to blatantly ignore the "New updates are
>>> available" bubble because he doesn't care,
> 
> 
> Using a bubble for that would be poor design, because the easiest path
> would be to ignore it. A better design would be to immediately present
> the list of updates in an a dialog (hence, no close button), so that the
> easiest path is to bonk the "Install Updates" button.
> 
>>> he's still going to ignore the "SUID binaries being installed" warning
>>> in Autopackage (if autopackage ever implements such a warning),
> 
> 
> I've helped redesign Autopackage alerts to be more understandable, but I
> can't redesign those that don't exist yet. :-)
> 

Yeah.  That one doesn't exist yet because installing a .package gives it
full access to all everything.  It was proposed to wrap that in an
SELinux policy; but I have no idea how to write SELinux policies.  I did
come up with a few basic rules, of course. Remember that Autopackage
should run the .package; if you execute the .package, all bets are off.
 We can't policy it reliably.

 - Autopackage gets a role sys_autopackage_r
 - sys_autopackage_r has full system access (it unfortunately needs it)
 - Autopackage runs a command that interprets prepare and install
scripts; this command gets sys_autopackager_r (autopackageRestricted)
 - sys_autopackager_r has full access only to a certain directory under /tmp
 - All other areas of the system are non-writable in sys_autopackager_r
 - The sys_autopackager_r role gets read permission only by the
world-readable permission; user and group permissions are considered 0
 - The sys_autopackager_r role can only signal or otherwise communicate
with and see other tasks in the sys_autopackager_r role
 - Autopackage itself makes note of the changes
 - Autopackage at this point can warn the user if SUID files exist, etc
 - Autopackage merges the changes to the system
 - Autopackage can later undo the changes without external scripts

Of course I can't implement this until I learn selinux policies; and
even then, changes to the autopackage API may be in order.  Heh.  Then
again the policy would become part of the API. . . .

Anyway, again more theory, and this is offtopic junk.  :)

>>> he's still going to rabidly download and install whatever regardless
>>> of the dangers, and thus his system will quickly become a riddled hell
>>> of spyware and viruses.
> 
> 
> Similarly, providing lots of text saying "Please don't" would be poor
> design. It would have about as much effect as the Boulder Pledge has had
> on spam.
> 

Provide very little text, at as few points as possible.  :)  Also, take
a step back and think about what you're saying.  The user might ignore
the thing right?  Why?  Because he doesn't know and doesn't care?  This
looks strangely like a marketting issue. . . .

>>> ...
>>> In the end I recognized that no matter how much PaX or SELinux I throw
>>> at something, until I start getting in the end user's way, he's still
>>> going to be able to break his system by installing viruses and spyware
>>> and other setuid trojan crap without remorse.  I realized that a few
>>> simple concepts need to be explained; but "dumping" that on the user
>>> would result in blatant ignorance.  To that end, I came up with simply
>>> inlining the information just-in-time to pass the user critical,
>>> need-to-know data.
> 
> 
> Which, again, is an excellent idea, and not just for security.
> 

Of course, I know it's an excellent idea beyond security.  Security is
my main focus; but I'm the type that takes something that's good one
place and makes it robust enough to work everywhere.  Particularly, my
end goal with most of the personal endeavors I take is to create a high
security desktop distribution for the average user (combine what MacOSX
is seen as by its userbase with what OpenBSD is seen as by its
userbase).  The entire 'assistant' idea was only considered as more than
a joke because it's the only real way to help with the problem of the
end user still being able to undermine the security of the system (worms
and spyware love social engineering).

Users aren't going to read a manual or survival guide or 2 page essay
that dumps information ambiguously at them to tell them how to run their
system.  There's certain things that are dangerous to do unless you can
make an informed risk assessment; it's a little more than "just tell
them in the manual."  Hence, I'm after my ideal situation being that
initial settings are to show security class information on all levels,
and have the system designed to cause as little a need for that as possible.

At the same time, of course, the delivery system is useful for other
things; these shouldn't all be bundled together, but rather separated
and sorted so that the assistant can be tuned up or down.  Most users
don't even WANT the computer to give them any help; that's why even if
you're hard-up for having the assistant deliver actual usage assistance,
you still have to start with just bare-minimum all-important
need-to-know information.  Get them used to the water and they'll climb
into the pool on their own; throw them in and they'll jump straight out
because it's COLD!

As for security and uninformed decisions, look at e-mail.  People won't
open .zip files, pictures, or even .txt files attached to e-mail.  Why?
 Because "any file attached may cause a virus and openning the email at
all runs the virus."  They won't read the e-mail because "it'll run a
virus," they just delete it -- nevermind that this involves selecting
and thus automatically opening the e-mail anyway (if you're gonna get
infected as you say, then you just did).  Overreaction because the user
can't make an informed decision.

Now look at the other side.  Users go to any geocities web site,
download any random .exe file, and run it; it won't have a virus,
because it's not in e-mail.  They'll auto-install any ActiveX control or
plug-in the site tries to download; if IE blocks it, they click the info
bar and say "allow."

IE pretends to help with this threat with an ineffective message for
ActiveX controls:

("Internet Explorer has blocked an ActiveX control from being installed.
 Click here for options." options include "install" and no further
explaination.)

A better explaination for such a scenario, potentially tied to Firefox
extensions:

("Firefox has blocked automatic software installation.  The software
/may/ contain viruses or other malware; however, if you trust the site,
you may allow the software to be installed.")


>>> ...
>>>
>>>>>> A better assistant would give multiple classes and levels of
>>>>>> information, allowing the user to essentially set the verbosity of
>>>>>> the assistant in a fine-grained manner.
>>>>
>>>>
>>>> I disagree. The usual answer to "How much help do you want?" would be
>>>> "How am I supposed to know, I haven't tried doing anything yet".
>>>
>>>
>>> And the usual answer to "it looks like you're writing a letter, would
>>> you like help?" would be "NO FUCKING GO AWAY."  Not always, but often.
> 
> 
> Yes, that's an example of what I'm talking about: Clippy give you no
> information on which to base your decision, so it was a useless question.
> 

A lot of what clippy gives you is useless.

>>> ...
>>>
>>>> Saying "Please read this introduction carefully" will not protect you
>>>> from the relentless human intolerance for text that is Getting In
>>>> Their Way. Fortunately, that whole intro is unnecessary.
>>>
>>>
>>> Fail.  Introduction to the assistant is critical; although it could be
>>> shorter, I hope.  Luke Swartz' paper, "Why People Hate the Paperclip,"
>>> confirms this assumption.
>>> ...
> 
> 
> An introduction to what? You're trying to introduce a "thing" that's
> presenting the assistance. If the assistance has zero interface outside
> itself -- for example, if it consists of sentences in translucent
> bubbles in the corner of the screen -- such an introduction is unnecessary.
>                              ________________________________________
>                             |                                        |
>                             | Unencrypted e-mail like this can be    |
>                             | read by eavesdroppers. To protect your |
>                             | mail, go to "Security" in Preferences. |
>                             |________________________________________|

Some people actually found the letter-writing thing in the MS Office
Assistant helpful.  Most people didn't.  There needs to be a level of
control over it.

Also I may not want bubbles just popping up on my screen.  A little 32
pixel circle flying around is annoying enough; and it better be
important.  If it keeps throwing unimportant crap at me I'm gonna turn
it off.

> 
> -- Matthew Thomas
> http://mpt.net.nz/

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDCi1yhDd4aOud5P8RAmpkAKCD0h7mHEzDJ/uOZT6UV/feajMezQCaAt/t
Y8paSZzToQLFb/PEMwiLShg=
=eRkr
-----END PGP SIGNATURE-----




More information about the ubuntu-users mailing list