During the past couple of years, I've been reluctant to comment on
electronic QSL issues because I was working on the LOTW design. I felt that
it would be inappropriate to say anything until the design and project had
been approved by the ARRL Board and announced to the membership. Also, I'm
not a League employee or spokesperson, and didn't want anyone to think I was
stating ARRL policy.
But now that LOTW has been announced and my part of the project is over, I
think it's OK for me to comment on some of the issues that have been raised
as a result of eQSL's change of policy. Please bear in mind that I'm
speaking for me, not ARRL, and that the LOTW specifications are subject to
change.
1. I resent the unfounded accusation that the "QSL technologists" somehow
forced a policy change on DXCC. Nothing of the sort happened. We could
easily have designed LOTW to allow browsing of unsolicited QSLs without
compromising security (our main concern), but were specifically instructed
by DXCC not to do so. LOTW does not permit users to examine unconfirmed QSLs
for the same reason DXCC has had a long-standing policy of discouraging
DXpeditioners from posting all QSO data from their logs on the Internet.
Regardless of any loopholes in the DXCC rules, it's never been right for
WC1M to get a card that was really intended for WY1M, or for WC1M to get a
20M CW confirmation when he incorrectly logged the QSO on 10M a day later.
I'm surprised that a contester wouldn't understand this -- after all, you
don't get credit when you log a contest QSO incorrectly. I suppose another
reason for discouraging the posting of full logs is that it would encourage
people in pileups to call and call, regardless of whether they can hear the
DX or not, in the hope that they will be worked and can get the QSO data
from an online log. Speaking as an Honor Roll and 5BDXCC DXer, I welcome any
DXCC policies that discourage poor operating practice (which, to me,
includes failing to accurately log a contact.)
2. Another completely unfounded accusation is that ARRL forced eQSL to
change its policy by dangling the prospect of DXCC acceptance. eQSL's claim
that the policy change takes them a step closer to acceptance for DXCC
credit is probably a figment of their imagination. They may perceive that
the big problem was browsing of unconfirmed QSLs (which DXCC certainly
frowns on), but as others have stated, the real problem with eQSL is its
lack of data security (see below.) There was no way for us to design LOTW to
be compatible because eQSL doesn't meet even minimal security standards
required to protect the integrity of the DXCC program. While it's
theoretically possible for third parties to securely collect QSO data
according to the LOTW specification, I recommended that ARRL develop its own
version of the system because over the long haul DXCC can't rely exclusively
on the viability of outside vendors. Even if outside vendors are used to
securely collect QSO data, ARRL cannot rely on any external entity to issue
credentials for using LOTW. That function completely controls the integrity
of LOTW and DXCC, which is the sole responsibility of ARRL (see
authentication, #9, below.)
3. It's been said that "The requirement to upload electronic logs in order
to receive QSLs will filter out thousands of potential users." This is an
extreme and baseless claim. First of all, it's not all that hard. You don't
have to submit your entire log -- you can extract and submit whatever QSOs
you want to confirm, although most participants will probably find it easier
just to upload the latest additions to their log. In either case, ARRL plans
to work with log program authors to ensure that this process is as simple
and automated as possible. A stand-alone program for manually entering QSOs
will be provided for those who do not use logging software. If you want a
confirmation, all you have to do is enter the data. It's hard to believe
that thousands will reject LOTW because of this simple requirement.
4. There's something funny about the demand that LOTW allow users to view
and print unsolicited QSLs without uploading matching log data. Does this
mean it's OK to completely ignore the confirmation request? Presumably, the
sender wants a response, but you don't have to give one. You can go merrily
about getting your card or DXCC without giving anyone your card, state or
county. That doesn't seem very friendly. Yes, you can do the same with paper
cards, but how many people hang unsolicited cards on the wall or submit them
to DXCC without having the courtesy to respond? Probably not very many. I
certainly don't (I'd feel guilty!) If most people do in fact respond, then
they have to do some work -- e.g., write out a card. Why is that any
different from uploading a log entry to LOTW or using the stand-alone
program to enter the QSO data? Are the proponents really arguing for the
right to print an unsolicited QSL or use it for awards credit without
providing a response? Will thousands of selfish potential users hate LOTW
for this?
5. But it's not really about the effort of uploading logs -- the real
argument here is that you shouldn't be required to log a contact in order to
receive a confirmation. This argument says you should be able to get a card
without giving your version of the contact information, or that it's OK to
simply echo back the information on the unsolicited QSL. As I said before, I
believe it's poor operating practice not to log a contact, and I believe
it's even worse practice to confirm the data on an unsolicited QSL unless it
matches a log entry (otherwise, in my book, it's NIL.) What if the sender is
mistaken about the time, date, mode or band? How meaningful is the card when
both stations haven't independently verified the data? Pretty pictures, I
guess. Then why not just exchange card images via e-mail or post them on a
website? There's no need to fill in the QSO data because it doesn't mean
anything. Given the it's poor quality, the data certainly should not be used
for awards credit, and then you don't need a central electronic QSL facility
at all.
6. Unlike eQSL, LOTW's primary purpose is not to produce QSL card images for
confirmed contacts. The goal for LOTW is to enhance DXCC and other award
programs, where the QSO information is supremely meaningful. As such, the
requirements of the DXCC program dictate much of the design. LOTW is
intended to speed up, simplify and reduce the cost of the awards
confirmation process for applicants and HQ, while maintaining or improving
the integrity of DXCC data. Rather than filtering out thousands of potential
users, the simplicity of uploading logs to LOTW for awards credit will
likely attract many amateurs who have avoided the awards program because of
the hassle, high cost and lengthy delays to obtain paper QSL cards.
Hopefully this, and the potential benefit of being able to obtain QSL images
from the same uploaded log data, will greatly outweigh the requirement to
upload logs and the restriction on viewing unconfirmed or unsolicited QSLs.
7. From the beginning, LOTW was designed to be a confirmation system. In
other words, both stations submit QSO data and LOTW automatically matches
them to obtain confirmations. It's analogous to what a QSL manager does,
except that confirmations are automatically routed to DXCC for pending
awards credit. Automatic confirmation is one of the big differences between
LOTW and the original eQSL design, and perhaps one reason why eQSL changed
their policy. Until the change, eQSL functioned more like an electronic
clearinghouse - a central repository of QSO data that facilitated manual
confirmation by users. LOTW's automatic confirmation means that you don't
have to decide, on a QSO-by-QSO basis, which contacts to confirm. You don't
have to pick through the incoming QSO data to determine which QSOs are
needed for credit and you don't have to do anything to submit them to DXCC.
Just upload your log and the rest is automatic.
8. Another crucial, and much more important, difference between LOTW and
eQSL is security of the data. Long before I entered the picture, ARRL had
been considering various designs for electronic QSLs. One of their biggest
concerns was the potential for modification of the QSO data. For example, I
receive an electronic QSL from 5A1A for 20M SSB, make a copy and change the
data to 10M CW so the confirmation will count for my 10M DXCC award. This is
trivially easy to do with computer data unless certain security precautions
are taken. I was one of several amateurs who suggested to ARRL that digital
signatures using public key cryptography could solve this and other security
problems. Digitally signed QSO data can't be altered without detection and
we can be positive that the signature came from a specific digital ID. To my
knowledge, no other method provides these safeguards. It may be argued that
this is stronger than the security of paper QSLs, but what's wrong with
that? Just because the old system wasn't secure, it doesn't mean the new one
shouldn't be. The extra security isn't necessary for exchanging pretty
postcards, but it sure enhances the integrity of the awards program.
9. A major problem for any security system, whether it be based on digital
IDs or passwords, is authentication. This is the process of determining the
identity of the person requesting the digital ID or password and safely
distributing the ID or password to that person. In the case of amateur
radio, the question is not so much identity per se, but callsign ownership.
The key requirement is that only the owner of a particular callsign, or a
QSL manager authorized by the owner, can digitally sign QSO data for that
callsign. But when some random online user claims to own a callsign, how do
we know he's telling the truth? It's a very difficult problem to solve, and
there are many tradeoffs. By far, this part of the LOTW design took the most
time and effort to work out. Almost half of the 83-page specification is
devoted to discussing authentication and related topics. Nine different
approaches were analyzed in great detail, including possible attack
scenarios and consequences. Using ARRL membership and e-mail addresses for
authentication, as suggested on this reflector, ranked among the weakest
methods (i.e., easy to cheat.)
10. Why so much security? Is it really necessary to use such advanced
methods to protect data that, in the final analysis, is important only to
hobbyists? Well, let's all remember the uproar that occurred when certain
DXpeditioners were found to have lied about the locations of some rare
operations (I can think of two famous cases.) One of the perpetrators was
also suspected of denying contacts to people he didn't like. Over the years,
the DXCC desk has intercepted plenty of altered cards and other attempts to
cheat the system. While some participants just say, "they're only cheating
themselves", others get pretty annoyed. Some feel quite diminished by the
thought of a cheater getting an Honor Roll plaque when they're still working
for it after 20 years and $1,000 in postage. There are others who, right or
wrong, aggressively protect their position in the Honor Roll list and would
be very vocal if "beaten" by a cheater. Although some may not take DXCC
seriously, there are many participants who take it very seriously, spend a
lot of money chasing awards, and care deeply about the integrity of the
program. I don't understand why anyone would cheat, but out of millions of
hams worldwide we're going to get quite a few who will.
11. There's a lot more to it than simple cheating -- there's also the
potential for malicious persons to undermine the integrity of the system by
stuffing it with lots of false data. A partial honor system works for paper
QSLs from non-rare entities because it's a lot of work to promulgate fake
cards on a big scale. Paper forgeries are likely to affect a small number of
people, or only the perpetrator. But computer fraud can be much more
damaging than paper fraud because it's easy to quickly duplicate the fraud
dozens, hundreds or thousands of times over. For example, without security I
could submit bogus P5 confirmations for hundreds of random callsigns in the
callbook. How does the computer know I'm not the real P5? For that matter, I
could submit bogus confirmations from any rare callsign. OK, let's say ARRL
doesn't allow electronic QSLs from rare entities unless mailed in on a
floppy disk with paper proof (sort of a pain for the DX station.) Then I'll
just flood the system with thousands of fake DL and OK confirmations. No one
will know who has a legitimate DL or OK and who doesn't. Don't care if DL or
OK cards are legit? How about the semi-rare ones that DXCC doesn't check?
Should we add more work for the DX and DXCC by requiring a floppy and paper
proof for those QSOs, too? What happens if someone hacks the ARRL server and
changes the QSO data for hundreds of users? What if a disgruntled ARRL
employee alters thousands of incoming QSL records just to get back at the
boss? How can we know whether any given QSO record was altered after it left
the sender's computer? Without good answers to these and many other
questions (or, worse, if a breach occurs), the LOTW system and the DXCC
program will be perceived to lack integrity. Once that horse gets out of the
barn, it'll be too late to put it back in.
12. One of the truisms in system design is that security and convenience
have an inverse relationship: the harder it is to breach a system, the less
convenient it will be to use (there can be tradeoffs with privacy, too --
e.g., are you prepared to let the government keep a digital copy of your
fingerprints in their database?) Much of the design work for LOTW involved
vigorous debates over this tradeoff. Everyone wanted the system to be
secure, but everyone also wanted it to be easy to use. KR1G and I were hired
to be the security experts, so naturally we advocated for as strong a system
as possible. ARRL staffers insisted on integrity of the system, but pushed
very hard to make it easy to get started and easy to use. I can assure you
that at all times the needs of LOTW's customers were paramount in everyone's
mind. In the end, it was hard for us to escape one piece of logic: you can
start out with strong security and, if it's too inconvenient, relax the
rules later on. But you can't do it the other way around.
13. Although automated software will not be provided for amateur-to-amateur
QSLing, the system design allows it. In theory, you can extract QSO data,
digitally sign it, send the signed QSO data to another station (for whom it
was unsolicited), get a confirming digitally signed QSO record in return,
then e-mail both records to LOTW for confirmation and awards credit for both
stations (or the station getting the unsolicited QSO data can send it in
along with his signed matching QSO data.) It doesn't matter who actually
e-mails the QSO data to LOTW -- it only matters that there are matching
records, each digitally signed by one of the stations. That said, I don't
know why anyone would go through the trouble. It's much easier just to
upload your log and forget about it. Besides, what DXpedition would want to
receive 50,000 e-mails before they even leave the island? Or have to send
50,000 e-mails back? The point is this: application design should be
appropriate for the medium that will be used. It is often the case that
mirroring a bricks-and-mortar or snail-mail design is not the best approach
for the Internet.
14. Someone wondered whether contest logs submitted to ARRL could
automatically get into LOTW. The implementation team is responsible for
selecting the LOTW format and I don't know what they settled on. My
understanding is that Cabrillo won't be adequate for all the QSO data we
might want to submit. Also, each LOTW record has to be digitally signed,
which is not part of the Cabrillo standard. The original spec for LOTW
records didn't have a field for a contest exchange, but I don't know what
the final spec will be. My conclusion is that it's likely you will have to
do two e-mail submissions: one in Cabrillo for the contest sponsor and one
in LOTW format for DXCC. As long as logging programs support the LOTW format
(as is hoped), it won't be a huge hardship to do two e-mails, and maybe the
logging programs will make this transparent to the user. It's entirely
possible that the two formats will merge down the road so that only one
submission will be required.
15. I plan to use LOTW for two things: 1) to get awards credit (faster
turnaround time, zero postage cost and no stolen cards/greenstamps/IRCs),
and 2) to ease the burden of responding to thousands of requests for contest
QSLs. I'll use mail or the buro to request a card for any new entity that I
work or from DXpeditions that offer interesting cards. But I'll get DXCC
credit right away through LOTW and I won't clog up the buro with new
band/mode requests or preemptive contest QSLs. My hope is that most contest
stations will stop preemptive QSLing and use LOTW instead. If paper QSLs are
requested only by those who really want them, or those who don't have access
to LOTW, then the burden on the buro, QSL managers and contest operators
should be greatly reduced.
I hope this too-lengthy e-mail sheds some light on the subject. Given that
full details about LOTW won't be released until the system becomes
available, it's understandable that there are some misimpressions about it.
But I would hope that in the future people would refrain from making
statements about the actions and motives of others without first
ascertaining the facts.
73, Dick WC1M
|