5-MAR-79 23:04:00-PST,7689;000000000001 Mail-from: USC-ISI rcvd at 23-FEB-79 2314-PST Date: 23 FEB 1979 2314-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 801 SURVEY [ISI]PROCEEDINGS.MSG#751-#800 From: STEFFERUD at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]23-FEB-79 23:14:36.STEFFERUD> Redistributed-To: scott at SRI-KL Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#751-#800;1 -- FRIDAY, FEBRUARY 23, 1979 23:07:02-PST -- 50 24 FEB RMS at MIT-AI (Richar MSGGROUP# 800 FINGER: An analysis of the arguments and the issue. (10600 chrs) 49 24 Feb JWALKER at NBS-10 MSGGROUP# 799 Privacy and the FINGER (1743 chrs) 48 23 Feb McLure at SRI-KL (Stu MSGGROUP# 798 Re: #795 The CMU Finger program and privacy ... (2499 chrs) 47 Fri, 2 dcrocker at Rand-Unix MSGGROUP# 797 Re: #795 The CMU Finger program and privacy ... (3269 chrs) 46 23 FEB FARBER at USC-ISI MSGGROUP# 796 A defense of the rights of the individual (3259 chrs) 45 23 Feb McLure at SRI-KL (Stu MSGGROUP# 795 Re: The CMU Finger program and privacy ... (4001 chrs) 44 23 FEB FARBER at USC-ISI MSGGROUP# 794 The CMU Finger program and privacy ... (11166 chrs) 43 21 Feb PANKO at BBN-TENEXB MSGGROUP# 793 Adios from Ra3y Pank (1464 chrs) 42 20 Feb rudisin at UCLA-Secur MSGGROUP# 792 Response to MSGGROUP 790 re licensing (10505 chrs) 41 10 Feb Zellich at OFFICE-1 MSGGROUP# 791 Re: Are we professionals? (1932 chrs) 40 8 Feb MICHAEL SHAMOS at CMU MSGGROUP# 790 Are we professional s? (6683 chrs) 39 7 Feb david at UTEXAS MSGGROUP# 789 Add David@UTEXAS To Mailing Lists (609 chrs) 38 29 Jan Bair at SRI-KL (James MSGGROUP# 788 Workshop on Human-Computer Communication (8341 chrs) 37 24 Jan POOL at BBN-TENEX MSGGROUP# 787 Planning for a DOE Workshop (5005 chrs) 36 2 Jan POSTEL at USC-ISIE MSGGROUP# 786 New RFC 752 Availab (664 chrs) 35 28 DEC E. von Gehren MSGGROUP# 785 FAREWELL FROM ED VONGEHREN (772 chrs) 34 20 Dec Mark Crispin RFC751.TXT (697 chrs) 30 19 DEC Joanne Sattley PROC EEDINGS.SURVEY#701-750 (6858 chrs) 5-MAR-79 23:04:00-PST,2476;000000000001 Mail-from: SRI-KL rcvd at 23-FEB-79 2155-PST Date: 23 Feb 1979 2134-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: MSGGROUP# 802 [dcrocker at Rand-Unix: private response] To: msggroup at USC-ISI Redistributed-To: [ISI]Mailing.List;178: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 --------------- Mail-from: SRI-KL rcvd at 23-Feb-79 2132-PST Mail-from: RAND-UNIX rcvd at 23-Feb-79 2123-PST From: dcrocker at Rand-Unix Date: Fri, 23 Feb 79 21:21-PST To: McClure at SRI-KL Subject: private response On the theory that we've both made our opinions known to the group, I'm limiting this response just to you, so as not to consume everyone else's time/bits... Your latest note repeatedly refers to productivity. If you will pardon my, once again, taking that point of view to its extreme, fascism is very efficient. Personal liberty, such as the right to privacy, is generally acknowledged to incur inefficiencies; however we (supposedly) decided that the expense is worth the benefit. (Granted, the battle of which should dominate and where the line is to be drawn continues to rage and probably always will; but we should be clear that THAT is the battle we are engaged in.) My personal belief is that the personal rights should carry one hell of a lot of weight. In particular, in the absence of a consensus or equivalently weighty base -- e.g., suprememe court decision -- I think it VERY important to lean towards respecting the right of individuals to make choices and in the absence of that choice to make the "safest" decision on behalf of the individual.) You refer to your need to obtain information about others. This is that "right to know" argument I mentioned in the previous note. It is one of the things to factor into deciding where to draw the line. Example: an employer is generally agreed to have the right to know the whereabouts of an employee during worktime. It is generally agreed, also, that it is NOT his right to have that information any other time. So when you claim concern for obtaining information about a person, I have to respond with a question: what makes your need to know stronger than that person's right to prevent you from knowing? (If you think that this note will contribute tot he public discussion, feel free to forward it.) Dave. --------------- ------- 5-MAR-79 23:04:00-PST,1985;000000000001 Mail-from: SRI-KL rcvd at 23-FEB-79 2206-PST Date: 23 Feb 1979 2208-PST From: McLure at SRI-KL (Stuart McLure Cracraft) Subject: MSGGROUP# 803 Re: private response To: dcrocker at RAND-UNIX Cc: msggroup at USC-ISI In-reply-to: Your message of 23-Feb-79 2132-PST Redistributed-To: [ISI]Mailing.List;178: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 The entire point is not that my need is greater than your desire for privacy. It is that the area in which you are demanding privacy, applies to more than one person. The very fact that something is used by numerous people, and unless peculiar initializations are left to the whims of them, then we find ourselves battling a dead horse. That is why I favor the default of openness and force people to take the action to protect themselves in any form they see fit. In a research environment in which contributions between members of cooperative areas of work can be very productive, limiting the ease of interaction and exchange of information has a very deliterious effect on the output and quality of work. You can require privacy but not when your demand is forced upon other people who must also have that privacy. Clearly, it should be the person who seeks privacy to do so rather than the person who seeks openness. Note that everything I say applies only to a research site. Obviously privacy must be maintained in circumstances where the release of that information could be truely injurious to some party, but in cases such as the ones we are discussing, I see no point in making the default something that constricts the flow of information. If anything, the program should implement the default of openness and those wishing to exhibit their desire for closed non-interaction may do so at their leisure. I certainly see no connection at all between this and facisim which I can only construe to be an ad homien. ------- 5-MAR-79 23:04:01-PST,2458;000000000001 Mail-from: MIT-MULTICS rcvd at 23-FEB-79 2236-PST Date: 24 February 1979 01:37 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: MSGGROUP# 804 fingering cc: msggroup at USC-ISI Message-ID: <790224063746.053740 at MIT-Multics> Redistributed-To: [ISI]Mailing.List;178: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 Date: 24 February 1979 01:29 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: Fingering To: durham at CMU-10a cc: msggrp at USC-ISI, McLure at SRI-KL, Farber at USC-ISI Message-ID: <790224062922.739587 at MIT-Multics> Having used both ITS (totally unprotected and Multics, defaulting to complete (almost) privacy), I can make some comparisons. ITS is nice in many ways, especially if you don't mind living in a glass house. It is difficult to see ITS as a model for "real world systems". What business would tolerate a system that would not allow your secretary to say that you are unavailable when you simply do not want to answer a call. A simpler exaample is simply not choosing to answer the telephone. The difficult is that many systems have historically been used by small local and homogeneous communities. This results in a distorted view of the world. Even the community on the ARPANET has been very closed and friendly (except for occasional files disappearing or being hacked on ITS -- so far not a big problem). But part of what we are doing is setting examples for the larger community where these privacy issues are more real. For example, ITS has a nice text editor but it cannot be used by the MIT administration because of the lack of security (I think that there is some experimentation with using a Unix system for some of this stuff instead). In any case, putting protection on something like a finger command does not mean I cannot findout the whereabouts of a coworker at all. It just provides some choice in the matter. If one wanted to be concerned about security, the existance of the option of showing last login and presence of mail itself might be going to far as it can cause social presusre to allow the invasion. this is equivalent to allowing a patient access to medical records. The result is that the patient can be pressured (by an insurance comany, for example) to reveal the information anyway, thus removing real control. 5-MAR-79 23:04:01-PST,2836;000000000001 Date: 23 FEB 1979 2346-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 805 FINGER MUST BE SUBJECT TO DISCIPLINE From: STEFFERUD at USC-ISI To: Msggroup Message-ID: <[USC-ISI]23-FEB-79 23:46:08.STEFFERUD> Mail-from: USC-ISI rcvd at 23-FEB-79 2346-PST Redistributed-To: [ISI]Mailing.List;178: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 This argument about privacy and the rights of serious folk who need the information to get their work done has been before MSGGROUP before. Last time, in 1976, it was focused on the likes and dislikes of the feature that tells a sender when the receiver has "READ" the mail (ie. printed it, and thus is presumed to have read it). If my secretary, without my directive, told anonymous inquirers "when I last read my mail," I would fire him. I said that three years ago about this issue and I say again now. I might, maybe, relent a bit if he found out for me who asked but I don't see any hint of query logging in FINGER. I am willing to let an indiscriminant third party agent tell you that your mail has indeed arrived in my mailbox, but not that I have removed it. Note this distinction carefully. I demand that my secretary exercise discretion and be discriminating. Since my mail system, including FINGER, is my secretary, I wonder how I might discipline it? It is none of your business when I read mail from you, or from anyone else, unless I decide to tell you. If I am a member of a collaborating group, then making such information available seems sensible, but I must assume that any such group would only want this availability to be established on a voluntary basis. Even our vaunted research conclaves should not require forced openess. People either want to work together or they don't. If they don't they won't, with or without open FINGER defaults. The entire problem is with the idea that anyone might be allowed to deny mailbox privacy to anyone in the larger public community, either through technical dictate or by social dictate. Quite frankly, if the "open finger" default setting is necessary to the ethos of CMU, then ... As for McLure's claim that he has never heard of anyone having a problem with SRI FINGER, I now present him with one. In the summer of 1977, I found that I needed to prevent FINGER information from being given out on my STEF@SRI-KA mailbox. I had to arrange for full privacy on that mailbox until the problem went away. (And no, I won't tell you why!) I suggest that SRI consider this a request for SRI to install the CMU kind of refinement, and default settings. I will expect others who use the SRI systems to ask for these improvements too, now that this issue has exploded into the open. Best regards - Stef 5-MAR-79 23:04:01-PST,632;000000000001 Mail-from: MIT-MULTICS rcvd at 23-FEB-79 2356-PST Date: 24 February 1979 02:57 est Subject: MSGGROUP# 806 Minor Technical point on RMS finger reply. From: Frankston.Frankston at MIT-Multics To: stefferud Message-ID: <790224075717.346210 at MIT-Multics> In-Reply-To: Msg of 02/24/79 00:17 from MIT-AI rcvd Redistributed-To: [ISI]Mailing.List;178: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 Brief techical point -- Multics has an anonymous attribute that permits users to hide the fact that they are currently logged in. The default is not anonymous. 5-MAR-79 23:04:01-PST,2766;000000000001 Mail-from: UCLA-SECURITY rcvd at 24-FEB-79 0052-PST Date: 24 Feb 1979 0048-PST Sender: lauren at UCLA-Security Subject: MSGGROUP# 807 FINGER and PRIVACY From: lauren at UCLA-Security To: FARBER at ISI CC: MSGGROUP at ISI Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I too was going to stay out of this discussion, but it has gotten too opinionated for me to ignore. I'm all in favor of "freedom" in research environments -- but, I'm sorry, I simply can't go along with the notion that it is better to default to uncontrolled access than to controlled access. It's not as if I'm saying that no information should be made available at all -- simply that it MUST be an individual decision and not a general enforced one. Since there has got to be SOME default, it certainly makes sense to default towards individual protections. The person who wants to make more information available could presumably always do so -- and those who aren't even aware of such possibilities are protected until somebody, or something, "enlightens" them -- then they simply change their modes -- if that is what they want to do. I submit that it is very important that we insist on the same levels of personal privacy in our computer interactions as we would in any other portion of our lives. It is wrong to try split these two facets apart -- in coming years, they will no doubt become more and more inseperable -- and not just for us, but for an increasing proportion of the population. The argument that project interactions suffer if a person doesn't know when someone else's mail has been read MIGHT be true (I personally don't think it is) -- BUT if that's the case, it is simply the responsibility of the project members to agree to set their modes appropriately to allow the agreed-upon level of information flow. One last point. It was said by one recent message sender that he knew of no occurrence of misuse of FINGER information. Well, I'm real happy about that. At least there's been none that he knows of. Or none that anybody else knew about, or complained about, or understood. But it always seems that it takes a real serious problem to bring an outcry about any situation. Life flows along just fine until that ONE person abuses something, and then everyone starts screaming bloody murder about why this condition was allowed to exist -- why nothing was done about it. And by that time there are hurt feeling at best, and more serious results at worst. We should act to prevent this situation from coming about -- not just sit by smiling because nothing has happened YET. --Lauren-- ------- 5-MAR-79 23:04:01-PST,2203;000000000001 Date: 24 Feb 1979 0157-PST Subject: MSGGROUP# 808 Giving the FINGER From: Mark Crispin To: MsgGroup Cc: MARS-Filer at CCA-TENEX Mail-from: SU-SCORE rcvd at 24-FEB-79 0158-PST Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I don't understand what the issue is about. I personally believe that the last logged-out time is something that can be determined with a little detective work (hence is already public domain). SAIL's policy is that everybody's last logged-out is public domain (although it could be evaded by various means, all antisocial). I implemented the mail reporting feature at SAIL, and I have not yet received a complaint about privacy violation. In fact, when I added CKMAIL I specifically ASKED if anybody thought it was a violation of his or her privacy via a system announcement. The point was that in SAIL's environment enough people (including our paranoids) like the feature of being able to know what time they might expect somebody to show up (useful for us random-phase hackers!) and to check for new mail (and for sufficiently unparanoid people, READ it) without logging in. In fact, the paranoids are the biggest fans of these features, since it gives them something to snoop at other people with! So much for my little flame. Now, I understand that everywhere is not SAIL. Fine, so what is a good alternative to make the largest number of people happy? Well, CMU implemented the bits, which is a reasonable way out, but invited harassment by creating a default (thereby setting an "officially approved standard"). Suppose instead there was a temporary third bit saying "has not set the bits yet", and set up the log in on their system to demand a decision on the part of the user what his/her bits should be? The default until the user logs in could be to no allow the powerful finger. Seems that would maximize everybody's happiness and minimize the hate mail that the poor implementor gets. But, then if everybody did things like this there'd be nothing to talk about in MsgGroup! -- Mark 5-MAR-79 23:04:01-PST,2626;000000000001 Mail-from: SRI-KA rcvd at 24-FEB-79 1016-PST Date: 24 Feb 1979 1015-PST From: Pine at SRI-KA (Bud Pine) Subject: MSGGROUP# 809 re: Finger Controversy. To: msggroup at USC-ISI cc: pine Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I would like to add another view to this brewing controversy. I believe we as computer scientists -- from both sides of the arguments - - are taking a much too simplistic view of the problem. We are arguing about only two basic alternatives. Either we open the information to anyone and everyone, or we make the information PRIVATE and thus unavailable to anyone. Non computer systems and there are many analogous ones, are much much more selective than either of these choices. My secretary is knowledgable enough to make an almost perfect assessment of the "rightness" of giving out clearly private information DEPENDING upon the circumstances of the request. She knows my very personal friends and that it is absolutely OK to give them any information they request about anything, eg whether I am in, who I am with, what subject we are discussing, when I plan to leave, come back, etc etc. She knows who my clients are and when its ok to disturb me so that I can take a msg etc. I wait for our efforts to get much more sophisticated than they are. i would like some selectivity in who can "finger" me. ie Don't tell anything to this groupd of individuals, do tell this group, and I would like to be able to set the default for the rest of the world to sometimes be "tell them" and sometimes be to "don't". I am aware that bill collectors have sometimes very devious ways of finding out what they want to know. I would simply like to be able to make it difficult for them without making it difficult for me at the same time. How about recognizing that all or nothing is an inadequate solution. And, that one of the really important issues in the controversy is "How do we make it easy for all users - novice as well as experienced - to find out what features are available, and how they can best utilize them." As an aside, I use the SRI machines regularly, and only occasionally use the finger program. I will bet that at least 80% of the users of these machines have no knowledge of finger and the details of it's existence. We need to be able to design systems that are much more usable and ways of communicating there strengths and weeknesses to who can benefit from them or be trod upon by them. Bud Pine ------- 5-MAR-79 23:04:02-PST,1401;000000000001 Mail-from: SRI-KA rcvd at 24-FEB-79 1029-PST Date: 24 Feb 1979 1029-PST From: Pine at SRI-KA (Bud Pine) Subject: MSGGROUP# 810 More re: Finger controversy. To: msggroup at USC-ISI cc: pine Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 Stuart, I would like to comment on your last msg. Is it so difficult to obtain permission from the various users of the system to make the finger info public, that you really feel compelled not to try? It seems to me that a well worded msg to all users describing the usefulness of making the finger info public could be sent to all users of the machine. it would also seem to me that a system for facilitating each users ability to institute his desires is easy to implement. At the most it takes a clerk to receive msgs fromthe users and either set the bits that control the processing. This would clearly "err" on the side of privacy, while still letting those of us that find utility in finger to continue to use it on, "and that is a very freudian slip", to continue to use it on SOMEONE. You have acknowledged the right of users to say no don't give out that info, so what is so difficult about asking each and every user what their desire is before being so presumptive about what is right for everyone. Bud ------- 5-MAR-79 23:04:02-PST,4240;000000000001 Mail-from: CMU-10A rcvd at 24-FEB-79 1117-PST Date: 24 Feb 1979 1415-EST From: Scott Fahlman at CMU-10A (C380SF50) Subject: MSGGROUP# 811 Finger and Privacy To: stefferud @ isi Message-ID: <24Feb79 141538 SF50@CMU-10A> Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 Hi, RMS @ MIT-AI tells me that you are the person who has been collecting opinions on this subject and distributing them to various places. Here is my contribution, for what it may be worth. -- Scott Fahlman @ CMUA - - - - Begin forwarded message - - - - Date: 24 Feb 1979 0240-EST From: Scott Fahlman at CMU-10A (C380SF50) Subject: Finger and Privacy To: Ivor Durham at CMU-10A CC: RMS @ MIT-AI, fahlman @ CMUA, Wulf @ CMUA Message-ID: <24Feb79 024020 SF50@CMU-10A> Ivor, I just saw the load of mail that has been migrating around the net concerning the default bits on finger, in my case because RMS @ MIT-AI thought I might be interested. I am. I that both sides of the issue are arguable. On one hand we have the pragmatists who point out that 99% of the people on the net are perfectly willing to have finger reveal when they last logged in and when they last read mail, but with the default preventing this a good 50% will never get around to overriding this default. And this sort of thing makes the system a much less friendly and somewhat less efficient place. Often I have wasted a day or two waiting for a netmail reply from someone who was out of town or just was not a netmail reader. Few of us would deny the 1% the right to their privacy, even though it is hard to think of a non-paranoid reason for wanting privacy of this particular sort. But many of us think that having the system be 50% ineffective is too high a price to pay for protecting those among the 1% who, for reasons of ignorance or laziness, do not get around to overriding the default. On the other hand, there are the idealists who believe that we simply do not have the right to invade someone's privacy in an area which has traditionally been private, nor to force someone to take positive action to preserve some privacy that he already has. I think this is very clear where the person might not know about the action that he must take, and perhaps less clear if it can be established that the person had ample notice of the impending change. I tend not to believe in absolutes of this sort, but one must recognize that large erosions can result from enough insignificant nibbles. Given the options that you had -- to set or not set the bits as a default -- I think it's about a toss-up. I would probably have gone the other way, but not without checking around a bit to see if the 99%- 1% characterization given above fits with reality. If the breakdown were 80%-20%, say, I probably would have gone for privacy as the default, as you did. In any event, I am not prepared to say that you were wrong, let alone spineless. What we really want, it seems to me, is to have the profile bits accurately reflect each person's desires and not to rely on easily- ignored defaults. To satisfy the civil libertarians in the audience, we would not print the finger info unless given the go-ahead, but the system should force each user -- once! -- to indicate what he wants to do about this, perhaps nagging him at each login until he answers the question one way or the other. Of course these questions could themselves become an unwelcome invasion, but in this case I think the usefulness of the Finger facility would justify them. The point is to use them sensibly and sparingly. The proposal to deny Finger service to those who do not cooperate would go a certain distance in this direction, but it seems needlessly vindictive and would not help to set the proper defaults for non-finger users who are willing to be fingered but have just never thought about the issue. In any event, the new finger stuff is a big win, and I thank you again for cooking it up. If you want to, you may forward this to anyone interested. -- Scott Fahlman - - - - End forwarded message - - - - 5-MAR-79 23:04:02-PST,1338;000000000001 Mail-from: OFFICE-1 rcvd at 24-FEB-79 1218-PST Date: 24 Feb 1979 1213-PST From: Zellich at OFFICE-1 Subject: MSGGROUP# 812 Re: FINGERing and other fun issues To: msggroup at USC-ISI Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I enjoy reading, and occasionally participating in, group flaming over issues such as this, but can't help wondering if we should establish a new group (FLAMING-ISSUES@somehost ?) rather than bother "serious" groups such as msggroup and header-people. Putting my own two cents in on FINGERing, I observe that the arguments seem to be split mainly by whether ones orientation is as a member of an academic/research community or the general public (also laughingly referred to as the "real world"). Both sets of arguments are right - it's obvious that you have to adjust the computing environment to match the type of user it serves. While I far prefer the completely open environment that is desirable for a research community, I recognize that I am developing applications for some users with (potentially) highly sensitive data (and feelings!) and must design accordingly - whether I happen to agree with the users' privacy/secrecy philosophy or not. Cheers, Rich ------- 5-MAR-79 23:04:02-PST,3196;000000000001 Mail-from: CMU-10A rcvd at 24-FEB-79 1528-PST Date: Saturday, 24 Feb 1979 1826-EST From: Brian K. Reid Subject: MSGGROUP# 813 Finger privacy To: MsgGroup at ISI CC: Durham at CMU-10A, Farber at CMU-10A Message-ID: <24Feb79 182620 BR10@CMU-10A> Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I am the person who started all the brouhaha at CMU about Finger privacy in the first place, and I may well be the person who called Ivor "spineless", though he should have figured out by now that I was just being mindlessly vituperative. I think I should put in a brief note explaining my position. Personal privacy in the face of computer systems and data bases is a very sticky problem, but it is not the problem that I was trying to address with my complaints about closedness. I was worried, and still am worried for that matter, about the decay of our lab as a place in which to do research and creative thinking. I certainly @i[don't] want some credit bureau to know when I last logged out of the machine, but I certainly @i[do] want my co-workers to know when I did. The question of "who is asking" is to me very important. In the 5 years that I have been at CMU, I have watched a decline of direct person-to-person talking and an increase of comuter-based conferencing of all kinds. I have seen people send computer mail to someone ten feet away to avoid having to get out of a chair and actually use his vocal cords. I have seen an increasing number of design discussions take place entirely within the confines of the computer. And I have watched the "sense of community" that is so valuable to research institutions become weaker and weaker. Like it or not, the computer is becoming our conference room, our secretary, our file cabinet, and even our game room. The very nature of the way research gets done is changing irrevocably. And I want to make sure that people are aware of those changes, and that they recognize the effect that they have on the ability of an institution to be creative and to do research. I complained originally about the default setting of the Finger bits because I saw it as one more communication path becoming blocked. I know full well that 95% of our people are not ever going to change the bits from the default, no matter what the default is, simply because they are lazy and don't want to learn how to use yet another piece of software. So the sense of community suffers. We can go days without seeing one another, each hiding in our office or at home with our terminal, sending mail instead of talking. And now I can't even find out whether or not somebody has "come in" to the virtual research lab today, simply because he's too lazy or too preoccupied to tweak a couple of damn bits. Every communication path, every bit of information, is vital. As with so many other social issues, it seems to be the case that the maximum benefit to the group (CMU in this case) is not achieved by maximizing the benefits to all individual members of the group. Brian 5-MAR-79 23:04:02-PST,2684;000000000001 Mail-from: MIT-AI rcvd at 24-FEB-79 1539-PST Date: 24 FEB 1979 1838-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 814 Reply to Lauren on privacy To: lauren at UCLA-SECURITY CC: Stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 Lauren has repeated the absolutist claim that any slight chance of a violation in any sense of someone's privacy outweighs any other considerations. This is ridiculous and it implies a lot of conclusions that I doubt that Lauren would like to be stuck with. Does he believe that search warrants should be illegal because they violate privacy? Their very existence shows that society has decided that privacy must vie with other considerations, and has established a criterion for deciding when privacy is paramount and when the other considerations outweigh it. You needn't agree with them, but unless you are willing to adopt the view that police must NEVER be allowed to search anything, you must agree that other considerations can outweigh privacy. Of course, the reasons for wanting to find out something on a research computer are a lot less important than the reasons why one might sometimes want the police to conduct a search. The dangers involved in someone's knowing your last logout time are also much less than the dangers of police. Note that disagreeing with the conduct of police or with the details of the current legal system does not remove the force of this argument. I don't like them either. There are parts of the country where people proudly proclaim that they don't need to lock their doors. They see this as an advantage over cities where it really is dangerous not to lock them. Those people are not devoid of concern for their privacy, nor do they think that crimes will never happen there (what they think is that crimes will hardly ever happen there - one crime doesn't disprove that). If crimes gradually increase, they might start locking their doors, but they won't go around screaming bloody murder that such a situation of unlocked doors was permitted to exist in the first place. And they will probably think that it is a shame that locking became necessary. In such areas of the country, while some people may lock their doors, the default is not to lock them. If such places can exist, and be good to live in, how can one say that a computer on which such minor pieces of information as we are discussing can't be good? Remember that the open doors are considered a feature, not just a bug that nobody has fixed yet. 5-MAR-79 23:04:02-PST,2815;000000000001 Mail-from: MIT-AI rcvd at 24-FEB-79 1555-PST Date: 24 FEB 1979 1853-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 815 Reply to Frankston on Fingering To: Frankston at MIT-MULTICS CC: Stefferud at USC-ISI Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I don't think Frankston is exactly wrong, but not exactly right either. It's close enough to right to deserve a detailed comment. Date: 24 February 1979 01:29 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: Fingering To: durham at CMU-10a cc: msggrp at USC-ISI, McLure at SRI-KL, Farber at USC-ISI Message-ID: <790224062922.739587 at MIT-Multics> Having used both ITS (totally unprotected and Multics, defaulting to complete (almost) privacy), I can make some comparisons. ITS is nice in many ways, especially if you don't mind living in a glass house. It is difficult to see ITS as a model for "real world systems". What business would tolerate a system that would not allow your secretary to say that you are unavailable when you simply do not want to answer a call. A simpler exaample is simply not choosing to answer the telephone. Agreed. ITS isn't offered as a model for "real world systems". There are plenty of non-real-world systems, though. The difficult is that many systems have historically been used by small local and homogeneous communities. This results in a distorted view of the world. Even the community on the ARPANET has been very closed and friendly (except for occasional files disappearing or being hacked on ITS -- so far not a big problem). But part of what we are doing is setting examples for the larger community where these privacy issues are more real. Our small, homogeneous communities may be bad models of the world - but why consider them models of the world? What's right for them may be bad for the world as a whole, but again, so what? Why SHOULD we try to set an example for the world if that's bad for us? Let the world as a whole do what's right for it, and let our small, homogeneous communities do what's best for a small, homogeneous community. For example, ITS has a nice text editor but it cannot be used by the MIT administration because of the lack of security (I think that there is some experimentation with using a Unix system for some of this stuff instead). As an ITS user, I'm glad that no compromises were made in ITS for the sake of administrative users. ITS wouldn't be as easy to get research work done on if they had been, and research was what ITS was intended for. 5-MAR-79 23:04:03-PST,2065;000000000001 Mail-from: UCLA-SECURITY rcvd at 24-FEB-79 1651-PST Date: 24 Feb 1979 1637-PST Sender: lauren at UCLA-Security Subject: MSGGROUP# 816 Finger and Defaults From: lauren at UCLA-Security To: RMS at MIT-AI CC: Stefferud at ISI Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 24 FEB 1979 I sense that this discussion is rapidly starting to lose a sense of proportion, but be that as it may ... The examples you cite in your message to me (search warrents and unlocked doors) can both be flipped around the other way. As I view the U.S. system, search warrents are not an ENFORCED DEFAULT. If this was the case, the authorities would have a blanket permission to enter any home for any reason UNLESS the owner had previously registered some sort of disagreement with this policy. The system as it is now set up is clearly defaulting to personal protection, in that it takes a court order (or probable cause) both of which are strictly defined, to OVERRIDE the default of personal protection. As far as locked doors are concerned, the lock manufacturer's do not pass some sort of blanket edict that forces every lock owner to leave their door unlocked unless they follow some (comparatively complex) procedure to lock it. Perhaps a better way to put it would be that if most people didn't know that it was possible to permanently lock or unlock a door, and most people left it the way the manufacturer set it, would it be better to set it to locked or unlocked initially? Of course there are towns where people leave their doors unlocked. But it is done by choice, and not by technical or governmental edict. The INDIVIDUALS involved leave their doors unlocked. I think it is clear that these two examples are really not that suitable for this argument, but I felt a responsiblity to answer your points. I repeat, when a default must be chosen, it should be chosen to err on the side of individual privacy. --Lauren-- ------- 5-MAR-79 23:04:03-PST,1716;000000000001 Mail-from: MIT-MULTICS rcvd at 24-FEB-79 1718-PST Date: 24 February 1979 20:19 est From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP# 817 RE: #809 re: Finger Controversy. To: Pine at SRI-KA (Bud Pine) cc: msggroup at USC-ISI In-Reply-To: Msg of 02/24/79 13:15 from SRI-KA rcvd Message-ID: <790225011922.183108 at MIT-Multics> Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 The request for finer resolution of access -- specification of more types of access and who has which access is quite reasonable. In fact, Multics does this for mailboxes, you specify a list of users who may: do nothing with your mail, send you mail, delete mail they've sent, read their own mail that they've sent , read mail to oyou from others, delete mail from others, or see if you have mail at all -- or any combination of these). This is fine for sophisticated or paranoid users. The difficulty comes from having to make explicit decisions about each potential case that one might encounter. Intelligent defaults help ease this problem. But computers, as our secretaries, are not, currently, very smart. So the burden falls upon the user to anticipate every possible situation and decide what the action should be. I dealt with some of these issues with respect to charging for computer-based services in my Master's Thesis in 1974 (that long ago??) and think they are real. I am glad to see these issues being aired periodically, if for no other reason, than to make people aware of these issues as they design systems that have impact on people outside our small community. 5-MAR-79 23:04:03-PST,1234;000000000001 Mail-from: MIT-MULTICS rcvd at 24-FEB-79 1722-PST Date: 24 February 1979 20:23 est Subject: MSGGROUP# 818 The current controversy From: Frankston.Frankston at MIT-Multics (Bob Frankston) To: stefferud Message-ID: <790225012312.814366 at MIT-Multics> [Text]: Note by STEFFERUD on 24 FEB 1979 1946-PST [Text]: This entire set of messages is kept in [ISI] for [Text]: whomever. MsgGroup is practically a publishing operation. [Text]: When this is all over (soon I hope cause it takes too much of [Text]: my time, and I am supposed to be going on a trip), you can get [Text]: the complete set from . Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 When things die down, it would be nice to collect the current set of discussions in a single file, possible without names, for distribution as a memo to those responsible for implementation of software affecting users. I would like to maintain a copy on Multics, when it is complete, to give to new people. {I'm kind of sorry that I haven't retained the full dialogue, but it is probably easier to wait till it is all collected first} 5-MAR-79 23:04:03-PST,4549;000000000001 Mail-from: SRI-KA rcvd at 24-FEB-79 2106-PST Date: 24 Feb 1979 2106-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 819 Finger gas From: the tty of Geoffrey S. Goodfellow To: Msggroup at ISI Cc: Durham at CMUA Message-ID: <[SRI-KA]24-Feb-79 21:06:26.GEOFF> Reply-to: Geoff @ SRI-KA Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 I too was going to try and ride this one out, but I just have to point out a few things.... There are two issues in question here. Finding out when a person last logged out and weither or not a person has read their mail (or weither they have new mail or not, and maybe who that unread(new mail) is from and what time it was sent, and perhaps what the last time was that the person read their mail). First, last logout: Currently on Tenex and TOPS-20 as most everyone is aware there is a SYSTAT command which lists for you all users on the system, hence anyone on the system can find out what anyone else is doing. This is in fact how our finger system works. We have a background job, which is a subfork of SYSJOB, which wakes up every so often, and thru some efficient JSYS's takes a look around the system to see what everyone is doing and writes it into a file. The reason for doing this is that the norm way of doing SYSTATish stuff on TENEX and TOPS-207s is quite costly in terms of resources, hence we have one background job that does it super efficiently, and makes the data available for everyone to use, therefore saving everyone the trouble of doing it themselves, since its only done once. Also, what this background program does is record the last times of attach, login, logout and detach. The finger program mearly looks at this file, and tells you which one of those events was the most recent, hence that's how you find out when someone last loggedout and where from, etc. Now you should be beginning to see why it is impossible for us to restrict this info on our systems, because NOTHING keeps a user from writing his own program to take similer snapshots of the system and finding out the same info from it. What is needed if you really do not want this info to be "known" is that it must be protected on the operating system level. i.e. you can't do a system wide systat or a where on a user and find out what they are doing and if they are logged in, and in fact, this is exactly what exists on Tymshare's systems. Every user is isolated from every other user, , and the only system wide thing you can find out about is the load avg. PERIOD. Hence if you want this type of information kept confidential, you'll either have to take your business to Tymshare, or pay us some money and try to convince us that its in our(your) best interest that we go thru and make modifications to the operating system to support such a user environment. (p.s. good luck on that). "2nd issue. When did I last read my mail? Again, the problem here is in the operating system, however, there is a difference in the way TOPS-20 and Tenex handle things here. On TENEX if your DIRECTORY protection is set up such that access to each file is on a file protection basis, anyone can find out FDB information on that file (i.e. last read time, last write time, author, etc.) even if the file itself is protected against their reading! On TOPS-20, if the file is protected against their reading, then they can find NOTHING out about it (which is, of course, as it should be). The only way to protect anyone from knowning weither you have read your mail or not, is to have your DIRECTORY protection set up such that REGARDLESS of what file protections you have set, NOTHING is accessible to the world, and this is what I did for Stef when he has his problem. However, since MAIL files on TOPS-20 and TENEX have set (usually) append only access, the operating system allows this FDB info to be gotten. So again, it will take operating system diddling to protect you from snoopers. An adendum: I also believe system wide information on what users are logged in and what they are doing is available on TOPS-10, UNIX and other systems around the net, and also on UNIX it has the same problem that TENEX does wrt dates , times and sizes of mail files, hence nothing prevents users there from writing similer programs to "collect" and "provide" such already "publicly" available information on demand. I rest my case. 5-MAR-79 23:04:03-PST,998;000000000001 Date: 25 FEB 1979 0222-EST Subject: MSGGROUP# 820 On Equivalence of AI Labs and Farms From: RMS at MIT-AI (Richard M. Stallman) To: lauren at UCLA-SECURITY Cc: Stefferud Mail-from: MIT-AI rcvd at 24-FEB-79 2322-PST Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 People in the country are PROUD of the fact that everyone leaves their doors open. This is despite the fact that once in a blue moon someone gets hurt because of it. They just don't think it matters when it's so rare. People at CMU could be just as proud of leaving doors open even if it were true that once in a blue moon someone would be hurt by it. But for some reason people are taking tha attitude that this minute possibilty of harm is the most important concern - regarding it as far more important than the country people regard the possibility of real live burglary. This seems out of proportion to me. 5-MAR-79 23:04:03-PST,2830;000000000001 MAIL-FROM: SRI-KL rcvd at 25-FEB-79 0255-PST Date: 25 Feb 1979 0255-PST From: Stuart McLure Cracraft Subject: MSGGROUP# 821 RE: Reid's comments on electronic mail/privacy/etc To: reid at CMU-10A Cc: msggroup at USC-ISI In-reply-to: Your message of 25-Feb-79 0214-PST Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 You contend that electronic mail & non-personal interaction appears to be causing a slow decay of your lab. This seems an unreasonable way to slough off the reason for the alleged decay onto one type of communication between users. To me, it is a far more reasonable thing that electronic mail actually increases the quality of communication over meetings when the people involved are all independent enough to be working at very strange hours and would find it difficult, if not impossible, to all gather together frequently. Ocassional meetings, of course, are definitely useful, but I see no reason to criticize mail as an inpersonal form. It is my experience that people's arguments, if effectively put forth in electronic mail, can be easily disected in replies. How often can you say this about personal interaction when the people involved are so concerned with appearance and worrying about expressing themselves rapidly? With the written word, they can take their time to express their exact views on the topic. It can be saved for future reference. Can you say the same for personal interaction??? I don't think you can. So let's not blame the faults of your lab on electronic messages. If there are problems, I contend it is something far more general than the fact that people communicate via the computer rather than speech. As for the rest of this FINGER debate, many people have proposed the scheme of individual bits for users and having them forced, by the system, to specify which they want. But this argument can be taken further and you could force upon them a list of ALL the users and then they could relish the long and boring task of deciding whether user 1 should get the information about mail and last login, and whether user 2 should or shouldn't and so forth. This ludicrous conclusion wastes everybody's time and patience, and yet the privatists would have us believe that a single bit for each person precludes the fact that they wouldn't want a particular person to be completely snubbed and never get any information on them at all. I think that carrying privacy to this extreme, even the extreme of individual bits, is going just too far. People's time can be certainly spent in a more productive manner than twiddling bits for every person's desired whims of privacy on every conceivable sub-topic. ------- 5-MAR-79 23:04:04-PST,1203;000000000001 MAIL-FROM: SRI-KL rcvd at 25-FEB-79 0305-PST Date: 25 Feb 1979 0301-PST From: Stuart McLure Cracraft Subject: MSGGROUP# 822 Reply to Bud Pine's FINGER reply To: pine at SRI-KA Cc: msggroup at USC-ISI In-reply-to: Your message of 24-Feb-79 1029-PST Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 For the very reason stated in the above message, who are you to decide that a particular user would want to let everyone see it while another would want no one to see it? That, in itself, is a very grueling decision and certainly one that some people could argue with. My contention is that if people want that sort of privacy, they certainly don't belong in an enviroment such as the one we have. The very nature of the time-sharing, interactive machine is one of vast amounts of information all shared through a central resource. I certainly don't think that people should be able to 'clam up' without going through very negative amounts of work for no good reason other than they want to be completely segregated from the rest of the user community. ------- 5-MAR-79 23:04:04-PST,1459;000000000001 Mail-from: MIT-MULTICS rcvd at 25-FEB-79 0440-PST Date: 25 February 1979 07:41 est From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP# 823 Re: #819 Finger gas To: Geoff at SRI-KA cc: Msggroup at USC-ISI, Durham at CMU-10a In-Reply-To: Msg of 02/25/79 00:06 from SRI-KA rcvd Message-ID: <790225124106.208091 at MIT-Multics> Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 Geoff does bring up a good point by describing the issues with TOPS-20 and Tenex. Obviously, the claims that what we are talking about are strictly academic issues is false. Tenex (especially via TOPS-20) is now out in the real world preventing innocent users from privacy because Tenex (and its predecessor the SDS- 940 system from Berkley and whatever antecedants that had) was designed to work nicely in a laboratory environment. Incidently, the 940 system was also a widespread commercial system, most notably at Tymshare. The systems did not have to be designed this way (as usual I bring in Multics as a counter-example). By the way, I find the small town and farm examples silly. In fact, a reason why many people move out of these places is not bcause they long for door locks, but rather to leave the fishbowl environment where everyone knows whether they have read their mail, the time of last login or equivalent information. 5-MAR-79 23:04:04-PST,1610;000000000001 Mail-from: USC-ISI rcvd at 25-FEB-79 0856-PST Date: 25 FEB 1979 0856-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 824 You will be on your own for 8 days From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;179: Message-ID: <[USC-ISI]25-FEB-79 08:56:18.STEFFERUD> Gentle people all - As of this message I am completely caught up with your onslaught. I hope it will subside now. Or at least slow down to entertain more thought between broadsides. I a going away on a long trip (8 days) and I have no volunteers to do the care taking of . It is not easy and I don't have time to teach anyone the tricks at this point. If you must continue through the next 8 days, then you should send your mail directly to the group, though I know this will not be as nice. In consideration of those who will read your contributions, please try to keep them within the 72 column page, and try to format them reasonably. I have had to do some considerable reformatting on some of your stuff. You know who you are that send me such messes. It will be very helpful to us all if you tend to your own formatting. And a special note for RMS, if you persist in sending messages without subject fields, your stuff may well be left out of the transcript when I get back! I think we have captured on file a very interesting bunch of thoughts, and I am pleased to have been a party to the exercise, though I do see a considerable repetition in the more recent items. I will send the Mailing list in the next message so you may flail away without me. Best - Stef 5-MAR-79 23:04:04-PST,1797;000000000001 Mail-from: USC-ISI rcvd at 25-FEB-79 0901-PST Date: 25 FEB 1979 0900-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 825 [ISI]MAILING.LIST;179 From: STEFFERUD at USC-ISI To: MSGGROUP Message-ID: <[USC-ISI]25-FEB-79 09:00:49.STEFFERUD> Redistributed-To: [ISI]Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 [ISI]Mailing.List;179:, @AMES-67, Hathaway, @BBNA, Burchfiel, DDeutsch, Mathison, Mooers, Myer, NMA, Sandberg, @BBNB, Day, Hall, Panko, Turman, Whallon, @BBNC, INFOMEDIA, Pool, LPouzin, @BBND, JHaverty, Koncer, MTravers, Vittal, @CCA, MARS-Filer, JZS, Tom, RCT, @CMUA, Mark.Faust, Rick.Gumpertz, Lehman, BZM, Newcomer, Brian.Reid, RdMail, Wactlar, @ECL, TBlount, Caine, Carlisle, Carlson, RDeMent, JMcHugh, HSolomon, Widener, @I4-TENEX, Reynolds, @ISIA, MSGGROUP, Adams, PBaran, Broos, Comport, Goodwin, Kirstein, Schlaff, Spivey, Stefferud, Tasker, Walker, @ISIB, Cohen, Ellis, Holg, Postel, Stotz, @ISIE, Schill, @MIT-AI, KLH, Hewitt, RMS, @MIT-DMS, MSGGRP, Vezza, @MIT-MULTICS, Frankston, Palter, Pogran, @MIT-MC, FFM, FJW, Sirbu, @MIT-ML, CBF, KENS, @NBS-10, Cotton, Dunlavey, JWalker, @OFFICE-1, ARMTE, DRXAL-HDA, DBall, Dames, Farber, Grobstein, Sternberg, Taylor, vonGehren, Walsh, Zellich, @OFFICE-2, Engelbart, Jordan, Stone, @PARC-MAXC, Brotz, Danielson, AHenderson, Karlton, McDaniel, White, @RAND-UNIX, Anderson, DCrocker, Gaines, Greep, Kiessig, GRM, Szurko, MLW, @SRI-KA, Geoff, Hewitt, Ole, Pine, SDSAN-DMS, @SRI-KL, Bair, LCampbell, Feinler, Gaschnig, McLure, Pickens, Scott, @SU-AI, MRC, DGR, @SUMEX-AIM, Feldman, Kahler, Rindfleisch, @UCLA-SECURITY, Lauren, Rudisin, Steve, @UTEXAS, David, 5-MAR-79 23:04:04-PST,2002;000000000001 Mail-from: SRI-KA rcvd at 25-FEB-79 0941-PST Date: 25 Feb 1979 0941-PST From: Pine at SRI-KA (Bud Pine) Subject: MSGGROUP# 826 Re: Reply to Bud Pine's FINGER reply To: Stuart McLure Cracraft Mailing.List;179: Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 25 FEB 1979 In response to your message sent 25 Feb 1979 0301-PST Stuart, I believe there is a fundamental falicy in your logic. You seem to be assuming that there is nothing going on with the SRI-KL that is or needs to be private. I happen to believe there is much -- very legitimate -- business going on that at various times is very very private business. As you know, I use the SRI-KL quite a lot. Some of this work is for SRI and involves writing reports, proposals, discussions of business prospects, etc etc. I also know that on tenex and tops 20 machines, the security is very minimal for any knowledgable person. There are a number of wheels on the system, and there are a number of people who have easy access to logged in wheel terminals that could easily do anything. Thus I know that I cannot prevent any knowledgable person - who wants to read things - from doing so. And therein lies the real problem from my point of view. I think we should clearly define the etchic and moral situations when it is ok and not ok to violate someone else's privacy. This is even more important than usual because of the ease with which information can be obtained. Do you really advocate that it should be ok for anyone to write a program to constantly check whether you are logged in, from what local terminal, from what remote line, what subsystems you are using, who you send mail to, etc etc. That it would be relatively easy for a knowledgable person to do this has been documented. But should we start to define the ethic aspects of these kinds of acts? Bud ------- 5-MAR-79 23:04:05-PST,1284;000000000001 Mail-from: UCLA-SECURITY rcvd at 25-FEB-79 1406-PST Date: 25 Feb 1979 1357-PST Sender: lauren at UCLA-SECURITY Subject: MSGGROUP# 827 Unix and Privacy From: lauren at UCLA-Security To: MSGGROUP Redistributed-To: [ISI]Mailing.List;180: Redistributed-By: STEFFERUD at USC-ISI (Connected to MSGGROUP) Redistributed-Date: 26 FEB 1979 1505-PST I take this opportunity to verify Geoff's statement concerning Unix for the record. It is indeed the case that Unix's protection system resembles Tenex's in this example. Most users' "root" (that is, main login) directories are readable by all users. It is THAT protection that determines the ability to look at the file-specific system data (last modified, last accessed, etc.) for a given file, and NOT the protection of the file itself (which only determines what you may do with the actual DATA of the file.) To protect themselves from exposing this sort of information, the user would have to turn off read access to the directory. Essentially then, we would be left with no access at all to that directory for most users. Mail could still be delivered to the user's mailbox (since the mail programs run in a "wheel" mode on most Unix systems), but all other access would be denied. --Lauren-- 5-MAR-79 23:04:05-PST,1164;000000000001 Mail-from: MIT-ML rcvd at 25-FEB-79 1646-PST Date: 25 February 1979 19:22-EST Subject: MSGGROUP# 828 MSGGROUP@MIT-ML now broadcasts MAILING.LIST; From: Charles Frankston To: MSGGROUP at MIT-MC Well, I may regret it, but in Stef's absence, I have placed MSGGROUP in an ITS distribution list like header people by using all those balanced parens and stuff that RFC733 wants to tell us are illegal. Persons wishing to continue flaming can simply send a message to MSGGROUP@MIT-ML. I chose ML for this because it has more free disk space and MC already has the burden of HEADER-PEOPLE. I would hate to see what would happen if the two should explode at the same time, but fortunately its mostly the same people. The messages should be logged in [MIT-MC] CBF; MSGLOG >. MC and AI senders should address their messages to simply MSGGROUP on their local machine, so as to prevent ITS internal headers from escaping onto the net. As soon as Stef returns I intend to point these all back to him and give him the log file to do what he will with. ITS users needn't tell me they got 2 copies of this, I already know. 5-MAR-79 23:04:05-PST,640;000000000001 Mail-from: MIT-ML rcvd at 25-FEB-79 2208-PST Date: 26 Feb 1979 0056-EST Subject: MSGGROUP# 829 FINGER flames From: PAT.MCGEHEARTY(N810PM10) at CMU-10A Remailed-To: MsgGroup @ ML Remailed-From: BZM Remailed-Date: Monday, 26 Feb 1979 0059-EST All I can say is "What flames!!!" I'm not sure I would have started if I had known the volume. I suspect that for many the issues of "PRIVACY" and "FREE DISTRIBUTION OF KNOWLEDGE" take on religious proportions. I believe in both strongly, placing PRIVACY in first place. --Patrick McGehearty PS-- This may be distributed if you think it worthwhile. 5-MAR-79 23:04:05-PST,9081;000000000001 Date: Monday, 26 Feb 1979 0334-EST Subject: MSGGROUP# 830 Water for the Flames From: BZM To: MsgGroup at ML Cc: Durham at CMU-10A Message-ID: <26Feb79 033420 BN30@CMU-10A> In-Reply-To: which started the MSGGROUP FINGER discussion Mail-from: MIT-ML rcvd at 26-FEB-79 0107-PST People: As author of the original "Message 27" I, like Brian Reid ("Message 26"), want to add to the context of Farber's initial transmission. The bottom line of this note is that CMU suffers from a real communication problem. Brian discussed this a bit, but I have a different twist. (Some previous messages in this set have dealt with this too.) I will approach this by responding to the remarks added to my initial message to Ivor. There is some backtracking here. ----Message 27 is---- Date: Wednesday, 31 Jan 1979 0020-EST Subject: Re: Public Pressure. In-Reply-To: <31Jan79 000012 ID20@CMU-10A> [[ID: The previous message was re-mailed to about half a dozen people all of whom traditionally hold strong opinions on subjects such as that under discussion. My reply encouraged them not to add fuel to the fire, but to encourage people to set their profile bits according to their personal preference rather than ignore the facility. The following message is a response to that note. ]] Ivor, I find myself angry that you implement something that is so nice without considering the (more important) social ramifications. If we as computer scientists continue to punt such issues to second place, who the hell is going to take responsiblity for them? In particular, I refer to your attitude about talking to HDW the other day. [[ID: This refers to a discussion in which I had agreed with our operations manager that Finger should be inhibited from revealing login and mail information by default. ]] [BZM: This is not what I remember. I understood Ivor to have taken NO position and, feeling that the opposite should be the case, I entreated him to talk to the manager with me to try to convice him otherwise. After repeated encouragement, Ivor told me that he didn't want to go talk to him; that whatever operations decided was fine because users could change the settings themselves; that he was providing the program and operations could determine whatever default they wanted because all Ivor had to do was reverse the test and get whatever default they decided. I was disturbed because Ivor seemed to be punting on MAKING the decision, not because he took a position different than mine. Miscommunication! ] I do not bicker with your RIGHT to leave finger alone, or to leave useage decisions to the elders. And I think that Brian's proposal has the smack of a hack. But HE said THAT off the top because HE didn't want to nearly-uselessly flame like I am--like I feel I MUST as an outraged CSist. The decision to remain paranoid is one I accepted because I know how much work and shit would have to be plowed through to change it. I don't hope for it now. [BZM: I still don't hope for it. I gathered the following statistics on the FINGER program's privacy bits tonight: Summary of CMUA FINGER settings, by account. 761 accounts included, 175 inactive ones excluded. FingerNeither FingerMailOnly FingerLoginOnly FingerBoth 618 6 6 131 Now a great many of the 618 accounts are also never used, but my method didn't catch them. So throw half out. That still leaves 300 accounts which have not been changed through ignorance or laziness. And--of course--there are a few who don't want the information shown. Why is there so much laziness and ignorance? Three main reasons: [1] CMU has two announcement "facilities". The system NOTICE is short and most people get it. After my meeting with the operations manager "we" decided to publicize in this most-widely-read place the fact that users should change their PROFILE settings if they wanted to. This note never appeared!!! And even if it had, the shortness constraint on it would have required indirection through a file with the explanation. Lazy users rarely follow these pointers. [2] The CMU BBOARD facility is also available for messages. All notes about FINGER have in fact been on BBOARD. My statistics show 288 of 936 total accounts get BBOARD printed on login. Many users print it only on demand; many of those 936 accounts are unused. Looking at my listing, about half of the automatic BBOARD readers also have both FINGER options OFF. These users may be lazy or desiring privacy; it's the other ones--who never heard--that bother me the most. (It's important to note that all new accounts are created with BBOARD printing OFF. You don't know about it, you can't print it; recursive lossage (see below). (A controversy about THIS default happened last summer. The flames got almost as hot as these, but "status quo" reigned.)) [3] The PROFILE changing program takes a long time to run and (until VERY recently) had synchronization problems--your change never appears, etc. The proposed 3rd bit solution would have to interface to this or work around it. Good luck!!! The "person who implements the bits" is part-time and has exclusive control. And someone then has to write some text which explains the options even to the most novice users. This has YET to be done! Defaults can be very powerful indeed--"follow the leader". Doesn't this ALL sound like petty bullshit we've heard N times before? Damn right. It's the stuff that got me into whole (fruitful) mess. I foresaw this, and that's why I wanted the default changed. Most of our users won't change, even now, after this controversy. If it were really possible to communicate with the whole CMU community, INCLUDING those you don't see very often, then the default could be OFF and we could reasonably expect that the "loose" people would change. But new users at CMU are given NOTHING, not even a one-page sheet detailing their learning options. If they dig around they'll find the (reasonable) manual given to first-year grad students. (These messages have motivated me to see that something is being done about this now.) ] But when I yell "closed and tight atmosphere" from my corner and not "free and open research community", be prepared to talk about the REAL thing and please DONT say "What ever policy they decide is fine; I'm just a mechanism." I don't accept your right to punt. [BZM: As an ex-SAILer, I believe in open research systems. This is why I would have FINGER's default be to show the information. On the other hand, I do my research in security, and am extremely finicky about these issues for secure (non-open) systems. I believe people should always have the choice, AND be made aware of it. But there is this communication problem! How many of you have read the Privacy Act Notice that came with your income tax return? How many of the "real worlders" out there can really understand it? Now this no-random-FINGERing law is a good one. Just as is the Fair Credit Reporting Act (which keeps usurious bankers from ripping us off blindly). But how many of those people out there can understand the related "customer explanation" that comes with their bills once a year or so? I'm pessimistic. I'm glad that the government requires "erring on the side of the individual" in these cases. My point is that the more mechanism we invent or legislate, and however nice it is--fully capability-based, authority-based, whatever--the harder it is to explain it. With privacy, you have to pick a policy and then explain the mechanisms which one can use to properly circumvent it (or tighten it up). And you will STILL get problems either way. In computer science we solve them with wizards; in the legislature they use amendments. We're back to tradeoffs again. In "private" systems like the government's I'm willing to solve my problems with legal circumvention because it ensures my privacy from a hell of a large and unknown population. In the CMU research environment--with fixed, default READ-ONLY protection for all files and unnecessarily poor communication for MOST users--I want the open 99% to live easily with no problem and the private 1% to BE INFORMED OF and TOLD HOW TO solve their "problem". ] I am NOT a mechanism. [BZM: Discussions like these, while sometimes tedious, aren't mechanistic, either. It's good for our collective health to thrash this stuff now before our incomplete ideas become the policies of substantial "real world" systems. I daresay we have some communication problems of our own, too. ] ----End Forwarded Message---- Like Bud Pine, I find the communication and user interface issues just as important as the privacy ones here. Bruce 5-MAR-79 23:04:05-PST,1409;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 0125-PST Date: 26 February 1979 03:50 est Subject: MSGGROUP# 831 Re: Water for the Flames From: Frankston.Frankston at MIT-Multics Cc: MsgGroup at MIT-ML, Durham at CMU-10A Message-ID: <790226085038.149753 at MIT-Multics> In-Reply-To: Msg of 02/26/79 03:38 from BZM Good discussion of the issues. I would choose default of accessable for finger login, no access for files and mail checking. The readonly default for files is really unfair to the naive user who opts to do writing of letters and papers. Normally he would presume some privacy for papers left on a desk. While it is inconvenient, a default of readonly is "intuitive" for the paranoid. There should, however, be a mechansim for a default of readonly set by the project administrator. Perhaps a default of readonly to the user's project might be an acceptable compromise. By the way, the problem of the wrong default for naive users is a common one. On Multics, I originally implement the interconsole message command as a user program and its usage has essentially spread by word of mouth, even though it is now an official part of the system. It looks like we may finally recify this (after 9 years) by providing a set of default initial commands settable by the installation manager. Many project administrators have long since set such defaults. 5-MAR-79 23:04:05-PST,1807;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1029-PST Date: 26 Feb 1979 1300-EST Subject: MSGGROUP# 832 FINGER! From: Joe Newcomer at CMU-10A To: msggroup at MIT-ML Cc: shamos at CMU-10A, durham at CMU-10A I have now wasted an hour going thru the FINGER mail. I have to feel that the time was not completely wasted, so I am generating my own addition to the flak. Some time ago, Mike Shamos requested information about our attitudes on licensing professionals (AND FOR GOD'S SAKE, DON'T START SENDING THIS STUFF AROUND TO THE MSGGROUP!!!! CREATE A PRIVACY SUBGROUP SO I DON'T HAVE TO READ IT AGAIN!). I originally thought that computer scientists were basically responsible people. The finger controversy has demonstrated that a nontrivial percentage of people in sensitive positions (we call them "system hackers") have little or no understanding of moral, social, and legal responsibilities with respect to privacy. Frequently, the justification is "well, that isn't private anyway, so a program that makes it easily accessible doesn't violate privacy." All this says is that they have already failed to consider some issues and have build inadequate systems, then use that inadequacy as justification for the existence of programs that violate privacy in some additional way. In the light of some of the comments I read, I may completely revise my position on licensing of computer professionals; some of these people should not be left out of their cages! They are dangerous. As the computer becomes more and more powerful and convenient, more and more of my life is on it. Current systems are already proven inadequate for anything really sensitive. The number of people advocating even more glass in the houses scares me. Joe Newcomer 5-MAR-79 23:04:05-PST,786;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1135-PST Date: 26 Feb 1979 1414-EST Subject: MSGGROUP# 833 Finger From: HALL at BBN-TENEXB To: msggroup at MIT-ML Please take me off the MSGGROUP mailing list. The FINGER controversy is too much for my file system. The issues aren't going to be resolved by this group in any case. Presumably back at the dawn of history when ordinary mail was invented a similar controversy raged. Certainly, in the early days of the telephone, many people were outraged by the invasion of their privacy. In both cases convenience won out over privacy. Electronic mail is here to stay. The question is should it be modeled after ordinary mail or after the telephone. I vote for ordinary mail. I have little enough time to myself as it is. * 5-MAR-79 23:04:06-PST,2176;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1238-PST Date: 26 Feb 1979 at 1158-PST Subject: MSGGROUP# 834 Re: privacy education and the sensitivity of information From: Mike at Rand-Unix To: Joe.Newcomer at CMU-10A Cc: shamos at CMU-10A, durham at CMU-10A, msggroup at MIT-ML, Cc: guyton at PARC In-Reply-To: Your message of 26 Feb 1979 1300-EST. For those of you who don't believe that knowing when someone has read his mail is a gross violation of privacy please read part 2. 1. At one time I might have thought that ethics re:privacy would disseminate through the community along with other notions in this field (like structured programming), and that our hackers and systems designers would acquire these ethics through osmosis. I am, being older and wiser, quite certain that this is not the case. How often do we see 'new' software come out of important shops which appear to have been written in total isolation from the events of the last decade? (unreadable error messages, login names which must be a number, text editors which dont allow a 'copy' command ...) How often do we hear people (like Mark Crispin) say "the ACM has no value, at least to me" effectively closing out that channel of information? Joe Newcomer may have changed my mind about some sort of computer certification: perhaps it would be useful to have some simple privacy lecture series where people are exposed to these issues. Then when they are sued for negligence in privacy design (absolutely certain to happen) they can not plead ignorance. 2. A good friend of mine recently went out of town for two days. I know this not because he told me or because a friend told me, but through analysis of his mail reading behavior convenienly provided by Tenex. Now, he probably doesn't care that I know what he does with his time, but it really isn't any of my business. So dont be so fast in saying that some kinds of information are "obviously" of no importance. Knowing something about the subject, we can deduce an amazing amount of information from the most trivial-seeming data. Remember: In the proper context, all information is sensitive. 5-MAR-79 23:04:06-PST,3239;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1550-PST Date: 26 Feb 1979 1405-PST Sender: lauren at UCLA-SECURITY Subject: MSGGROUP# 835 privacy education and certification From: lauren at UCLA-Security To: Joe.Newcomer at CMUA Cc: shamos at CMUA, durham at CMUA, MSGGROUP at MIT-ML I remind the reader that my personal position on the whole FINGER controversy was one oriented towards the personal privacy view. Now ... I feel that lack of morals, sensitivity, privacy considerations, etc. are DEFINITELY NOT problems to be dealt with through governmental or some other beaurocratic edics. I must concur with rudisin's view on this point to quite an extent -- I feel that more basic means (like careful discussion of issues by prospective purchasers and providers of software services) are the correct means to design and contract systems. The whole reasons the finger issue has come up is not (in my opinion) because of people who "shouldn't be let out of their cages." I feel that these people are probably just as moral and basically nice human beings as most of us like to think we are. However, their view on this issue happens to not coincide with mine. OK. In a REAL WORLD system, it is less likely that a facility such as finger would have been introduced without considerable discussion of its use and ramifications. This is as it should be. In a reasonable contracting situation (at least the way I operate) I would have put forth a spec of exactly what information finger would give out. If the client didn't want that -- or wanted something different, so be it. The decision of what information should and should not be made available is going to stay one for the contracter and contractee to work out -- subject to such items as the federal privacy laws and such (such laws may decide the whole issue in the end, but I hope not.) My point is that you cannot legislate morality. It does NOT work. Forcing people to sit through some lectures on "the moral issues of privacy" or some such will accomplish nothing. Just as I suspect few views on finger privacy hasve really been changed by all the recent flames, few real views would be changed or altered in any way by the lectures. Certification would tend, in my opinion, to end up concentrating on technical issues, and due to the very nature of the way CS is now so broad, would be bound to lockout various people with excellent talents, and pass through those people who take tests well but have little or no ability in the real world -- how well we all know these people! I'm sorry. I just don't feel that more beauracracy, more imposed governmental standards, is the way to go. Finger did not become an issue because of lack of competence or "shoddy workmanship". It simply was not treated as a real issue. In the research environment, this isn't necessarily bad (I don't want to start THAT argument up again....) but in the real world it cannot be tolerated. But I repeat. You can't legislate responsibility or morality. And trying to legislate technical qualifications in something like CS, where less intrusive forces can do the job, would be detrimental to the whole field. --Lauren-- 5-MAR-79 23:04:06-PST,500;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1658-PST Date: 26 FEB 1979 1544-PST Sender: HOLG at USC-ISIB Subject: MSGGROUP# 836 FINGER From: HOLG at USC-ISIB To: msggroup at MIT-ML Message-ID: <[USC-ISIB]26-FEB-79 15:44:49.HOLG> It occurs to me that the program is aptly named for what it gives to the (little) privacy a user has.. Matter of fact, I think it would probably be a step in the right direction to have TENEX say "BEATS THE HELL OUT OF ME!" whenever someone uses WHERE (IS). 5-MAR-79 23:04:06-PST,2114;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1714-PST Date: 26 FEB 1979 1619-PST Subject: MSGGROUP# 837 Misconceptions in current privacy discussion From: Hathaway at AMES-67 To: MSGGROUP at MIT-ML A quick two cents worth on a couple of what I feel are serious misconceptions in the current discussion. First, I seem to notice a lot of the following feeling: "Of course one shouldn't release things like medical records, but we are talking about innocent stuff like when you last read your mail, and since that can't possibly cause any harm there is really no privacy issue at all." This is just plain WRONG! The issue really IS a binary one: I don't care how innocent it may appear at first, it ain't none of your business and I don't want some system busybody dishing out information behind my back. As an example, how would you like it if I freely publicized the fact that you visited the County VD Clinic five times in the past two weeks? Gee, I didn't release any medical records or anything, did I? And second, it seems many of the comments are mixing up the two very different concepts of PRIVACY and ANONYMITY. To quote from an excellent "The Forum" in the February 1976 "Datamation," "To attempt to hide publicly known facts, to remove or obscure such facts from the historical record, is to seek anonymity, not privacy. ... The right to privacy is the right to do or say things and not be covertly observed. What I do in public anyone has a right to observe, to remember, to report." If this thesis is accepted, then the issue becomes one of defining the word "public" properly; I would certainly hope that any such definition would exclude things like the contents of personal mail! Wayne PS: Sorry, but with Stef not minding the store I didn't know what to do about a MSGGROUP number in the "Subject" field. PPS: If anybody is counting votes side me with the folks who think this IS a serious issue and who want all defaults to be of the "none of your business" variety. 5-MAR-79 23:04:06-PST,2680;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1749-PST Date: 26 FEB 1979 1955-EST Subject: MSGGROUP# 838 A LECTURE ON COMPUTER MORALITY From: RMS at MIT-AI (Richard M. Stallman) To: NEWCOMER at CMU-10A Cc: SHAMOS at CMU-10A, DURHAM at CMU-10A, LAUREN at UCLA-SECURITY, Cc: msggroup at MIT-ML A lecture on the morals of privacy would change my opinions about as much as a lecture by Sun Myung Moon - and for the same reason. No strong person will change his mind merely because someone else tells him to. If you want to go on insisting that you have a right to privacy on CMU's computer, first you should demonstrate that you have any rights at all on CMU's computer. It doesn't belong to you. It exists to get research done, and the lab can set any policy at all about privacy. If you don't like it, nobody forces you to work there. The lab might happen to decide to give people some form of privacy, if people there decide that they are better off that way. But this wouldn't mean that you had any rights; the privacy would be on sufferance of the lab. If they decide to follow any sort of tradition of what privacy you can have, that's still a decision they could have made differently. Or the lab might decide that people will get more work done if privacy doesn't get in people's way (which is what MIT AI has decided). But "individual rights" don't apply in any case, because the lab's computer is not something that you have any rights on. And if some information becomes "sensitive" for you, you can just keep it off the lab's computer just as you wouldn't say it over their public address system. Sometimes you will indeed give something away because of a change in your habits. But that is just like all the rest of life. If you form the habit of walking through your lab's front door most days, and someone who works near there sees you, then if some day you don't walk through the door people might suspect that you were away - just as they might if they saw you hadn't read your mail. If they shouldn't be able to find out that you hadn't read your mail, should they also not be allowed to see that you didn't walk in the door? Perhaps you should be able to sue anyone who sees you walk in. Or perhaps nobody should be allowed into the vicinity of the lab's front door unless he is blindfolded. Maybe the lab should be required to install a system of shuttle cars that will take you from the parking lot to your office in solitude if you don't want anyone to know that you are there. Haven't you learned yet that people not only have a right to disagree with you, but can do so without being complete morons? 5-MAR-79 23:04:06-PST,778;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1811-PST Date: 26 Feb 1979 1659-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 839 Re: FINGER From: the tty of Geoffrey S. Goodfellow To: HOLG at USC-ISIB Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]26-Feb-79 16:59:51.GEOFF> In-Reply-To: <[USC-ISIB]26-FEB-79 15:44:49.HOLG> Reply-to: Geoff @ SRI-KA HA! I bet you'd go right up the wall if all you could do was find out the LOAD AVG from the system and nothing else PERIOD., (i mean NO: WHERE, SYSTAT, WHO, TELL, LD, *A*N*Y* command that would tell you ANYTHING about another user on the system other than about yourself). P.S. You really have no right to make a statement like that since ISI doesn't even have any tyoe of FINGER system in operation. 5-MAR-79 23:04:06-PST,882;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 1829-PST Date: 26 Feb 1979 2107-EST Subject: MSGGROUP# 840 Remove me from the list From: Joe Newcomer at CMU-10A To: msggroup at MIT-ML I've seen enough trash over the privacy issue to annoy me beyond my current level of endurance. I've wasted time drafting two replies, and am mightily sick of the whole discussion. I leave you with this word of warning: there is a real world out there, whether you want it there or not, and it likes and values privacy. If you do not respond to this in a reasonable way, said real world will land on you like a ton of legislation, and you will then be receiving exactly what you have earned. I now consider my participation in this discussion ended, terminated, and completed. Emphatically finished. Goodbye, and good luck; you'll need it. joe 5-MAR-79 23:04:07-PST,792;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 2146-PST Date: 26 Feb 1979 at 2138-PST Subject: MSGGROUP# 841 a msggroup message about messages! From: Mike at Rand-Unix To: msggroup at MIT-ML ... and not about privacy. Is this a symptom of a poor message system design: people receiving what they consider to be junk mail (ie privacy messages) do not find it EASY or SIMPLE to merely delete the messages with the offending subject field (ie contains 'FINGER!'). Why is this? Do people feel obligated to read everything that comes by their desk, rather than discarding what they know will be aggravating garbage? Is the facility to scan and delete a message too clumsy? Or is it just because it is coming via computer that they feel they have some obligation to read everything? 5-MAR-79 23:04:07-PST,1762;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 2203-PST Date: 27 February 1979 00:46 est Subject: MSGGROUP# 842 Re: a msggroup message about messages! From: Frankston.Frankston at MIT-Multics To: Mike at RAND-UNIX Cc: msggroup at MIT-ML Message-ID: <790227054616.808853 at MIT-Multics> In-Reply-To: Msg of 02/27/79 00:40 from Mike There are a number of reasons for the junk mail. Basically msggroup and header-people (whatever the current distinction is other than Stef's intravention in the former) are currently the two best sources of wide audiences for general Cs/Social discussions. While there are lists for more specialized issues, it is no accident that those with general interests in CS and who are aware of the value of mail systems are mail system freaks. Of course, given this is a nucleus, other people have joined what seemed like good discussion (though possibly long tedious and bullheaded at times). I've thought of creating an alternate list for a floating discussion, but have simply decided that msggroup and header-people are the broadcast medium. If you just want to read about mail system technical stuff, fine, create such a specialized group. I doubt though that you will succeed because the mail systems, as the new communication medium are central too other seemingly unrelated issues -- everyone on header- people and msggroup will want to join the new list and then will forget the intended distinctions. The only solution is to have a good mail systems and descriptive subject lines. Observation, the volume of mail in the middle of the night between Saturday and Sunday is quite large implying that there is more involved than just an interest in purely technical discussions. 5-MAR-79 23:04:07-PST,1938;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 2228-PST Date: 26 Feb 1979 at 2217-PST Subject: MSGGROUP# 843 Finks and FINGERs Subject: .:. From: Grm at Rand-Unix To: msggroup at MIT-ML In-Reply-To: All the fluff recently circulated on this topic From the tty of: Gary R. Martins From the tty of: .:. Guys - Just two short remarks, to prove to everybody that I am reading my netmail regularly (and that I know the difference between real flames and mere swamp gas): (1) R & D (or The Golden Fleece) Much of the 'argument' blowing over these issues from one side seems to rest on the scriptural assertion that personal privacy inhibits effective R&D. Readers of Solzhenitsyn's "First Circle" will recall that the Soviet experience does not support this claim. My own experience as an R&D project leader emboldens me to go further: I KNOW that poking around in other people's files is a poor substitute for real work (R&D or otherwise); and I KNOW that people who thus fill their days on the job are poorly focussed assets, to put it charitably. Work in progress, intermediate results, drafts, and invitations to meetings can be distributed effectively through mail, open files, phone calls, personal visits, and meetings, among other media. If your organization has problems in this area, support for proven techniques like these will be far more productive than hacks like FINGER; try them, you may even come to like them! (2) WHAT PRICE GLORY ? I concur with the elegantly stated judgment of Mr. Cracraft that, on ethical grounds, he must not to be required to do battle with a dead horse. But who will not honestly admit to the anticipation of rare delights at the prospect of such a spectacle (viewed -- of course -- from a suitable distance) ? Gary [I do not say what I am not ashamed to admit denying I am proud of, either!!] 5-MAR-79 23:04:07-PST,4800;000000000001 Mail-from: MIT-ML rcvd at 26-FEB-79 2334-PST Date: Tuesday, 27 Feb 1979 0214-EST Subject: MSGGROUP# 844 Technology, Society, and History From: Brian K. Reid To: MsgGroup at MIT-ML Cc: Durham at CMU-10A Message-ID: <27Feb79 021421 BR10@CMU-10A> I've spent the evening re-reading my various undergraduate history textbooks, trying to get a cute and quotable statement of the effects of technology in history. Sure, we all know that the invention of the plow and the printing press and the stirrup and the telephone each caused huge and revolutionary upheavals in the society of the time. The simple invention of the plow made permanent dwellings possible; the printing press made mass communication possible; the stirrup made cavalry possible, and the telephone was invented for dialup home terminals. But history-book writers seem to take differing views as to whether the technology was driven by the social changes, or vice versa. I'm only a computer science student, so I won't try to make the final decision, but I can certainly observe trends as well as the next guy. Electronic mail is a major advance in communication technology, and with each major advance in communication technology there has been a corresponding revolution in the way ordinary people live their lives. The Roman roads enabled a few militarists in Italy to govern half of the world's population. Alphabetic writing permitted the accumulation and exchange of knowledge. Gutenberg's movable type allowed printing to be for Everyman. Television has caused a revolution of some kind, but we're too close to it still to be able to understand the true effect of television on society. We technologists have always played a supporting role in history, but never a determining role. We might invent dynamite or telescopes or disk files or electric generators, but we have never been able to control their use or misuse. Though it always infuriates and saddens us, the ultimate application of our wonderful inventions is determined by numerous and usually unpredictable social forces, of which greed and the lust for power have been dominant through the ages. For want of a better word, let me just call the people behind these forces "leaders." We are busily inventing a technology, and our leaders will someday figure out what to do with it. Sometimes they have made mistakes, as DeGaulle did with the telephone in France. DeGaulle believed that the telephone was an evil instrument, a horrendous intrusion on the basic right to privacy that every Frenchman enjoyed, and did everything in his considerable power to discourage its use in France. Today France has a terrible telephone system, certainly to its detriment. There is no basic human right to privacy. The Constitution and the Bible and the Arpanet Protocol Handbook are all quite silent on that issue. Every year when I pay my ACLU dues I cast my vote in the direction of believing in privacy, but that doesn't mean that I am willing to sacrifice everything for privacy. When the telephone rings, I have to answer the damn thing and thereby reveal that I am home. Were I interested only in privacy, I would agree with DeGaulle and banish it from my house. But it is useful to me, and I am willing to sacrifice a certain amount of privacy for a certain amount of convenience. But let me get back on the track. We are busily inventing the communication technology of the future, but we are much too close to it and have so little experience with it that we cannot make absolute judgments about which way is good or bad or better or worse. So I think that it behooves us technologists not to make decisions about what should be done, but to try everything. And to talk about everything. I see nothing at all wrong with "flaming" about this issue. Some people want to talk about technical details, others want to talk about design principles, others about social side-effects. Wonderful! All the better for us to understand this new technology before it's taken out of our cozy little research environment and made federal and official and we have to pay for every message that's transported. But let's finish inventing it before they take it away from us. Let the military sites bristle with privacy and let the liberal sites have none. Let's find out what happens with and without various kinds of protections. Let's hear people's bad experiences and their good ones, their ideas and their implementations. Maybe along the way a few national secrets will leak and a few embarassments be suffered, but it's much better that we get this all done in the clinical environment of the Arpanet before it becomes real. Flame on. Brian 5-MAR-79 23:04:07-PST,1140;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0018-PST Date: 27 Feb 1979 0004-PST Subject: MSGGROUP3 845 Re: Finks and FINGERs From: Stuart McLure Cracraft To: Grm at RAND-UNIX, msggroup at MIT-ML In-Reply-To: Your message of 26-Feb-79 2352-PST Let's face it. This privacy issue is really one of paranoia. What you seem to neglect is that openness in research sites is something that can be PRODUCTIVE. People are not at research places to be PARANOID. Paranoia consists in protecting yourself from EVERYONE and allowing nothing of your whereabouts, work, or concerns to be released. It is antisocial in a research environment and I certainly think people who expend their time and energy enforcing paranoia at such sites are doing a great disservice to the people involved. People who implement, and those who use such schemes are attempting to show only that they can do as the please when they please. I am all for paranoia in places where it is a question of monetary gain and so forth, but not in an environment of non-profit research. Please keep the paranoia confined to business. 5-MAR-79 23:04:08-PST,658;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0032-PST Date: 27 February 1979 03:15 est Subject: MSGGROUP# 846 Re: Finks and FINGERs From: Frankston.Frankston at MIT-Multics To: McLure at SRI-KL Cc: Grm at RAND-UNIX, msggroup at MIT-ML Message-ID: <790227081556.341352 at MIT-Multics> In-Reply-To: Msg of 02/27/79 03:04 from Stuart McLure Cracraft Being in research also means the ability to temporarily get away from peer group pressures and work by youself for a while. In any case, many of our finest researchers are also people and research establishments are social environments made up largely, if not primarily, of people. 5-MAR-79 23:04:08-PST,3980;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0303-PST Date: 27 FEB 1979 0546-EST Subject: MSGGROUP# 847 Cages. From: CBF at MIT-MC (Charles Frankston) Cc: msggroup at MIT-ML In the light of some of the comments I read, I may completely revise my position on licensing of computer professionals; some of these people should not be left out of their cages! They are dangerous. As the computer becomes more and more powerful and convenient, more and more of my life is on it. Current systems are already proven inadequate for anything really sensitive. The number of people advocating even more glass in the houses scares me. Joe Newcomer And you have thoughtfully reenforced my opinion against "licensing" computer professionals. If such a thing were to happen I am afraid that people like yourself would be foremost among the ranks of the licensors. As far as professionalism goes, I think your remarks constitute unprofessional behavior in showing a general contempt of the opinions of others. You do not direct your vituperations against any specific technical issue, but rather constitute hotly worded rhetoric weighted toward one side of the argument. But your remarks (as RMS is so fond to point out) lack the slightest perspective. That you are for privacy is about the only thing clear from your remarks. You do manage to raise 2 technical points among all of your flaming. 1) the fact that information is freely available anyway does not mean it is all right to create software to better collect and organize it 2) is that "current systems show they are inadequete for anything really sensitive" I believe each of these points has validity in a general argument about privacy. (Although I will leave it to my brother to point out from his Multics platform that your 2nd point is probably not well researched.) However, your conclusion from these 2 technical remarks that most "system hackers" are irresponsible and immoral and should be kept in cages is horrendous. Your remarks (as RMS has already pointed out of some remarks in this discussion already) are entirely without perspective. It would seem perfectly reasonble from what you have said to presume that the responsible, moral and ethical behavior of system programmers on all the systems of which you speak (presumably the entire ARPAnet community?) to make it impossible for users to obtain any information about one another. If you would deny this, I challenge you to produce one qualifying or specifying statement in your messages. You speak of inadequate systems (your point 2) that allow people to construct information gathering programs (your point 1). One must conclude then that you feel it is irresponsible of the designers of these systems to allow users to find out who else is logged in because such information would violate their privacy. While this conclusion might be valid when constructing a secure system for commercial timesharing, I believe the attributes you presume necessary for a responsbile system are in fact (or were in fact when the systems were originally designed) undesirable on most of the systems currently on the Arpanet. It happens that I prefer to work in an environment where most of this information and more is available to my co-workers and I would have serious doubts about working on a project with someone who protected much computer oriented information from his co-workers. You would tend to imply because of these preferences that I am irresponsible, unethical and be put in a cage. However, my preference for certain conditions in my working environment does not mean I am ignorant of these issues. If I were to design a new operating system (and I am going to!) I expect it to have most of the protection features of Multics. And, as with most Multics sites, I would expect most of them not to be used in most environments. 5-MAR-79 23:04:08-PST,1462;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0323-PST Date: 27 FEB 1979 0604-EST Subject: MSGGROUP# 848 [MIT-MC]CBF;MSG LOG - ETC. From: CBF at MIT-ML (Charles Frankston) To: MSGGROUP at MIT-ML I have deleted Hall@BBNB and Newcomer@CMU-10A from the MSGROUP mailinsg list on ITS as requested. I apoligize that this form of distrubtion means that you had to recieve all the messages from the time of your requests until I got around to acting upon them. Sibert@Multics has been added. Note that the names of the log file has changed somewhat, it is now [MIT-MC] CBF;MSG LOG . Note that this log will exist only until such time as Stef asks for it for incorporation into the MSGGROUP minutes, presuming he actually wishes to do so. Stef, you said you were going away for 8 days, yet there you are still doing MSGGROUP stuff. If you are actually around, would you rather I reverted this stuff back to you? (Please be assured I intend no invasion of your privacy in asking questions concerning your personal whereabouts). Lastly, MSGGROUP did not used to be this flaming a mailing list. I suspect that the current and future dropouts may in fact still be interested in somewhat less intense flaming on electronic mail related issues. I might suggest either that people move this flaming to Header-People which has a tradition of vast flaming arguments or if there is demand I would be willing to set up some more specific mailing list. 5-MAR-79 23:04:08-PST,2005;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0340-PST Date: 27 FEB 1979 0626-EST Subject: MSGGROUP# 849 R&D and Solzhenitsyn From: CBF at MIT-MC (Charles Frankston) To: Grm at RAND-UNIX Cc: msggroup at MIT-ML In-Reply-To: (1) R & D (or The Golden Fleece) Much of the 'argument' blowing over these issues from one side seems to rest on the scriptural assertion that personal privacy inhibits effective R&D. Readers of Solzhenitsyn's "First Circle" will recall that the Soviet experience does not support this claim. My own experience as an R&D project leader emboldens me to go further: I KNOW that poking around in other people's files is a poor substitute for real work (R&D or otherwise); and I KNOW that people who thus fill their days on the job are poorly focused assets, to put it charitably. Work in progress, intermediate results, drafts, and invitations to meetings can be distributed effectively through mail, open files, phone calls, personal visits, and meetings, among other media. If your organization has problems in this area, support for proven techniques like these will be far more productive than hacks like FINGER; try them, you may even come to like them! Good lord. What sort of a place do YOU work in? I think you miss the point of the "R&D" advocates entirely. This is NOT the environment at MIT (ie. bosses wanted to, or even needed to go around "poking" in their employee's files because work is tardy or something), and I don't believe it is the environment McClure or any other people who say openess helps get work done. In the specific examples people are using as being efficient open environments, we are talking about independent, well-motivated professionals. If you ever even contemplated (as an "R&D leader") that it might have been USEFUL to do the sort of things you advocate not doing, I certainly wouldn't be working for you long. 5-MAR-79 23:04:08-PST,1116;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0558-PST Date: 27 Feb 1979 at 0741-CST Subject: MSGGROUP# 850 FINGERing Information From: david at UTEXAS To: msggroup at MIT-ML I vote for: 1. Maintain as much user and system monitoring information as it is possible to reasonably do. 2. Allow a user to find out anything about himself. 3. Allow a user to specify who should be able to find out what about him. Provide a program to help the user conveniently set up this control information. 4. In setting up defaults, tend toward the side of privacy and protecting the rights of the individual. 5. Provide a "return receipt requested" mechanism in mail systems. A couple of small points: That something is possible (if difficult) to find out doesn't imply that the information should be freely given out. I do not care about fingering randoms, and I would just as soon they didn't finger me. What's needed is a finer control mechanism. I want something like the ACCESS.USR control that DEC's recent FILE DAEMON file protection scheme provides. -David M. Phillips 5-MAR-79 23:04:08-PST,7087;000000000000 Mail-from: USC-ISI rcvd at 5-MAR-79 2033-PST Date: 5 MAR 1979 2033-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 851 SURVEY OF [ISI]PROCEEDINGS.MSG#801-#850;1 From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;182: Message-ID: <[USC-ISI] 5-MAR-79 20:33:31.STEFFERUD> -- Messages from file: [USC-ISI]PROCEEDINGS.MSG#801-#850;1 50 27 Feb david at UTEXAS MSGGROUP# 850 FINGERing Informati (1116 chrs) 49 27 FEB CBF at MIT-MC (Charle MSGGROUP# 849 R&D and Solzhenitsy (2005 chrs) 48 27 FEB CBF at MIT-ML (Charle MSGGROUP# 848 [MIT-MC]CBF;MSG LOG - ETC. (1462 chrs) 47 27 FEB CBF at MIT-MC (Charle MSGGROUP# 847 Cages. (3980 chrs) 46 27 Feb Frankston.Frankston a MSGGROUP# 846 Re: Finks and FINGE (658 chrs) 45 27 Feb Stuart McLure Cracraf MSGGROUP3 845 Re: Finks and FINGE (1140 chrs) 44 Tuesda Brian K. Reid from the list (882 chrs) 39 26 Feb the tty of Geoffrey S MSGGROUP# 839 Re: FINGER (778 chrs) 38 26 FEB RMS at MIT-AI (Richar MSGGROUP# 838 A LECTURE ON COMPUTER MORALITY (2680 chrs) 37 26 FEB Hathaway at AMES-67 MSGGROUP# 837 Misconceptions in current privacy discussion (2114 chrs) 36 26 FEB HOLG at USC-ISIB MSGGROUP# 836 FINGER (500 chrs) 35 26 Feb lauren at UCLA-Securi MSGGROUP# 835 privacy education and certification (3239 chrs) 34 26 Feb Mike at Rand-Unix MSGGROUP# 834 Re: privacy education and the sensitivity of information (2176 chrs) 33 26 Feb HALL at BBN-TENEXB MSGGROUP# 833 Finger (786 chrs) 32 26 Feb Joe Newcomer at CMU-1 MSGGROUP# 832 FINGER! (1807 chrs) 31 26 Feb Frankston.Frankston a MSGGROUP# 831 Re: Water for the Flames (1409 chrs) 30 Monday BZM MAILING.LIST; (1164 chrs) 27 25 Feb lauren at UCLA-Securi MSGGROUP# 827 Unix and Privacy (1284 chrs) 26 25 Feb Pine at SRI-KA (Bud P MSGGROUP# 826 Re: Reply to Bud Pine's FINGER reply (2002 chrs) 25 25 FEB To:MSGGROUP MSGGROUP# 825 [ISI]MAIL ING.LIST;179 (1797 chrs) 24 25 FEB To:[ISI]Mai MSGGROUP# 824 You will be on your own for 8 days (1610 chrs) 23 25 Feb Frankston.Frankston a MSGGROUP# 823 Re: #819 Finger ga (1459 chrs) 22 25 Feb Stuart McLure Cracraf MSGGROUP# 822 Reply to Bud Pine's FINGER reply (1203 chrs) 21 25 Feb Stuart McLure Cracraf MSGGROUP# 821 RE: Reid's comments on electronic mail/privacy/etc (2830 chrs) 20 25 FEB RMS at MIT-AI (Richar MSGGROUP# 820 On Equivalence of AI Labs and Farms (998 chrs) 19 24 Feb the tty of Geoffrey S MSGGROUP# 819 Finger gas (4549 chrs) 18 24 Feb Frankston.Frankston a MSGGROUP# 818 The current controversy (1234 chrs) 17 24 Feb Frankston.Frankston a MSGGROUP# 817 RE: #809 re: Finger Controversy. (1716 chrs) 16 24 Feb lauren at UCLA-Securi MSGGROUP# 816 Finger and Defaults (2065 chrs) 15 24 FEB RMS at MIT-AI (Richar MSGGROUP# 815 Reply to Frankston on Fingering (2815 chrs) 14 24 FEB RMS at MIT-AI (Richar MSGGROUP# 814 Reply to Lauren on privacy (2684 chrs) 13 Saturd Brian K. Reid PROCEEDINGS.MSG#751-#800 (7689 chrs) 5-MAR-79 23:04:08-PST,3142;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0800-PST Date: 27 Feb 1979 0734-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 852 Re: FINGERing Information From: the tty of Geoffrey S. Goodfellow To: david at UTEXAS Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]27-Feb-79 07:34:00.GEOFF> In-Reply-To: Your message of 27 Feb 1979 at 0741-CST Reply-to: Geoff @ SRI-KA 1. Maintain as much user and system monitoring information as it is possible to reasonably do. with respect to TENEX and TOPS-20 FINGER, this is currently what we do. 2. Allow a user to find out anything about himself. the case with most operating systems i know of. 3. Allow a user to specify who should be able to find out what about him. Provide a program to help the user conveniently set up this control information. Impossible/impractical (wrt 10x/20x) without hairy and ugly changes to the operating system, which is where such restrictions would have to go, of course. Note: that 10x/20x (even tops-10 and UNIX) were not designed with this type/level of privacy in mind. 4. In setting up defaults, tend toward the side of privacy and protecting the rights of the individual. As far as file protections go this is what we lean towards at SRI, to protect the innocent and unsuspecting, but thru the GROUP protection mech. in 10x&20x all files are open to each other (expect mail files, as a default, unless changed by the user) 5. Provide a "return receipt requested" mechanism in mail systems. i'll ignore this one since its already made its rounds in the msggroup, and Stef has fired another secretary over it. A couple of small points: That something is possible (if difficult) to find out doesn't imply that the information should be freely given out. I do not care about fingering randoms, and I would just as soon they didn't finger me. What's needed is a finer control mechanism. I want something like the ACCESS.USR control that DEC's recent FILE DAEMON file protection scheme provides. How do you define randoms? Someone who is not logged in? Someone who is logged in but not on your good guys list? How do you set things up in a network environment where your "friend" (read non-random) on another computer wants to finger you, and how do you distinguish other people on the same other computer from randoms? ABout the only solution i can think of right off hand would be to have all of your non-random friends to have accounts on your system just for fingering, or implement a finger password scheme that is so bletcherous i even hate mentioning it. The way i see it is you are going to have to be like TENEX / TOPS-20 / TOPS-10 / UNIX / ITS and let EVERYONE find out find out FINGERish stuff about ANYONE on the system, since the operating system itself makes that information available to anyone, or be like Tymshare (and ?) and not let ANYONE find out ANYTHING about another user on the system (unless of course you are a Tymshare employee and have the app. system license). 5-MAR-79 23:04:09-PST,1793;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0907-PST Date: 27 Feb 1979 at 1046-CST Subject: MSGGROUP# 853 Selective FINGERing From: david at UTEXAS To: msggroup at MIT-ML It seems the FILE DAEMON file protection scheme could be easily and profitably applied to the FINGER privacy concerns. A user who wants to use this mechanism protects their files (on TOPS-10) to <477> so any access is caught. They make a file called ACCESS.USR. This file lists the names of files (or sets of files, using wildcards) to be protected. You can specify which accounts (with wildcards allowed) can do what to the files. The possible "what" list is quite complete. You can specify that any combination of the normal kinds of file access are allowed or disallowed. You can specify kind of access by specific programs. And you can log any accesses. The scheme seems to give the user complete control over what others can do with your files. FINGER and similar programs could use this sort of mechanism to control how much they are willing to tell about a user. In my environment the computer is run as a utility for instruc- tional and research computing. The two groups don't care about each other except as they affect machine loading. Even research groups in different areas don't care much about each other. This is my point about random people. Unless I know (and can specify) another user on the system, I don't care about their particulars. I'd like to know what machine resources others are using, but I don't want to waste my time knowing where they are, what they plan, and so on. I presume (hope) most people would feel the same way about me. For those who like to tell all, this mechan- ism should allow that too. 5-MAR-79 23:04:09-PST,2364;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 0957-PST Date: 27 Feb 1979 0933-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 854 Re: Selective FINGERing From: the tty of Geoffrey S. Goodfellow To: david at UTEXAS Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]27-Feb-79 09:33:03.GEOFF> In-Reply-To: Your message of 27 Feb 1979 at 1046-CST Reply-to: Geoff @ SRI-KA You state: It seems the FILE DAEMON file protection scheme could be easily and profitably applied to the FINGER privacy concerns. .... and FINGER and similar programs could use this sort of mechanism to control how much they are willing to tell about a user. First off, the overhead of requiring a 3rd party program such as the TOPS-10 file daemon to have to get in the act when a system call is executed to get some information about another user on the system would be horendous and also the operating system changes to support that would be hairy, ugly and undesireable to most systems. Secondly, you say "FINGER and similer programs...", nothing keeps someone from writing there own program to just bypass the daemon, and getting the information straight from the system as is now the case. To prevent someone from bypasing the daemon, it would require that for each system call used to obtain information about another user on the system, that the operating system prod the daemon, which in turn would require that the daemon look up in the users' directory on which you are trying to find out stuff on to see if its ok or not, then poke the monitor back with an OK or NOT-OK response and then allow or disallow such information. Can you imagine the overhead of doing this for system wide "SYSTAT"!? No thank you, my systems are already overloaded, have enough background system daemons, and users who are used to being able to do system wide systats, and where's and FINGERs on their fellow system users that implementing such a thing is out of the question. P.S. In all DECUS's I'v gone to i have never ever heard one mention of someone griping that someone could do a SYSTAT on them. I bet if such a thing as you proposed were brought up at DECUS you'd be laughed out of the place. If this is the type of "privacy" you desire, please take your business to Tymshare, i'm sure they'd be happy to accomodate you. 5-MAR-79 23:04:09-PST,351;000000000001 Date: 27 Feb 1979 1058-PST Subject: MSGGROUP# 855 A suggestion From: Sweer at SUMEX-AIM To: Msggroup at MIT-ML Mail-from: MIT-ML rcvd at 27-FEB-79 1325-PST How many people would "randomly" finger others if the finger program first sent a message to the fingeree announcing when and whom he was fingered by, then gave the finger info? Andy 5-MAR-79 23:04:09-PST,789;000000000001 Date: 27 Feb 1979 1123-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 856 Re: A suggestion From: the tty of Geoffrey S. Goodfellow To: Sweer at SUMEX-AIM Cc: Msggroup at MIT-ML Message-ID: <[SRI-KA]27-Feb-79 11:23:19.GEOFF> In-Reply-To: Your message of 27 Feb 1979 1058-PST Mail-from: MIT-ML rcvd at 27-FEB-79 1142-PST Reply-to: Geoff @ SRI-KA What a gaseous suggestion! Just how would you propose to implement this? Have the finger program ask WHO you are before revealing the information? I bet most people would just answer such a silly question like that with with "foo" or plain return. P.S. And what would happen when you did a FINGER of all users on a system?? TTMSG everyone logged in that there were just fingered by foo at random host? 5-MAR-79 23:04:09-PST,521;000000000001 Date: 27 FEB 1979 1423-EST Subject: MSGGROUP# 857 RE: A suggestion From: FFM at MIT-MC (Steven J. Kudlak) To: Sweer at SUMEX-AIM, Msggroup at MIT-ML In-Reply-To: Mail-from: MIT-ML rcvd at 27-FEB-79 1205-PST Thats sorta reasonable for paranoid sites. It wouldn't bother me if it told who i was fingering that i was fingering them and certainly if a person got a message every 5 mins that he or she is getting fingered by freinds would quickly unparry-noify them. Have fun sends Steve 5-MAR-79 23:04:09-PST,699;000000000001 Date: 27 Feb 1979 1130-PST Subject: MSGGROUP# 858 Re: A suggestion From: Pine at SRI-KA (Bud Pine) To: Sweer at SUMEX-AIM, Msggroup at MIT-ML Cc: PINE at SRI-KA In-Reply-To: Mail-from: MIT-ML rcvd at 27-FEB-79 1228-PST In response to the message sent 27 Feb 1979 1058-PST from Sweer@SUMEX-AIM Andy, I think that is a brilliant suggestion. It would perhaps permit the defaults to be wide open to start with, and then every time that someone fingered someone else, that person would know about it. Then, improper and/or excessive snooping would be obvious and something could be done. How about it finger hackers, how quickly can that feature be added? Bud 5-MAR-79 23:04:09-PST,599;000000000001 Date: 27 Feb 1979 1149-PST Subject: MSGGROUP# 859 Re: A suggestion From: Stuart McLure Cracraft To: Sweer at SUMEX-AIM, Msggroup at MIT-ML In-Reply-To: Your message of 27-Feb-79 1058-PST Mail-from: MIT-ML rcvd at 27-FEB-79 1251-PST That is the most moronic thing I have ever heard. Supposedly next you would have it so that whenever someone logged in, everyone else would be informed of that fact since they might be paranoid and want to know who is accessing the same system that they are. Waste of resources. Waste of man-power. Waste of wizardry. 5-MAR-79 23:04:10-PST,582;000000000001 Date: 27 Feb 1979 1240-PST Subject: MSGGROUP# 860 Re: A suggestion From: Scott at SRI-KL (Scott J. Kramer) To: Sweer at SUMEX-AIM, Msggroup at MIT-ML In-Reply-To: Your message of 27-Feb-79 1058-PST Mail-from: MIT-ML rcvd at 27-FEB-79 1313-PST You must also consider the annoyance this would cause by having a message bleep across your terminal every time a finger was taken. So if this were to be implemented, the fingeree should have the option of turning the alert off. Otherwise, the idea sounds interesting, maybe not practical, but interesting. 5-MAR-79 23:04:10-PST,856;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 1442-PST Date: 27 Feb 1979 1427-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 861 Re: A suggestion From: the tty of Geoffrey S. Goodfellow To: Pine at SRI-KA Cc: Sweer at SUMEX-AIM, Msggroup at MIT-ML Message-ID: <[SRI-KA]27-Feb-79 14:27:49.GEOFF> In-Reply-To: Your message of 27 Feb 1979 1130-PST Reply-to: Geoff @ SRI-KA Bud, That (mis-)feature will never likely be implemented at SRI (and I suspect elsewhere as well) for reasons previously explained. If you want to know each time you are fingered, ask your friends to send you a note each time they do so . If you are worried about excessive snooping, i first suggest you take whatever it is you are worried about off the ARPANET, most everyone knows that if you have a secret, you don't keep it on the ARPANET. geoff 5-MAR-79 23:04:10-PST,1110;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 1509-PST Date: 27 FEB 1979 1750-EST Subject: MSGGROUP# 862 Re: A suggestion From: FFM at MIT-MC (Steven J. Kudlak) To: Sweer at SUMEX-AIM, Scott at SRI-KL, vic at SRI-KL, To: Msggroup at MIT-ML Well that would be cute! If we had profile bits that defaulted everyone to super paranoid and they got messages every 5 mins or less they would see the idiocy of being so paranoid in fact many people would change their bits to be less paranoid. Perhaps another alternative for those places that believe in finger bits is to write a program that automatically starts up sorta like inquir for unknown users at MIT which asks such questions as : Are you a really loose person? i.e an you an ITS type Are you prettyloose but still a bittouchy sometime? i.e. are you from sail? Are you a paranoid? i.e. are you a sumexican? Are you you a super paranoid? i.e are you from a big govt system? This way we could determine who was paranoid and deal with them. Please excuse me hacking the characterizations of your sites. Have fun sends Steve 5-MAR-79 23:04:10-PST,612;000000000001 Date: 02/27/79 19:56:32 Subject: MSGGROUP# 863 On not changing our ways From: RMS@MIT-AI To: msggroup at MIT-ML Mail-from: MIT-ML rcvd at 27-FEB-79 1706-PST Veiled and vague threats, such as Pine's threats that some unidentified "real" users of our systems would force us to change our ways, are really sinking very low. I'd like you to identify the people who are going to do this, and then explain what will stop us from ignoring them. Even if such an event does come to pass, it won't prove anything about the morality issues. Similar events occur every day on our streets and in our parks. 5-MAR-79 23:04:10-PST,2818;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 1721-PST Date: 27 Feb 1979 1612-PST Subject: MSGGROUP# 864 Re: A suggestion From: Pine at SRI-KA (Bud Pine) To: GEOFF Cc: Sweer at SUMEX-AIM, Msggroup at MIT-ML In response to your message sent 27 Feb 1979 1427-PST Hello Geoff, This has almost become another flaming Maserati issue. I personally don't have the political power to make many changes in the present behavior of the systems we all regularly use. However I work with and for a number of people that do, and I am very concerned about how some of the real users out there on the ARPANET might react. The excessive openness, excessive in that we are looser than we need to be to get our work done, of our systems could be easily and very quickly taken away. All it would take is for some of the people to discover how loose and unsecure thing are to find out, and they might well decide to close things up with out any discussion of the pro's and con's of convenience versus privacy. Is there anyone out there that - in order to perform their job - that needs to finger someone else more often that very infrequently? If so, are they afraid of openness about whom and when that they are fingering people? Who can possibly want to finger all users on a system? For what ultimate purpose? For what legitimate purpose? If a user of the system wanted to be notified via a message each and every time someone, logged in( and identifyable) or not ( and thus anonomous), fingered him, or did one of a number of easily and more potentially undesirable things, Who could object to that? It would not cost the fingerer anything, the msg would just go to the fingeree, silently and quickly. I happen to use finger reasonably often, although i more often use the information mail and system (user) commands. And I am unaware that anyone of the people that I have fingered have ever objected, or would ever object. Part of that is because I don't finger people that I think might object. I don't want to lose the power and convenience of the tool we have, but I am very afraid that we could if these tools are improperly used, and even if the tools are improperly conceived. I would also like the finger msg bit to be easily turned on and off, and that to the degree it is possible, for it to be difficult for the fingerer to know whether the bit is on or off. I think we all need to strike a more balanced position on all of this. It's nice to have finger and other such tools, but how long will we have them if we ignore the very genuinely and seriously suggested requests for more capability for privacy. There is much we could do to optimize the usefulnes and privacy o these things. Isn't a compromise in order? Enough for now. Bud 5-MAR-79 23:04:10-PST,2997;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 1816-PST Date: 27 Feb 1979 1751-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 865 Re: A suggestion From: the tty of Geoffrey S. Goodfellow To: Pine at SRI-KA Cc: Sweer at SUMEX-AIM, Msggroup at MIT-ML Message-ID: <[SRI-KA]27-Feb-79 17:51:49.GEOFF> In-Reply-To: Your message of 27 Feb 1979 1611-PST Reply-to: Geoff @ SRI-KA First off, i drive a Jensen, not a Maserati! I haven't the foggiest notion on who you think is going to "quickly take our systems away" from us. That's utter BS. We have been working like this for years now, and there have been no great upheavels with our mode of operation. If you feel that our current system is to "loose" then you are free to TAKE YOUR BUSINESS TO TYMSHARE. One of the things you do not realize is that everyone does know how loose and unsecure things are on the ARPANET. Fer instance, how do you know this message is REALLY from me? After all, ever since ARPANET mail came in to being, it has been possible to forge a mail header, but has that stoped people from negotiating contacts, proposals and other "sensitive" things over the ARPANET. NO!. If you want this type of "security" and "un-looseness" TAKE YOUR BUSINESS TO TYMSHARE. i for one don't care when or how often I am fingered and by whom. If I did, I would not be on the aARPANET or using the TENEX operating system, which i have been since my 7th grade in school. I for one would object to getting a message everytime i was fingered, because it would generate junk mail that I don7t care to get, and with my current load of 30 to 60 msgs a day, i don't need to know that drivel. Secondly, what the hell keeps someone from writing there own FINGER program that doesn't send me/you a message when FINGERing takes place? See, to do the type of stuff you want will take mods to the operating system itself, as I have explained many times before, but you refuse to listen each time a new "alternative" is proposed. (refer to my earler msg today to David, and the one that RMS sent out earler this weekend, and also the one I sent out this weekend as well about TENEX finger gas). Someone who would object to being fingered doesn't belong on a system like TENEX that allows ANYONE to get at that information freely since it is available to all, hence you have no right to complain about that. As for the Finger msg bit, that can be done one of two ways. (1) Have your directory protection set to 777700. (2) Modify TENEX not to allow anyone to get at FDB info regardless of file protections (3) TAKE YOUR BUSINESS TO TYMSHARE. We have not ignored the open and looseness of FINGER and such tools, we just except that with the current operating system which allows that type of information to flow freely that that is the way things are. for those who don't like it, there is TYMSHARE, and for those that do and live by it, there is the current state of things. 5-MAR-79 23:04:10-PST,4587;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 1904-PST Date: Tuesday, 27 Feb 1979 2057-EST Subject: MSGGROUP# 866 An exchange on the worth and flammability Subject: of the Finger controversy: From: BZM To: MsgGroup at ML Cc: Lamb at CMU-10A, Everhart at CMU-10A Message-ID: <27Feb79 205730 BN30@CMU-10A> - - - - Begin forwarded messages - - - - Date: Monday, 26 Feb 1979 2311-EST From: David Lamb at CMU-10A Subject: what fools these mortals be Sender: RdMail at CMU-10A To: Nelson at CMU-10A, Reid at CMU-10A, Newcomer at CMU-10A, Durham at CMU-10A, Shamos at CMU-10A, Lehman at CMU-10A, Everhart at CMU-10A Message-ID: <26Feb79 231125 RD00@CMU-10A> "Whom the gods would destroy, they first make mad". I'm disheartened at the high emotional content of the two recent controversies flaming through MSGGROUP. Very few of the letters had much semantic content; even normally reasonable people had to spend a lot of each note defending themselves from the flames of others. I'm almost ready to give up on MSGGRP as a place to see any reasonable discussion of computer-related issues; it's too much mental effort to try to glean any sense from the verbiage. I can't even get into the frame of mind that would allow me to read the transcripts with amusement. Maybe we should start a fresh mailing list, for reasoned discussions only. Flamers need not apply. David - - - - - - - - - Date: Monday, 26 Feb 1979 2355-EST From: Craig Everhart at CMU-10A Subject: Re: what fools these mortals be To: David Lamb at CMU-10A, Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, Joe Newcomer at CMU-10A, Michael Shamos at CMU-10A, Philip Lehman at CMU-10A Message-ID: <26Feb79 235532 CE10@CMU-10A> In-Reply-To: <26Feb79 231125 RD00@CMU-10A> In some sense, there's a need for the flaming to happen. What was happening with the BBoard bits is that two issues wind up conflicting, but I feel it's important for every system-builder to have some sense of social resonsibility with respect to them. Some programmers (AI types?) build systems principally for their own use, but it is our responsibility, as builders of interactive systems, to know how our programs relate to the user and to the community in which that user participates. This is not to say that the discussions have to include name-calling and emotionally-loaded expositions of all the opinions involved; it's just to say that I'm following the discussions for more than entertainment value. Sure, there should be groups whose calling is to discuss just what the network's bit patterns should be, and to discuss standards for protocols and the performances of existing network interfaces, but it happens that the union of MsgGroup and Header-People is a group of people who are writing programs for real users, working within real communities, and they've developed a set of beliefs about the way computers should interact with and as agent for humans. I've never seen a discussion quite like this one, not to mention one that also hits so close to home. If nothing else, I'm finding it a learning experience for that time when I'll make some decision affecting how computers can act as agents for humans, and I'll have to take responsibility for that decision. Craig - - - - - - - - - Date: Tuesday, 27 Feb 1979 1116-EST From: David Lamb at CMU-10A Subject: Re: what fools these mortals be To: Craig Everhart at CMU-10A CC: Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, Joe Newcomer at CMU-10A, Michael Shamos at CMU-10A, Philip Lehman at CMU-10A Message-ID: <27Feb79 111637 DL10@CMU-10A> In-Reply-To: <26Feb79 235532 CE10@CMU-10A> Buried deep in the messages that are flying back-and-forth, even in the most flaming, are the germs of ideas worth considering. Dousing the flames to find those ideas, in all the MSGGRP discussions I've seen, is a hell of a lot of work. Skirting around the false analogies, personal epithets, loose thinking, and loaded terminology takes so long with these notes that I find it dificult to believe it's worth it. There are techniques for reworking such notes to remove the emotional fog; it's been a long time since I've studied such things, so I can't claim to be good at it any more. I'm quite sure that semantic analysis would reduce the 45 (at last count) messages to a few paragraphs of meningful information. - - - - End forwarded messages - - - - 5-MAR-79 23:04:11-PST,3679;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 2221-PST Date: Wednesday, 28 Feb 1979 0055-EST Subject: MSGGROUP# 867 "Take your business to TYMSHARE" From: Bruce Leverett at CMU-10A To: geoff at SRI-KA, msggroup at MIT-ML Message-ID: <28Feb79 005541 BL03@CMU-10A> Mr. Goodfellow, In a recent contribution to the FINGER controversy, you emphatically used the phrase "Take your business to TYMSHARE" to respond to claims that there is not sufficient provision for privacy on various systems, such as those on the ARPANet. In this, you are in essential agreement with other people (Stallman, McClure, etc.) who have suggested that people who have "sensitive" work to do should not use systems whose primary purpose is research. Thus, if one wants privacy for one's contract negotiations, one should not do them on one's ARPAnet computer, and so forth. While this prescription has some logic, I feel that it is essentially not practical. At CMU, I have access to several big, general-purpose timesharing computers. If I didn't use them for almost all of the clerical work I have to do, including that which is "sensitive", I would be squandering funds on a large scale. It's not just me. Our secretaries are expected to keep large documents and other information sources that they deal with on-line. What other choice is there? Could we really take our business to TYMSHARE when we have 3 large PDP-10's and several dozen PDP-11's in house? This sort of solution is unappealing to the people who decide how our money is spent (i.e. the senior faculty types and others who write the proposals, and the DOD types who read them). Instead, we worry about providing suitable protection ("privacy", "security", etc.) facilities on the given systems. The best designed systems can be turned off by people who don't want protection, of course. Sometimes the protection facilities we go for are pretty weak. Your example of forging message headers using NET mail is an obvious one; in addition, there are problems of physical security (i.e. an office can be broken into). In general, one gets the level of protection that one is willing to pay for. It is almost always the case, however, that when some protection is desired, an inadequate level of it is better than none at all. So I think you should not lightly dismiss the problems that people have with privacy on systems at "open, loose" research institutions. In addition, you should not claim that because some protection scheme does not completely protect the user, it is worthless. You should not deny that a proposal is plausible because it is hard to implement ("requires major changes to the OS"); if somebody wants it enough, they will pay to have it implemented, one way or another. Ultimately, I suppose, I am arguing that people get "stuck to" a system, and they find it difficult or impossible to move to another system just because the one they got stuck to doesn't offer enough "privacy" or some other desirable feature. It's the same way with nations as with systems. When someone grouses about how the U.S. is too decadent and capitalistic or imperialistic, you can't get away (these days) with telling them, "Why don'tcha go to Russia where ya belong." Moving from one country to another is just not practicable for most people! Likewise, when someone grouses that they don't have enough privacy at Institution X, you can't get away with telling them, "Take your business to TYMSHARE." Moving from one system to another is more than most people can hack! Bruce Leverett 5-MAR-79 23:04:11-PST,4890;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 2258-PST Date: 27 Feb 1979 at 2211-PST Subject: MSGGROUP# 868 the finger discussion From: Gaines at Rand-Unix To: msggroup at MIT-ML The debate on fingering has been mostly a pleasure to observe and think about. One always expects a certain amount of noise in such discussions; this one has had a lot of intelligent analysis of issues as well. It has also had at least its share of people who are sure they are right and the rest of us idiots are wrong (and who make their attitude clear by the tone of their messages). There is always a fundamental conflict between the reasons for free flow of information and the reasons for restricting the dissemination of information. In any particular case, the chosen compromise is generally a function both of the strength of those reasons when applied to that case and the tastes of those involved in making the decision. Generally society as a whole has something to gain in making as much information as possible public, while individuals' private lives, and their autonomy, are enhanced by limiting the dissimenation of information about them. (But not always: in times of war, a nation's military plans are best kept secret). The tradeoff between both likely and potential harm to the individual from some loss of privacy, and the needs of a group for free access to as much information as possible, must be an evaluation made repeatedly. The debate informs us of the issues which must be weighted in such a calculation, issues which many of us might have thought through less deeply without the debate. It is perhaps worth separating the information that a finger program would give into several different categorys, since the way of dealing with this information may depend on the category. One category is "who is logged in now?" That is often a useful bit of information. Someone at a remote terminal who has a problem may look around to see who is available to help him. The curious may have many non-malicious reasons for desiring this information. The special case reasons which validly go beyond curiosity are myriad. I would imagine that rarely in an environment where there are many users who work together would there be any restrictions on this information, since it is hard to imagine when single instances of the use of this information would be of any substantial harm. Repeatedly collecting and saving this information takes us to the next category. The second category is "when was x last logged in?" The number of occasions when this is useful, while not negligible, is far smaller than for the previous question. The case for keeping this information private is much stronger. There are a few legitimate reasons for giving access to such information (vs neutral reasons like idle curiosity, and negative reasons, such as to conclude from this information something the person being asked about usually keeps private). One type of reason has to do with people who do things when they are logged in that affect others (eg. change a program or a file). You may wish to check when someone who could have taken an action affecting you last logged in. Another atypical example occurred at Rand years ago, when ports were scarce, and connections were hand-patched. It was useful to find out who had not logged in recently as an indication of port use. But one suspects that not much would be lost if access to such information were limited. Another category is "when did x last read his mail?" A specific interesting question, "Did x see the message I sent yet?" is one of the most obvious potentially legitimate reasons for asking the former question. But the question about reading mail cannot necessarily answer it. For example, using many mail systems one may take an action that means the place mail has been stored has been accessed by a program operating in behalf of the user, x, but this does not mean x has actually read the mail. I would question (though not insist) whether legitimate benefit would frequently derive from informing a questioner about "when mail was last read" while beleiving that the (probably inaccurate) answer a system provides will be used mainly for snooping purposes. Some interesting suggestions about how to deal with the problem have surfaced. Sweer's suggestion is perhaps a bit of overkill for asking about currently logged in users, but might be reasonable for other questions. Concerning the setting of the bits that control access to such information: a possibility not yet mentioned is to demand a setting from each individual, with no default possible. This would be cheap and easy to implement in some systems, and hard and expensive in others. Where no particular default is obviously the right one, this could be an answer. 5-MAR-79 23:04:11-PST,1567;000000000001 Mail-from: MIT-ML rcvd at 27-FEB-79 2322-PST Date: 28 February 1979 01:58 est Subject: MSGGROUP# 869 Form (as opposed to content) From: Frankston.Frankston at MIT-Multics (Bob Frankston) To: msggroup at MIT-ML Message-ID: <790228065855.156390 at MIT-Multics> 1. I'd like to apologize for the long lines I've sent, I rely on the mail sender to do the line wrapping, but do to implementation oversight, the reply command doesn't do wrapping at the moment. 2. It would help if people had more descriptive headers for sorting out comments. This is a problem with reply commands in that they just reproduce a vague header. Maybe a little content. I enjoy watching the current flaming and find it useful for gaining perspective on the issues. There is also a feeling of satisfaction in seeing issues dealt with (though not, of course, fully solved) in Multics more than 10 years ago (getting towards 20). being recognized as real issues and not just theoretical concerns for military paranoids. There is, perhaps, a semi solution to the fingering problem. The information can be maintained in a user maintained database. Users can either voluntarily participate in updating this database via the initial or logout programs. An administrator at a specific installation can choose to make this a default. This has the nice feature that a user can also lie and claim not to have logged in. These white lies can be useful for permitting a formal organization structure to function even when it doesn't quite mesh with realities. 5-MAR-79 23:04:11-PST,1506;000000000001 Date: 28 Feb 1979 1004-PST Subject: MSGGROUP# 870 clarification of my suggestion From: Sweer at SUMEX-AIM To: Geoff at KL Cc: Pine at KA Redistributed-To: msggroup at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 28 Feb 1979 Geoff, This is mainly for you. I purposely kept my suggestion short in a vain attempt to set an example for the others that have been a bit intoxicated by the exhuberance of their own verbosity. It seems that in so doing you have inferred a number of points that I didn't intend to imply. 1. System wide fingers (local or over the net) do NOT divulge the last logout/message info, so of course there would be no msg sent to the fingeree in this case. 2. An option would be provided on an individual basis for those of you who don't mind being fingered, so as not to clutter up your message.txt files. 3. The main intent was so that if you are away from the system for a while, you could have a list of who had fingered you while you were gone, so you would know who was trying to get in touch with you, like a telephone recorded message after the beep. 4. This technique would provide the intended facility for mutual development by a number of different people on the same project, allowing them to keep up with where each one is at, while at the same time discourage "random" snooping, thus trying to satisfy both the wide open access, and the paranoid beurocrat devotees at the same time. 5-MAR-79 23:04:11-PST,1351;000000000001 Mail-from: MIT-ML rcvd at 28-FEB-79 1801-PST Date: 28 Feb 1979 at 1934-CST Subject: MSGGROUP# 871 Simple FINGER Limits From: david at UTEXAS To: msggroup at MIT-ML I do not suggest we hack up our operating systems to provide secure privacy. I'm not concerned about a person with the knowledge and desire to write programs to find out system-things about users. An analogy: anyone with the inclination could stake out my house and learn all my comings and goings. I'd be hard-pressed to prevent that. But I wouldn't want that informa- tion publicly and easily available. It's a matter of degree of difficulty. I propose a simple mechanism that could satisfy the needs of those concerned about privacy, while permitting full openness to those who want it. 1. When FINGER runs it checks the user's PROFIL to see if there are only certain persons of interest. 2. After it determines the set of people--from command line, PRO- FIL, or interaction--FINGER checks the PROFIL of each person available. It determines for each person whether they will allow FINGERs from this enquirer. (There should be convenient descrip- tors and definitions of classes for inclusion or exclusion.) And it determines how much information can be given out. 3. It gives the available information. 5-MAR-79 23:04:12-PST,1111;000000000001 Mail-from: MIT-ML rcvd at 28-FEB-79 2256-PST Date: 1 March 1979 01:49 est Subject: MSGGROUP# 872 Shame on you From: Frankston.Frankston at MIT-Multics (Bob Frankston) To: cbf at MIT-MC, cbf at MIT-MULTICS Cc: msggroup at MIT-ML Message-ID: <790301064947.914585 at MIT-Multics> Letting an ITS header out on the world. I can understand it from the others, but from my own brother?? Mail-from: MIT-ML rcvd at 28-FEB-79 2239-PST In reply to david at UTEXAS message of 28Feb79at1934-CST Cc: msggroup at MIT-ML CBF@MIT-MC 03/01/79 01:30:46 Re: Simple FINGER Limits The idea that the operating systems not be modified to conceal the information one wishes to conceal, but instead the finger program control the flow of that information simply will not work. If one person on a machine writes or acquires a program to collect this information, he can let everyone else use it. (It might not be worth it for someone to watch your house 24 hours a day, but suppose I offered a service which offered to give out your whereabouts free of charge?) -------------------- 5-MAR-79 23:04:12-PST,507;000000000001 Date: 2 MAR 1979 1122-PST Subject: MSGGROUP# 873 No flames; technical question From: WEISSMAN at I4B-TENEX To: MSGGROUP at ML Cc: WEISSMAN at I4 Without fanning the flames of controversy, allow me to ask a question I've wondered about for some time; you people seem like ones who might know the answer: when running Tenex MAILER as a user program, it always tells me "No acknowledgements for Weissman." Does anyone know how to activate and use this "acknowledgment" feature on Tenex? -- Bob 5-MAR-79 23:04:12-PST,809;000000000001 Mail-from: MIT-ML rcvd at 2-MAR-79 1203-PST Date: 2 Mar 1979 1141-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 874 Re: No flames; technical question From: the tty of Geoffrey S. Goodfellow To: WEISSMAN at I4B-TENEX Cc: MSGGROUP at ML, WEISSMAN at I4 Message-ID: <[SRI-KA] 2-Mar-79 11:41:58.GEOFF> In-Reply-To: Your message of 2 MAR 1979 1122-PST Reply-to: Geoff @ SRI-KA When TENEX mail has a queued mail file that fails for some reason or other it mails you back a note in your mail file to that effect. If for some reason your mail file is busy or unaccessable at the time it created an unsent negative acknowledgement file file for you, which it also sacns for on each run, either when you run it by hand or when the system background mailer wakes up every 10 mins. 5-MAR-79 23:04:12-PST,5599;000000000001 Date: 3 Mar 1979 0021-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 875 Levity, on the lighter side of mail delivery with the Subject: Postal Service. a commentay on current affairs From: Mike Royko To: Msggroup at ML Message-ID: <[SRI-KA] 3-Mar-79 00:21:05.GEOFF> Reply-to: Geoff @ SRI-KA BY MIKE ROYKO (c) 1979 Chicago Sun-Times CHICAGO - I have no medical evidence to support this theory, but I'm convinced that one of the biggest single causes of mental illness in this country is the federal bureaucrat. The more they increase in number and power, the more we have to deal with them. And the more we deal with them, the crazier they make us. Gwen Nobbe is an example. Normally, she is a calm person. But after her experience with some postal employes, her eyes began to get wild and her voice rose in pitch. Ms. Nobbe, who works for a business publication, lives in a North Side apartment building. She recently noticed that she had not received any mail for almost two weeks. No bills, letters - nothing. Because she was expecting a check, she finally went to the Lake View Branch of the Postal Service to ask what the problem was. She walked up to a woman at the counter and asked if she would check to see if there was anything addressed to her. The woman said: ''What makes you think we have any mail here for you?'' ''Because I'm not getting any mail delivered.'' The woman said: ''We aren't general delivery. I can't hand you your mail. It has to be delivered.'' Another employe, a man who was standing nearby, said her mail was probably not being delivered because there was snow on the sidewalk. He said postal carriers don't have to deliver mail where there is snow. Ms. Nobbe said that the sidewalk outside her building was clear enough for her to walk on, and asked if he could at least look to see if there was anything being held there for her. The man went into a room, came out and said, yes, she had mail. ''Then let me have it.'' He said that was impossible. The mail had to be delivered. ''If you hand it to me, it will be delivered,'' said Miss Nobbe. ''No. It has to be delivered to your address. It is not my job to hand it to you.'' ''But they aren't delivering it. If you won't deliver it, why can't you hand it to me? It's got my name on it.'' ''I am sorry,'' the man said, ''but that is not possible.'' Ms. Nobbe then phoned the main post office and talked to the supervisor of customer complaints. He said her mail wasn't being delivered because of snow on the sidewalk. She says he told herBYou people have to take the responsibilit- y. If there is snow on the walks, we don't have to deliver. And they don't have to hand it over to you at the post office.'' She responded: ''That is ridiculous. I live in an apartment and our walk has been shoveled. It's much better than those in front of a lot of businesses in the area. I don't have any trouble walking on it.'' The downtown bureaucrat said there was nothing he could do. After Ms. Nobbe told us the story, we called the supervisor of customer complaints, whose name is James Paige. ''Yes, there was a woman who called,'' he said. ''I told her that if there is snow, we do not deliver. We do not want to endanger the lives of our carriers.'' You mean there is no way she can get her mail? She can't get it if she goes to the post office branch? ''This is true.'' If they won't deliver the mail, and she can't get it by asking for it, how does she get it? ''I guess she is just going to have to clean her street.'' But that's silly. She is a tenant in a large apartment building. ''That's my point. I think she is just trying to lay something on the post office that is not our fault. She is blaming us. She comes crying to us for something her landlord should do.'' She says the sidewalk in front of her building is clean. ''Then it may not be her building that is causing the problem. It could be something up or down the street. If there is a big pile of snow there that endangers the life of the carrier, her mail will not be delivered.'' Even if it isn't in front of her building? ''That's right.'' Then what can the poor woman do to get her mail? ''She can get it anytime she can get the city and her landlord to clean up the street.'' But the people at the branch post office won't hand it to her across a counter? ''No. That is not their job.'' And so Ms. Nobbe's mail just sits there because it is not someone's job to pick it up, walk 20 feet with it and hand it to her. Yet the Postal Service employs a supervisor of complaints whose job is to explain why somebody can't pick up the envelopes and hand them to her. The supervisor did suggest that there was one way citizens might pursuade the branch office to give them their undelivered mail. He said: ''It sometimes happens that somebody will go in there with a long tear hanging down from their eye, and a sad story, and somebody will take pity and give them the mail. But Lake View is not a general delivery office. They do not have to give somebody their mail if they ask for it.'' So if Ms. Nobbe goes back, weeping and wailing, and maybe threatening to leap off a bridge, they might take pity on her. On the other hand, they might just think she's crazy. And if she has to deal with any more people like them, she might be. (End missing.) *************** 5-MAR-79 23:04:12-PST,1915;000000000001 Mail-from: MIT-ML rcvd at 5-MAR-79 1750-PST Date: 5 MAR 1979 1732-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 876 Re: [MIT-MC]CBF;MSG LOG - ETC. From: STEFFERUD at USC-ISI To: CBF at MIT-ML Cc: MSGGROUP at MIT-ML Message-ID: <[USC-ISI] 5-MAR-79 17:32:30.STEFFERUD> In-Reply-To: Your message of 27 FEB 1979 0604-EST I AM BACK FROM MY TRIP, AND WANT TO THANK YOU FOR SETTING UP THE MSGGROUP@MIT-ML REBROADCAST ARRANGEMENT. SEEMS AT THIS POINT THAT IT WORKED JUST FINE. I AM PROCESSING THE MESSAGES, WHICH I FIND ARE ALL IN PROPER SEQUENTIAL ORDER SO I DO NOT HAVE ANY UNSCRAMBLING TO DO. WERE IT NOT FOR SOME OF THOSE BAD FORMATS AND MISSING SUBJECTS, THE PROCESSING BURDEN WOULD NOT BE TOO MUCH. LEST YOU ALL THINK I LIKE DOING THIS PROCESSING, LET ME DISABUSE YOU OF THE THOUGHT. I AM DOING IT AS MY CONTRIBUTION TO THE FIELD, NOT TO JUSTIFY A MAILBOX. I HAVE TOO MANY OTHER MAILBOXES ALREADY YET! ACTUALLY, WHAT I FIND AS A NON-HACKER, IS THAT THE STUPID TOOLS I HAVE TO USE ARE NOT ADEQUATE TO THE TASK OF INSERTING ACCESSION NUMBERS AND MASSAGING BAD FORMATS, OR INVENTING MISSING SUBJECTS, ETC. IF ANY HACKERS WANT TO VOLUNTEER SOME TENEX HACK BUILDING HELP, I WILL BE PLEASED TO DISCUSS WHAT I FEEL I NEED TO DO THE JOB. IN THE MEANTIME, I THINK THAT I BEST CONTINUE TO EXERCISE SOME INTELLIGENCE IN THE PROCESSING TASK. ACTULLY, I THINK THAT THE PROCESSING DONE IN MSGGROUP GIVES IT MORE OF A "PUBLISHING" TONE THAN CAN BE ACHEIVED WITHOUT IT. I SUSPECT THAT KEEPING THE MSGGROUP@MIT-ML REFLECTOR THERE IS A GOOD IDEA FOR THE TIME BEING CAUSE IT MAKES MY LIFE MUCH MORE PLEASANT. AS FOR THE PROPENSITY OF SOME OF OUR MEMBERS TO OMIT SUBJECT FIELDS, I SUGGEST THAT ALL OF YOU WHO WANT SUBJECTS SHOULD REPLY TO THE SENDERS OF SUBJECTLESS MESSAGES TO TELL THEM THAT YOU PREFER SUBJECTS. IT IS A PLEASURE TO BE OF SERVICE. STEF 5-MAR-79 23:04:12-PST,1112;000000000001 Date: 5 Mar 1979 1842-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 877 Re: [MIT-MC]CBF;MSG LOG - ETC. From: the tty of Geoffrey S. Goodfellow To: STEFFERUD Cc: CBF at MIT-ML, MSGGROUP at MIT-ML Message-ID: <[SRI-KA] 5-Mar-79 18:42:55.GEOFF> In-Reply-To: <[USC-ISI] 5-MAR-79 17:32:30.STEFFERUD> Reply-to: Geoff @ SRI-KA One of the main offendors of non-subject msgs are those from ITS since you must explicitly type Escape S to get it to prompt you for a subject, and most other mail systems i am aware of ask you for a subject, which i think is a completly reasonable thing to do. Perhaps ITS MAIL might consider prompting for a subject line? I also might add that SAIL's mail program did this too, so if one types MAIL it asks for TO: and Subject:, and also if one types MAILlist-of-addresses it asks for a subject before you enter the msg, however if you say MAILaddressesmessage followed by more msg or meta-lf to end msg input it doesn't ask for a subject, hence this lets people who don't want to prompted with a subject no be. 5-MAR-79 23:04:13-PST,1464;000000000001 Mail-from: MIT-ML rcvd at 5-MAR-79 2003-PST Date: 5 MAR 1979 2217-EST Subject: MSGGROUP# 878 Let's go without subjects till someone fixes all our Subject: systems to use the first line of text From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC Redistributed-To: msggroup at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 5 Mar 1979 If I found :MAIL prompt me for a subject, I would probably be taken aback and need half a minute to figure out what I was doing again. To eliminate this problem I would train myself to ignore it. The result would be that the first line of my message would appear as the "subject". This might not be so bad. However, if it were going to do that, I would rather not have it bother me about it. I also wouldn't want the fact that the first line of my message was thought of as the "subject" to prevent me from rubbing out back into it in the way I otherwise could. I still think, though, that people should change mail readers to report the first line of the message as the subject, in summaries, if that's what they want. That is what ITS does. Once in a while I have something I consider a useful subject, but for the most part I don't have anything that feels worth supplying and subjects in messages I receive are usually information-free. Therefore, I think that making a mail sender bother the user for a subject will just get in the way of getting work done. 5-MAR-79 23:04:13-PST,1180;000000000001 Mail-from: MIT-ML rcvd at 5-MAR-79 2102-PST Date: 5 MAR 1979 2025-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 879 RMS on why bother? From: STEFFERUD at USC-ISI To: RMS at MIT-AI Cc: header-people at MIT-MC Message-ID: <[USC-ISI] 5-MAR-79 20:25:47.STEFFERUD> In-Reply-To: Your message of 5 MAR 1979 2217-EST Redistributed-To: msggroup at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 5 Mar 1979 MsgGroup contributions are kept in more or less organized form for later reference. did you not know you are talking into a recording device when you flame into MsgGroup? Cheers - Stef - - - - - - - - - - - - - - - - - - - - 453 chars/ 3 Date: 5 MAR 1979 2218-EST From: RMS at MIT-AI (Richard M. Stallman) - - To: Stefferud at USC-ISI Now that we have CBF;MSG LOG, why is it necessary for you to do any editing on it? Why not just let people read it as is? I hope it doesn't make you feel bad to be "replaced by a computer", but it sounds like you don't think that task is much fun, anyway. Does the transcript get printed and published? *** TRAILER *** Mail-from: MIT-AI rcvd at 5-MAR-79 1919-PST *** END /# 3 8-MAR-79 18:01:00-PST,821;000000000000 Mail-from: USC-ISI rcvd at 6-MAR-79 1031-PST Date: 6 MAR 1979 1031-PST Sender: STEFFERUD at USC-ISI Subject: MSGGROUP# 880 [isi]FINGER.MSG#794-#NNN & ...PRT#794-#NNN From: STEFFERUD at USC-ISI To: [ISI]Mailing.List;182: Message-ID: <[USC-ISI] 6-MAR-79 10:31:37.STEFFERUD> I HAVE PROCESSED THE ONSLAUGHT AND HAVE CONSOLIDATED THE FINGER EXERCISE INTO ONE FILE OF MESSAGES AND A CORRESPONNDING TEXT FILE SUITABLE FOR PINTERS WITH ^L PAGE SEPARATION, ET AL. THE TWO FILES ARE: [ISI]FINGER.MSG#794-#NNN;1 (IN MESSAGE FILE FORMAT) AND [ISI]FINGER.PRT#794-#NNN;1 (IN TEXT FILE FORMAT WITH ^L) I HAVE DONE THIS TO EASE THE PROBLEMS OF FTP ACCESS AND TO EASE THE PROBLEMS OF PRINTER FORMATTING FOR THOSE WHO ARE NOT USING TENEX/TWENEX SYSTEMS. BEST - STEF 8-MAR-79 18:01:01-PST,2474;000000000001 Mail-from: MIT-ML rcvd at 6-MAR-79 2243-PST Date: Tuesday, 6 Mar 1979 1820-EST Subject: MSGGROUP# 881 ARPA "order" (TO REMOVE TWO NAME FROM FIELDS) From: Howard Wactlar at CMU-10A (S300HW09) To: RDMAIL at CMU-10A, bajzek at CMU-10A Message-ID: <06Mar79 182009 HW09@CMU-10A> Remailed-To: RdMail-Maintainers: (RDHACK.DST[A800RD00]) Rdmail at CMU-10A, Remailed-To: Craig Everhart at CMU-10A, David Lamb at CMU-10A, Remailed-To: Philip Lehman at CMU-10A, Bruce Nelson at CMU-10A, Remailed-To: Brian Reid at CMU-10A, Karlton @ PARC-MAXC, Remailed-To: Sapsford @ PARC-MAXC; Remailed-To: MsgGroup at ML, Header-People at MC Remailed-From: RdMail at CMU-10A Remailed-From: RdMail at CMU-10A Remailed-Date: Wednesday, 7 Mar 1979 0058-EST Remailed-Date: Wednesday, 7 Mar 1979 0124-EST People, We have been officially asked by ARPA, through Duane Adams, program manager in their IPT office, to eliminate two-name from fields in mail we transmit. There was appropriate recognition that it was within the defined 733 spec, but that NOBODY benefitted by our using it. How about going back to placing a period between first and last names instead of a space when both first and last names are non-empty (i.e. no period if the first name is empty). How about getting it done as soon as reasonable. We made our point, now lets concede the issue and give the others on the net what they can all handle. If you have any technical or philosophical difficulties with the change, come talk to me (or send flaming mail if that makes you feel better). Thanks much, Howard - - - - Begin forwarded message - - - - Date: 6 MAR 1979 0703-PST Sender: ADAMS at USC-ISI Subject: Re: And Hermes' not handling multi-word mailbox names From: ADAMS at USC-ISI To: dcrocker at RAND-UNIX Cc: Adams, Farber at SRI-KA, Wactlar at CMU-10A, Mooers at BBNA Message-ID: <[USC-ISI] 6-MAR-79 07:03:20.ADAMS> In-Reply-To: Your message of Sat, 3 Mar 79 15:06-PST Dave, Requesting a change to Hermes to handle a two-name from field is exactly the kind of change I want to avoid requesting maintainers of message systems to have to incorporate. Here the corrective action is obvious-- those who use two-name from fields will remove them from their message systems. I have already asked Howard Wactlar of CMU to remove this feature from their system. Duane - - - - End forwarded message - - - - 8-MAR-79 18:01:01-PST,1849;000000000001 Mail-from: MIT-ML rcvd at 6-MAR-79 2332-PST Date: 7 Mar 1979 0218-EST From: Richard H. Gumpertz at CMU-10A Subject: MSGGROUP# 882 Re: ARPA "order" and white-space in names Sender: Rick Gumpertz at CMU-10A To: Howard Wactlar at CMU-10A (S300HW09) CC: ADAMS at USC-ISI, MSGGROUP @ MIT-ML, Header-People @ MIT-MC, Newcomer at CMU-10A, Reid at CMU-10A Reply-To: Gumpertz (who has a first name AND a middle name!) at CMU-10A Message-ID: <07Mar79 021843 RG02@CMU-10A> In-Reply-To: <06Mar79 182009 HW09@CMU-10A> Damn it this annoys me. I have two names (well really three) and there is no period after the first. There is both a period and white-space after my middle initial. Although I have been compliant (complacent?) enough to list only my last name in mail addresses for me, I am seriously considering changing that just to be rebellious. Any time one requests that one avoid a standard, one is in a very questionable position. I just can't believe that some hacker on TENEX can't fix the problem somehow. Perhaps by internally changing spaces to something like # when queueing mail and then changing them back when actually transmitting it. (I am working under the assumption that the problem is that queueing is via file names which can't include blanks, or some such thing -- my best recollection of an old explanation I once saw.) Being depersonalized by a computer is bad enough; being stomped on one more time by TENEX is absolutely infuriating. Perhaps it is appropriate that TENEX was invented by a company whose initials can stand for BIG BAD NEIGHBOR. I have not been this mad in some time. What the hell do we develop standards for, if we will be asked not to use them? Richard H. Gumpertz An aside to Charlotte Mooers: what does Calvin think of all this? 8-MAR-79 18:01:01-PST,1292;000000000001 Mail-from: MIT-ML rcvd at 7-MAR-79 0033-PST Date: Wednesday, 7 March 1979 03:21-EST From: MTRAVERS at BBN-TENEXD (Mike Travers) Subject: MSGGROUP# 883 Re: ARPA "order" and white-space in names To: Gumpertz at CMU-10A Cc: Howard Wactlar at CMU-10A, ADAMS at USC-ISI, MSGGROUP at MIT-ML, Cc: Header-People at MIT-MC, Newcomer at CMU-10A, Reid at CMU-10A In-reply-to: Your message of 7-Mar-79 0218-EST In point of fact, TENEX and TOPS20 are perfectly capable of having spaces in file names, by quoting them in the same manner in which lowercase chars are quoted. Making the mail systems such as HERMES capable of generating such files is another matter, of course. Also in regards to RFC733 and ARPA policy, I was told (indirectly) that ARPA does NOT plan to make this a bonafide, standardized standard, and they are going around telling people not to bother upgrading their software to handle/generate RFC733 messages. The mailsystem I use has just been modified to conform to RFC733, and I find it extremely annoying that now that I have conformed to the standard, I get complaints from HERMES users that they can't parse my messages, and HERMES people tell me they are not supposed to fix it. Does anyone know more about this situation? --Mike ------- 8-MAR-79 18:01:01-PST,3221;000000000001 Mail-from: MIT-ML rcvd at 7-MAR-79 0813-PST Date: 7 MAR 1979 1029-EST From: Charles Frankston at MIT-MC Subject: MSGGROUP# 884 MORE RE ARPA ORDER AND WHITE SPACES IN NAMES Sent-by: CBF at MIT-MC To: Richard H. Gumpertz at CMU-10A, Howard Wactlar at CMU-10A CC: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-ML CC: Joe Newcomer at CMU-10A, Brian Reid at CMU-10A, ADAMS at USC-ISI If what is being said about this "ARPA order" is true, I find it disturbing. Firstly, RFC733 was one of the most democratically adopted standards I know of. I don't really care if it has been "blessed" by the Arpa bureacracy or not. Its design at least had widespread input and comment. The standard may not be universally loved, but it has been pointed out before that almost all of the non-Tenex/Tops-20 sites have taken steps toward adhereing to it. Now, we hear that some bureaucrat has ordered that CMU cannot do something that RFC733 specifies as legal, presumably because his (and perhaps other) mail reading program cannot handle them. Also presumably, these mail reading programs run on Tenex/Twenex, the operating system Arpa has tried so hard to get CMU, MIT and Stanford to run as the network standard operating system. Fine network standard operating system. The system with the most installations on the network, that in total most recieve the most Arpa support, cannot find the manpower to correctly implement a widely adopted network standard. I would like to hear Arpa's official position clarified soon. I think it is a very poor idea for them to simply decide that one aspect of the standard is null and void. That jeapordizes the whole idea of decent coherent standards and threatens to push us back to the dark ages before RFC733 when a new mail system implementor could first review a bunch of contradictory, incomplete and confusing standards, and then have to take a survey of the network to find out how many different ways it was implemented. I should point out that the change being demanded is retrogressive. It takes away capabilities. I point this out mainly to differentiate this "order" with the request the ITS and Multics sites have been making to support a progressive change to allow structured recipients. (Note, the structured recipient request was made during the drafting of RFC733 and ignored by the committee supposedly chosen by Arpa to draft the standard. I presume no one asked for the space restriction then, because I cannot believe that committee would have adopted something so difficult to implement on Tenex, but perhaps I am wrong). In any event, I will admit the point to be minor, and CMU could probably live without it. In fact, the ITS rmail program never was modified to reply them correctly either, because the change was actually somewhat painful. This dicussion have motivated me to rectify that. As of today, ITS Rmail will correctly reply to CMU headers. The pain proved to be about 2.5 hours worth of work. Thanks to Dave Moon, MC will now recieve incoming mail to addresses with imbedded spaces (he did that in about 5 minutes I guess). The rest of the ITS sites should do the same in a few days. 8-MAR-79 18:01:01-PST,956;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 1216-PST Date: 7 MAR 1979 1129-EST From: EAK at MIT-MC (Earl A. Killian) Subject: MSGGROUP# 885 ARPA "order" Costs - - Pro & Con To: HEADER-PEOPLE at MIT-MC Redistributed-To: MSGGROUP at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 7 Mar 1979 I've been wondering in all the flurry of messages about flushing RFC733 whether that's actually more work than fully adopting it. For example, did the people that asked CMU to stop sending its two word names consider the possibility that it might be more difficult stop what they're doing now than it would be to fix Hermes? Btw, I'd be interested to hear from the CMU people if ARPA is going to provide funding for them to remove their two (or more) word names from ARPAnet headers. If the Hermes people can use "lack of funding" as an excuse for not implementing them, then can't CMU use the same excuse for not de-implementing them? 8-MAR-79 18:01:02-PST,3697;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 1302-PST Date: 7 Mar 1979 1114-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 886 ARPA "orders", white-spaces, RFC733 and HERMES. From: the tty of Geoffrey S. Goodfellow To: Adams at ISI Cc: Everhart at CMUA, Lamb at CMUA, rdmail at CMUA, Cc: Newcomer at CMUA, MSGGROUP at ML, Header-People at MC Message-ID: <[SRI-KA] 7-Mar-79 11:14:21.GEOFF> Reply-to: Geoff @ SRI-KA Duane; I would like to ask you to please reconsider your asking CMU to eliminate the two-name field (also referred to as the "white-space") from mail they transmit. Currently what CMU does is completely legal within the "THE STANDARD" -- RFC733. I think it is rather unjust of you to ask them to remove the two-name field from mail they send just because HERMES (which, by the way, I use as well) cannot parse their headers when you try to use the REPLY command on such a message, but rather the correct and right approach would be to have the HERMES maintainers (BBN) modify HERMES to handle the "completely legal" headers they send. This brings me to the point of HERMES and RFC733 in general. Currently, I believe that HERMES does not support RFC733 at all, and in fact, in some ways actually violates it! An example of this would be if you were to REPLY to this message, HERMES would get my name NOT from the "REPLY-TO:" field as it should, but from the "SENDER:" field, which, according to the standard, is explicitly prohibited. Hence, i think it is rather important that HERMES be made 733 compatible. If that was the case today, you wouldn't have the problem you now have with CMU. One of the big problems with getting this done as I have come to understand it is that BBN will not touch HERMES or improve it unless you wave the almighty dollar (aka funding) in front of them. I for one would be curious to know just how many sites that do support RFC733 were funded by ARPA to do so, or even more interesting would be just how many sites that have any type of a mail system at all were funded by ARPA to design, code, debug, implement, maintain and have a running mail facility that allows them to communicate with users on their host computer as well as with the rest of the network? I would suspect there is only one possible and that being TENEX, even though i understand SNDMSG (first TENEX mail sending program) came about originally just as every other mail system on the network: Out of the pure NEED for one user to communicate with another, and then when hooked up to the network, the sites mail system wizard spent his own time, or on the time of the org. he works for making his mail system talk to the ARPANET. On the subject of RFC733, simply put/asked: JUST IS IT A STANDARD OR NOT? Jon Postel says it is, and he is the keeper and final word on standard right or wrongs, that i am currently aware of. Yet, others have told me, and i have heard rumblings from various corners of the net, that NO , 733 is not a standard. Please, tell us, for once, and for all, which it is? I presume, at least, that you are the person who has that say-so? Lastly, on the subject of HERMES, 733, et al. If BBN is unwilling to modify HERMES to handle CMU's two-name from field (and support RFC773 totally, without mega dollars flowing forth) at least have BBN make the sources for HERMES available so that gainful hackers like myself and others who enjoy doing things out of the pure interest of network standardization and for the sheer "fun of it" can FREELY do so, without have to tolerate institutions that refuse to do such things because they are not funded to. geoff 8-MAR-79 18:01:02-PST,4484;000000000001 Mail-from: CMU-10A rcvd at 7-MAR-79 1402-PST Date: Wednesday, 7 Mar 1979 1658-EST From: David Lamb at CMU-10A Subject: MSGGROUP# 887 The ARPA whitespace "order" Sender: RdMail at CMU-10A To: Header-people @ mit-mc, MsgGroup @ usc-isi CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A, Nelson at CMU-10A Message-ID: <07Mar79 165838 RD00@CMU-10A> CMU will be complying with ARPA's request to remove whitespace in names generated by our RDMAIL program. I hope to head off what could turn into an acrimonious debate by explaining why we are doing so. When CMU converted to full compatibility with RFC733, we also began to make use of a number of the facilities that a number of other sites hadn't implemented. For example, we supplied an option to include a user's login PPN as a comment, for cases where someone had many accounts and wanted to let his friends see which hat he was wearing this week. Some sites didn't parse that sort of thing, so people who wanted to communicate with such sites simply turned off the option. We also decided to use a person's full name as the "recipient" portion of a local mail name. We have many cases where people with the same last name both have accounts. Having the two names separated by a space rather than a dot seemed like a nice piece of human engineering that was allowed by the standard, at least as we read RFC733. Unfortunately, a lot of other sites didn't see the standard as allowing that, and so didn't include it in their mail systems (I am told it isn't just Hermes, so I see no good reason for singling Hermes out. It merely happens that Hermes users were more vocal in their complaints). We weren't simple ordered by ARPA to make the change. It was discussed with our local site manager. CMU is the only site on the net which generates recipients with imbedded spaces. From the point of view of anyone managing time or money, it makes more sense to have one site make a change rather than many, especially if the change is as small as this one is (I expect to take a total of about 1/2 hour to make the change). It bothers me to some extent that ARPA seems to be "revising" the "standard", making "retrogressive" changes. I sympathise with anyone who feels like their democratically-arrived-at standard is being changed by apparently arbitrary bureaucratic fiat. But there is a whole other way of looking at the situation. From the point of view of the ARPA people who made the request, there was a protocol problem that was interfering with people's work, making some network communication difficult. Given the problem, the least expensive way to fix it was to ask the single site to change, rather than the many. It is certainly possible to bewail the degree to which people violate the RFC733 standard. On the other hand, it should be obvious from the recurrent heated debates that RFC733 is easy to misinterpret. It's easy to point the finger at someone and say "you are violating paragraph 3.4.1 of the standard", but that still leaves the practical everyday problems of finding someone with time, energy, and willingness to do the programming to make the change. I'm willing to fight for conformity when the piece of the standard in question is important to me, but parenthesised comments and blanks in names just aren't significant enough to me to fight for. I also can't believe it will get us anywhere to accuse Hermes sites of laziness (or whatever). Even if Hermes is the only system that has trouble with CMU headers, the fact that the problem has to be fixed on many sites means it's more work than fixing it here. Even if one site changes the source and passes on the change, there's more work. I am speaking here of this one change, which is probably fairly easy to make at either end; a big enough improvement in functionality would make that kind of multisite change worthwhile. I don't think that anyone need worry too much that ARPA might be "sabotaging" RFC733. The requested change is small; it's a direct result of the January meeting; it's one of the few RFC733-related problems that have really been interfering with communication. I'd rather not be included in direct replies to this note; I see everything that gets sent to the CMU RDMAIL account, which includes everthing that goes to the MSGGROUP and HEADER-PEOPLE mailing lists. David Alex Lamb 8-MAR-79 18:01:02-PST,1205;000000000000 Mail-from: CMU-10A rcvd at 7-MAR-79 1512-PST Date: Wednesday, 7 Mar 1979 1743-EST From: Brian K. Reid Subject: MSGGROUP# 888 Header People, RFC733, etc. To: Header-people @ mit-mc, MsgGroup @ usc-isi CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A, Nelson at CMU-10A Message-ID: <07Mar79 174335 BR10@CMU-10A> In-Reply-To: <07Mar79 165838 RD00@CMU-10A> I am pretty bummed out at all of the time that I have wasted on this "standard", and I suspect that Dave, Jon, and company are even more bummed out by it all. I think that CAHCOM had absolutely no business soliciting help from the Arpanet community in the design of this standard, letting hundreds of man-hours get spent fine-tuning a very nice, reasonably consistent, and very usable standard, and then abandoning it. Human-readable but machine-processed ASCII headers are the wrong way to do computer mail anyhow; perhaps the general low quality of the current Arpanet mail systems that is resulting from our having to be compatible with this incompetent Hermes program will ultimately end up being a blessing, resulting in a redesign instead of an incremental upgrade. Brian 8-MAR-79 18:01:02-PST,2204;000000000001 Mail-from: MIT-AI rcvd at 7-MAR-79 2014-PST Date: 7 MAR 1979 2311-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP# 889 Header People, RFC733, etc. To: MsgGroup at USC-ISI, Header-people at MIT-MC CC: Wactlar at CMU-10A, Everhart at CMU-10A, Lehman at CMU-10A CC: Nelson at CMU-10A Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 7 MAR 1979 Using the first name as well as the last one is certainly a good idea. It's one of Tenex's real losses that (at most sites) it ALMOST lets you refer to a person by his last name - but maybe you have to use his initial as well, and how can anyone predict? Maybe his login is his last name, or maybe it's his initial and last name. Whereas ITS and CMU, where the login and last name are usually or always different, don't have available any easy way out that only almost works, so they have special provisions that really do let you refer to a person by last name in mail. But that still leaves a problem of disambiguation. Only CMU has implemented a reasonable solution to the problem. I think that the CMU way is the only really right way to deal with it: let a person give the last name, or both names, and win as much as possible with whatever it gets. What COMSAT does is, if you send a message to an ambiguous lastname such as Frankston, send the message to all of the possibilities, which solves things for the most part but is clearly not right. To ask for the only winning solution to the problem to be banned because it is ahead of the rest of the world is stifling and wrong. And I can speak as one whose mail reader didn't (until yesterday) understand CMU headers: I would rather have my own system lose on them indefinitely and hope to make it win someday (as it finally does) than ask someone else to lose for my sake. The Tenex people who aren't willing to do as much for someone else's winning idea deserve no sympathy. The way to resolve such disputes between different systems is simple: change whichever ones don't do things right. Assuming you believe that progress beyond the current perfection is possible. 8-MAR-79 18:01:02-PST,573;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 2035-PST Date: 7 MAR 1979 2319-EST From: JNC at MIT-AI (J. Noel Chiappa) Subject: MSGGROUP# 890 Livable Computers & all that... To: Rick Gumpertz at CMU-10A Remailed-To: MsgGroup @ MIT-ML, Header-People @ MIT-MC Remailed-From: Rick Gumpertz at CMU-10A Remailed-Date: 7 Mar 1979 2321-EST Incredible!! We finally get a computer mail system that will handle peoples NAMES, for God's sakes, and it gets flushed. Foo! We DESERVE to be looked at as inhuman etc. etc. Noel PS Keep.it.up.withe.the.".".action..I.love.it!! 8-MAR-79 18:01:03-PST,714;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 2055-PST Date: 7 Mar 1979 2240-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 891 RFC733 compliance To: Header-People at MIT-MC Message-ID: <07Mar79 224039 RG02@CMU-10A> Redistributed-To: msggroup at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 7 Mar 1979 I.have.a.couple.questions.that.might.be.able.to.elicit.some.useful.information: 1).Why.can't.Hermes.be.easily.modified.to.handle.the.spaces?..What.is ...the.technical.obstacle? 2).Who.maintains.Hermes?..Is.it.multiple.persons?..Have.they.no.funding ...or.is.that.a.red-herring? 3).What.systems.besides.Hermes.have.trouble.with.white-space,.if.any? ................Rick 8-MAR-79 18:01:03-PST,1649;000000000001 Mail-from: CMU-10A rcvd at 7-MAR-79 2056-PST Date: Wednesday, 7 Mar 1979 2351-EST From: David Lamb at CMU-10A Subject: MSGGROUP# 892 CMU mail names Sender: RdMail at CMU-10A To: RMS at MIT-AI (Richard M. Stallman) CC: MsgGroup @ usc-isi, header-people @ mit-mc Message-ID: <07Mar79 235139 RD00@CMU-10A> In-Reply-To: Richard M. Stallman's message of 7 Mar 79 23:11 Redistributed-To: MSGGROUP at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 7 MAR 1979 ARPA isn't really asking us to get rid of our first names (at least, as I interpret the request); they merely want us to send David Lamb at CMU-10A as David.Lamb at CMU-10A which, as you might suspect, is a trivial change for us to make. We still have some loopholes we don't intend to change that allow C410BR10 to appear as "Brian K. Reid" instead of "Brian.Reid", but that comes down to a personal decision on the part of individual people to generate headers that Hermes can't handle. All we are doing is making the default behaviour something that (a) Hermes can handle (b) isn't too different from what we have now. I do appreciate your praise of our mail names, though. Even though our login names are horrid, our Mail system, Finger program, and Systat all manage to treat people as names rather than bizarre character sequences. There's even some hope of eventually being able to log in via name rather than by CMU PPN, but that's a lot more work than we can foresee in the near future. It's all done via table lookup in a large binary file, but even so seems to work well and reasonably efficiently. 8-MAR-79 18:01:03-PST,511;000000000001 Mail-from: MIT-ML rcvd at 7-MAR-79 2112-PST Date: 7 Mar 1979 2230-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 893 Re: The ARPA whitespace "order" To: David Lamb at CMU-10A CC: Header-People @ MIT-MC Message-ID: <07Mar79 223057 RG02@CMU-10A> In-Reply-To: <07Mar79 165838 RD00@CMU-10A> Redistributed-To: msggroup at ML Redistributed-By: GEOFF at SRI-KA Redistributed-Date: 7 Mar 1979 David.- Just.for.the.record,.I.think.you.are.making.a.big.mistake. ................Rick 8-MAR-79 18:01:03-PST,553;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 2226-PST Date: 8 Mar 1979 0015-EST From: Rick Gumpertz at CMU-10A Subject: MSGGROUP# 894 Redistribution To: GEOFF at SRI-KA CC: Header-People at MIT-MC, MsgGroup @ mit-ml Message-ID: <08Mar79 001529 RG02@CMU-10A> Geoff - I tend to choose my destinations carefully. In particular, I saw no reason to distribute some of my latest mail to MsgGroup. I am trying to keep down the amount of junk mail. Please refrain from redistributing mail unless you have a good reason. Rick 8-MAR-79 18:01:03-PST,623;000000000000 Mail-from: MIT-ML rcvd at 7-MAR-79 2242-PST Date: 7 Mar 1979 2121-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 895 Re: Redistribution From: the tty of Geoffrey S. Goodfellow To: rg02 at CMUA Cc: Header-People at MIT-MC, MsgGroup at MIT-ML Message-ID: <[SRI-KA] 7-Mar-79 21:21:30.GEOFF> In-Reply-To: <08Mar79 001529 RG02@CMU-10A> Reply-to: Geoff @ SRI-KA good reason: no one on header people would beable to answer your questions about HERMES policy issues, re: why.cant.hermes.be.modified.to.handle.spaces.and.who.maintains.hermes. things.for.people.not.on.header.people,like.adams.and.other.bbn.folk. 8-MAR-79 18:01:03-PST,414;000000000001 Mail-from: MIT-ML rcvd at 7-MAR-79 2306-PST Date: 8 March 1979 01:41-EST From: Richard M. Stallman Subject: MSGGROUP# 896 Horrible Erroneous Reply-program ... Subject: Making Everyone Squirm To: msggroup at MIT-ML Would anybody who knows where the sources for HERMES live please say where, so that the various Twenex hackers can fix the bugs that BBN refuses to fix? 8-MAR-79 18:01:03-PST,638;000000000001 Mail-from: MIT-ML rcvd at 7-MAR-79 2324-PST Date: Thursday, 8 Mar 1979 0211-EST From: Brian K. Reid Subject: MSGGROUP# 897 Re: Horrible Erroneous Reply-program ... Subject: Making Everyone Squirm To: Richard M. Stallman CC: msggroup at MIT-ML Message-ID: <08Mar79 021117 BR10@CMU-10A> In-Reply-To: Richard M. Stallman's message of 8 Mar 79 01:41 Those aren't bugs, they are carefully crafted features. Besides, I'll bet you a dollar that it's copyrighted, protected, trade-secreted, patented, encrypted, and otherwise kept proprietary, to protect its wonderfulness. 8-MAR-79 18:01:03-PST,1065;000000000000 Mail-from: MIT-ML rcvd at 8-MAR-79 0411-PST Date: 8 Mar 1979 0404-PST From: Mark Crispin Subject: MSGGROUP# 898 A plea for sanity To: Header: ;, Header-People at MIT-MC, MsgGroup at MIT-ML Please, let's stop sending messages to both MsgGroup and Header-People. It is getting awfully silly getting four or five copies of the same message. Let's leave outrageous flaming messages with Header-People where they belong and not assault MsgGroup with the crud. I really think that MsgGroup exists for other purposes than flaming. My mailbox is growing on the average of 50 messages/day due to this multi-forwarding. And please, no comments about message-id's; instead of kludging around extra message copies let's not send them in the first place!! I hope I'm not going to get infinite retributions about being hypocritical by sending this message to both. I might as well do it rather than let somebody else forward it with HERMES and add three or four more header lines to the nth extra copy. -- Mark ------- 8-MAR-79 18:01:04-PST,931;000000000001 Mail-from: MIT-ML rcvd at 8-MAR-79 1130-PST Date: 8 Mar 1979 1042-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP# 899 Re: Horrible Erroneous Reply-program ... Making Everyone Squirm From: the tty of Geoffrey S. Goodfellow To: RMS at MIT-AI Cc: msggroup at MIT-ML Message-ID: <[SRI-KA] 8-Mar-79 10:42:03.GEOFF> In-Reply-To: Your message of 8 March 1979 01:41-EST Reply-to: Geoff @ SRI-KA I strongly suspect that they are located in either or on BBNA, however, I am even more sure that they heavely protected and copywrited, since everytime one starts up HERMES it tells you that, and also i bet that BBN has their legal axe all sharpened up just ready to fall on anyone who attempts a rescue mission. It also is very interesting of note that BBN has not said a word to header-people or msggroup about any of this. Perhaps we have to fund a reply out of them? 8-MAR-79 18:01:04-PST,3622;000000000001 Mail-from: PARC-MAXC rcvd at 8-MAR-79 1427-PST Date: 8 Mar 1979 2:18 pm (Thursday) From: Karlton at PARC-MAXC Subject: MSGGROUP# 900 White space in tokens To: Header-People at MIT-MC, MsgGroup at USC-ISI cc: Wactlar at CMU-10A, RdMail-Maintainers: (RDHACK.DST[A800RD00]) cc: Rdmail at CMU-10A, Craig Everhart at CMU-10A, cc: David Lamb at CMU-10A, Philip Lehman at CMU-10A, cc: Bruce Nelson at CMU-10A, Brian Reid at CMU-10A, cc: Karlton @ PARC-MAXC, Sapsford @ PARC-MAXC; Redistributed-To: msggroup at ML Redistributed-By: STEFFERUD at USC-ISI (connected to MSGGROUP) Redistributed-Date: 8 MAR 1979 People and Flamers, I have enjoyed the conversations over the past couple years going through Header-People and MsgGroup and I wish once again to add a comment. A great deal of time and effort went into constructing RFC733. Many hard feelings were smoothed only due to the passage of time. The important thing is that a useable (not the end-all, be-all) standard was generated. This was done under the guise that the final result would become a recognized standard. I was assured of this more than once. In fact, my introduction to Header-People was because of complaints that CMU was not in compliance with RFC561. RFC724, a precursor to 733, even had as a title "Proposed Official Standard for the Format of ARPA Network Messages." When I added 733 compatible headers to RdMail I really thought that it had become "Official". It is not necessary to have CMU prohibit the sending of mail that contains white space in the delivery tokens. The user can specify how he/she wants the name to appear in the outgoing messages. (There even exists a profile switch that will cause the CMU programmer-number to be used as the delivery token.) Any user at CMU that wishes to generate First.Last instead of First Last can do so (and is not a particularly onerous task, but does involve the spending of the time to do so). Allow me to quote from the November 1978 version of the RdMail manual. If you do a lot of communicating with people at TENEX sites, it is suggested that you have no embedded blanks in your name-- use periods instead. This was done since the then existing systems (soon to be replaced!) could not cope with embedded spaces. I really am at a loss as to why HERMES is not fixed to handle this spaces. It was undergoing development at the time that 733 came out. It was written with the programming technology of 1975. I question the technical competence of a project leader that would allow the parser to be so inflexible that making this seemingly trivial change is a hard task. What has happenned to pride of craftmanship? No one builds bug free systems (in the technology available right now), especially those that have to deal with user interface issues. It has been my experience that any program that is being used all the time grows as its users' needs expand. Sometimes it is overwhelmed and a new program has to be written to take its place. PK p.s. RdMail-Maintainers: I request that you do not change RdMail so that people can no longer send out their names in the format that they wish. You might wish to undertake an education task at CMU, but please do not remove that feature from a program that I still consider (perhaps no longer rightfully) mine. If you still think that it is necessary to remove that feature, then I implore you to poll your users and ask them if they are willing to do without because those that communcate over the net are unwilling to learn how to set their user profile.