employees.org

Operating Policy


"Anyone caught outside the gates of their subdivision sectors after curfew
will be shot." -- J. Biafra



employees.org Operating Policies


All employees.org users are expected to follow these policies.
Read them, and be sure you understand them, before you apply for an account.



Throughout this document, "we" and "us" refer to the Ruling Oligarchy of the Employee Net Server Cooperative, acting in our capacity as administrators of the employees.org system. "You" refers to the user of the employees.org system.


Account Availability


Unless resource constraints make it impossible to create new accounts, employees.org accounts are available to all employees (and contractors of over 90 days' standing, who are to be considered employees for the purposes of this policy) at covered companies, and to designated members of their families. Accounts may be granted to others at the discretion of the administrators.

At present, we offer employee accounts on the "credit union principle". Once you have an employees.org account, the account remains yours even if you (or your family account sponsor) later change jobs. We may change this policy in the future if it causes administrative headaches or creates a resource problem.

Because of accountability concerns, each employees.org login account belongs to a single, specific, individual person. We do not permit accounts that are used for login by more than one person. "Functional" accounts belonging to software exist, but are accessed through "op" or a similar mechanism, never logged into directly.

There is no fee for having or using an employees.org account.

We may cancel accounts because of system abuse. We may refuse to create new accounts because of past abuse by the applicant or any of her family members.


Accounts for Family Members


employees.org accounts are available for family members of employees of covered companies, regardless of whether the employees in question themselves have accounts. An employee may designate up to 5 family members to receive employees.org accounts. An employee who does this is called a "sponsor" of the designated family members' accounts.

Only employees of covered companies may sponsor family accounts. People who receive sponsored family accounts may not sponsor further "subsidiary" family accounts of their own. Furthermore, should you resign or be terminated, your ability to sponsor new family members ends with your employment, even though neither your own existing accounts nor those of your already-sponsored family members are generally affected.

A sponsored family member may have multiple accounts, just as any other employees.org user may.

Each sponsor is free to decide whom she considers to be part of her family; no particular legal or biological relationship is required. We expect the group to include only people with whom the sponsor has lasting bonds, not casual friends or mere acquaintances, but we will not try to second-guess anybody's determination of who's in her family.

A sponsor certifies to us that a designated person is trustworthy. As an incentive for wise judgement in this matter, we've instituted the policy that a family sinks or swims together. If system abuse forces us to delete a family account, we will also delete the sponsor's own account, and the accounts of all her other family members.

We usually consider system abuse investigations to be confidential matters between us, the abuser, and any victim(s). Therefore, we may delete accounts belonging to innocent family members without notice and with little or no explanation. The same applies to usage restrictions short of deletion.

A sponsor may revoke a family member designation, in which case the account(s) belonging to the "de-designated" person will be deleted. This is the only special right that the sponsor has with respect to a family member's account.

In particular, the sponsor is not permitted to have the password for a family member's account, nor to have any other means of unsupervised access to that account. We will not give the sponsor any special system privileges, nor will we offer the sponsor any assistance in monitoring the activity on family accounts. We won't even tell the sponsor which login names belong to her family members.

We wish to make it specifically clear that these policies apply to accounts given to employees' children. If you sponsor your child, you are free to require her to make her files readable to you, or to take you on "inspection tours" of her account; that's between you and her. In matters that involve us, however, you must agree to follow our policies. You may not have your child's password or log into her account when she's not present. You may not attempt to circumvent system security to monitor her activities. We will not copy you on any communications we send to your child. We will hold your child to the same standards, and accord her the same privileges, that we apply to our adult users. If you don't feel comfortable with these terms, it probably means that your child isn't mature enough for us to feel comfortable with giving her an account.


Charitable, Recreational, and ProfessionalOrganizations


employees.org users often create accounts in support of charitable, recreational, or professional organizations with which they are involved.

Although you're welcome to use the employees.org system for such purposes, we consider such accounts to be your personal accounts. We do not directly support outside organizations, and outside organizations can't own accounts on our system. All employees.org accounts are owned by individuals.

We will not create accounts for people other than yourself who are involved with your charitable, recreational, or professional organization, nor will we let more than one person use any account. This means, among other things, that you may not allow other members or officials of your organization to log into the account; you must handle all maintenance personally.

Many activities of charitable, recreational, and professional organizations, including most fund-raising activities, are forbidden under our commercial use policy. This applies even if the organizations are not run for profit.


Accounts for Others


In some cases, we may grant accounts to people who are neither employees of covered companies, nor family members of employees. The creation of any such account must be specifically approved by an employees.org administrator; it is not appropriate to use the employee or family account creation forms to create such third-party accounts.

We will create non-employee, non-family accounts only when there's an obvious benefit involved for the employees.org system or for some large part of its user community. Our receptiveness will vary with our perception of the resource situation.


Multiple Accounts and Account Naming


The real name of each employees.org account holder, although known to us, is generally considered confidential information. However, should you abuse the anonymity of your account (for example, by harassing or threatening people), we may make revealing your name a condition of your continued access to the employees.org system.

You may have more than one employees.org account. You may select your own account name(s). You may use any name you like as long as it's not likely to cause confusion or interfere with the operation of the system. You may use a "handle" in the full-name field for your account.

Names are issued on a first-come, first-served basis. We will not get involved in disputes over who owns a particular name, except when there's been an attempt to impersonate somebody. We do ask that you be courteous in your choice of names. Try not to take what may be somebody else's cherished nickname unless that name is equally important to you.

Although there is no hard limit on the number of account names you may have, please be reasonable in the number of names you use. Two or three names are often reasonable. More than that may be reasonable in some cases. Tens or dozens of names are almost never reasonable, especially if they're all "good" names that other people might want. The multiple-account facility was created for two reasons:

  1. To let you isolate application programs for security purposes. For example, you might want to isolate a large, complex system of CGI scripts in a different account from your "main" account, so that flaws in the scripts couldn't damage data other than their own.
  2. To let you establish multiple, independent personae. For example, you might want to join a support group under a confidential alias. As a rule of thumb, two accounts are not "independent personae" if the general public knows they belong to the same person.

The multiple-account facility was not intended as a way for you to lay claim to large numbers of vanity aliases. Please do not take names you don't need just because you don't want other people to have them. Keep the purpose of the facility in mind when you decide how to use it. Gross excess in the creation of multiple names may constitute system abuse.

On most systems with significant numbers of users, some "name wars" take place. We're taking a relatively hands-off attitude and expecting you to act like mature adults. If people don't seem to be able to be reasonable, we may have to rethink this policy.


Lack of Service Guarantees


The employees.org system is run entirely by volunteers, and there is no charge to users. You get what you pay for. No particular level of service is guaranteed on employees.org. Although we'll try to deal with problems, each of us has other priorities. It's possible that the entire system may go down for long periods of time, or even forever, with no warning. It's also possible that individual services may become unavailable, or be so degraded as to be unusable.

This isn't intended to scare anybody, and we fully intend to keep the system running smoothly. You simply need to understand that nobody is obligated to do so.


Limited Help-Desk Support


There is limited help-desk support on the employees.org system. "How-to" questions may be sent to help@employees.org. Response is on an as-available basis, and no particular service level is guaranteed. We strongly suggest that you at least try to read the documentation before sending in a help request.


Security


On any computer system, there is a tradeoff between security on the one hand, and functionality and ease of use on the other. The employees.org system is managed to emphasize the latter; we accept some potential security weaknesses in order to provide better service for our users. You are strongly advised not to use employees.org for any application you consider sensitive.

When we say that the security weakness we accept are "potential", we mean that they're created by the fact that we're prepared to run a large variety of relatively untested, unreviewed software. We do not mean that we accept actual known, exploitable system security holes. Any significant security holes that come to our attention will be closed by whatever means are necessary. Furthermore, our emphasis on functionality over security is not absolute; there will always be times when security concerns prevent us from offering certain services, or from offering those services in the most natural and convenient way.

You as a user are expected to observe basic security precautions in the design of all services you set up. You are responsible for making sure that your services don't let their users do more than they should be able to do. You will be held responsible for any breach of system security via a service that you maintain. This includes Worldwide Web CGI scripts. It's very easy to introduce a security hole with a CGI script; be very careful. If you're not a security expert, read the appropriate reference material before you install your service. We will disable services that, in our judgement, create unacceptable security holes.


Lack of Backups and Disaster Recovery


User data on the employees.org Web server are not backed up. You should maintain copies of your data elsewhere. Disaster recovery for employees.org will consist of reinstalling the system from scratch, without any user files.


Announcements and User E-mail Response


Users are expected to respond appropriately to e-mail sent to them on the employees.org system. The system administrators and others may send correspondence about your Web pages or other services to your employees.org account, and you're expected to read that mail in a timely manner. The appropriate definition of "timely" depends on the sort of services you offer.

We may sometimes send announcements about system downtime, software updates, configuration changes, and the like, to your employees.org account. These announcements will often be the only notice you get of upcoming changes.

If you don't log into the system on a regular basis, we strongly suggest that you forward your e-mail to an account on a system you do log into regularly.

In the case where your account or those that you sponser are exceeding the maximum disk resource allocation of 150MB per sponsor, you will receive an e-mail warning to reduce your disk usage so that you do not impact other users.

Please ensure that you are reading and responding to administrative messages sent to your account. Failure to do so will cause your account to be declared abandoned and deleted with no possibility to recover the files deleted (you must keep your own backups).


Software Updates


Software is updated only on an as-needed basis; there's no attempt to keep up to date unless new features (or bug fixes) are needed. If you think a piece of software should be updated, send e-mail to admin@employees.org.

Incompatible software updates are usually announced in advance.


Service Creation


The basic purpose of employees.org is to allow users to provide services to the Internet at large. The most common services are expected to be Worldwide Web pages and anonymous FTP information, but it's both permitted and encouraged for users to set up other services.

You need not get permission to set up any (non-abusive) service on the employees.org system, unless the service may make very heavy demands on the computer, or stands a serious chance of damaging system security. If you're not sure what demands your service will put on the computer, or if you need other help, you should send a message to help@employees.org or admin@employees.org.

Remember that providing a service includes making that service secure and robust. Sometimes it's easy to provide a service in an insecure way, but difficult to provide it in a secure way. Your service must be adequately secure, and must not interfere with the proper functioning of other employees.org services. You are responsible for finding a way to provide your service within these constraints.

Please understand also that your being permitted to set up services doesn't necessarily mean that we'll always be able to help you. We have limited time to spend administering the system. If what you want to do is going to require a lot of work that you're not willing or not qualified to do yourself, you may have to change your plans.

If installing your service requires privileged access to the system, you must explain to us exactly what you're doing, what privileges you need, and why. We reserve the right not to grant you privileged access if you don't meet our requirements, even though it may mean you can't set up your service.

If you set up any service on the employees.org system, you are responsible for properly administering it. All questions and complaints about the service will be referred to you. If you don't deal with those questions and complaints satisfactorily, our most likely response will be to disable the service entirely.

Some services create the potential for system or network abuse. For example, writable "incoming" directories on anonymous FTP servers are often co-opted as drops for software pirates. If you create a service on the employees.org, it's your responsibility to monitor it as closely as its abuse potential dictates. We will shut down any service that persistently generates genuine complaints of abuse, or that doesn't seem to be being administered prudently.


Resource Allocation


employees.org has limited system resources. At the time of this writing, the entire system runs on a single relatively low-capacity computer. Because the service is new, we don't know how much demand there will be. If the system becomes heavily used, we may run into resource constraints.

If we do run out of resources, we'll look into getting more hardware, but that may not be possible, and will in any case take time. In order to maintain an acceptable performance level, the employees.org administrators may have to impose disk or data transfer quotas, or to remove resource-intensive services, including services provided by individual users, from the system. If the disk fills, we may have to delete user files.

If any of this happens, we will make an effort to notify users before turning off their services or deleting their files, but it may not be possible to do so. Remember, employees.org guarantees no particular level of service, and you are responsible for keeping your own backups.

If we run into serious resource problems, we will stop accepting new users, and ask existing users not to install new services. If that still isn't enough, we'll remove or cut back newer services and/or services that seem to be using more than their fair share of scarce resources.

If resources get tight, we will probably give top allocation priority to accounts owned by current employees of covered companies, and second priority to accounts held by family members of current employees. This will not, however, be the only consideration.


Content and Editorial Control


In general, we exercise very little editorial control over material placed on the employees.org system; we are simply a communications service. Users are free to present almost any information they wish, in whatever terms they may desire. We request that users take reasonable steps to avoid offending or upsetting others, but we will not undertake to evaluate the offensiveness, or lack thereof, of anyone's material.

The following types of information are explicitly prohibited:

  • Commerical content. This includes any content that requests money, such as non-profit or charitable donation requests. Users may post information about non-profit or charitable organizations they belong to as long as they do not solicit donations on employees.org.
  • Any content tied to your employer. This includes any internal or public documents and any links to internal web pages.
  • Unauthorized reproduction of copyrighted materials.

While content is very lightly regulated, conduct is more strictly regulated under the system abuse policy. For example, the sytem abuse policy forbids harassment of other users. A common form of harassment on computer networks is the sending of unwanted electronic mail. In determining whether harassment was taking place in such a case, we would not make reference to the content of the e-mail. Instead, we would concentrate on whether the e-mail, however innocuous, was in fact unwanted, and whether the sender was in a position to know that.


System Abuse


Users who abuse the system may be admonished, or their privileges may be restricted, or their accounts may be suspended or revoked, or other action may be taken, at our option. In severe cases, action may be taken without notice.

System abuse means using the employees.org system or an employees.org account in ways that interfere unduly with other users' peaceful computer and network use, and includes, but is not necessarily limited to, any of the following:

  1. Illegal activity.
  2. Activity whose purpose appears to be to harass or annoy others.
  3. Activity which violates the established norms of use and interferes with the smooth operation of the Internet or the Usenet, including "spam", "velveeta", and "mail bombing".
  4. Activity which uses excessive system or network resources, either at employees.org or elsewhere.
  5. Attempting to interfere with the proper operation of the employees.org system or of any other computer system or network.
  6. Attempting to gain improper access to others' data.
  7. Deliberately or negligently creating or maintaining security vulnerabilities on the employees.org system or any other system or network.

No part of this document should be interpreted to "legalize" system abuse. If you abuse the system, we will come after you, even if you can invent some creative interpretation that makes it look as if we said it was OK.

We realize that this gives us essentially unlimited discretion in defining "abuse". Unfortunately, there's no alternative; people are always coming up with new ways to abuse systems, and we can't specifically mention every possible one. We are reasonable people. We don't intend to be capricious about this, nor do we intend to go out of our way to find problems where none exist. We will, however, respond strongly to complaints, whether from inside or outside our system.

Our determination as to what constitutes system abuse is final, as is our decision as to the appropriate response. You should understand that multiple accounts are not a protection; if you abuse one account, all of your accounts are subject to administrative action. Furthermore, if a family account holder abuses an account, action may be taken not only against that person's account(s), but against the accounts of her sponsor and of the sponsor's other family members.


Reporting abuse


The employees.org administrators are part-time volunteers, and do not in general actively "patrol" the system. Administrators may not notice system abuse immediately. Some system abuse, such as harrassing e-mail, will never be noticed unless somebody complains. If you notice any abuse of the employees.org system or any account on the system, please report it to admin@employees.org.


Investigations, Evidence, and "Due Process"


When we receive a report of system abuse, we will generally conduct some sort of investigation to determine whether abuse has really occurred. The amount of investigation involved will depend on the specifics of the situation, including the severity of the alleged abuse, the impact of letting it continue, the plausibility of the report, the credibility of the reporting source, and the availability of evidence. We will make the final decision on the adequacy of any evidence of system abuse.

We may on occasion review users' private data during the investigation of system abuse. Information found during such a review will be treated in accordance with the policy on administrative monitoring and access. We see examining private data as a very serious matter, and we will do it only as a last resort. We may in many cases choose to take action, such as disabling a user's account, without examining private data, even when other evidence is borderline, on the theory that losing the account is actually less intrusive upon the user than having us read the data in question.

We will in general consider any investigation of system abuse, and the details of any action taken in response, to be a confidential matter. Victims of system abuse will be usually given a basic description of what's been going on and of what we've done about it, but no names will usually be named. We do, however, reserve the right to disclose information about system abuse, including hearsay and pure conjecture, with or without the names of those involved, to any person, should we determine that it's merited by the facts of a particular case.

Should we take action against you because of your own system abuse, we will always tell you what we're doing, what abuse you have committed, and what evidence we have of that abuse. If, on the other hand, we take action against you because of system abuse by one of your designated family members, we may give you little or no information as to what's going on, because of the confidentiality policy.

We will give any person accused of system abuse a reasonable chance, consistent with the circumstances of the case, to offer evidence and explanations in her own defense. Please be aware, however, that we are not a court of law, and that we do not intend to follow the stringent standards of process and evidence used in such courts. This is a private system, and we are both entitled and obligated to control its use.


User Privacy


A general note about privacy: This is a networked computer system, managed to a relatively relaxed security standard. Regardless of our policies, it remains technically possible for people to get unauthorized access to data on this system. We strongly advise you to avoid using the system for information you consider secret. See also Administrative monitoring and access.

This section goes into fairly complex detail, but still doesn't cover every possible situation. We think the general idea is clear.


What is (and is not) private


The UNIX system provides a way to define the public or private status of files. If you set the UNIX protections on a file on the employees.org system to make that file world readable, you are telling the other users of the system, and whatever programs they may choose to run, that it's OK to read that file. Likewise, if you set a file to be group readable, you're telling members of the appropriate group that the file should be readable to them.

Similarly, making a file available to the public on a Web server or an anonymous FTP server tells the world that that file is public information. You have no grounds to be upset if people read the file, or even if they forward copies of it to others. On the other hand, if you password-protect the file, then how public it is depends on how public you make the password.

We are not in general receptive to complaints based on people accessing things that weren't protected. The UNIX protection scheme is the primary way of telling people what they may access on employees.org. The protection systems provided by the network server programs are the primary ways of telling users of other systems what they may access. We suggest you learn to use these mechanisms.

This does not mean that it's OK to do anything at all that the system lets you do. If you have to go to great lengths to get access to something, to the point where it's obvious that somebody was really trying to deny you access, but failed, then you may not access the data. Instead, you should report the fact that you can access them as a security hole. If it's obviously technically tricky to implement a particular access policy, and the owner has used other, obvious means to make it clear that something is private, leave it alone. If a file is writable, that doesn't mean you're allowed to write garbage into it. The system abuse policy still applies to whatever you do.

One more thing-- the fact that you're allowed to read something doesn't mean you should do so. Unless there are special circumstances, we're not going to yank your account because you read a publicly-readable file in somebody's home directory. That doesn't mean you should go around doing it indiscriminately. Reading a file called "recipes" is a lot different from reading a file called "diary". Few people will care if you do the former. A lot of people will think you're a jerk if you do the latter. Use some common sense.

We've tried to make the default permissions for user files on employees.org relatively restrictive, so that you have to take action to give up your own privacy rather than to protect it. This can't always work, and doesn't absolve you of your responsibility to understand the system.


Special cases


Some classes of information are treated specially, or at least in ways that aren't absolutely obvious from the general discussion above. They include:

  • E-mail. E-mail is special both because the privacy of at least two people is involved and because the software is notorious for security holes. E-mail in transit is always considered private on the employees.org system, regardless of the UNIX permissions, as are mailer logs. Intercepting somebody's mail is the worst kind of system abuse.
  • System logs and administrative infomation. Logs other than mailer logs are considered public if they're world-readable, otherwise not. The same applies to system configuration files. Information given out to ordinary users by system status programs like "who", "ps", "last", "netstat", and "lsof" is considered public.
  • Encrypted data. Encrypted data (except for files encrypted with ROT13 or other trivial obfuscation algorithms) are always private, and considered available only to their owner or those to whom she chooses to give the keys.
  • Temporary files. Software often botches the permissions on files in temporary directories, and users may not know when that happens. It's forbidden to access other people's files in /tmp or /var/tmp, or obvious temporary files in other places, with the only exception being files that are deliberately used as communications rendezvous points by multiuser applications. WWW browser caches and similar caches are considered private temporary files.
  • True names. The association between an employees.org user's login name and/or handle and her real-life name is considered private information, just like any other private information under this policy, unless the user herself makes it public.

    However, the employees.org administrators may disclose this association to any bona fide law enforcement agency engaged in a criminal investigation. Furthermore, revealing her real name may be made a condition of continued system use for any user who has engaged in "anonymous" system abuse.

Privacy from third parties


The basic principle of third-party privacy on employees.org is that you may not republish somebody else's data without her permission. The ability to read something does not confer a right to pass it on to others, whether in the original form or in rewritten or summarized form.

This applies to e-mail. If you forward confidential e-mail, or information gleaned from it, without the permission of the sender, you run a very strong risk of system abuse. If you are the least bit unsure as to whether the sender wants you to forward something, get her permission first. The only exception to this rule is the forwarding of harassing or otherwise abusive e-mail to system administrators as evidence of system abuse.

Users are encouraged to attach notices to the data they make available to others, specifying how those data may be forwarded. Absent such a notice, the following rules apply:

  1. If a user has made data readable, without a password or other protection, on the employees.org Web server, or on the anonymous FTP server, or via some other means available to the public on the Internet at large, she is deemed to have made those data public, and other users may freely forward them to, or discuss them with, anybody in the world.
  2. If a user has made data readable to all users of the employees.org system, for example via a world-readable UNIX file, she is deemed to have published those data only to the other users of employees.org. Absent her permission, other users may forward or discuss the data among themselves, but not outside of the employees.org system.
  3. If a user has made data available to a restricted group of other users, those users may forward or discuss the data among themselves, but not with users not in the group. This applies to data protected by passwords or other security measures on network servers, as well as to data in plain files on the employees.org system.

Administrative monitoring and access


Users are warned that administrators may inspect any information on the system at any time, and may monitor activities on the system. We intend to follow and enforce the rules below, but the practical reality of the matter is that you must rely on our integrity and sense of propriety in safeguarding your confidential information.

It may sometimes be necessary for privileged users to access private data. For example, a system administrator trying to debug a mail delivery problem may need to look at e-mail in system queues, or even in user mailboxes, and will almost certainly need to examine mailer logs. In some cases, the system may even bring private data to an administrator's attention without being asked, as when the e-mail system copies "bounced" mail to the postmaster.

The rules for this sort of access are as follows:

  1. Administrative access to users' private data is to be used only when there is a complaint, or other strong evidence, of a problem with the system or of system abuse. Administrative access to log files or other "monitoring" data is to be used only to assure the smooth functioning of the system. There are to be no "fishing expeditions" into private data.
  2. If reasonably possible, a user whose data are to be examined is to be notified in advance, and invited to conduct or assist in the examination. If advance notification is not possible, the user is to be notified as promptly as possible after the fact.

    This rule does not apply for access to mail logs or to other system logs. It applies for "bounced" e-mail only if the contents are obviously very sensitive; users are expected to understand that postmasters sometimes see copies of bounced e-mail.
  3. The least intrusive means possible are to be used whenever user data are examined. For example, if an administrator needed to determine whether or not a given e-mail message had been delivered, she might search the recipient's mailbox file for a string known to be unique to that message, rather than viewing the entire file.
  4. Anything a privileged user learns because of administrative access is to be kept completely confidential, and not revealed to any third party or used for any purpose other than resolving the problem or improving the system. Administrators may under some circumstances share information gleaned from private data with other administrators who have reasonable needs to know. If this is done, the information shared will be the absolute minimum necessary.


Privileged Access


Some users have special access to the system. This group includes the employees.org administrators and other users who maintain or assist with the maintenance of various services on the system. Privileged access is granted only for specific purposes, and only the minimum privilege needed is granted. Privileged access is granted only to users whom the administrators believe to have both the technical skill and the good judgement to use it properly.

Privileged access does not necessarily take the form of "having root"; any form of access not granted to users in general, or granted only for the purpose of maintaining system services, is considered privileged access.

Privileged access is to be used only for the purposes for which it is granted. It is never to be used as a way of invading another user's privacy, or as a way of getting an unfair share of the system's resources, or in any other way that does not advance the usefulness and proper functioning of the system. Misuse of privileged access is considered an extremely serious form of system abuse.

Users with privileged access are under a special obligation to observe system security constraints, and to exercise care to avoid inadvertantly compromising system users' privacy. For example, a user who "has root" must be careful about browsing other people's directories using root shells; the system will permit a root user to read any file, and the privileged user is expected to take precautions to avoid accidentally seeing private data.

In the course of their maintenance work, users with privileged access may occasionally be exposed to the private information of other users. Such information must be treated in accordance with the rules for administrative data access. The relationship of a privileged user to the users of the services she maintains should be thought of as similar to that of an doctor, or perhaps even that of a confessor; information found during administrative work is to be kept absolutely confidential.


Commercial Use Forbidden


Because of software licensing restrictions, we cannot allow commercial use of the WWW server, or of any of the cryptography software, on employees.org. Similar licensing restrictions may apply to other software in the future. To simplify matters, and because of limited resources, we have decided to ban commercial use of the system entirely. If you need to provide a commercial service, any number of ISPs will be happy to sell you accounts.

Commercial use is defined as any of the following:


  • Any service you charge for.
  • Any service used to advertise or demonstrate something you charge for (or something anybody else charges for).
  • Any service used to process orders or payments for anything you or anybody else charges for.
  • Any service that sells advertising or announces paid "sponsorships".
  • Staging, development, or support for any of the above.

Third-Party Use Forbidden


Each employees.org account is issued to a single, specific person. You may not allow any other person to use your account except under your own direct and immediate supervision. By "direct and immediate supervision", we mean that you are in a position to watch what she's doing on a second-by-second, keystroke-by-keystroke basis, and that you're paying an appropriate amount of attention.

Under no circumstances may you give your password, or any other means of getting unsupervised access to your account, to any other person. You will be held personally responsible for the actions of third parties using your account.

If you feel that some other person should have employees.org access, the right thing to do is to apply for a an account for that person.


Unsupported Services

We often get requests for services we can't can't support. To save everybody's time, we're listing some of those services here, with our reasons for not supporting them.


DNS Service

We can't provide either primary or secondary DNS service for your private domains (nor for domains for organizations you're involved with). The reasons:

  • The DNS system is critical to the smooth functioning of employees.org, and DNS administration is error-prone. Constant DNS changes are likely to cause systemwide problems.
  • Because the employees.org administrators can't guarantee an appropriate level of response to DNS service requests, we'd have to give root access to anybody who had a domain hosted on our system. We want to minimize the number of root users on our system.
  • Our system provides no guaranteed level of service. We're not entirely comfortable with such a system becoming a major DNS server.

This policy will continue until such time as we have an easy-to-use, automated way for users to manage DNS service for their own domains... and only their own domains. If we find appropriate software, we may modify the policy. Even then, we'll probably support only secondary service, and only subject to heavy caveats.


Mail Exchanger Service

We can't act as a mail exchanger for a private domain, for essentiallythe same reasons we can't act as a DNS server for such a domain.


Points of Presence

Our space in Cisco's computer room is extremely limited; we've been allocated just enough rack space to hold our own, single machine. If we ourselves ever need to install a second machine because of user load, we'll have to go to Cisco or another covered company and beg more space.

We can't provide space or network connections for users' "private" machines, even if those machines support services that would otherwise be reasonable on the employees.org system. This will continue at least until we have a signficant surplus of POP space, which is unlikely ever to happen.


Special Services for Charities

We can't offer any special services for charities. Our purpose is to provide a platform for personal services, and our covered companies fund us because we provide such services for their employees. Although you're free to use your own accounts in support of charities, we can't do anything more for you than we'd do for any user.


These Policies and the Law


We will follow and enforce these policies whenever legally possible, but please be warned that there are times when the law may force us to violate them. Legal requirements always supersede the requirements of these policies.


Policy Changes


These policies are subject to change at any time and without notice.



admin@employees.org