Re: ::scr Internet Explorer - Danger in numbers?

[Arvid Gidhagen <arvgi575@xxxxxxxxxxxxxx>]

> Not really.  Security needs to be designed in right from the start,
> but once it is, it need not get in the way of usability*.

Even if security is designed in from the start, the user must still
be aware that there is such a thing as security and how that security
works.

Two simple examples come from Windows 9x (ME, XP? haven't had any
hands-on experience with either) and Unix.

If you have a local TCP/IP network running Windows in which one of the
computers is connected to the Internet and acts as a proxy server
for the rest of the network and wish to make parts of it accessible
from within the local network, you simply "share a folder". But in
doing so, it actually gets shared with the entire world. Nothing in
Windows tells you that all sorts of strange people can access it.
And to set a Scope ID in Windows 9x, you have to hack the registry.
This is of course due to the scope-clobbering mentioned earlier.
You could easily argue that this is an example of security not being
designed in from the start, but bear with me for a while.

The Unix example is more insidious and comes from my university.
When students begin their education and get their own accounts, they
all take an introductory course. And during this introductory
course, students learn all about why Unix is so nice and secure
with its accounts and logins and file modes. But what people don't
learn is that the default security for files is set so that
everyone else can read them provided that they know the exact
file names. This is due to two things:

1) It can be practical to have the default security set like this,
   provided that you are aware of it and know how to change it

2) Sysadmins and SOME teachers know about 1) and take it for granted,
   but new Unix-naive students don't.

This is mentioned in the various introductory primers, but in
such a way that people who don't understand Unix yet won't
understand any of it. They are struggling just to edit text in
Emacs or grasp what a process is or managing to print out
files. Besides, it doesn't say explicitly anywhere that I've seen
"WARNING! With the default file security on, all other students
can read your files provided that they know the exact filename."
So it's really no better than the missing scope ID in Windows.


I would argue that in both of the above cases, whatever security 
there is fails because of three things: 

i) unawareness among users that security features exist and why
   they are needed

ii) low usability with regards to security (and in other ways)

iii) assumption from system designers and admins that users
     ARE aware of security issues


Somehow, iii) leads the designers and admins to turn off a lot
of security as default. Seems like a bad idea no matter how
well-educated the users are, as people have a tendency to forget
little things sometimes. It's easy to fix everything EXCEPT that
tiny little hole... just because you were distracted by something
else, like a rumbling stomach or whatever.

As far as ii) goes, Unix IS an archaic command-line based
interface and it IS hard for newbies to learn. CDE, which is
the default window manager at the univeristy, does show
security information in its file manager (or at least I think so,
I don't use CDE) and makes it slightly easier to change modes
than chmod, but doesn't in any way indicate that it might be
important. And the only built-in sources of info are extremely
terse man pages.

When it comes to Windows, the ScopeID thing is just plain
idiocy, but all security issues in Windows are troubled by the
fact that Windows cries wolf all the time. Windows warns you
about everything all the time, eventually teaching users that
all these warnings can safely be ignored. Poor usability in
a nutshell.

Point i) is still the most important one, I think. Computers
are not intuitive and cannot be completely intuitive if they are
to be useful, flexible, powerful tools. Some things you just have
to learn. Which means someone has to teach these things.

Forcing functions can be nice (like requiring users to login),
but it only works as far as people use passwords that are hard
to crack. The human is always the weakest link in this chain -
average users, lazy sysadmins (like the ones at Jönköping
"university", where I have a friend - they refuse to switch from
Telnet to SSH because "it's too much work to learn new things")
and whatever else.

I think the Jönköping problem is illustrative - learning new
things takes time and work. So someone has to motivate and teach
people why and how to use security properly. Better usability
works with security, not against it, because it makes it easier
to learn and use security features. But it is never enough on its
own.

- Arvid