Computer Security Primer-The Internet:
Usability is a term that can have many related meanings. Because the primary
reason for this text is to explain things to help you use the Internet, this
portion will use a much narrowed meaning. Also, somewhat unlike that which
preceeds, this section raises many questions you can answer for yourself.
These questions are intended to get you to think about your own use.
With the considerations above, is it important to you where your data is stored?
Is it important for you to know when you are accessing a distant web
page, and when you are using a program confined to the computer which is
directly attached to your keyboard? When you are asked for a password, or
passphrase, is it important for you to know what program is asking, and where
that program is located?
Just as you are required to identify yourself when you log onto the net, with
a username and password (which might be stored or created each time,
and entered automatically), does your system insure that it is you, before
it gives you access to your data files and programs? Does it require some
special and exceptional authorization to install or modify the software, or
can it install or run software, without special authorization, from the net?
If you walk away, from the computer without logging out, can someone change
your entire system? Or is there some special access needed to actually
change system settings and software installed?
Interestingly, systems that do require this additional authorization
for modification of basic software and settings are generally considered
completely immune to viruses, even without any special software to check for
them. That is an overstatement. They are not 100% immune because it is still
possible for that special authorization to be given when software is installed
that is infected. Yet, when it is run, it cannot spread, unless when it is
run, that authorization is also given. This special authority is normally
called ``system administrator'' access, as opposed to ``user access''. Systems
even with only one user, which still discriminate in this way, and which
make the use of that ``administrator'' access easy, are inherently more secure,
because of it. The tradeoff? Usually you need to remember a second password
Across the Net
We saw cryptography mentioned many times above, and hopefully it has become
clear that it can be an important part of your computer use. This is especially
true because some of the best available tools are free or at worst, at low cost.
Yet, also we must consider the usability of it as a tradeoff for the security it
provides. It can be quite irritating to enter a good passphrase time after time
to accomplish a task, but unsafe to not do it. Again, you must decide what
needs protection, and how much protection. You must decide the dangers of
leaving software running that stores a password or passphrase, or read good
analyses of that software. It is NEVER safe to leave passwords
and passphrases sitting on disk between times you run a program, including
that for connecting to the internet.
But, we mentioned above the differences in http and https, but
at that point did not mention that various websites also use little bits of
data stored on your hard drive called cookies to attempt to keep track
of when it is you. Those cookies are open and usually automatically
sent back (once approved), for anyone using the same browser for the
same login to the computer on which the browser actually runs (your computer).
The security-usability question here is whether you ever want
are able to provide conveniences to you when you approve cookies. Others
develop information about your habits, and may eventually tie back to full
identification of you, when you approve cookies.
Some people just approve all cookies, telling their browser to always accept, to
get rid of the popup every time cookies are requested. Others refuse all
cookies, also to get rid of that popup, but accepting that some sites will
be unfriendly, and even refuse service when the cookies are refused.
Others go on manually deciding each time. Again, it is your decision
which of these options to take. A few browsers allow you to always
cookies by default, because they don't even recognize the request.
Have you ever closed one window at a website only to have one or more open
automatically? This is not a malfunction of your browser. It is deliberately
placed in the code of the original page. This can even crash some machines
as you battle futilly to close windows as fast as they open. When two or
more open for every close, make a note to not ever visit that site
again. You are being attacked electronically, and specifically it is called
a ``denial of service'' attack.
This part of usability can only be touched upon in this brief space. While
it certainly concerns the usability of your computer and internet
services, not all of the information about E-Mail compatibility directly
is a security issue. Yet, some of that compatibility issue does affect both
usability and integrity of your data.
Originally, E-Mail was restricted to US-ASCII (the upper- and lowercase
26 letters of the American alphabet, plus a few symbols and the ten
digits 0-9). As time progressed, various encodings were added to
allow binary data files, and software to also be transferred as part
of an E-Mail message. Today there is one universal open data format
standard for E-Mail messages. This is called MIME - an acronym
for Multipurpose Internet Mail Extensions.
Anyone with an E-Mail account on any kind of machine can be expected, today,
to be able to receive that original form of E-Mail, and your E-mail software
should be able to produce it. That is plain-text (or text/plain) with
US-ASCII encoding. This includes programs which receive mail, perhaps to
respond with an automated answer. This also includes most special
E-Mail-to-Fax and E-Mail-to-Pager facilities.
The irony is that in order to add convenience, many software designers
have added incompatibilities when you send mail, the main purpose of
which (the mail) is to communicate with someone on another computer. Some
software may embed program references that are only usable on a very similar
system (e.g. OLE). Others may produce almost word-processed bolding, and
similar features by sending the text in the same format as a web page (HTML).
Neither of these features is intrinsically bad. But both make your usability
ironically more complex, even as they attempt to make it easier or nicer.
If your correspondant cannot properly read the mail you send, your message
may even be perceived as the opposite of what you intend. Some
simple rules will help streamline your usability:
There are FAQs and Newsgroups or mailing-lists dedicated to most E-Mail software
in use. You should be able to find the answers to questions about your specific
E-mail software in those locations.
- Never send attachments without first confirming that your correspondant
can receive them properly. That includes the overall size of message
that the correspondant can receive. Some E-mail programs, and some
services are not at all friendly to attachments.
Never send large messages (over 40-50k plain text) before confirming
that your correspondant can receive them. Some systems automatically
cut off a message and only pass the first part (truncate). Others
may just refuse or discard messages which are too large.
Never use a non-general format with a correspondant who uses a different
E-mail program. E.g. If you both use Netscape 4 for E-Mail, both
can handle HTMLized mail. If you both use a Microsoft MIME-OLE, then
you both should be able to use the same extensions, if you
both happen to have the same software installed. But, if you send
a message with embedded OLE, to someone using XFMail, it is unlikely
that your message will arrive in the way you wish it to. If you
send HTML to someone using Pine, they must try to pick from between
the markup, or save the message and find it with a browser to read it.
Realize that not everyone uses the same E-mail program at all times. Just
because you received a message with a disposition notification request
from someone using Eudora, does not mean that they will necessarily use
that same Eudora to read your response.
Be sure that your program uses a character-set that is common PLUS
fits the language you are using. There are many references on the
internet that give detailed examples for each commonly used language.
Most importantly, insure that your software properly IDENTIFIES the encoding
used, if it is not US-ASCII. Also be sure that your software
properly checks such identifications before assuming that what you
received was what was sent, even if it was not modified enroute.
Be sure that you and your correspondant use the same encryption program, and
that the encryption is strong enough to give the protection you expect.
Some E-Mail programs, and even word processors, have weak encryption
as a built-in option. Some have strong encryption available, sometimes by
using the services of another program.
If using public key encryption be sure to use different channels
to exchange verification of keys before counting upon the validity of those
keys. This will become clear as you examine the documentation for the
specific software, such as PGP. It is an important step in insuring that
the software is usable for its best advantage.