Joel
Pippin
INLS 187-300
11.11.04
Policy Analysis
You can find the policy here:
ImHosted's Script Usage Policy
:::
Overview of the policy -
The ImHosted.com website has a service policy page that discusses their general policy stance and links to all of their policies' details. I chose this policy because I have recently been moved from one server type to another, and I've had multiple problems over the years with my host - which is not to say that I'm displeased with the overall service. I believe that I get my money's worth. Regardless, one of the problems I have had is with the successful running of scripts and their unwritten "you need to request it to get it enabled" handling of server configuration. Plus, the other policies were less exciting to me, and this one related more directly to security. Maintaining the security and integrity of the ImHosted servers is the main reason this policy exists.
The policy, in a nutshell, is an explanation of what is permissable activity from user scripts running on the host's servers. It is essentially a list of rules that discusses what the scripts can and cannot do. Interaction with the host's server, such as resource hogging, is not allowed.
:::
Criteria for examination -
Four criteria that will assist in an evaluation of the policy:
:::
Analysis -
Are the rules clear?:
mostly. Resource hogging is broken down into three brief rule subsets. Essentially, they warn users to not eat up the RAM and CPU, to not use more than 20% of the system's resources, and to not interact with the hardware or the server configuration. That's a pretty clear rule set.
This part of the policy should legally protect the host from people who might try to fight back against shutdown with some ridiculous claim that they didn't know they couldn't eat up all of the server's resources or run attack scripts against the server. ImHosted is more than fair with the allocation of resources, stating that "Each user account may not use more than 20% of system resources at any given time." They even allow for spikes, as long as they are transitory in nature; "If an account is consistently using 20% or greater system resources, the account holder will be warned and if no action is taken on behalf of the account holder the account may be suspended."
So why mostly? Becuase they should simplify the chatroom issue by saying "no chatrooms except on high-end accounts, and even then, no Perl-based rooms." Instead, they state that, "Perl-based chat room scripts are strictly prohibited." The next rule states that, "Scripts that require high-bandwidth usage, such as non-Perl chat room scripts or banner rotation scripts, will be allowed to run only on our high-end accounts." I know that I'm being very picky, but it annoyed me that for a moment, I thought, "Hey, I can run a chatroom," only to be beaten down by the next rule. My solution says it more concisely and with no hope-raising.
Are the rules subject to interpretation?:
at times. 20% is 20%, the additional warnings are similarly straightfoward. There is one exception. "Scripts must be kept secure. Unnecessary chmoding scripts to 777 is a violation of this policy." What defines "unnecessary is debateable, although I agree with the notion. Furthermore, they have a "NOTE: If a script will NOT execute with a permission other than 777 (rarely the case) you may contact customer care to get approval for the script which will be given under most circumstances." So they'll bend the rule as long as you ask. This is the sort of issue that is hard to manage on their end, I would think. "Did we give that user permission to change those scripts to all 777? I don't see it written down anywhere... but then tech sometimes doesn't note it. We don't want to lose their business if we gave them permission and now take it away. Oh, dammit, just forget about it." That sort of head scratching, at least in my experience with technology, is a plausible notion.
Is the policy written in a technical language that is understandable to most users of the servers?:
yes. Using myself as an example of a user who would want or need all of the options available from this host, I didn't have any trouble understanding the language. Most people who are capable of using scripts on their site should be able to understand the terminology of a script policy. Furthermore, "don't do this or that" should be understood by anyone.
Is the process for handling user violations fair and of low impact to other users?:
It seems so if the policy statements are true.
For example:
"Any accounts with scripts found in violation of these policies are subject to future scrutiny of all CGI, Perl, CFM, ASP, and PHP scripts by our System Administrators. If a script is found to be harmful to the system, it will be killed immediately and the account locked down until the account owners have been contacted. Malicious scripts are subject to immediate account termination without refund of any pre-paid monies."
But the determining factor is in the actual enforcement. My experience with the host shows that while they can resolve most issues given enough time, the lower techs are less than reliable in their speed of response to many issues. Assuming that I am a high-maintenance user and that the advanced techs are more "on the ball," - which I believe are safe assumptions - the policies are likely enforced well. I have had an access problem that turned out to be a hostee on my server sharing mp3 files from his site. The issue only lasted a short time and I was notified that the issue was resolved - and they explained the problem to me, which was surprising considering how guarded many support places are about sharing information that might paint them in a negative light in some contexts. If this were a user running a process intensive script or set of scripts, I do believe that they would respond appropriately and impact on others would be minimized.
:::
Recommendations not mentioned above -
There is a semantic issue in the last part of the policy.
"All accounts that are found to using excessive amounts of system resources will receive an email warning from ImHosted™. This warning will inform you that there is too much CGI running and it will provide options for reducing the usage or upgrading your server. If you do not reduce the usage within 24 hours of the email being sent, your account will be cancelled."
"...too much CGI..." doesn't include the other scripts mentioned previously - namely Perl, CFM, ASP, and PHP. This should be fixed for clarity.
There are two other sentences in the policy that bother me a bit:
"We regret that in many cases we are unable to determine what specific script or application is causing the system resource over-run. Under most circumstances, we are able to pin-point it to the offending account on the system."
This is at the beginning of the policy, and would better server the policy as a disclaimer at the end. But perhaps I've just been manipulated by corporate America into believing that the fine print should exist that way - absolving and protecting the vested party or parties. Perhaps "up front" is the best method, after all. Nevertheless, the statements of the two sentences are worrisome. What happens if they cannot pinpoint the issue is not discussed. Why there would ever be an instance where "we are unable to determine..." the source of a script issue is a case for concern at a host of true quality and technical expertise. I'd like to see this portion revised, at least to explain the possible ramifications of not finding the offending script.
:::