WebNet98 Paper Submission

Paper For WebNet 98

Insight Through Experience:
Hands-on Internet Experiments for Non-CS Majors

David Arnow and Chaya Gurwitz
Department of Computer and Information Science
Brooklyn College, CUNY
{arnow,gurwitz}@sci.brooklyn.cuny.edu

ABSTRACT

We describe a series of lab exercises developed for an Internet course targeted at non-Computer Science majors. These hands-on experiments were designed as a means of providing concrete examples of how the Internet works. Our goal is that students should not merely acquire the skills to make effective use of the Internet, but should gain an understanding of the underlying concepts and principles.

INTRODUCTION

Recognizing that email and the web are essential tools for all college students, many colleges have introduced courses on the Internet for the general student. In developing a college-level course on the Internet, we are wary of designing a course that is narrowly focused on teaching skills. Rather than merely teaching our students how to use the Internet, our goal is to provide a conceptual understanding of the way the Internet works.

Students can more easily learn "how to" and "what" when they understand how and why these techniques work. Computer science in general, and the Internet in particular, is a rapidly changing field. The state-of-the-art tools of today are likely to become obsolete in the near future. Students who understand the principles involved will be better prepared to use new software as the technology evolves.

It is our responsibility to prepare our students to be informed citizens in a technological society. Social and ethical issues relating to the Internet cannot be fully addressed without a true understanding of the underlying technology. For example, a student who understands the way email software works can appreciate the ease with which email can be forged or tampered with. This student will be better prepared to analyze controversies regarding wiretapping and encryption.

Non-Computer Science majors require very concrete demonstrations and hands-on experience in order to understand concepts and principles. These students generally have had little computer experience, and have not developed the abstraction skills that Computer Science majors acquire through their program of study.

In this paper we describe a series of hands-on exercises that we developed to provide insight into how the Internet works. The experiments afford the students the opportunity to experience the way various protocols and software interact, transforming students from passive listeners to active explorers.

BACKGROUND AND CONTEXT

Brooklyn College is one of the five senior colleges of the City University of New York. The college has an undergraduate enrollment of about 10,000 students. The student body is diverse and reflects the City's many ethnic groups and socio-economic classes.

Our course, CIS 3, The Internet, is a two-hour lecture/ two-hour lab, three-credit course aimed at non-Computer Science majors. In fact, students who have completed two courses in the Computer Science major sequence are barred from the course. Although students registered for this course are not expected to be computer-savvy, they are required to have completed the College's required Math/Computer Science core course. This prerequisite guarantees that all students in the class will have had at least a half-semester of computer literacy.

The course goes beyond the Internet-based Math/Computer literacy course described by Gurwitz [4]. The course shares a treatment of HTML [3] and JavaScript [7] with that described by Mercuri et al [6], but does not go as far in programming, opting instead to include forms, network concepts, ethics and the labs we describe below.

In developing the course, we were disappointed that we could not find a textbook that would serve our approach. We found that texts on the Internet tend to fall into two categories: highly technical books suitable for Computer Science majors, and very light "cookbook"-style texts targeted at non-CS majors.

Two notable exceptions are the books by Comer [2] and Lehnert [5]. Comer's book provides a non-technical explanation of the way the Internet works, but is lacking in terms of providing direction for further exploration. Lehnert's book (which we have adopted as the course text) is an excellent "how-to" book which includes many references and suggestions for hands-on learning.

Although Lehnert's book contains suggestions for many online exercises, these exercises are for the most part skills-based. For example, typical hands-on exercises are a Web scavenger hunt and design of a home page. These types of exercises should certainly be included in a course such as ours. However, our aim is to go beyond skills-based exercises and develop experiments that can provide insight into the nature of the Internet.

OUR ENVIRONMENT

Brooklyn College has a campus LAN that connects a variety of PC labs and classrooms, Mac labs and classrooms, and Sun labs to each other and the Internet. All students received Unix accounts in one of the Sun labs for this course. Because these were non-majors, an extremely minimal but relatively gentle environment was created for them, one that allowed them to create, edit and manage files-- mostly so they could create web pages-- and have experience with the standard Unix mail client.

From the perspective of the lab modules that are described below, the most important tool that the students had access to was telnet. The telnet tool was used by students to access their accounts from anywhere on campus. More significantly however, telnet can be used to open any TCP connection with a TCP server. The telnet user controls this by specifying the appropriate port number for the server to be contacted. Thus telnet machine 25 contacts an SMTP server at machine whereas telnet machine 80 contacts an HTTP server at machine.

FIVE INSIGHTFUL EXPERIENCES

(1) Experiencing IP: The traceroute experiment. At the heart of the Internet is IP, the protocol that among other services creates a virtual network that provides the illusion of direct point-to-point connectivity. Most of the time we are better off operating under that illusion. However, to comprehend the Internet, appreciate its achievement, understand the nature of slowdowns, and recognize the complexity of certain social, legal and ethical issues, the illusion must occasionally be dropped. There is no better way of doing this in a concrete fashion than using the traceroute facility.

The traceroute ("tracert" in DOS) utility displays the path that a packet takes from the executing machine to a given IP address. Each hop (i.e. router) is shown along with additional timing information. An typical example of output is:

     traceroute to www.aace.org (205.197.102.18), 30 hops max, 40 byte packets
      1  default (146.245.1.90)  0 ms  0 ms  0 ms
      2  146.245.3.9 (146.245.3.9)  2 ms  2 ms  2 ms
      3  bcgate1.brooklyn.cuny.edu (146.245.2.100)  3 ms  3 ms  3 ms
      4  146.245.41.2 (146.245.41.2)  106 ms  13 ms  79 ms
      5  sprint-gw.cuny.edu (128.228.254.1)  9 ms  8 ms  7 ms
	...
      9  sl-bb6-pen-6-0-0.sprintlink.net (144.228.60.21)  11 ms  21 ms  12 ms
     10  core4-hssi5-0.WestOrange.mci.net (206.157.77.105)  19 ms  40 ms  16 ms
     11  bordercore4.Greensboro.mci.net (166.48.120.1)  37 ms  47 ms  49 ms
     12  * * cornerstone-networks.Greensboro.mci.net (166.48.120.22)  94 ms
     13  nibbles.cstone.net (205.197.102.18)  139 ms  94 ms *

The output reveals the unseen part of the Internet, exposing an institutional complexity and technical virtuosity rarely appreciated by most users. Repeated use of traceroute reveals the dynamic character of the net, as timings and even routes change.

Following a demonstration of traceroute in the lab, students are invited to trace routes to their favorite web sites and note the differences. Although this demonstration/experience did make a big impression, we went further. We assigned our students the task of deducing as much as they could about the campus LAN topology by going from one lab or office (with permission) on campus to another, tracing internal routes.

This assignment was in one sense a failure: in many labs and offices, traceroute was unavailable; as a result, there were not enough obtainable routes to deduce the campus LAN technology. However, some deductions could be made and the better students greeted this task with enthusiasm and increased intuition about IP and routing. In the future, we plan to arrange for a greater number of points from which to do traceroute.

(2) Experiencing client-hood: playing the role of an email client. If the Internet's heart is IP, then its soul is client-server computing. As casual users of the net, our students are frequently working with client software. Often they are aware of the existence of servers (thanks to messages informing them that the server is down or refusing their request). However, they have little sense of the nature of client-server computing and are only dimly aware of the distinction between different kinds of servers. Part of the goal of this lab module and the next is to correct this.

We start by showing students a live session of sending mail on a Unix system, with the -v switch turned on. What they see is something like:

     louis (1) > mail -v arnow@its.brooklyn.cuny.edu
     Subject: show off SMTP
     here is the message
     EOT
     louis (1) > arnow@its.brooklyn.cuny.edu... Connecting to atrium61.its.brooklyn.cuny.edu. via esmtp...
     220 atrium61.its.brooklyn.cuny.edu ESMTP Sendmail 8.8.8/8.8.6; Tue, 3 Mar 1998 22:53:23 -0500 (EST)
     >>> EHLO sci.brooklyn.cuny.edu
     250-atrium61.its.brooklyn.cuny.edu Hello louis [146.245.1.7], pleased to meet you
     250-8BITMIME
     ...  additional lines from SMTP server displayed here
     250 HELP
     >>> MAIL From:<arnow@sci.brooklyn.cuny.edu> SIZE=95
     250 <arnow@sci.brooklyn.cuny.edu>... Sender ok
     >>> RCPT To:<arnow@its.brooklyn.cuny.edu>
     250 <arnow@its.brooklyn.cuny.edu>... Recipient ok
     >>> DATA
     354 Enter mail, end with "." on a line by itself
     >>> .
     250 WAA07101 Message accepted for delivery
     arnow@its.brooklyn.cuny.edu... Sent (WAA07101 Message accepted for delivery)
     Closing connection to atrium61.its.brooklyn.cuny.edu.
     >>> QUIT
     221 atrium61.its.brooklyn.cuny.edu closing connection
     louis (1) >

What we see after the message is sent is the client reporting its TCP connection to the appropriate mail server and a transcript of its dialog -- using the SMTP protocol -- with that server. We provide a hardcopy of this to the students, clearly indicating the client's lines (boldface above). In the context of this demonstration we discuss the nature of client-server computing, protocol in general, and SMTP in particular.

Again, the key to reaching students is not to leave the topic with a demonstration but to give them hands-on experience. In this lab, they are to use telnet (on DOS or Unix) to contact the machine with the mail-server for the class on port number 25 and engage it in a client-server exchange. They are to use SMTP as a language with the goal of sending themselves email.

The second part of the lab is to recognize the possibility of sending faked email. Their task is to send mail to their instructor so that the header appears to come from their favorite fictional character or celebrity but with their own name in the message body so that they can get credit. As they work on this, the instructor's mail headers are continuously displayed on the overhead monitors and soon mail from the likes of BugsBunny from CartoonLand.org starts to appear.

The fake email lab provides a natural setting for a discussion on ethics in cyberspace [1]. It also generates a good deal of healthy skepticism on the part of the student regarding the automatic authenticity of Internet information.

(3) Experiencing client-hood: playing the role of a web client. In this exercise, students used telnet to establish a connection to HTTP servers. The protocol they used was much simpler than SMTP. They just had to send a line starting with "GET", a path specifying the resource, and the version of HTTP, all followed by a blank line. A typical interaction (student typing shown in bold) was

     atrium15> telnet 146.245.2.68 80
     Trying 146.245.2.68...
     Connected to 146.245.2.68.
     Escape character is '^]'.
     GET /~arnow/index.html HTTP/1.0
     
     HTTP/1.1 200 OK
     Date: Tue, 03 Mar 1998 17:21:48 GMT
     Server: Apache/1.2.5
     Last-Modified: Mon, 13 Oct 1997 01:18:38 GMT
     Content-Length: 1698
     Accept-Ranges: bytes
     Connection: close
     Content-Type: text/html
     
     <HTML>
     <HEAD>
     <TITLE>David Arnow's Home Page</TITLE>
     </HEAD>
     <BODY>
             <H1>David Arnow's Home Page</H1>
     </BODY>
     </HTML>
     Connection closed by foreign host.

This experience continues to highlight the control-information/data-content duality of network communication and reveals a different kind of client-server relationship than the one they experienced exploring SMTP. Applying this to a web page that contains multiple images demonstrates another point that benefits from concrete experience: each web page displayed typically requires multiple repeated connections and HTTP interchanges. After this lab, the flurry of status bar messages seen in browsers became more understandable.

To enhance the lab experience, we arranged for the large overhead monitors to continuously display the last 20 lines of the access log file that the HTTP server maintained. As the various student web clients made contact, their information was displayed. We had earlier discussed the fact that an HTTP server may maintain access, referrer and error logs and had actually examined these files. However, the students were startled to see their own web activities instantly displayed on the monitor of a different machine. Novices apparently do not fully grasp the distributed character of the net without concrete demonstrations like this-- mere use of a web browser is too much like any other desktop computing experience.

In addition, students were intrigued by the "Big Brother" aspects of this. Again, we believe that although they all knew "in principle" that their web activities could be recorded in part, this aspect of web use isn't appreciated until they directly experience it for themselves.

(4) Experiencing encryption: using Pretty Good Privacy encryption software. Students who have completed a lab in which they sent fake email are eager to learn how safeguard against such forgeries. In this lab exercise, we illustrate the use of PGP (Pretty Good Privacy) software, which provides an implementation of double-key cryptography.

The first part of the lab is to have each student generate a key pair. When a key is to be generated, the user is offered a choice of security levels - low grade, high grade, and "military" grade. We ask different students to select different choices. The students requesting the higher security levels find that it takes more time for their keys to be generated than for the lower grade keys. This provides a concrete example of the tradeoff between tight security and fast execution time.

The second step is to have the students clear sign a text file with their private key, and verify the signature. Then we ask the students to edit the file slightly - perhaps change only one word of the text - and then attempt to verify the signature of the tampered file. A sample session is shown below:

	atrium46> pgp -sat +clearsig=on testmessage
	Pretty Good Privacy(tm) 2.6.2 - Public key encryption for the masses.
	(c) 1990-1994 Philip Zimmerman, Phil's Pretty Good Software. 11 Oct 94 
	Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
	Distributed by the Massachusetts Institute of Technology.  Export of 
	this software may be restricted by the U.S. government.  
	Current time: 1998/03/04 06:08 GMT

	A secret key is required to make a signature. 
	You specified no user ID to select your secret key,
	so the default user ID and key will be the most recently
	added key on your secret keyring.

	You need a pass phrase to unlock your RSA secret key. 
	Key for user ID "Chaya Gurwitz <gurwitz@sci.brooklyn.cuny.edu>"

	Enter pass phrase: Pass phrase is good.  
	Key for user ID "Chaya Gurwitz <gurwitz@sci.brooklyn.cuny.edu>"
	1024-bit key, Key ID F8AAB131, created 1998/02/25
	Just a moment....
	Clear signature file: testmessage.asc

	atrium46> more testmessage.asc
	-----BEGIN PGP SIGNED MESSAGE-----


	This is a test of PGP software.


	-----BEGIN PGP SIGNATURE-----
	Version: 2.6.2

	iQCVAwUBNPzufbemED34qrExAQGkTwP/XU/KowN/bzb3MvfjGzCRdxNeCjLhsdgy
	5KgUg/2gIZyzOn8oaJgKfx+dMaKagNvlQaY+CHBvRwfnhkAUoq0SiqD2gBdkDxRB
	m/m3K0/h+RyXYTjqL5dgBkismpPL9v0cPhfB/Xi4ONF7JthfaU9Auwome+17BP0r
	4eEhjj1rRWY= 
	=c0Ks
	-----END PGP SIGNATURE-----

	atrium46> pgp testmessage.asc

	... Copyright notice displayed here 
	File has signature.  Public key is required to check signature. .
	Good signature from user "Chaya Gurwitz <gurwitz@sci.brooklyn.cuny.edu>".
	Signature made 1998/03/04 06:03 GMT

	Plaintext filename: testmessage
	Output file 'testmessage' already exists.  Overwrite (y/N)? y 

	atrium46> vi testmessage.asc
	atrium46> more testmessage.asc
	-----BEGIN PGP SIGNED MESSAGE-----


	This isn't a test of PGP software.


	-----BEGIN PGP SIGNATURE-----
	...  PGP signature displayed here
	-----END PGP SIGNATURE-----

	atrium46> pgp testmessage.asc
	... Copyright notice displayed here 
	File has signature.  Public key is required to check signature. .
	WARNING: Bad signature, doesn't match file contents!

	Bad signature from user "Chaya Gurwitz <gurwitz@sci.brooklyn.cuny.edu>".
	Signature made 1998/03/04 06:03 GMT

A naive user might be amazed when the verification fails -- after all, he may realize that he wouldn't have been able to detect the change on his own!

The final step involves verifying email coming from the instructor. We post our public key and have the students add that key to their virtual key ring. Then we send a series of email messages, some authentic and some not, and have the students determine which messages are legitimate.

The PGP lab naturally ties in to a discussion of the controversy over digital wiretapping and attempts by the government to limit the use of cryptography [1]. These issues relate to the broader conflict between individuals' rights to privacy and government's need for access to privileged information.

(5) Experiencing Cookies. Whether because of their whimsical name or the discomfort of having external entities modify one's computer, students and Internet users in general have a fascination with cookies. In this module, we leveraged the work the class did with forms and JavaScript so that each student could set cookies and then discover the cookies their machine was providing.

Setting cookies is easy in JavaScript. It simply is a matter of assigning a long string to document.cookie:

     <SCRIPT LANGUAGE=JAVASCRIPT>
     <!--
        document.cookie = "food=junk; domain=acc6.its.brooklyn.cuny.edu; \
                           path=/~arnow; expires=Wednesday, 23-Dec-98 00:00:00 GMT; "
     // -->
     </SCRIPT>

The string consists of a name-value pair which is the content of the cookie, an expiration date, and two fields, domain and path, that control which web pages can receive the cookie. No web page outside the indicated domain will get the cookie. Furthermore, the string following "path", in this case "/~arnow" prevents any web page whose path does not start with "/~arnow" from receiving the cookie. Thus, in the case above, only web pages on the server acc6.its.brooklyn.cuny.edu and within user arnow's web pages will receive the "food=junk" cookie.

Reading cookies in JavaScript is complicated and beyond the scope of the class. Reading cookies is easy in CGI, but the students were not allowed to write server-side scripts. We therefore provided a simple CGI script that students could reference in the ACTION field of a form as a means to discover the cookies their browser is sending:

     #! /bin/sh
     # showcookie CGI script
     echo "Content-type: text/html" 
     echo
     echo "cookies received = $HTTP_COOKIE"

Students could include a minimal form in a web page to activate this script with a submit button:

     <FORM ACTION="http://acc6.its.brooklyn.cuny.edu:/cgi-bin/showcookie" METHOD="POST">
          <INPUT TYPE="submit">
     </FORM>

With this apparatus in place, the fun and the insight begins. The key point for the student to see is that the domain and path fields control the circumstances under which the cookie is sent back. Changing path to "/~studentA" prevents the cookie from being sent when the web page belongs to studentB. Students readily could verify this by accessing each other's showcookie pages.

Unlike the other exercises, this exercise demonstrated that there is "less than meets the eye". Still, this kind of demystification is almost as necessary as the four ones above-- and is very much appreciated by at least some of the students.

SUMMARY/CONCLUSION

The experiments described here are easy to incorporate into an Internet course. Our experience has been that students are intrigued by these labs and find them the most interesting part of the course. The hands-on activities enhance their absorption of the lecture material. We feel that these experiments illuminate some of the inner workings of the Internet and that our students gain a firmer understanding of the Internet than they would from either a purely skills-oriented course or even an Internet-programming (e.g. JavaScript) course.

BIBLOGRAPHY

Baase, Sara., A Gift of Fire, Prentice-Hall, 1997.
Comer, Douglas E., The Internet: Everything you need to know about computer networking and how the Internet works, Second edition, Prentice-Hall, 1997.
Flanagan, David, JavaScript: The Definitive Guide, Second edition, O'Reilly Associates, 1997.
Gurwitz, Chaya, The Internet as a Motivating Theme in a Math/Computer Core Course for Nonmajors, Proceedings of the Twenty-ninth Technical Symposium on Computer Science Education, February 1997.
Lehnert, Wendy, Internet 101: A Beginner's Guide to the Internet and the World Wide Web, Addison-Wesley, 1998.
Mercuri, Rebecca, Herrmann, Nira, and Popyack, Jeffrey, Using HTML and JavaScript in Introductory Programming Courses Proceedings of the Twenty-ninth Technical Symposium on Computer Science Education, February 1997.
Musciano, Chuck and Kennedy, Bill, HTML: The Definitive Guide, Second edition, O'Reilly and Associates, 1997.