Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit precedence: bulk Subject: Risks Digest 32.73 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 as The current issue can also be found at 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 Subject: It's a new world today for RISKS!!! With huge thanks to Dan Jacobson 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" 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" 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" Subject: Re: Wabi-sabi software systems Date: Wed, 23 Jun 2021 14:27:35 +0100 On 23/06/2021 06:07, Henry Baker 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" 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 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." 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" 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-request@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 risks@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. *** 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: ------------------------------ End of RISKS-FORUM Digest 32.73 ************************