Subject: RISKS DIGEST 17.26
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest  Tuesday 15 August 1995  Volume 17 : Issue 26

  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:
Motorola cell-phone software bug: accidental denials of service (PGN)
Australian Navy rejects Windows 95 (Dave Horsfall)
Air-traffic control power struggles continue (PGN)
Re: Oakland ATC Problem (Barry Margolin)
Re: Oakland Center Airspace (Andres Zellweger)
"National" Crypto Policy (Bill Murray)
Northwest Airlines spit me out (Daniel Frankowski)
Insisting on explanations for failures (Jonathan I. Kamens)
"The Trouble With Computers" by Landauer (Rob Slade)
Re: R&D on User Interfaces (Brenton Hoff)
Re: Birthday issue of risks (Frederick B. Cohen)
Re: "The Net" (D.J. Bernstein)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: Mon, 14 Aug 1995 8:44:44 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Motorola cell-phone software bug: accidental denials of service

An article in The New York Times, 14 Aug 1995, by Lawrence M. Fisher
(Software Bug in Motorola Cell Phone Prompts Worldwide Recall) describes a
software bug in one model of Motorola's cellular phone.  Apparently Israelis
tend to keep their cell phones on all the time, because service is only 3
cents a minute.  This resulted in a bug manifesting itself that had not
previously been a problem.  Motorola's Alpha digital phone was introduced in
December, and sporadic problems were reported in Hong Kong in February.
  By April, 65,000 Alphas had been distributed in Israel by Cellcom.
Alphas were being blamed for sound quality that made voices inaudible, a
lack of reception in areas where reception was promised, cutting off calls,
and long periods when the phones simply did not work.  The biggest problem
seems to have been that the digital TDMA (time division multiple access)
phones would lock onto one frequency during the periodic registration,
rather than switching; this resulted in blocking all other users in the
local cell.  Motorola wound up recalling 150,000 Alphas in six countries, to
change the software (a job estimated by Motorola as costing between $10
million and $20 million.

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

Date: Tue, 15 Aug 1995 10:27:53 +1000 (EST)
From: Dave Horsfall <[email protected]>
Subject: Australian Navy rejects Windows 95

I just heard on the radio this morning that the Royal Australian Navy has
prohibited the use of Windows 95, citing security concerns to do with its
uploading of possible sensitive information.

Dave Horsfall (VK2KFU) | [email protected] | VK2KFU @ VK2DAA.NSW.AUS.OC

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

Date: Mon, 14 Aug 1995 8:26:53 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Air-traffic control power struggles continue

On Saturday, 12 Aug 1995, lighting knocked out both the main power and the
backup for almost 1.5 hours at the Miami-area ATC radar center that tracks
400,000 square miles of air space over Florida, the Atlantic, and the Gulf
of Mexico (ok, RISKS readers, that is a radius of about 357 miles, assuming
a circular area).  ``Travelers were never in danger, said an FAA
spokesman.''  [Source: San Francisco Chronicle, 14 Aug 1995, p. A3.]

 [Typo fixed... SQUARE removed.  PGN]

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

Date: Sat, 12 Aug 95 23:07:49 EDT
From: [email protected]
Subject: Re: Oakland ATC Problem (Pettit, RISKS-17.24)

> Why did the planners building the air-traffic control
> center not think a constant supply of power would be important?

They did.  According to the brief CNN story I saw, there were two backup
power supplies.  However, one was down for repairs, and the other didn't
come online automatically like it should have.  When this was realized,
engineers had to start it manually, and this took time.

Barry Margolin  BBN PlaNET Corporation, Cambridge, MA  [email protected]
Phone (617) 873-3126 - Fax (617) 873-5124

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

Date: Mon, 14 Aug 95 10:32:04 EST
From: "Andres Zellweger" <[email protected]>
Subject: Re: Oakland Center Airspace (RISKS-17.24)

My guess is that the airspace controlled by Oakland Center was correctly
reported to be 18 million square miles.  The Center is responsible for
controlling traffic over most of the Pacific.  Its airspace includes Guam,
goes almost as far south as Fiji, and further north, more than 2/3 of the
way west from California to Japan.  Dres

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

Date: 13 Aug 1995 13:55:09 -0400
From: [email protected] (WHMurray)
Subject: "National" Crypto Policy

A recent post from Ross Anderson via Lance Hoffman and David Farber
contained the following:

>... says that the OECD countries will hold a meeting on National
>Cryptography Policies later this year. While at the conference, I found
>out that a classified meeting took place this March in Germany between
>the signals intelligence agencies of the developed countries, plus
>Australia and South Africa, at which the assembled spooks agreed to
>press their governments to bring in escrow and/or weak crypto.

I think that it should be noted that these policies are not "national" in
any real sense of that word.  They are not the result of national dialogue.
They are not positions taken by the elected government.  Rather they are the
unchallenged policies of the bureaucracy. These so-called policies are the
positions of the princes, not to say spooks.  They ignore the interests of
the merchants and the bankers, let alone the citizen.  It may already be too
late for elected officials to reassert their authority over the bureaucracy
but we do not yet have to consent to having the language distorted against
us.

While I am defending the language, the use of the term "escrow" in this
context is intended to sugar coat something that is nothing like escrow.
Historically, escrow has been used to talk about a fiduciary with equal
responsibilities to both parties.  That is very different from these
proposals where the duty of the agent is to act in the interest of one party
without so much as notice to the other.

William Hugh Murray  New Canaan, Connecticut

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

Date: Sat, 12 Aug 1995 12:41:14 -0500 (CDT)
From: Daniel Frankowski <[email protected]>
Subject: Northwest Airlines spit me out

Here's a little test for your readership, sort of like a word search.
It's a risk search.  How many risks can they find in the letter below?
This letter was sent to Northwest Airlines on August 11.

Should I have done anything differently?  Should Northwest?

Dan Frankowski [email protected] http://www.winternet.com/~dfrankow

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

Dan Frankowski
ADDRESS DELETED
WorldPerks numbers XXX-XXX-XXX and YYY-YYY-YYY

John Dasburg
Northwest Airlines
5101 Northwest Drive
Saint Paul, MN  55111

Dear Mr. Dasburg:

The purpose of this letter is to request

(1) detailed information that your computer information and
   information-related problem-resolution practices are safe and
   effective
(2) an apology from customer service
(3) an explanation about what happened to my XXX-XXX-XXX WorldPerks account
(4) restitution of the miles on that account or equivalent compensation

I have a master's degree in computer science, and I work as a
programmer.  I realize that you cannot reveal trade secrets, but as a
customer, I feel entitled to some reasonable amount of information.

Since 1987, I had a WorldPerks account (#XXX-XXX-XXX).  Because I used
the account infrequently (once or twice a year), I did not keep
written correspondence from Northwest.  Thinking back, I had not
received an account statement for at least 18 months.

On July 16, 1995, I flew to Chicago on Northwest.  I presented my
WorldPerks card (#XXX-XXX-XXX), and was asked to confirm an address in
Milwaukee, Wisconsin.  I have never been to Milwaukee; I could not
confirm the address.  The Northwest employee told me to call customer
service when I had time.

I called customer service within a week.  They told me that without
written correspondence from Northwest, I had no option but to open a
new account with zero miles on it.  I was repeatedly told that
XXX-XXX-XXX was not my account, since it had weekly flights from
Milwaukee since 1988.  I agreed that the flights listed were not mine,
but maintained that the account was.  The only proof I have is my dark
blue WorldPerks card with red lettering (photocopy enclosed).  The
customer service representative said that the color is important, as
it indicates when the card was issued.

I felt accused and shabbily treated by customer service.  It would
have been simple to call me back after someone knowledgeable in
customer records had investigated my case.  Instead, I was treated as
the wrongdoer, repeatedly told the account was not mine, and given the
"only option" of opening a new account.  I opened a new account
#YYY-YYY-YYY.

Accompanying the overwhelmingly rapid expansion in the use of
information services, companies must develop responsible
problem-resolution capabilities.  It's good business.  Demonstrate
your good business capabilities by satisfying my requests in the first
paragraph of this letter.

Your customer,

Dan Frankowski

P.S.  I am also sending this to the Usenet newsgroup comp.risks, which
has international readership, as an example of the risks of computing.
I will keep them updated with your replies.

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

Date: Sat, 12 Aug 1995 20:04:51 -0400
From: "Jonathan I. Kamens" <[email protected]>
Subject: Insisting on explanations for failures (Green, RISKS-17.24)

In RISKS-17.24, Paul Green suggests that more customers should, when
confronted with a failure by a company they patronize, insist not only on a
fix to the failure, but also on an explanation of the root cause of the
failure and of how it will be prevented in the future.  Perhaps he has had
better experience than I with this approach, but every time I've tried it,
I've been blown off.  I'll give a recent example, which I confess is not
directly related to computer risks, but which I believe illustrates my point
in a useful way.  I am not "changing names to protect the innocent," because
Dell is *not* innocent and has, in my opinion, earned through its actions a
public condemnation of its cluelessness.

In November of last year, I purchased a Pentium PC (model XPS P90) from
Dell.  I began to follow discussions in alt.sys.pc-clone.dell, and shortly
after my PC arrived, I saw a posting from someone asking what the story was
with the BIOS upgrade for XPS P90 systems.  A Dell representative posted a
response saying that the current BIOS version was A05 and that update disks
had been mailed, via U.S. Mail, to all registered XPS P90 owners.

I checked, and lo and behold, my system was running BIOS version A04,
despite the fact that Dell had shipped it to me *after* they released
A05.  I never received an update disk from Dell.

I engaged in a lengthy E-mail conversation with Dell's on-line
technical support department, in which I pointed out that (a) I should
not have been shipped a system with an obsolete BIOS on it, and (b) I
should have received an update disk if my system had an obsolete BIOS,
I was a registered owner, and disks really were mailed to all
registered owners.  I asked for specific explanations of why both of
these failures occurred, and what was being done to fix them, so that
at the very least I would not miss out on any future mailings from
Dell that I was supposed to receive.

Despite repeated requests, the people with whom I corresponded never
even tried to address point (a) above.  As for point (b), they
continued to insist for quite a while that everyone had been mailed
update disks, and when pushed on the issue, they claimed that either
my address must have been wrong in one of their databases, or the
U.S. Postal Service must have lost some of the disks that were sent
out.

I pointed out to them that in either of those cases, there was something
wrong that they needed to investigate.  If my address was wrong, then they
needed to find out how it got to be wrong and fix it, because I gave them
the correct address when I ordered the system and it hadn't changed since
then (and I'd received other mailings from Dell with no problem).  If the
Postal Service lost some of their mail, then they had a serious bone to pick
with the Postal Service, and they should demand an investigation and
compensation from the Postal Service.

Using Occam's Razor, it seems far more likely that rather than any of their
excuses being correct, what really occurred is simply that the switch from
A04 to A05 in manufacturing and the mailing out of update disks to
registered owners were not properly synchronized, so some people received
new systems with the obsolete BIOS after the mailing out of disks to
registered owners had already occurred, or even that they made an error when
mailing out the disks and some registered owners were not included in the
mailing.

At no time during this stream of correspondence did the people at Dell show
any comprehension of why I considered it important to find the cause of the
problem, rather than just to solve its symptoms.  Several times, they told
me that I could download the BIOS update program from their BBS, FTP server
or WWW server, even though I told them several times that I'd already *done*
that, and that I was trying to get *past* that to find and fix the root
cause of their failure to ship me a current BIOS.

In the end, I sent a paper letter to the manager of Dell's support
department, relating in it this entire story and suggesting that perhaps he
might want to consider training his employees in simple TQM concepts such as
the one I was trying to get across to them.  I got a response a few weeks
later, informing me that my letter had been received and was being acted on,
and that I would subsequently received a more substantive response to my
complaints.  I never received such a response, and that's where things stand
to this day.

The treatment I received from Dell is not, in my experience, an isolated
experience.  Almost invariably, when I suggest to someone that I have a
right to know the root cause of a failure, and that finding and providing me
with that root cause will *help* them serve customers better in the future,
I am met with stone-faced resistance of the "Stop telling me how to do my
job" variety.  I do not blame only the employees with whom I have dealt with
for this.  When a company encourages its employees to handle customer
complaints *quickly* (as in, "This call may be monitored to ensure that our
employee gets you off the telephone in the shortest amount of time possible,
so that they can handle more calls per day, so that we don't have to hire
more support people."), as opposed to encouraging them to handle complaints
*well*, taking initiative to ensure that similar problems do not occur in
the future, employees have little choice but to buckle under.  When speed is
rewarded at the expense of everything else, quality suffers.

TQM isn't the grail of quality customer support.  It has a lot of aspects
that I find silly; I'm certainly not a TQM junkie like some managers (and
companies) I've seen.  Nevertheless, it has some good ideas, and one of the
best is encouraging all employees to treat the root causes of problems
rather than the symptoms.  Alas, I don't know how we can get that message
out effectively.

Jonathan Kamens (whose XPS P90 is now en route from the United States to
Israel and over three weeks overdue, thus forcing him to use his wife's
PowerBook instead, due to another customer service horror story that's too
long to include here)

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

Date: Sat, 12 Aug 1995 16:13:37 EST
From: "Rob Slade" <[email protected]>
Subject: "The Trouble With Computers" by Landauer

BKTRBCMP.RVW   950605

%A   Thomas K. Landauer
%C   55 Hayward Street, Cambridge, MA   02142-1399
%D   1995
%G   0-262-12186-7
%I   The MIT Press
%O   U$27.50 [email protected]
%P   425
%T   "The Trouble with Computers"
"The Trouble with Computers", Thomas K. Landauer, 1995, 0-262-12186-7, U$27.50

Oh yes, we got Trouble!
Right here in Silicon Valley!
With a capital "T" and that rhymes with "P"
And that stands for Design!  (Poor Design!)

Landauer has compiled an impressive collection of studies and statistics to
show that computers are not contributing to productivity as they ought.
Liberally sprinkled with computer horror stories occurring to his friends,
family, and self, both anecdotes and academics point out what readers of the
RISKS-FORUM Digest know already--we are using computers the wrong way.

Over and over again, we see instances of bad design.  Devices and interfaces
that are unusable.  Mission-critical tasks entrusted to insufficiently
reliable machines.  Whole systems viewed only from the output end.  About
halfway through the book, the statement is made that computers are marvelous
toys: this is quite true.  The trouble is that the majority of computer
owners are demanding more frills on their toys, drowning out the faint cries
of those who need more design in their tools.

Landauer's solution is UCD, an acronym that stands for three variations on
"user-centred design".  This sounds a lot like human factors engineering or,
as we highly technical types refer to it, doing a good job.

Anyone involved in the implementation or support of technology knows that
bad designs abound, and that more care should be taken to improve usability.
This work does not offer significant help in that direction.

copyright Robert M. Slade, 1995   BKTRBCMP.RVW   950605
Vancouver Institute for Research into User Security Canada V7K 2G6
[email protected] [email protected] [email protected]

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

Date: Fri, 11 Aug 1995 23:47:06 +0930
From: behoffski <[email protected]>
Subject: Re: R&D on User Interfaces (RISKS-17.22)

With regard to the article by Maxion and Goldberg in RISKS-17.22 about about
the problems with humans interfacing with computers, I have a comment that
is highly unorthodox but which might provide a pathway into the problem.

Traditional methods (adapted and extended by object-oriented methodologies)
are based on breaking the system into a series of objects, and then
modelling the messages between objects.  Conventional languages such as C
(etc.) are used to implement the system as modelled.

My belief is that the inheritance of procedural languages based on FORTRAN
or ALGOL is that in choosing to define programming as a series of formulas,
they have also chosen to implement a simplified algebra where the operations
are limited to nouns and verbs, without much support for adjectives and
adverbs.  The result is that simple but powerful parts of thought have to be
broken down before they can be expressed in a program.  A simple example is
a program to select all the "leaf" nodes of a tree: to implement this
simple, powerful, parallel operation typically involves breaking "leaf" into
the test "is_leaf" and then checking each node in a loop.

Adjectives and adverbs are common in systems, but not at the level of
languages like C: they are found in the command line switches to programs
which modify the behaviour of the program or the set of objects processed by
the program.

I believe that the freedom to express adjectives in a graphical fashion is
one of the reasons why windowing systems have become more popular than
command-line systems.  Modifiers such as shift-clicking also provide a
convenient way of expressing adverbs.

My personal goal (which is still a long way off, sigh) is to design and
implement a language where adjectives and adverbs join nouns and verbs as
primitives when presenting an interface to clients.  The process of
constructing a solution to a problem then becomes a process of building a
language in which the solution can be expressed.  Each module that
contributes to the environment also provides an implementation of the
facilities it offers.

The major reason for having this sophistication in the interface is that it
allows the separation between modules to be much greater than is afforded
now.  This results in improved reuse of the code, which leads to fewer bugs.
The approach also allows more sophisticated concepts used by the programmer
to be captured in the implementation, which results in a clearer and more
maintainable program.

Another corollary of this idea is scaling: one of the major hurdles to code
reuse is that interfaces appropriate to an 8-bit embedded microprocessor are
not suited to a supercomputer, yet many of the problems being solved are
alike.  Adjectives and adverbs allow efficient requests to be generated,
with the effort required hidden from the interface.  One could easily
imagine a family of implementations for a tree that covered a wide range of
hardware; any user could use the interface equally without caring about the
scale of the machinery underneath.  This is not feasible where the client
has to get involved in the step-by-step processing.

And finally, the scope offered to implementors of the interface is much
greater where the request is able to be more expressive.  For example, an
interface might offer "node" and "leaf", and have standard routines for
handling requests that include these elements.  However, if "leaf nodes" was
very commonly used, then this pair could be identified in the implementation
and an optimised fragment of code selected.  This optimisation can be kept
entirely hidden from the user.

As I said before, this is a (slightly) unorthodox point of view;
I hope it is helpful in the research.

Brenton Hoff

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

Date: Mon, 14 Aug 1995 08:06:16 -0400 (EDT)
From: [email protected] (Dr. Frederick B. Cohen)
Subject: Re: Birthday issue of risks

I was very pleased to see that the Risks Forum is now 10 years old, and I
thought a comment would be appropriate on the contents of the tenth
anniversary issue.

I thought the different viewpoints were interesting and worthwhile, but
I didn't see anything explicit on the two areas that I consider to be
the most important issues we face in the computing community today:

                       Integrity and Availability

I saw several fine articles, including [list deleted by PGN...]

All of these issues are vital and interesting and the authors gave us well
thought out discussions and/or pointers to useful material.  I commend them
on their efforts, but at the same time, I am deeply concerned that we, as a
community, are scoring magnificent hits on the wrong targets.

I don't want to take a great deal of time and space in this illustrious and
now scholarly forum to go into a great deal of detail.  I only want to
express that the issues of privacy, perceptions, reliability, and how people
interact with computers will never be fully addressed unless and until we
address the issues of integrity and availability, for meeting each of these
challenges depends on the integrity and availability of information systems
and the information they manage.

I thank the risks forum for ten years of meaningful discussion, active
participation, and thoughtful exchanges of information.  I hope that the
moderator continues to operate with the same degree of integrity that has
brought this forum so far and that the forum remains available for all of
its readers for many years to come.

Fred Cohen
                     -> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

  [Thanks.  Hopefully we can operate with Integrity AND Availability.  PGN]

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

Date: Sun, 13 Aug 1995 20:28:50 -0500
From: "D.J. Bernstein" <[email protected]>
Subject: Re: "The Net" (Greene, RISKS-17.22)

In RISKS-17.22, Andrew Marc Greene writes:
> the software equivalent of the "Sneakers" chip

The ``Sneakers'' chip could magically invade any computer system. ``The
Net'' created a more plausible scenario. (Warning! Spoiler follows.)
serih eH .rood kcab a htiw erawtfos ytiruces secudorp yug dab ehT
dna IBF eht yltneuqesnoC .smetsys retupmoc fo stol otni kaerb ot srekcah
,erawtfos :laroM .erawtfos ytiruces wen sih llatsni no os dna QADSAN
)-: .toor sa nur ot dewolla eb ton dluohs ,erawtfos ytiruces neve

> (and the IP equivalent of a 555-xxxx number is
> xx.xxx.345.xxx).

Yeah. Unfortunately, typical IP software will silently convert 345 into
89, which is a valid number. A better solution would be to allocate a
set of IP addresses for use in movies. How about 43.43.xxx.xxx?

---Dan

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

Date: 9 August 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from 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.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
the newly automated <[email protected]>, with first text line
  SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
  HELP
gives instructions on using the Majordomo listserver in other ways.

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.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
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.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password.  Also ftp [email protected].  WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
  or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen.  Use wisely.

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

End of RISKS-FORUM Digest 17.26
************************

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.