Subject: RISKS DIGEST 17.39

RISKS-LIST: Risks-Forum Digest  Monday 16 October 1995  Volume 17 : Issue 39

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc.       *****

 Contents:
Ambulance Dispatch System (Rohan Baxter)
Presidential Black Hawk Crash (Craig J. Coley)
The Johnson Bug - IBM (Jason Fleischer)
How to derail a train (Bob Frankston)
Basic Flaws in Internet Security (David Wittenberg)
Pinging the vacuum tubes (Paul Wernick)
Risks in Java (Prentiss Riddle)
Effective use of the Internet (Richard Sexton)
Risk of visiting wrong place on the Web (Marc Rotenberg)
Another example of poor use of databases (Mathew)
Analysis of Human Factors and Outages (John Mainwaring)
RSI Risk/Editor Correlation (Become a statistic!) (Rudi Cilibrasi)
Re: Microsoft Excel 1.40737488355328 (Francois Grieu, Marv Schaefer,
   Joe Birsa, John Lane)
ABRIDGED info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 17 Oct 1995 08:55:35 +1000 (EST)
From: Rohan Baxter <[email protected]>
Subject: Ambulance Dispatch System

A new computerised dispatch system for the Metropolitan Ambulance Service
(MAS) (Melbourne, Victoria) has run into some difficulties. According to a
report in `The Age' newspaper by Thom Cookes (17/10,p.35), an independent
consultant's report identified more than fifty faults labelled `critical' or
`high priority'. The dispatch system is now operating with some of the
faults still outstanding.

The system's supplier, Intergraph, has installed more than 160 similar
systems around the world. However, it is the first time that the company has
supplied both system and staff. It is believed that this may have resulted
in less scrutiny being applied to any reported faults.

The outstanding problems are believed to be with:

1. Automatic Vehicle Location, which uses satellites to keep track of
ambulances. Too much information is causing the system to `bog down' and
report incorrect locations.

2. Automatic route recommendation, which suggests the best way for an ambulance
to get to an incident. No statistical tests have been applied. However on
simple tasks, the system recommended routes heading in the opposite direction
from the accident scene.

3. Allocating a vehicle to a job can take up to two minutes, during which
the console is `locked up'.

Intergraph has argued that any faults in the system would show up in the log
files generated daily and provided to the MAS and government. However the
consultant's report flagged the report generator as also containing critical
faults. In particular, the system does not accurately time how long it takes
to respond to a call. Responses taking longer than 16 minutes are meant to
generate an exception report. A test, where the response time was 25
minutes, straddling the time from before midnight till after midnight,
didn't generate an exception.

It appears that one of the difficulties with identifying and rectifying the
system faults has been their use in a game of political football between
government (who has cut costs by using Intergraph), Intergraph (who is about
to provide similar systems for fire and police), the Ambulance Union (who
prefers its own members to do the dispatching, rather than non-paramedic
civilians), and MAS management (caught between the other three). Its hard to
tell what is what!

Rohan Baxter, [email protected]  ph. +61 3 905 5721
Dept. of Computer Science, Monash University, Clayton, 3168, Australia.

------------------------------

Date: Fri, 13 Oct 1995 22:29:02 -0500 (CDT)
From: [email protected] (Craig J. Coley)
Subject: Presidential Black Hawk Crash

A Tragic Crash of a Presidential Helicopter or a Marine Corps Cover Up?
By C.J. Coley

On May 19, 1993, an unusual crash occurred in southern Maryland. What made
this crash unusual was not the loss of a military helicopter and four
dedicated Marines but the fact that the helicopter was part of the
Presidential 'White Top' fleet and the crewmen may have perished in a most
unusual way.

The first person on the scene was Frank C. Owens, a civilian who saw the
wreckage while driving home from an archaeological dig. He immediately
rushed to the site to render aid to any survivors. "I couldn't believe what
I saw," said Owens. "Those men were burned and there was almost no bleeding
from their wounds."  Owens went on to describe the grizzly sight in the
mangled wreckage. "What got me was there was fuel everywhere but no evidence
of a fire. Their uniforms weren't even burned. But the men sure were." What
Owens saw in the woods that day ultimately launched him on his own
investigation to find out what really happened.

The official Marine Corps Judge Advocate General (JAG) investigation blamed
the crash on an improperly installed 'roll pin' by maintenance personnel at
HMX-1 in Quantico, Virginia, but Owens didn't believe this explanation.
"Experts I talked to said this particular part would have failed almost
immediately after installation yet the helicopter had flown over fifteen
hours since the repair. It even flew President Clinton from the White House
to the U.S.S. Theodore Roosevelt. Besides, I don't know how they could have
come to any realistic conclusions without all of the evidence," Owens said
as he pointed to a display case containing over a thousand pieces of the
wreckage collected at the crash site more than a week after the incident.
"They certainly didn't follow normal investigative procedures," he said.

Owens believes that there may be another explanation as to the cause of the
crash. Owens discovered that the Sikorsky UH-60 Black Hawk has a long
history of Electromagnetic Interference (EMI) problems. Apparently, a number
of these helicopters were lost in the 1980's after flying too close to
microwave or broadcast towers. The Army tried to deny there was a problem
for years but was ultimately forced to retrofit their helicopters to correct
the problem. Owens went on to say he believes an Army research facility just
four miles from the crash site has been working on a high power microwave
system as part of the former Star Wars program. He believes that this
microwave directed energy or 'beam' weapon may have been responsible for the
crash.  "It just fits," said Owens. "The crash fits the profile of the Army
EMI problem. Most of them were flying below 1000 feet when they passed a
tower and just nosed in. It's also the only way I can explain the burns
suffered by the crewmen without damage to their clothing."

Owens' conclusions have been met with considerable resistance by Marine
Corps officials at HMX-1. He was even questioned by Naval Investigative
Service (NIS) agents who came to his White Plains, Maryland home early one
Sunday morning. In addition, orders have been reportedly issued by the
Marine Corps forbidding any further contact with Mr. Owens. But Owens vows
to continue his investigation. "Those men had wives and children and I just
can't let it go until something is resolved," he said.

In reality, the real truth may never be known. Marine Corps officials
continue to deny Owens' allegations and the helicopter wreckage has now been
removed from the Marine Corps inventory.  In addition, many of the records,
including critical autopsy photographs have been destroyed even though there
is pending law suit by the families of the deceased crew members.

------------------------------

Date: Mon, 16 Oct 1995 06:37:24 -0700
From: [email protected] (Jason Fleischer)
Subject: The Johnson Bug - IBM

  [Via Mike Crawford <[email protected]>]

A question to any IBM people or others who remember this-

This is a bit of campus folklore from here at CSU, and I wanted to see if
anyone could provide verification for it. The story goes thus:

Several years ago a Colorado State professor of Mech Engr named Gerry
Johnson goes to an IBM networking exposition.  At this expo IBM is
demonstrating some kind of new networking software to link PCs to the IBM
global network.  Dr. Johnson being the savvy controls engineer that he is
asks for a demonstration of an unusual kind.  He knows that the software
will work in normal parameters, so he asks for something only an idiot
would.  He has the demo guy try to transfer a 50MB file from a 370 a few
miles away.  The catch is the PC has only a 20MB drive.  Dr. J's argument is
that if the software is written properly it will error out and say what's
wrong.  So they start the transfer and *poof* down goes the PC and the 370.
The demo guy is apologetic and asks Dr. J. to come back tomorrow, and he'll
see if he can get them to fix the problem overnight.  The next day Johnson
comes back to find the display boarded up.  A note says that the booth is
closed due to technical problems.  Later that day Johnson finds out why.
Not only did the 370 and the local PC go down, IBM'S ENTIRE GLOBAL NETWORK
BIT THE DUST!  Every computer attached to it went off-line.  Months later,
it turns out that it wasn't the new networking software as they had expected,
but a bit of code in the 370 MVS operating system that had never been
executed in the entire 15yrs or so that it had been in existence up to that
date.

According to the story around campus, this is a fairly (in)famous incident
in IBM history.  I would like to know if anyone out there knows anything
about it.  How about IBM's viewpoint on it?  I'd really like to know how
much of this is fact.

And, if no one knows anything, I hope it was at least amusing to read :)

Jason Fleischer [email protected]

------------------------------

Date: Fri, 13 Oct 1995 07:56 -0400
From: [email protected]
Subject: How to derail a train

I was surprised to see TV news stories and front page articles giving
instructions on how to derail a train from which bolts to remove to how to
defeat the electronic system checks. In today's news, there is some
suspicion that the sabotage was inspired by a recent article giving the
details and, in effect the instructions, on how to derail a train. It was a
story, in a limited circulation railroad magazine, describing a 50 year old
crash that, apparently, was printed a week ago.

This is reminiscent of the controversy over Internet security alerts, though
this doesn't necessarily argue for keeping the details secret. In the case of
the train, however, I was surprised how public the instructions were made.

------------------------------

Date: Thu, 12 Oct 1995 16:44:14 -0400 (EDT)
From: David Wittenberg <[email protected]>
Subject: Basic Flaws in Internet Security

Eric Brewer, Paul Gauthier, Ian Goldberg, and David Wagner have published an
attack on most of the "secure" internet protocols.  The trick is to spoof
NFS to provide corrupted code to the NFS client which runs the code.  They
have demonstrated that their attack works against Netscape and Kerberos.

The New York Times had a page 1 article on this on 11 Oct.

The original article, which includes a pointer to the article in the The New
York Times, is available at
http://http.cs.berkeley.edu/~gauthier/endpoint-security.html

--David Wittenberg  [email protected]

------------------------------

Date: Fri, 13 Oct 1995 11:25:52 +0100
From: [email protected]
Subject: Pinging the vacuum tubes (Re: Univac episode, Williams, RISKS-17.38)

I have been told that, in the early vacuum-tube days of computing, it was
the responsibility of one of the lower-order acolytes to go round the vacuum
tubes on the system and `ping' each one.  A `pong' meant that the tube had
failed or was about to fail, and it was replaced before the machine was
started.  How can we perform such preventive maintenance nowadays - are
there any systems which inform us of when they might be about to go wrong,
other than by having multiple instances of the hardware and reporting
disagreements?  What is the equivalent of the `ping' test for small
components?

The RISK? - implicit in any system that will tell you that it's _going_
wrong only when it's _gone_ wrong, like all of those dinky bits of
plastic-covered silicon with legs!

Paul Wernick

------------------------------

Date: Fri, 29 Sep 1995 12:38:51 -0500 (CDT)
From: [email protected] (Prentiss Riddle)
Subject: Risks in Java

BACKGROUND: Java is a language for writing procedural objects known as
"applets", intended to be distributed on the World-Wide Web as easily as
HTML is distributed today.  Netscape Communications Corp. has announced the
impending release of a beta version of Netscape 2.0 to include support for
Java.  For more information, see:

  http://java.sun.com
  http://home.netscape.com/comprod/products/navigator/version_2.0

RISKS: On its face, Java violates the security principle that one should
minimize the execution of untrusted software.  On a Java-enhanced web, every
click of the mouse in one's web browser could download and execute software
about which one knows little or nothing.  The designers of Java say that
they have paid a great deal of attention to Java's security environment, and
they are confident that Java is immune to viruses.  This claim may be true,
but it does not address the issue of trojan horses.  Even if Java applets
have access only to local resources which have been explicitly authorized by
the user, the risk of trojans remains.  It seems to me that it is impossible
to grant an untrusted program useful access to resources without granting it
the opportunity to *misuse* those resources.

Furthermore, since one of the resources to which Java may often require
access is the network itself, a trojan written in Java might carry out all
sorts of mischief without touching the local disk: consider a Java applet
which does something useful or entertaining while surreptitiously spamming
targeted mailing lists or newsgroups with, let's say, racist hate mail.  I'm
sure others can think of nastier examples.

None of these risks are new with Java, but widespread use of Java promises
to change the risky event of running untrusted software from something the
average Internet user does occasionally to something the average Internet
user does every time s/he visits a new web page.

META-RISKS: I have posted these concerns to a variety of forums in the past
weeks (including comp.security.misc and the hotjava-interest and
www-security mailing lists).  I have yet to see any satisfying discussion of
whether or not the impending widespread deployment of Java-capable web
browsers constitutes a serious risk, or whether responsible system
administrators should permit the installation of Netscape 2.0 on their
systems.

Part of the problem seems to be that most everyone who really knows much
about Java had a hand in developing or testing it and is committed to its
success.  Part of the problem also seems to be a sense of inevitability,
that Java and Java-capable Netscape are much too attractive for their
developers to consider not releasing them or for users to consider not using
them once they are available.  It may turn out to be the case that Java's
benefits outweigh its risks, but the Internet community appears to be
incapable of considering its risks and benefits in advance.  There's nothing
new about technological determinism, but Java seems to be a fairly clear
case in miniature.

-- Prentiss Riddle [email protected]
-- RiceInfo Administrator, Rice University / http://is.rice.edu/~riddle

  [See also an earlier item on this topic by Joe Smith in RISKS-17.01.  PGN]

------------------------------

Date: 11 Oct 1995 17:07:59 -0400
From: [email protected] (Richard Sexton)
Subject: Effective use of the Internet

I got a letter from a company in South Carolina flogging a publication they
wrote claiming this report will help me to make effective use of the
Internet.

Actually I got 22 of them so far. Addressed to such organizations as:

 "The Ontario Mango Growers Cooperative".
 "The Toronto Cabal"
 "The Sexton Clan"
 "The Society for preservation of god under windows"

In other words, the organization line of domain registrations I own for
mango.net, cabal.org, sexton.org and godwin.com,respectively.

The irony of this "effectiveness" is not lost on me. They spent over $US10
in postage to try to get my to buy their $300 report so I can use the
Internet as effectively as they do.

I called them to register my irony -- decidely not to complain. Nobody could
talk to me, but I could leave a message. I asked if I could leave an E-mail
address, they said sure, and took it down. The person on the phone, in the
customer service department, however, didn't have a clue what an E-mail
address was, the "@" and "." confused them terribly until I took 5 minutes
to explain what an E-mail address looked like.

Jane, get me off this crazy thing.

Richard Sexton  [email protected]  There is no Cabal

------------------------------

Date: Sun, 15 Oct 1995 18:44:44 -0400 (EDT)
From: [email protected] (Marc Rotenberg)
Subject: Risk of visiting wrong place on the Web

The Marketry company of Bellevue, Washington is now selling E-mail addresses
of Internet users obtained from Newsgroup postings. From the company's press
release:

  "These are E-mail address of individuals who are actively using
  the Internet to obtain and transfer information.  They have
  demonstrated a substantial interest in specific area of information
  on the Internet.  They are regularly accessing information in their
  interest areas from newsgroups, Internet chats and websites. . . .
  The file is anticipated to grow at the rate of 250,000 E-Mail
  addresses per month, all with Interest selections."

What are the interest areas currently available?  "Adult, Computer,
Sports, Science, Education, News, Investor, Games, Entertainment
Religion, Pets."  The release notes that "additional interests areas
will be added, please inquire." Activities of US and non-US Net users
will be included in the Marketry product.

*The Washington Post* reported that the president of Marketry, Norm Swent,
would not disclose who the actual owner of the list is. "That really is
confidential information," Swent said, "and we are obviously bound by
confidentiality agreements with the list owner."

WHAT YOU CAN DO:

  (a) Sit back, let your newsgroup postings get swept up by the data
  scavengers and watch the junk E-mail pile high on your system, or

  (b) Send E-mail to Marketry and tell them to STOP SELLING PERSONAL
  DATA GATHERED FROM THE NET.  Send E-mail to: [email protected]
  and tell your friends to send E-mail.  And tell your friends' friends.

It's your name.  It's your mailbox. Think about it.

------------------------------

Date: Tue, 10 Oct 1995 11:09:07 +0100
From: [email protected] (mathew)
Subject: Another example of poor use of databases

From the Electronic Telegraph <http://www.telegraph.co.uk/>, 1995-10-10:

Victim of gas blast sent 3230 pound bill (=A3230), by David Graves

BRITISH Gas apologised yesterday for sending a bill to a man who died in an
explosion at his home caused by a suspected gas leak.  The invoice,
addressed to "Mr J Clark - Deceased", was sent last month to John Clark, 36,
a father of two, who died when the explosion demolished a block of flats in
Ilkeston, Derbyshire, in July.  [...]  The bills, collected by Miss Hill
from a local Post Office sorting office, were also addressed to Mr Clark's
flat, which was destroyed in the explosion.  [...]  A British Gas spokesman
said a "billing error" had allowed the bills to "slip through the net.  "We
made arrangements to put a block on all accounts affected by the explosion
but, unfortunately, due to an administrative error, these invoices were
accidentally sent to Mr Clark. We have launched an investigation."

mathew  http://www.domino.org/~meta/

------------------------------

Date:  Fri, 13 Oct 1995 10:15:00 -0400
From: "john (j.g.) mainwaring" <[email protected]>
Subject:  Analysis of Human Factors and Outages

Long-time readers of RISKS may be interested to hear of an initiative by
Bellcore that would address some stories that have appeared here.

The Bellcore Digest for Aug/Sept 95 announces that document GR-2914-CORE is
due to be published in Dec 95.  The Digest says that extensive analysis of
field reports have identified patterns of procedural error that could be
attributed to design characteristics of maintenance user interfaces of many
elements of the telephone network.  GR-2914 will contain requirements
intended to improve and standardize maintenance user interfaces of any piece
of network equipment.

------------------------------

Date: 14 Oct 1995 07:41:30 GMT
From: [email protected] (Rudi Cilibrasi)
Subject: RSI Risk/Editor Correlation (Become a statistic!)

I've recently wondered whether the default keymappings of various popular
Unix editors might be risk factors in getting Repetitive Strain Injury.

To investigate this question, I've created a WWW-based survey program at
http://rmachine.caltech.edu/~www/rsisurv.cgi

If you have a forms-capable web browser, and have about two spare minutes,
I'd appreciate it if you'd take the time to fill out this simple survey.
I will post a summary of results, if any.

Thanks for your help,

-Rudi Cilibrasi

------------------------------

Date: Fri, 13 Oct 1995 16:19:49 +0100
From: [email protected] (Francois Grieu)
Subject: Re: Microsoft Excel 1.40737488355328

Enter       1.40737488355328   in an Excel cell.

Appears     0.64

This is reproducible in version 4.0 or 5.0, under Windows
and Macintosh OS.  Seen on 486, Pentium, 68040, PowerPC 601 processors.
Also reported in Excel version 7 under Win 95.

Now, more details on the problem.

It shows for at least the following 3 numbers, and their negative
  1.40737488355328     2.81474976710656     5.62949953421312

Also happens in scientific notation, e.g.
  140737488355328E-14  281474976710656E-14  562949953421312E-14

Mathematically these numbers are really
    2^47 / 10^14         2^48 / 10^14         2^49 / 10^14

In my configuration the bug does not show  VISUALLY  in a cell
containing  =1.40737488355328 or  = 2^47 / 10^14 .
Still, such a cell has something badly wrong: taking it's integer
part gives 0 instead of 1.  That is,   =INT(2^48/10^14)   gives 0.

It appears to be a bug, not a deliberate signature of the code as
suggested in RISKS DIGEST 17.38.

The fact that the numbers triggering the bug have a simple mathematical
form make them immensely more likely to appear in an Excel cell than
if it was for a few arbitrary values.  Still, the spread of the bug by
Internet is an even more decisive factor ;-)

Microsoft is rumored to acknowledge the problem and have/prepare a fix.
Still, I failed to find any info on this in the Microsoft Knowledge
Base on Excel, at   http://www.microsoft.com/kb/indexes/excel.htm

Quoting  Michael J. Lindsay  ([email protected]):
" This was discovered by Stuart Worley of Hughes Aircraft Company, Tucson
 AZ when he input the following formula in a large spreadsheet
 on September 11, 1995 :     +INT((2^47)/(10^INT(LOG(2^47))))
 The result  0  instead of  1  stood out of the middle of the spreadsheet.
 This prompted him to investigate further. "

Francois Grieu

  [Also noted by Mark Brader <[email protected]>, who pointed at
  <http://www.microsoft.com/msoffice/xler0925.htm>, the text of which
  was also posted recently to comp.apps.spreadsheets, comp.bugs.misc,
  and comp.arch.arithmetic by Michael J. Lindsay ([email protected]).
  There were many other messages on this subject as well.  I have sampled
  just a few.  PGN]

------------------------------

Date: Mon, 16 Oct 1995 13:38:09 -0700
From: [email protected] (Marv Schaefer)
Subject: Re: Microsoft Excel 1.40737488355328

> Interestingly enough., Excel v5.0a on a Mac IIsi also yields .64; however,
> if you paste the original number as text and then perform a math operation,
> Excel yields the correct result.

Curiouser and curiouser.  Not only does 1.40737488355328 get correctly
entered if pasted in place on my MAC PowerPC 6100 in Excel v5.0a, it also is
correct if entered manually as a computation (i.e., as '=1.40737488355328').
The boundary values (viz, 1.40737488355327 and 1.40737488355329) are
correctly treated in computation and in "Regular" display sans the '='
symbol.  1.40737488355328 becomes 1.28 if typed in directly, though.

It certainly does look like PGN's suggested special case for copyright
protection....

Marv

------------------------------

Date: Tue, 10 Oct 1995 14:29:18 -0400 (EDT)
From: "Joe J. Birsa E-375B 8-284-5192" <[email protected]>
Subject: Re: Microsoft Excel 1.40737488355328

Map companies also seem to put intentional errors on their maps to detect
copyright infringement.  One error on a Pittsburgh street map would have had
drivers going down steps on a hillside where a street ended at the top of a
set of municipal steps.  Since this was not corrected on the map for many
years, I suspect that it was intentional.  Usually, this type of error is
limited to insignificant streets and roads; insignificant, that is, if you
never have to travel on them.

Your suspicion that the spreadsheet error was intentional may well be not
unfounded.

Joe Birsa  [email protected]

------------------------------

Date: Thu, 12 Oct 1995 11:50:20 -0400 (EDT)
From: John Lane <[email protected]>
Subject: Re: Microsoft Excel 1.40737488355328

>[I have heard some reports that this flaw is actually an intentional
>feature intended to detect copyright ripoffs....  PGN]

I have my doubts about that. When the publishers of "Who's Who" put in a
handful of fake biographical entries, they want to catch anyone who presents
the contents of "Who's Who" as their own research in, say, a rival
dictionary or a mailing list.

But Microsoft's great problem is the selling of pirated copies of their
software packages. The pirates want to present their copy not as their own
work but as the original product, feature for feature. A copied mistake adds
to the air of authenticity.

John Lane

------------------------------

Date: 6 September 1995 (LAST-MODIFIED)
From: [email protected]
Subject: ABRIDGED info on RISKS (comp.risks)

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
  INFO     [for further information]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.  [...]
[Back issues are in the subdirectory corresponding to the volume number.]
  Individual issues can be accessed using a URL of the form
    http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
    ftp://unix.sri.com/risks  [if your browser accepts URLs.]

------------------------------

End of RISKS-FORUM Digest 17.39
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.