• Risks Digest 32.56

    From RISKS List Owner@21:1/5 to All on Fri Mar 19 23:47:30 2021
    RISKS-LIST: Risks-Forum Digest Friday 19 March 2021 Volume 32 : Issue 56

    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.56>
    The current issue can also be found at
    <http://www.csl.sri.com/users/risko/risks.txt>

    Contents:
    Victoria University of Wellington accidentally wipes all desktop computers
    (Critic-NZ)
    The Cybersecurity 202: Congress mulls legislation to require companies to
    report major cyberattacks (WashPost)
    New Zoom Screen-Sharing Bug Lets Other Users Access Restricted Apps
    (The Hacker News)
    Fintech Giant Fiserv Used Unclaimed Domain (Krebs on Security)
    Is automated vulnerability scanning the best way to secure smart vehicles?
    (AT&T Business Insights Report)
    Mission to clean up space junk with magnets set for launch (CNN)
    Cars Have Your Location. This Spy Firm Wants to Sell It to the U.S. Military
    (Vice)
    Spanish COVID-19 mortality statistics in young children exaggerated by year
    coding problem? (The Lancet)
    If you've gotten fake calls from "Amazon" about a bogus purchase, watch this
    video (Lauren Weinstein)
    Europe's artificial intelligence blindspot: Race (Politco)
    An existential discussion: What is the probability of nuclear war?
    (Martin Hellman/Vint Cerf in the Bulletin of Atomic Scientists)
    Re: Japanese contact tracing software of Covid-19 patient on Android did not
    work for four months (Kyodo News via Chiaki Ishikawa)
    Re: Voting Machine Hashcode Testing: Unsurprisingly insecure, and
    surprisingly, insecure (Wol)
    Re: Computers get Sundays off? (David Lesher)
    Abridged info on RISKS (comp.risks)

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

    Date: Thu, 18 Mar 2021 14:05:23 +1300
    From: Eliot Blennerhassett <eliot@blennerhassett.gen.nz>
    Subject: Victoria University of Wellington accidentally wipes all desktop
    computers (Critic-NZ)

    Victoria University of Wellington (New Zealand) accidentally deleted all the files stored on its desktop computers last Friday. Items in the H: drive, M: drive, or the cloud were still accessible.

    This morning, staff and post-grad students received an email saying that IT were ``still working on a technical solution to recovering the data that was deleted over the weekend.''

    Those who might have lost significant files were told not to log onto their computers, as that could overwrite the files even further. ``If you have a colleague who can't read this email because they're afraid to logon to their computer, please show it to them or get them to read it on their phone.''
    [...]

    The aim of the data wipe was to clear inactive users' data by getting rid of profiles of students who no longer studied, according to what IT staff told students. Instead, something went wrong and it cleared all of the files
    stored on the computers.

    https://www.critic.co.nz/news/article/9182/vuw-accidentally-wipes-desktop-computers

    I haven't seen any public information about what the backup status was or
    how the recovery is going.

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

    Date: Wed, 17 Mar 2021 11:21:48 +0800
    From: Richard Stein <rmstein@ieee.org>
    Subject: The Cybersecurity 202: Congress mulls legislation to require
    companies to report major cyberattacks (WashPost)

    https://www.washingtonpost.com/politics/2021/03/16/cybersecurity-202-congress-mulls-legislation-require-companies-report-major-cyberattacks/

    "Lawmakers worry too much leniency could provide a shield for negligent companies seeking to avoid liability for poor cybersecurity."

    The Internet, since inception, has been an unconstrained digital calamity, a minefield of risks to privacy, civility, blackmail, and theft without
    cure. Governments and businesses, sustaining repeat and intensified injury,
    are now compelled to attend these wounds with thicker, permeable duct tape.

    Nothing compels businesses to act more quickly than brand outrage and diminished profit threat attributed to questionable competence and feckless leadership. Enforced regulations -- financial penalty and possible incarceration -- compelling timely breach or malware intrusion disclosure
    are woefully tardy.

    Contemplating waivers for liability and indemnification amounts to corporate welfare that will diminish governance accountability, a political backslap
    to entice campaign contributions while ignoring elevated risks. If
    regulatory liability and indemnification waivers adjust to enhance corporate immunity for disclosure, they must also balance consumer interests against portentous outcome.

    To enhance corporate governance accountability, and inculcate internal behaviors that enhance cyberdefense practices, restrict invocation of indemnification scope. Federal regulation that requires a corporate charter
    to limit indemnification coverage to employees *or* the brand, but not both concurrently, can yield benefits for consumers and the corporation.

    Indemnification insures against corporate loss from liability and
    negligence, exposures which burden the consumer via product terms of service
    or use. Restricted indemnification can act like a "Damocles Sword" to constantly remind businesses of their perpetual obligation (i.e., investment in, and maintenance of, cyberdefenses) to fulfill regulatory compliance.
    While not bulletproof, requiring continued compliance with progressively tightened cyberdefense standards elevates deterrence in the public interest.

    Businesses that achieve compliance, but experience breach or malware impairment, can apply for regulatory penalty relief; those that do not are subject to mandatory accountability. This approach burdens compliance audit capability to demonstrate exceptional competence and high capacity,
    requiring the embodiment of significant expertise, to become "the de facto smartest folks in the room." Procuring this talent, and knowing how to
    retain and nurture it, may be the greatest challenge the regulatory body confronts.

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

    Date: Fri, 19 Mar 2021 09:23:55 -1000
    From: geoff goodfellow <geoff@iconia.com>
    Subject: New Zoom Screen-Sharing Bug Lets Other Users Access Restricted Apps
    (The Hacker News)

    A newly discovered glitch in Zoom's screen sharing feature can accidentally leak sensitive information to other attendees in a call, according to the latest findings.

    Tracked as CVE-2021-28133 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28133>, the
    unpatched security vulnerability makes it possible to reveal contents of applications that are not shared, but only briefly, thereby making it
    harder to exploit it in the wild.

    It's worth pointing out that the screen sharing <https://support.zoom.us/hc/en-us/articles/201362153-Sharing-your-screen-content-or-second-camera>
    functionality in Zoom lets users share an entire desktop or phone screen, or limit sharing to one or more specific applications, or a portion of a
    screen. The issue stems from the fact that a second application that's overlayed on top of an already shared application can reveal its contents
    for a short period of time.

    "When a Zoom user shares a specific application window via the 'share
    screen' functionality, other meeting participants can briefly see contents
    of other application windows which were not explicitly shared," SySS researchers Michael Strametz and Matthias Deeg noted "The contents of not shared application windows can, for instance, be seen for a short period of time by other users when those windows overlay the shared application window and get into focus." <https://www.syss.de/pentest-blog/syss-2020-044-sicherheitsproblem-in-screen-sharing-funktionalitaet-von-zoom-cve-2021-28133>

    The flaw, which was tested on versions 5.4.3 and 5.5.4 across both Windows
    and Linux clients, is said to have been disclosed to the videoconferencing company on December 2, 2020. The lack of a fix even after three months could
    be attributed in part to the difficulty in exploiting the vulnerability.
    [...] <https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2020-044.txt>

    https://thehackernews.com/2021/03/new-zoom-screen-sharing-bug-lets-other.html

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

    Date: Fri, 19 Mar 2021 10:28:24 PDT
    From: Peter Neumann <neumann@csl.sri.com>
    Subject: Fintech Giant Fiserv Used Unclaimed Domain (Krebs on Security)

    Krebs on Security, 21 Mar 2021 (via Jimmy Upton

    https://krebsonsecurity.com/2021/03/fintech-giant-fiserv-used-unclaimed-domain/

    If you sell Web-based software for a living and ship code that references an unregistered domain name, you are asking for trouble. But when the same
    mistake is made by a Fortune 500 company, the results can range from costly
    to disastrous. Here's the story of one such goof committed by Fiserv, a $15 billion firm that provides online banking software and other technology solutions to thousands of financial institutions.

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

    Date: Fri, 19 Mar 2021 10:32:45 -1000
    From: geoff goodfellow <geoff@iconia.com>
    Subject: Is automated vulnerability scanning the best way to secure smart
    vehicles? (AT&T Business Insights Report)

    To those who pay attention to such things, it seems like a new vulnerability
    in smart car systems is found every week. In 2020, the numbers beat all previous years. The inescapable conclusion is that smart cars are now among the favorite targets of hackers and APT (Advanced Persistent Threat) actors. <https://www.cpomagazine.com/cyber-security/last-years-surge-in-exploited-security-vulnerabilities-for-open-source-projects-could-be-surpassed-in-2020/>

    One of the main reasons for this is the sheer number of different systems
    that the average connected car contains today. Quite apart from advanced features like autonomous driving and automatic braking, even less expensive cars now offer extensive Bluetooth and WiFi connectivity.

    As we'll explore in this article, this makes securing these cars against cyberattack almost impossible for human analysts. Instead, we should think
    more seriously about turning to automated systems -- and soon -- in order to make sure that our smart vehicles are safe as they can be.
    Connectivity vs. Security

    Connected vehicles pose something of a unique challenge for cybersecurity engineers. This is because the way in which these vehicles are designed and built, as well as how they interact with the real world that you and I
    inhabit, is quite different from the average mainframe.

    In most cases, for instance, the connectivity offered by smart vehicles is often designed by automotive product designers, or at very best UI
    designers, who have little understanding of the way that their desired level
    of connectivity will affect security. In other words, smart cars are
    generally keen to connect to any other device that comes within range -- whether this be a smartphone, pen drive, set of headphones, or Wifi router
    -- and often does so in a highly insecure manner.

    This gives rise to a number of consequences: some obvious, some less so.
    One is that the long-running debate about whether vulnerability scanning
    vs. pen testing has been resolved, at least as it relates to smart
    vehicles. They are incredibly easy to penetrate, and so scanning for vulnerabilities becomes the only practical way to protect them. Even
    insurance companies have been forced to become at least somewhat
    knowledgeable when it comes to pricing out their service. In short, it now costs more to cover tricked-out supercars loaded with the latest in
    technology. More connected systems means there is greater opportunity for hackers to execute a successful cyber-carjacking. The supply chain. [..]

    https://www.carinsurancecomparison.com/how-do-you-get-car-insurance-for-supercars/
    https://cybersecurity.att.com/blogs/security-essentials/comparing-penetration-testing-vs-vulnerability-scanning
    https://cybersecurity.att.com/blogs/security-essentials/is-automated-vulnerability-scanning-the-best-way-to-secure-smart-vehicles

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

    Date: Fri, 19 Mar 2021 09:36:04 -1000
    From: geoff goodfellow <geoff@iconia.com>
    Subject: Mission to clean up space junk with magnets set for launch (CNN)

    It's invisible in the night sky, but above us there is a cloud of more than 9,000 tons of space junk equivalent to the weight of 720 school buses. <https://www.esa.int/Safety_Security/Space_Debris/Space_debris_by_the_numbers>

    This debris is composed of parts of old satellites as well as entire defunct satellites and rocket bodies. The debris poses risks to the International
    Space Station and threatens things we take for granted on Earth -- weather forecasting, GPS and telecommunications. It's a problem that's getting worse with more and more satellites being launched each year by ventures like Elon Musk's SpaceX. <https://edition.cnn.com/2021/02/11/tech/spacex-starlink-satellites-1000-scn/index.html>

    A demonstration mission to test new technology developed by the company Astroscale to clean up space debris is set to launch in the early hours of Saturday from the Baikonur Cosmodrome in Kazakhstan.

    A Soyuz 2 rocket will launch a 175-kilogram spacecraft with a satellite attached into space. The spacecraft and the 17-kilogram satellite -- the
    debris to be cleaned up -- will separate and then perform a high-stakes game
    of cat and mouse over the next few months. [...]

    https://www.cnn.com/2021/03/19/business/space-junk-mission-astroscale-scn/index.html

    [Also noted by geoff:
    https://www.space.com/space-station-jettisons-huge-space-junk-pallet
    ]

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

    From: geoff goodfellow <geoff@iconia.com>
    Date: Wed, 17 Mar 2021 13:28:36 -1000
    Subject: Cars Have Your Location. This Spy Firm Wants to Sell It to the
    U.S. Military (Vice)

    15 billion car locations. Nearly any country on Earth. The Ulysses Group is pitching a powerful surveillance technology to the U.S. government.

    A surveillance contractor that has previously sold services to the U.S. military is advertising a product that it says can locate the real-time locations of specific cars in nearly any country on Earth. It says it does
    this by using data collected and sent by the cars and their components themselves, according to a document obtained by Motherboard.

    "Ulysses can provide our clients with the ability to remotely geolocate vehicles in nearly every country except for North Korea and Cuba on a near
    real time basis," the document <https://www.documentcloud.org/documents/20515640-ulysses-document>,
    written by contractor The Ulysses Group, reads. "Currently, we can access
    over 15 billion vehicle locations around the world every month," the
    document adds.

    Although the company told Motherboard it has not sold the product to the
    U.S. government at this time, the news highlights the scale and reach of car-tracking technology, and the fact that car location data is of interest
    not just to insurance companies and the finance sector, but to government contractors who explicitly say they want to source the data for
    intelligence and surveillance purposes.

    Ulysses previously had a contract with U.S. Special Operations Command
    (SOCOM), though for a different piece of technology.

    Do you work for a company buying car location data? Does your company sell
    it? Do you know of any other companies offering telematics data to
    government agencies? We'd love to hear from you. Using a non-work phone or computer, you can contact Joseph Cox securely on Signal on +44 20 8133
    5190, Wickr on josephcox, OTR chat on jfcox@jabber.ccc.de <jfcox@jabber.ccc.de>, or email joseph.cox@vice.com <joseph.cox@vice.com>.

    Consumers may be unaware that automakers and Original Equipment
    Manufacturers (OEMs) often include sensors in vehicle parts that collect information such as their airbag and seatbelt status, engine temperature,
    and current location, and then transmit that information either back to the automaker or to third parties. Aggregator companies also purchase or obtain this data, repackage it, and then sell that data or products based on it to their own clients. [...] https://www.vice.com/en/article/k7adn9/car-location-data-telematics-us-military-ulysses-group

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

    Date: Wed, 17 Mar 2021 21:28:31 +0100
    From: Nick Brown <nicholasjlbrown@gmail.com>
    Subject: Spanish COVID-19 mortality statistics in young children exaggerated
    by year coding problem? (The Lancet)

    Last week, *The Lancet* reported worrying data from Spain, suggesting that mortality from COVID-19 among young children was notably higher than in comparable countries.

    https://www.thelancet.com/journals/lanchi/article/PIIS2352-4642(21)00066-3/

    Today the Spanish news site *Niusdiario* reported that this is probably due
    to a software problem, whereby people aged over 100 who died from COVID-19
    had their age recorded without the first digit, so that someone aged 103
    would be recorded as just 3 years old.

    https://www.niusdiario.es/sociedad/sanidad/sanidad-reconoce-datos-muertes-ninos-covid-erroneos-contabilizaban-centenarios-como-menores_18_3107220241.html

    Comment from Twitter user @timalmond: "I would bet a good dinner that Excel
    was involved in this somewhere". https://twitter.com/timalmond/status/1372210607269765133?s

    Nick Brown, Palma de Mallorca, Spain (formerly Strasbourg, France)

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

    Date: Fri, 19 Mar 2021 15:00:26 -0400
    From: Gabe Goldberg <gabe@gabegold.com>
    Subject: If you've gotten fake calls from "Amazon" about a bogus purchase,
    watch this video (Lauren Weinstein)

    Quoting from Lauren Weinstein mailing:

    How the big bucks fake "Amazon" international scams hurt the most vulnerable

    Whether or not you're a fan of this particular form of presentation and/or approach to this serious problem, this video (already well over 2M views
    since uploaded today) is worth viewing and sharing (or at least viewing and explaining to your loved ones) about how to avoid being taken by the
    horrific fake "Amazon" (and similar) scammers.

    https://www.youtube.com/watch?v=VrKW58MS12g

    23-minutes, well worth watching. It's same guy who does glitter bomb "gifts" for porch pirates. Now I understand the Amazon scam -- intricate, many
    moving parts. Amazing/depressing that people fall for it.

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

    Date: Fri, 19 Mar 2021 17:14:24 +0100
    From: "Diego.Latella" <diego.latella@isti.cnr.it>
    Subject: Europe's artificial intelligence blindspot: Race (Politico)

    You might be interested in the following article

    Melissa Heikkilä, Politico EU, 16 Mar 2021

    https://www.politico.eu/article/europe-artificial-intelligence-blindspot-race-algorithmic-harm/

    [I don't quite know whether it is especially computer science or its
    subdiscipline Artificial Intelligence that has such an enormous affection
    for euphemism. We speak so spectacularly and so readily of computer
    systems that understand, that see, decide, make judgments, and so on,
    without ourselves recognizing our own superficiality and immeasurable
    naivete with respect to these concepts. And, in the process of so
    speaking, we anesthetise our ability to evaluate the quality of our work
    and, what is more important, to identify and become conscious of its end
    use. One can't escape this state without asking, again and again: "What
    do I actually do? What is the final application and use of the products of
    my work?" and ultimately, "am I content or ashamed to have contributed to
    this use?" -- Prof. Joseph Weizenbaum ["Not without us", ACM SIGCAS
    16(2-3) 2--7 - Aug. 1986]]

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

    Date: Thu, 18 Mar 2021 15:14:01 +0100
    From: "Diego.Latella" <diego.latella@isti.cnr.it>
    Subject: An existential discussion: What is the probability of nuclear war?
    (Hellman/Cerf Bulletin of Atomic Scientists)

    Martin E. Hellman, Vinton G. Cerf
    An existential discussion: What is the probability of nuclear war?
    Bulletin of Atomic Scientists, 18 Mar 2021

    https://thebulletin.org/2021/03/an-existential-discussion-what-is-the-probability-of-nuclear-war/

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

    Date: Wed, 17 Mar 2021 09:06:44 +0900
    From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
    Subject: Re: Japanese contact tracing software of Covid-19 patient on
    Android did not work for four months (Kyodo News)

    Despite the patches released later (reported by Anthony Thorn in
    RISKS-32.51), the Japanese Covid-19 contact tracing software called COCOA
    still is not working quite respectably.

    The report in Mainichi Shimbun newsapper dated March 15 stated that the
    COCOA does not support the latest API from Apple/Google and thus is in
    danger of orphaned once the old API is cut off. https://mainichi.jp/articles/20210315/k00/00m/020/165000c (Google Translate
    or DeepL may be your friend here.)

    Problem with COCOA is multi-fold IMHO. Government is trying to fix them.

    - The chosen maintainer does not seem to be capable of updating the software
    although many reported bugs to github, and some even pointed out the exact
    places in source code where the problem lied.

      The government seems to have decided o  change the maintainer to
    a software development company which was part of the original companies subcontracted by the main contractor for maintenance. But to be honest, I
    doubt the capability.
    https://www.asahi.com/articles/ASP3J6H9BP3JULFA03D.html

    - The ministry of health, labour and welfare, the government agency
    responsible for COCOA is not capable of monitoring the development of a
    smartphone app which is used widely.

    It is an accident that the ministry was put in charge of the COCOA
    software. Previously, cabinet office under prime minister directly was
    looking at the precursor of today's COCOA, an open source development with
    an interest in adopting, but once the official policy to use it as part of
    the arsenal to combat Covid-19 outbreak, the ministry was put in charge. The ministry is not quite familiar with open source software development as
    opposed to cabinet office. The lack of proper oversight was too visible. -
    No attention to the user bug reports (it did not work for four months on Android !) - Lack of overall testing plan after major/minor upgrades. (A careful test on real Android setup would have revealed the problem.)

    - The government seems to have hired a skilled smartphone software person
    with a long history of development as the monitor on the government side
    for the contract work and overall of health of COCOA. (blog of the
    person. https://blog.keiji.dev/2021/03/cocoa.html ) I wish him luck, but
    won't hold my breath.

    I, for one, removed the app from my android phone in disgust when it was reported that it had not been working on Android for four months. The main reasons are as follows.

    The app used too much power.  Android is a reference design and many
    companies can build Android phone. This is a strength and can be a
    weakness. Strength is that there are variety of android phones in different price zones with additional hardware features. The weakness is that some features not specified in the original Android blueprint from google cannot
    be common across all the models. Case in point. Power-saving feature.
    COCOA uses Bluetooth Low-Energy signal among the smartphones for detecting
    the presence of other phones in the vicinity. Use of BLE
    transmitter/receiver is not quite well standardized from the viewpoint of power-saving. Some models have poorly designed driver which cannot be controlled via standard OS API very well to operation in low-power mode, it seems. COCOA CANNOT take advantage of power-saving feature of such phones
    very well. (It was also reported in 2016-2017 time frame that original
    Google driver sucked in this regard, too. It may still suck, but obviously better than before.) Result: my Motorola M6 phone consumes power like crazy after I installed COCOA.

    The original power-saving features introduced by OEMs also caused problems
    for other phone users as well. OEM's power-saving daemons have put COCOA
    into hibernation/background on some phone models, and COCOA never gets a
    chance to check the central database of known pseudo-IDs of the phones of confirmed patients. So it never had chance to report the contact at all in those cases. The ministry in charge asks the users of Android phones
    politely to restart the app once daily. Talking of automation.

    This is more of a policy framework where COCOA operates. For fear of
    privacy breach, the government has not mandated the registration via COCOA
    of confirmed infected person. That is, if I have a COCOA installed and I get
    a positive result from PCR testing at a government-paid lab, I do NOT have
    to register it. I am POLITELY REMINDED to do that. Total BS. This defeats
    the purpose of COCOA.

    Even after setting aside the issue of people not owning smartphones, the low registration rate (2-4% last time I checked) basically puts this COCOA at a great advantage.

    I installed COCOA early this year to see if the general population started
    to use it and register the confirmed infection cases voluntarily when I
    learned of the four months lapse of Android's serious bug. I felt there
    would be NO WAY the general population of Android would trust this software from then on. Thus I figured the registration figure would not go up.

    My prediction is correct. Well, it was a no brainer. As of March 16, the registered confirmed cases in COCOA is 11, 454. https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html The number
    of confirmed infected patients in Japan so far: 446,386. https://www.mhlw.go.jp/stf/covid-19/kokunainohasseijoukyou.html

    The percentage of registration via COCOA is slightly below 2%. (!)

    If you believe that COCOA works, I've got a bridge in Tottori desert you
    might want to buy.

    Very unfortunate social experiment of technology that would have been useful but plagued with technical glitches. mismanagement, and institutional misdesign. Government agency is not in a position to provide a widely used smartphone apps in today's volatile software market. I wonder how other governments in the world is utilizing the contact notification APIs offered
    by Apple/Google.

    To be honest, I feel like bringing the parties responsible for this whole
    mess concerning COCOA to gather in a public panel at respectable Information Processing Society of Japan,  IEEE and/or ACM conference and grilling /
    yelling at them for disgracing the name of software industry so badly. I
    hate to be lumped together with these developers/managers/etc.

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

    Date: Wed, 17 Mar 2021 03:02:17 +0000
    From: Wols Lists <antlists@youngman.org.uk>
    Subject: Re: Voting Machine Hashcode Testing: Unsurprisingly insecure, and
    surprisingly, insecure (Kristiansen, RISKS-32.55)

    Bear in mind the US normally has 20 or 30 races on a single ballot I'm
    led to believe ...

    But also, most people tend to vote a straight party ticket ...

    Anyways, to my mind, the quickest and most effective way to count ballots,
    even the US ones, is to use a sorter. If you separate out all the straight party ballots, then bundle them in hundreds say, they're dead easy to check
    at random.

    Then you can worry about all the people who don't vote straight party (or
    not, as the case may be). If the "weird voters" don't add up to enough to overturn the straight party vote, then you want to know the true vote for academic reasons, but you know who won. And probably even there, people tend
    to vote on the same line, so those votes could well bundle up into hundreds
    of matching ballots.

    And in countries like the UK where we (mostly) don't have multi-race
    ballots, you can count quick and fast by hand. Don't forget, even
    without machines, we usually know the final result of a general election roundabout midnight on the day of the election! Certainly by the morning
    news the result is almost always in, with a few late results adjusting
    the figures slightly.

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

    Date: Wed, 17 Mar 2021 15:11:50 -0400
    From: David Lesher <wb8foz@panix.com>
    Subject: Re: Computers get Sundays off? (RISKS-32.55)

    Another consequence of 'electronic clearing' is the checks are shredded
    after being imaged front and back.

    When first introduced, the FBI et al. were upset about how the destruction
    of the physical instruments of fraud, as this would make various frauds
    harder to detect/prove in court.

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

    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.
    <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.56
    ************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)