Risks Digest 32.73

[RISKS List Owner]

RISKS-LIST: Risks-Forum Digest Tuesday 29 June 2021 Volume 32 : Issue 73

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, founder and still moderator

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/32.73>
The current issue can also be found at
<http://www.csl.sri.com/users/risko/risks.txt>

Contents:
It's a new world today for RISKS!!! (PGN)
Re: Pipeline Investigation Upends Idea That Bitcoin Is Untraceable
(Toebs Doouglass)
Re: Government Chatbots Now a Necessity for States, Cities, Counties
(Toebs Doouglass)
Re: Wabi-sabi software systems (Martin Ward)
Re: End-to-End Verifiability Key to Future Election Security
(Barry Gold)
Re: Metrics and integrity -- and media (Wol)
Re: Optional is not always optional (Arthur T., Bob Gezelter)
Abridged info on RISKS (comp.risks)

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

Date: Tue, 29 Jun 2021 11:21:07 PDT
From: Peter Neumann <neu...@csl.sri.com>
Subject: It's a new world today for RISKS!!!

With huge thanks to Dan Jacobson <jid...@jidanni.org> for donating the
magic perl goodie, I am now able to automagically generate clean UTF-8 text
from your messages, despite all the header cruft and =3D encodings of equal
signs, and \200, and =E2=80=.. I regret that it took me so long to avail
myself of his wisdom. Because of work obligations, I am way behind on the
backlog, but thought I would start out this new world with just the pending
early replies to the previous issue. More of your submissions will follow
eventually. Cheeeers! Peter

There should be many fewer glitches in future issues. BTW, There was a
manual screw-up in RISKS-32.72: the second item was missing its headers and
an entry in the Table of Contents:

An autonomous ship's first effort to cross the Atlantic shows the
difficulty of the experiment (WashPost), submitted by GabeG.

[I also did not bother with the usual spelling checker. Meanwhile, back
to my day job. Sorry to have been grumbling about all the quirkiness.
The perl of wisdom allows me to save a huge amount of time. PGN]

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

From: "Toebs Douglass" <ri...@winterflaw.net>
Subject: Re: Pipeline Investigation Upends Idea That Bitcoin Is Untraceable
(NYTimes)
Date: Wed, 23 Jun 2021 10:16:10 +0200

For non-US readers, note that for about two decides, civil assert forfeiture
has been profoundly abused.

https://listverse.com/2015/06/29/10-egregious-abuses-of-civil-asset-forfeiture/

Such conduct has always been illegal at the Federal level, but not the State
level. A Supreme Court ruling in 2019 extended protections to the State
level. I have the impression the ruling is taking some time to actually
have an effect.

(There was an excellent Economist article about this, but I was unable to
dig it up. I recall a pair of shop owners had 10k USD bank transfer seized,
because the transfer "looked suspicious", since 10k is the limit under which
transfers are not reported to the Government. They would have been out of
business, except for the compassion and support of their suppliers, and at
the time the article was written they were engaged in legal proceedings.
The police had so far offered to return 20% of the seized - let's use the
right word here, and say stolen - money. All assets seized in this way go
into the police budget. The moral of the story is : do not permit the State
to grant excessive powers to itself, for fear of their misuse. How you stop
this from happening is however not something I have an answer to, and I note
the ever-increasing power of State over time, since the foundation of the
United States. I think I can argue the key problem is not technology, but
politics.)

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

From: "Toebs Douglass" <ri...@winterflaw.net>
Subject: Re: Government Chatbots Now a Necessity for States, Cities, Counties
Date: Wed, 23 Jun 2021 09:18:42 +0200

> The state estimates that it did the work of four full-time employees
during that time.

I have never, *not once*, had a useful interaction with a chatbot.

What happens is an interaction where I have to perform certain undocumented
mandatory actions, which I discover by experimentation, required by the
chatbot to fetch a human being.

> both worked with other departments to figure out what their needs were
and what their most frequent questions were so that they could build those
into their chatbots.

Chatbots seem to be basically an FAQ. The quality and value of the content,
the question-answer pairs, varies just as the quality and value of a normal
FAQs varies, with a single new factor, which is the user interface. With a
traditional FAQ, there is a page with a list of questions and answers. You
can scan down the list of questions, search the page, etc. With a chatbot,
you have to figure out how to operate the black box of the chatbot to try
and determine if in that black box there might be an answer to a question
you have. It's *different*, but I don't see it being an *improvement*.

The main property I see a chatbot possessing is that a chatbot inserts
itself into the path to obtain human assistance, and so is unavoidable. I
suspect with FAQs, they are often unread before people turn to human
assistance. I suspect this is so because FAQs typically are not useful,
because the questions and answers are no good, being often irrelevant,
self-promoting and poorly written, properties which all apply in full to
FAQs presented as chatbots.

> In May 2020, the state's chatbot tools, combined with its live chat
function, saved an estimated 1,700 hours of staff time that would have been
spent addressing those same inquiries using traditional tools.

The magic phrase here being "combined with its live chat function", which
means we have no idea at all if the chatbot was a help or a hindrance, with
my suspicious tending very strongly toward the latter.

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

From: "Martin Ward" <mar...@gkc.org.uk>
Subject: Re: Wabi-sabi software systems
Date: Wed, 23 Jun 2021 14:27:35 +0100

On 23/06/2021 06:07, Henry Baker <hba...@pipeline.com> wrote
> Most garbage collectors solve the memory safety problem at the expense of
> DDOS'ing the CPU's time schedule, making it difficult -- if not impossible
> -- to assure continuous responsiveness.

On-the-fly garbage collection algorithms have been known about since at
least 1976 (See: "On-the-Fly Garbage Collection: an Exercise in
Cooperation", E. W. Dijkstra, L. Lamport, A. J. Martin, C. S. Sholten,
E. F. M. Steffens, Lecture Notes in Computer Science, 46, "Language
Hierarchies and Interfaces" Edited by F.L.Bauer and K. Samelson,
Springer-Verlag, 1976)

"As an example of cooperation between sequential processes with very little
mutual interference despite frequent manipulations of a large shared data
space, a technique is developed which allows nearly all of the activity
needed for garbage detection and collection to be performed by an additional
processor operating concurrently with the processor devoted to the
computation proper. Exclusion and synchronization constraints have been
kept as weak as could be achieved; the severe complexities engendered by
doing so are illustrated."

On modern systems the "additional processor" can be simply
another execution thread.

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

From: "Barry Gold" <Barry...@ca.rr.com>
Subject: Re: End-to-End Verifiability Key to Future Election Security notsp
(Author via GabeG, RISKS-32.72)
Date: Tue, 22 Jun 2021 22:42:09 -0700

I have looked at several schemes for allowing voters to verify their
votes. So far I have not seen one that can't be used to make sure that
someone votes the way they're "supposed to".

Back in the days of paper ballots, it was common for the incumbent political
machine to give voters a pre-marked ballot. The voter would pick up a
(blank) ballot in the polling place, deposit the pre-marked ballot in the
ballot box, and bring the blank ballot back to the ward heeler, where they
would get paid.

If you can verify your vote after the fact, then somebody can pay you $50 or
whatever after making sure that you voted the way they want. Or your boss
can insist on seeing the verification to make sure you didn't vote for the
"wrong" candidate. If you voted wrong, or you refuse to produce your
verification token, you get fired.

I dunno. Maybe biometric identification? Your ballot gets marked with your
fingerprint or (image of a) retinal print. Afterward, you go into a
verification center and put your finger on a reader (eye against a lens),
and it shows you your vote. This is done in a booth where nobody else can
see the results and nobody is allowed to accompany you. Expensive, but
doable, I guess. You'd still have a problem with blind or otherwise
less-able voters, but then you have the same problem with existing
absentee/vote-by-mail systems.

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

From: antlists <antl...@youngman.org.uk>
Subject: Re: Metrics and integrity -- and media (Slade, RISKS-32.72)
Date: Wed, 23 Jun 2021 20:58:15 +0100

If official reports are to be believed, in the UK we KNOW it's Delta.
New infections are systematically selected for genome analysis
specifically to detect new variants, and allegedly we've identified most
new variants.

The latest figures I've seen, maybe a week or so ago, show the previous
(Kent/Alpha) variant as having pretty much disappeared. The delay in
lifting restrictions has been down to the fact nearly all new infections
are Delta, as shown by that analysis.

The good news is that, forget about preventing infections, but the old
vaccine is still nearly 100% effective at preventing hospitalisation and
serious illness. Even with soaring infections, the number of vaccinated
people ending up in hospital is down to double digits.

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

From: "Arthur T." <Risks20210...@xoxy.net>
Subject: Re: Optional is not always optional (RISKS-32.72)
Date: Wed, 23 Jun 2021 16:07:43 -0400

Bob Gezelter wrote (and I greatly snipped):
>While it is common to mark webform fields as *Mandatory*
>or *Optional*, *Optional*s not always optional.

>The field for Middle Initial was marked as optional.

>If an input leads to an inaccurate or incorrect result, it
>is NOT optional.

You aren't wrong. But the web page designers have a
problem. How can they clearly, yet tersely, tell everyone
that this field must be filled in if you have a middle
name, but can safely be left blank if you don't?

They marked it "optional" and you had a problem. If it had
been marked "mandatory", someone with no middle name would
have had a quandary. (And what should people with multiple
middle names do?)

So what's a good solution to the problem you ran into? In
this case, perhaps, a pair of mandatory either/or boxes:
"middle initial" or "I have no middle name". Or a mandatory
drop-down box with all 26 letters plus "none". But I
suspect it's more general problem, and a more general
solution would be better.

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

From: "Bob Gezelter" <geze...@rlgsc.com>
Subject: Optional is not always optional (RISKS-32.72)
Date: Wed, 23 Jun 2021 12:55:20 -0400

Rick, Quite possible. But that is not what the instructions said within the
form.

If the form had said, Middle Initial if any, that would be different.

It is not only a problem with webforms. RealID requires that requested
documents match precisely. If the proffered US Passport or Social
Security documentation does not match the birth certificate PRECISELY. I
do mean PRECISELY.

My birth certificate contains my complete middle name. My passport
obtained using the aforesaid birth certificate has the middle
initial.The mailer on my Social Security card has my full middle name,
but the card itself only has the initial. When this collides with RealID
requirements that require consistency, chaos ensues.

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

Date: Mon, 1 Aug 2020 11:11:11 -0800
From: RISKS-...@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)

The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
comp.risks, the feed for which is donated by panix.com as of June 2011.
=> SUBSCRIPTIONS: The mailman Web interface can be used directly to
subscribe and unsubscribe:
http://mls.csl.sri.com/mailman/listinfo/risks

=> SUBMISSIONS: to ri...@CSL.sri.com with meaningful SUBJECT: line that
includes the string `notsp'. Otherwise your message may not be read.
*** This attention-string has never changed, but might if spammers use it.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you never send mail where the address becomes public!
=> The complete INFO file (submissions, default disclaimers, archive sites,
copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
*** Contributors are assumed to have read the full info file for guidelines!

=> OFFICIAL ARCHIVES: http://www.risks.org takes you to Lindsay Marshall's
searchable html archive at newcastle:
http://catless.ncl.ac.uk/Risks/VL.IS --> VoLume, ISsue.
Also, ftp://ftp.sri.com/risks for the current volume/previous directories
or ftp://ftp.sri.com/VL/risks-VL.IS for previous VoLume
If none of those work for you, the most recent issue is always at
http://www.csl.sri.com/users/risko/risks.txt, and index at /risks-32.00
ALTERNATIVE ARCHIVES: http://seclists.org/risks/ (only since mid-2001)
*** NOTE: If a cited URL fails, we do not try to update them. Try
browsing on the keywords in the subject line or cited article leads.
Apologies for what Office365 and SafeLinks may have done to URLs.
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
<http://www.acm.org/joinacm1>

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

End of RISKS-FORUM Digest 32.73
************************