Home

Feedback

Credits

About Raj

Security: Internet Introduction Security in General Privacy Integrity Usability Can I Use Cryptographic Software?

Usability

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?

On-System security

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 or passphrase.

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 to approve cookies. Some sites, refuse service if you refuse cookies. Others 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 refuse cookies, or always accept cookies by website. Some browsers refuse cookies by default, because they don't even recognize the request.

Nuisance Panels

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.

E-Mail compatibility

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:

• 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.