Risks Digest 32.56

[RISKS List Owner <risko () csl sri com>]

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