[continued from previous message]

very dangerous when flights don't go as planned. There's been much teeth gnashing over the FAA's measured approach to commercial drone policy
adoption, but the fact is there are real dangers, including from bad actors using inexpensive GPS jammers.

GPS signal jamming technology is evolving, decreasing in size and cost.
Today, jammers can be bought online for as low as $50. Long a threat to military assets, jamming is now a commercial concern as commercial drone deliveries become a reality, and attacks are becoming pervasive globally.
This threat now affects commercial, law enforcement, and defense drones on critical missions. [...] https://rntfnd.org/2020/12/16/cheap-gps-jammers-a-major-threat-to-drones-zd-net/

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

Date: Fri, 18 Dec 2020 10:21:01 -0800
From: Rob Slade <rmslade@shaw.ca>
Subject: Betting on the election

Betting on elections is not legal in the US, but, with masses of offshore betting sites, that doesn't really prevent Americans from doing it. You can bet on pretty much anything these days, as long as you can get someone else
to take the other side of the bet. (With the betting sites taking a cut.)

For the sites, there is going to be some political analysis in setting the initial odds of an election, but later in the game the odds tend to reflect
how people are betting, as the sites try to ensure that they aren't too
exposed in the event of an unexpected outcome. The Trumpists were out in
force during the last election. The odds on Trump got shorter and shorter
as his supporters bet more and more.

Betting sites don't report much, and certainly not to any central authority,
so we don't know for sure how much money was wagered. But it was a massive amount, and Trumpists lost their shirts.

https://slate.com/news-and-politics/2020/12/trump-betting-markets-sportsbooks- offshore-2020-election-gambling.html

The risks are fairly obvious ...

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

Date: Sun, 13 Dec 2020 18:45:40 -0500
From: Gabe Goldberg <gabe@gabegold.com>
Subject: Vaccinated? Show Us Your App (NYTimes)

Covid-19 health pass apps could help reopen businesses and restore the
economy. They could also unfairly exclude people from travel and workplaces.

Among all the tools that health agencies have developed over the years to
fight epidemics, at least one has remained a constant for more than a
century: paper vaccination certificates.

In the 1880s, in response to smallpox outbreaks, some public schools began requiring students and teachers to show vaccination cards. In the 1960s,
amid yellow fever epidemics, the World Health Organization introduced an international travel document, known informally as the yellow card. Even
now, travelers from certain regions are required to show a version of the
card at airports.

But now, just as the United States is preparing to distribute the first vaccines for the virus, the entry ticket to the nation's reopening is set to come largely in the form of a digital health credential.

In the coming weeks, major airlines including United, JetBlue and Lufthansa plan to introduce a health passport app, called CommonPass, that aims to
verify passengers' virus test result-- and soon, vaccinations. The app will then issue confirmation codes enabling passengers to board certain international flights. It is just the start of a push for digital Covid-19 credentials that could soon be embraced by employers, schools, summer camps
and entertainment venues.

``This is likely to be a new normal need that we’re going to have
to deal with to control and contain this pandemic,'' said Dr. Brad Perkins,
the chief medical officer at the Commons Project Foundation, a nonprofit in Geneva that developed the CommonPass app.

https://www.nytimes.com/2020/12/13/technology/coronavirus-vaccine-apps.html

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

Date: Fri, 18 Dec 2020 10:57:26 +0800
From: Richard Stein <rmstein@ieee.org>
Subject: Devices Used In COVID-19 Treatment Can Give Errors For
Patients With Dark Skin (npr.org)

https://www.npr.org/sections/health-shots/2020/12/16/947226068/dark-skin-can-lead-to-errors-with-pulse-oximeters-used-in-covid-19-treatment

"The common fingertip devices that measures oxygen in the blood can
sometimes give misleading readings in people with dark skin, according to a report Wednesday in The New England Journal of Medicine."

The NEJM report "Racial Bias in Pulse Oximetry Measurement," retrieved from https://www.nejm.org/doi/full/10.1056/NEJMc2029240 on 17DEC2020 DOES NOT identify pulse oximeter suppliers or manufacturers used in their study.

The NEJM report identifies ~12% "incorrect measurement" events from
fingertip pulse oximeter devices within their patient cohort.

Fingertip oximeters are applied to measure patient oxygen blood saturation,
an important pulmonary function indicator. Under the COVID-19 pandemic, an estimated ~114K hospitalizations are identified (See https://covidtracking.com/data/charts/us-all-key-metrics, retrieved on 17DEC2020). It is doubtful that fingertip oximeter suppliers possess the capacity to follow up on "incorrect measurement" reports.

MDRs are routinely submitted by manufacturer representatives in response to injury, malfunction, death or causes arising from a host of regulated
devices. These include pacemakers/ICDs, neuro-stimulators, periotenial
dialysis systems, hip and knee replacements, intraocular lens, etc. Given COVID-19 incidence per
https://covid.cdc.gov/covid-data-tracker/#demographics, the FDA medical
device report (MDR) data summarized below suggests substantial
under-reporting.

The FDA's product classification platform @ https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/PCDSimpleSearch.cfm using "oximeter" as a search key returns 13 distinct product codes: DPZ,
DQA, DQE, GLY, MMA, MUD, NLF, NMB, NMD, OCH, PGJ, QEM, QLS.

Using FDA TPLC @ https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm with each product shows reveals DQA and MUD retrieve substantial (more than ~100)
medical device reports between 2015-2020. These MDRs include both anesthesia-grade oximeters with a fiber-optic catheter, and the standalone fingertip gizmos purchased off-the-shelf at amazon.com for US$ 25.

The DQA product codes TPLC report lsits seven (7) recalls between
2015-2019. The latest recall was in 2019 for a nasal oximeter from Xhale Assurance, Inc. See https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfres/res.cfm?id=172753 retrieved on 17DEC2020.

The top-10 DQA device problems in CSV format are:

"Device Problems","MDRs with this Device Problem","Events in those MDRs" "Incorrect Measurement",1685,1685
"Display or Visual Feedback Problem",904,904
"Device Operates Differently Than Expected",567,567
"Failure To Run On AC/DC",392,392
"Device Stops Intermittently",377,377
"Low Readings",254,254
"No Display/Image",205,205
"Inappropriate or Unexpected Reset",198,198
"Battery Problem",187,187
"Sensing Intermittently",167,167

The top-10 DQA patient problems traced to the device problems in CSV format are:

"Patient Problems","MDRs with this Patient Problem","Events in those MDRs"
"No Consequences Or Impact To Patient",3028,3028
"No Known Impact Or Consequence To Patient",2019,2019
"No Patient Involvement",929,929
"No Information",118,118
"Death",113,113
"Injury",90,90
"Burn(s)",71,71
"Pressure Sores",52,52
"Low Oxygen Saturation",37,37
"Skin Irritation",16,16

The top-10 MUD device problems in CSV format are:

"Device Problems","MDRs with this Device Problem","Events in those MDRs"
"Low Readings",82,82
"Incorrect Measurement",28,28
"Incorrect, Inadequate or Imprecise Resultor Readings",25,25
"High Readings",15,15
"Contamination /Decontamination Problem",14,14
"Sensing Intermittently",9,9
"Adverse Event Without Identified Device or Use Problem",9,9
"Sensor",7,7
"Failure to Analyze Signal",7,7
"Loss of or Failure to Bond",6,6

The top-10 MUD patient problems traced to the device problems in CSV format are:

"Patient Problems","MDRs with this Patient Problem","Events in those MDRs"
"No Consequences Or Impact To Patient",128,128
"No Patient Involvement",20,20
"No Known Impact Or Consequence To Patient",18,18
"No Information",13,13
"Injury",10,10
"Burn(s)",9,9
"Erythema",7,7
"Skin Irritation",5,5
"Pressure Sores",4,4
"Death",4,4

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

Date: Mon, 14 Dec 2020 10:06:19 -1000
From: the keyboard of geoff goodfellow <geoff@iconia.com>
Subject: An Internal Medicine Doctor and His Peers Read the Pfizer Vaccine
Study and See Red Flags (Naked Capitalism)

IM Doc, an internal medicine practitioner of 30 years, trained and worked in one of the top teaching hospitals in the US for most of his career before moving to a rural hospital in an affluent pocket of Flyover. He has been
giving commentary from the front lines of the pandemic. Along with current
and former colleagues, he is troubled by the PR-flier-level information presented to the public about the Pfizer and Moderna vaccines, at least
prior to the release of an article in the New England Journal of Medicine on the Pfizer vaccine: *Safety and Efficacy of the BNT162b2 mRNA Covid-19
Vaccine* <https://www.nejm.org/doi/full/10.1056/NEJMoa2034577>. However, he did not find the study to be reassuring. He has taken the trouble of writing
up his reservations after discussing the article with his group of nine physicians that meets regularly to sanity check concerns and discuss the
impact that articles will have on their practices. [...] https://www.nakedcapitalism.com/2020/12/an-internal-medicine-doctor-and-his-peers-read-the-pfizer-vaccine-study-and-see-red-flags.html

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

Date: Sat, 12 Dec 2020 10:36:45 -0800
From: Rob Slade <rmslade@shaw.ca>
Subject: More Differential Privacy for Ordinary Security Mavens

In the first account I composed, O Mystikophilus, I began to tell of all
that differential privacy was and could do for us. http://catless.ncl.ac.uk/Risks/32/40#subj18

People misunderstood.

Which is, perhaps, only to be expected. After all, we still don't agree
what privacy is. It is pretty much impossible to get a strict and working definition of what privacy actually is, at least in terms that are useful in the information age. Everyone has personal and subjective feelings about
what information is and is not private.

One of the best definitions I've ever come across states that privacy is
your ability to control information about you. And that ability has never
been absolute. (And I don't just mean Scott McNealy's "You have zero
privacy anyway. Get over it.") We live in communities, and the people
around you can see and hear you, see where you go, note who you talk to.
That's been the reality since we began to be able to talk. We can, temporarily, shroud ourselves, whisper to another, or get away from the
group, but our right to privacy is not binary, in the same sense as the
right to life or free speech. We don't, therefore, have a "right" to
privacy any more than we have the "right to be forgotten" in anything other than a purely artificial sense.

This is reflected, to an extent, in our laws and constitutions. They don't mention much about privacy. In my original presentation, I was challenged
on this statement by someone from Portugal, who said that Portugal's constitution *does* we have a right to privacy. But the right to privacy
that it mentions really only limits what the government can do with
information about you, like the American Privacy Act of 1974. (Since they
were written about the same time, this is hardly surprising.) He then said that the first mention of privacy in an *English* law dates to 1361. But, again, *that* law says that the authorities can't look into the window of
your house, and is much more about illegal search than it is about what we consider private.

In a fairly major sense, differential privacy avoids all of this definition
of privacy issue by not caring what privacy is. Differential privacy is
more concerned with databases, and queries on databases. Specifically it
looks at the problems of inference and aggregation attacks. An inference attack is where you can infer, from information you are given access to, information that you are *not* given access to. For example, suppose I am given access to a database that holds information about prices, but does not tell me about supply. If I see that the price of a certain commodity is
going up, I can infer that the supply is going down, even though I've been forbidden access to that data. Aggregation is the ability to find out restricted information by combining available information, often from a
variety of sources. The whole field of open source intelligence (OSInt) is based on this idea. In database security, inference and aggregation attacks are a long- standing problem with very few solutions.

We can, of course, try to address the problem by restricting what queries
are allowed. We can say that individual items can't be reported, and that
only queries on groups of data are allowed. (Aggregation can be both attack and defence.) Unless we are very careful about that, we get the situation where we say that you can't know Rob Slade's salary, but you can know the average salary of everyone in Vancouver. But if we then allow that you can
ask for the average salary of everyone in Vancouver *except* for Rob Slade,
we can aggregate those two queries and infer what Rob Slade's salary is.

So, what can we do about it? Well, you remember Bell-LaPadula? Of course
you do. They came up with a simple security property. (For
confidentiality. They were only concerned with confidentiality.) If you
don't want people to know secret information, don't tell them. If you are
at a medium security level, you can't see any high security information, and you can't tell anything to people who are at a low security level. No read
up, no write down. Simple.

Ah, if only life were so simple. But try to build a Bell-LaPadula computer. (OK yes, I know. "Multics." Fine. Try and build a computer that combines Bell- LaPadula and Biba. Come back when you're done.) However, formal
models *do* give us guidance and can be very useful in getting our minds
around the problem. So, in 2006, some people thought about how to protect against aggregation and inference attacks on databases. (Dwork/McSherry/Nissim/Smith, Calibrating noise to sensitivity in private
data analysis, Proceedings of the Third conference on Theory of
Cryptography)

So, some simple principles. Well, a person's privacy cannot be compromised
by a statistical release if their data are not in the database. That's
basic. You can't have your privacy violated if your information isn't
there. So, how can we make it as *if* your information isn't there? The
goal of differential privacy is to give each individual roughly the same privacy that would result from not having their data in the database.
(Hence the "differential" part: there should be no, or next to no,
"difference" in queries whether your data is there or not.) So the only functions (mostly statistical) run on the database should not overly depend
on the data of any one individual.

And, *that* leads to the Fundamental Law of Information Recovery: in the
most general case, privacy cannot be protected without injecting some amount
of noise. And as queries are made on the data of fewer people, you need
more noise.

So how do we get this to work? (to be continued ...)

MORE:

As I have said, differential privacy is not the type of privacy we normally think of when we think of privacy. But it is related, and can be valuable. Coincident with starting this research and writing on differential privacy,
I have been watching "Search and Rescue: North Shore," which is a terrific
five part documentary series about the team and it's activities. I believe
it is available for streaming simply by signing up (for free) at: https://www.knowledge.ca/program/search-and-rescue-north-shore I highly recommend it. Not only is it the gorgeous scenery of where I live, and some
of the emergency management people I've trained with, it also has numerous lessons about planning, training, risk analysis, and other elements
important to security management, security operations, and business
continuity. It is a wonderful example of film making. It must have been a bear to edit, since they not only embedded cameramen with the teams, but, in
a number of cases, had helmet cameras, fixed cameras inside helicopters, cameras fixed to quad bikes, cameras fixed to rope gear, and even aerial
drone shots, all of which had to be spliced together to create a whole, and seamless, narrative.

It also gives you yet another example of an inference attack. Since it involves real situations, real rescues, and real people, the film-makers had
to get permission from those involved in cases where you could clearly
identify someone. In some cases, that permission obviously wasn't given,
and faces are blurred out in the final series. This allows you to infer who was OK with being involved in the final product, and who was more bashful
(or embarrassed).

As previously noted, aggregation and inference attacks have been a
persistent and intractable problem in database security. But aggregation
can also be used as a protection. British Columbia's provincial health officer, Dr. Bonnie Henry, has done a masterful job both of managing the CoVID-19 pandemic, and leading the communications about it. For months she has, on an almost daily basis, provided a great deal of data on the
situation. However, initially that data was only provided on the five major health regions of the province. The reporters asking questions on "The
Doctor Bonnie Show (co-starring Adrian Dix and Nigel Howard)" have
consistently demanded data by towns, schools, and even individual neighbourhoods. As Dr. Henry has pointed out, providing data on that level, when the numbers are small, would allow for inference attacks that could identify individuals, so only sufficiently large sets of aggregated data are provided, in order to preserve individual privacy. As the numbers, of
cases, outbreaks, and even, unfortunately, deaths, have increased, however,
it has become possible to provide information based first on local health areas, and now on individual towns. (Hopefully it won't get to the point
where it is safe to provide data on individual neighbourhoods.)

Aggregation may have to be done carefully. There are situations, and
certain types of data, where you may wish to have anonymization taking place prior to aggregation. In those cases, you may even wish to have separate
teams doing the anonymization and the aggregation, and a Brewer-Nash type firewall between those teams, so that the aggregated data may not be re-identified. And, of course, the design of the anonymization and the
design of the aggregated database in such a way that it is not possible to de-anonymize the data is a non-trivial task.

Aggregation is not a new concept in database security. We've been using it
for years. Even decades ago it was part of the notion of data warehousing, with the idea being that we would use lots of lots of data that had no real personal information and pull out insights without ever having to risk someone's personal privacy. But, as with most simple answers, there are problems. In many cases, data can't be completely anonymized and still
remain useful. And anonymization isn't limited simply to the removal of personally identifiable information. Anonymization doesn't even seem to be enough. The trouble is, aggregation itself seemed to lead to privacy risks.
At one point Google made a bunch of its search data available to the public. The feeling was that no personal information had been involved, and
therefore there was no risk to privacy. However, some privacy experts
started digging into the data, and found that, simply given the volume of
the data, it was, in fact, fairly simple to collect searches related to an individual, and, in many cases, identify them. It's also now fairly widely accepted (except by most of the general public, it seems) that the
aggregation of even trivial posts on social media can result in the
compilation of dossiers that spy agencies of the past would have gladly
killed for. As has been pointed out, the NSA didn't have to go to all that trouble to illegally collect data on Americans: they just had to read
Facebook.

So, that leads us to the Fundamental Law of Information Recovery, and noise.

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

Date: Thu, 17 Dec 2020 12:08:39 -0800
From: Rob Slade <rmslade@shaw.ca>
Subject: Differential Privacy for Ordinary Security Mavens: noise

Of the CISSP sample questions which I have collected over the decades, one
of my very favorite is this one.:

Which of the following is NOT an effective deterrent against a database inference attack?

a. Partitioning
b. Small query sets
c. Noise and perturbation
d. Cell suppression

Answer: b.

Why do I like it so much? I have found that a lot of people get this one wrong. Remember, you are supposed to answer the question asked, from the answers provided. We were not asked, "Is it a good idea to add noise to
your database?" We were asked whether it would help in a specific
situation.

First off, let's get rid of a and d. Database inference attacks are an old
and established threat against database systems, and are not subject to many defences. Partitioning and cell suppression may not help much, but they do help.

Now we are left with small query sets (b) and noise and perturbation (c).
Lots of people choose noise and perturbation, because, well, noise. We
don't want to introduce errors into our databases, do we? That has to be
the worst (and therefore, in the wording of this question, right) answer.

The thing is that small query sets are, specifically, one of the tools that
you do use to mount inference attacks. So small query sets are,
specifically, NOT an effective deterrent against a database inference
attack.

And what about noise and perturbation? Well, if you are really, seriously, concerned about inference attacks, introducing small sources of noise and perturbation (very carefully) *is* a very effective protection.

Sometimes we can add quite a bit of noise, and still have useful information (and privacy). The social sciences have a system called "randomized
response" for situations where you want to poll a group or population about embarrassing or illegal behaviour. If you want to ask people if they have
ever murdered someone, they'll probably just answer "no." However, the randomized response system tells them to flip a coin. If the coin comes up heads, answer truthfully. If the coin comes up tails, then flip the coin again, and answer "yes" if heads, and "no" if tails. Since, from outside,
we don't know if the subjects got heads on the first coin toss, we don't
know if they answered truthfully or not to the question. Since this
preserves their privacy, they are more likely to answer truthfully. We can, statistically, remove the "noise" since we know that 25% of the total
answers will be "yes" on the basis of the random coin flipping.

Sometimes the noise we introduce can be done simply on the basis of
rounding. If we have the classic case of asking "What is the average salary
in Vancouver?" and then asking "What is the every salary for everyone in Vancouver *except* Rob Slade?" then merely rounding the answers to the
nearest thousand (or even hundred) dollars probably skews the numbers enough that you won't be able to calculate my salary with any degree of accuracy.

The amount and type of noise that will protect privacy and yet still allow useful results will likely depend upon the data being collected and the questions being asked.

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

Date: Sun, 13 Dec 2020 18:33:25 +0200
From: Amos Shapir <amos083@gmail.com>
Subject: Re: AI Can Run Your Work Meetings Now (RISKS-32.40)

George Orwell was an optimist... Pretty soon Big Brother could not only
watch you, he could tell exactly if* you really *loved him.

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

Date: Sun, 13 Dec 2020 18:12:55 +0200
From: Amos Shapir <amos083@gmail.com>
Subject: Re: Former Israeli space security chief says aliens exist, humanity
not ready (RISKS-32.40)

May I quote a comment to the Jpost article, as posted by "GoldMagnet":

"The main thing that shows that this is false is that anyone in the
universe convinced Trump to not say something, and that he doesn't want hysteria. No one has ever been able to get Trump to NOT say something."

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

Date: Sun, 13 Dec 2020 18:29:49 +0200
From: Amos Shapir <amos083@gmail.com>
Subject: Re: Police Drones Starting to Think for Themselves (RISKS-32.40)

"a special drone ... can follow a particular person or vehicle"

This reminds me of the case of the mistaken shooting of Jean Menezes by officers of the London Met Police on Jul. 22, 1978 (https://en.wikipedia.org/wiki/Shooting_of_Jean_Charles_de_Menezes).

Menezes was mistakenly identified as a suspected terrorist, and then
followed around London by detectives (all believing he was the wanted terrorist) until shot by a special police team while trying to board a
train.

Now it's technically possible that all of this -- misidentification,
following, and shooting -- might be accomplished by a single drone.

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

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

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