[continued from previous message]

of copyrightable computer code -- it's ``inextricably bound together'' with uncopyrightable features, such as a system of computer tasks and their organization and the use of specific programming commands (the Java ``method calls''). As the Court noted:

Unlike many other programs, its value in significant part derives from the value that those who do not hold copyrights, namely, computer programmers, invest of their own time and effort to learn the API's system. And unlike
many other programs, its value lies in its efforts to encourage programmers
to learn and to use that system so that they will use (and continue to use) Sun-related implementing programs that Google did not copy.

Thus, since the declaring code is ``further than are most computer programs (such as the implementing code) from the core of copyright,'' this factor favored fair use.

Justice Breyer then discussed the purpose and character of the use. Here,
the opinion shed some important light on when a use is ``transformative'' in the context of functional aspects of computer software, creating something
new rather than simply taking the place of the original. Although Google
copied parts of the Java API ``precisely,'' Google did so to create products fulfilling new purposes and to offer programmers ``a highly creative and innovative tool'' for smartphone development. Such use ``was consistent with that creative `progress' that is the basic constitutional objective of copyright itself.''

The Court discussed ``the numerous ways in which reimplementing an interface can further the development of computer programs,'' such as allowing
different programs to speak to each other and letting programmers continue
to use their acquired skills. The jury also heard that reuse of APIs is
common industry practice. Thus, the opinion concluded that the ``purpose and character'' of Google's copying was transformative, so the first factor
favored fair use.

Next, the Court considered the third fair use factor, the amount and substantiality of the portion used. As a factual matter in this case, the 11,500 lines of declaring code that Google used were less than one percent
of the total Java SE program. And even the declaring code that Google used
was to permit programmers to utilize their knowledge and experience working with the Java APIs to write new programs for Android smartphones. Since the amount of copying was ``tethered'' to a valid and transformative purpose,
the ``substantiality'' factor favored fair use.

Finally, several reasons led Justice Breyer to conclude that the fourth
factor, market effects, favored Google. Independent of Android's
introduction in the marketplace, Sun didn't have the ability to build a
viable smartphone. And any sources of Sun's lost revenue were a result of
the investment by third parties (programmers) in learning and using
Java. Thus, ``given programmers' investment in learning the Sun Java API, to allow enforcement of Oracle's copyright here would risk harm to the
public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the
Sun Java API's declaring code a lock limiting the future creativity of new programs.'' This ``lock'' would interfere with copyright's basic objectives.

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

Date: Mon, 19 Apr 2021 11:11:51 +0800
From: Richard Stein <rmstein@ieee.org>
Subject: What's Really in Your Water? (Scientific American)

https://www.scientificamerican.com/article/whats-really-in-your-water/

"The intention is to implement this new water test into a format that nonscientists can easily use; one that is affordable and gives results
within an hour for those who need them most. The technology is far from
ready to sell; there is still much work to do to ensure that the lead tests
are maximally user friendly.

"These tests are different because they harness the power of naturally occurring sensors from biology. Using tools from the nascent field of
synthetic biology, the sensors can be programmed to change color when a
target chemical is present in water."

Imbibing in a clean sip of water is a human right (see "The Human Right to Water and Sanitation," from drought, conflict, corruption, etc., but it is jeopardized by many factors: pollution, https://www.un.org/waterforlifedecade/pdf/human_right_to_water_and_sanitation_media_brief.pdf

Testing for chemicals, metals, and organics in municipal water is, or used
to be, an exclusive role of governments and their infrastructures. If one cannot trust a government to proactively protect citizen health and safety,
why are they elected and empowered?

Enter the consumer to arouse community protests with independent "trust but verify" evaluation to demand neglected mitigation.

Risk: False positive/negative water test pollutant indicators

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

Date: Mon, 19 Apr 2021 15:00:50 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: Water Safety That Uses Your Mussels ()

With just over half a million people, the Polish city of Poznań is the fifth largest in the nation. Situated on the Warta River, Poznań dates back more than a century, originally built as a fortress to guard access to the
waterway. Today, the Warta is still an important part of Poznań and the surrounding areas; it is a major source of drinking water for the nearly 1.5 million people in Poznań's greater metropolitan area.

Which is why these guys are so important.

Yes, those are mussels. And they keep the people of Poznań safe. http://nowiknow.com/water-safety-that-uses-your-mussels/
Risk? Water pollution? Solution? Quick-reaction mollusks.

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

Date: Mon, 19 Apr 2021 11:06:00 -0700
From: Rob Slade <rslade@gmail.com>
Subject: Stealthy Dopant-Level Hardware Trojans

Interesting new paper:
https://iacr.org/archive/ches2013/80860203/80860203.pdf

Very early on, in malware research, we looked at hardware trojans and the limits of the "trusted computing base." (When I say "early on," I'm talking about 1988, so I don't know why these guys thought the study didn't start
until 2008. Kids. :-)

I also did formal study in gate level circuit design, and worked with
companies that were involved with board and chip manufacturing, so I
understand some of those parts of the paper.

It's an interesting attack, and, yes, it demonstrates that, when dealing
with supply chain and "Reflections on Trusting Trust" issues you have to perform multiple types of checks, and keep on developing new tests as new attacks are created. So, yes, it's a valid attack in the current climate.

It's a pretty specific attack, and would only work on specific types of hardware. Fortunately for the authors of the paper, while the attack is
quite specialized, and only works on some applications, those are pretty important applications, since they deal with high-level crypto, most likely
for military or intelligence purposes. The attack could be used to create something that would pass basic tests, but would weaken crypto
implementations (it's always implementation, isn't it?), and possibly also
make the circuitry more susceptible to side channel, covert channel, or
related TEMPEST type attacks.

Once known, of course, the attack could be detectable by extending the
testing of the results produced by the affected circuitry. But, as I say,
it does show that attacks and defence are constantly moving targets, and
that the concept of the trusted computing base (and, particularly, supply chain) always needs refining in the real world.

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

Date: Wed, 21 Apr 2021 11:03:08 -0700
From: Lauren Weinstein <lauren@vortex.com>
Subject: The Postal Service is running a 'covert operations program' that
monitors Americans' social media posts (Yahoo!)

So while DeJoy is decimating mail delivery, putting millions of Americans at risk from late deliveries -- including vital medication prescriptions -- the USPS is instead turning into a social media spy agency. Yes, public social media posts are public. But where did USPS obtain this authority? Who
controls it? Who oversees it? What happens to the data that they collect?
WHY ARE THEY DOING THIS WHILE OUR MAIL DELIVERY IS GOING TO HELL? -L

https://news.yahoo.com/the-postal-service-is-running-a-running-a-covert-operations-program-that-monitors-americans-social-media-posts-160022919.html

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

Date: Sun, 18 Apr 2021 22:45:43 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: The Pandemic Proved That Our Toilets Are Crap (WiReD)

The core technologies for sewage systems were developed over a hundred years ago. It's time to get better, healthier updates in the pipeline.

https://www.wired.com/story/pandemic-proved-our-toilets-are-crap/

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

Date: Mon, 19 Apr 2021 18:31:07 +0800
From: Richard Stein <rmstein@ieee.org>
Subject: Space Junk Removal Is Not Going Smoothly (Scientific American)

https://www.scientificamerican.com/article/space-junk-removal-is-not-going-smoothly/

"Despite promising technology demonstrations, there is no one-size-fits-all solution for the growing problem of taking out the orbital trash."

Good discussion of the orbital junk/trash problem and mitigations. Includes interview quotations from Donald Kessler, the originator of the eponymously named "Kessler Syndrome."

Would ET start a conflict with Earth over anthropenic space pollution? They have a right to claim NIMBY too!

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

Date: 17 Apr 2021 22:37:34 -0400
From: "John Levine" <johnl@iecc.com>
Subject: Re: We tested the first state's vaccine passport: Here's
what to expect (WashPast, RISKS-32.60)

New York's Excelsior Pass has some solid privacy protections. But it's complicated to use and easy to fake.

I read the article and the [WashPost) author apparently doesn't understand
how this thing works.

The pass is a QR code that represents a signed blob of JSON. To get the
code, you visit the state's web site and enter a person's name, birthdate,
zip code, and the date, location, and type of vaccine. As the article says,
you can load it into their app, save it as a picture, or print it out.

The verifier app scans the barcode, checks the signature, and if valid
displays a check, the name and DOB, and says "Verify name and date of birth
by checking their photo ID."

The author seems to think since you can load any pass onto any phone that is
a fake pass. Well, yeah. While it would be hard for a random stranger to
guess my info, I know enough to get my wife's pass and I'd think that
roommates or housemates would know enough to get each other's passes,
too. Hence the clear instructions to check ID. I doubt that many places will actually check, more likely check that the name and age are plausible for
the person.

I don't know how he thinks they would fix this "problem". I suppose they
could try to embed a photo into the barcode, but the code is already so big that it's pushing the limit of what a phone's camera can scan reliably, and
I have no idea where the picture would come from unless he wants a far more intrusive system where the vaccination record is tied to your driver's
license or something similar. Ugh.

People have odd mental security models, but that shouldn't come as a
surprise to any of us.

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

Date: Sun, 18 Apr 2021 16:36:48 -0400
From: David Lesher <wb8foz@panix.com>
Subject: Re: Miss'taken assumptions lead to plane incident (RISKS-32.60)

[Overseas software/cultural differences lead to loading issues...]

It occurs to me there is another cultural difference that might well alter weight & balance predictions.

What is the "standard weight" of an male AMCIT vs. say a Japanese man the
same age, or someone from sub-Saharan African?

We already know that the normal assumptions go out the door on a NFL
charter; what about WNBA flights, etc?

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

Date: Sun, 18 Apr 2021 15:41:42 -0400
From: DrM <notable@mindspring.com>
Subject: Election Systems, Security, and the Future

A video of the 15 Apr 2021 joint meeting of the Princeton ACM/IEEE Computer Society's panel session on Election Systems, Security, and the Future has
been posted at <https://www.youtube.com/watch?v=YjRVTpRrJNc>.

The session's meeting description is as follows:

We have survived another contentious election, and most of our election technology seemed to work. But we still have many questions about the
future. Do we need to improve the security and resilience of our election systems? Our special panel will hold a discussion of why we can't be complacent. What are some of the risks lurking in our current election technology? What are the most important technical and political issues to be resolved before our next major election? The event was moderated by Chapter Chair Dennis Mancl, with panelists Landon Noll and Rebecca Mercuri, plus a cameo appearance by Peter Neumann.

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

Date: Wed, 21 Apr 2021 11:25:39 -0700
From: Rob Slade <rslade@gmail.com>
Subject: Infosec Ethics -- VSS, 4 May 2021

As part of the VanTUG Security Series (see https://community.isc2.org/t5/C/V/m-p/42919 ) I'll be doing "Infosec Ethics"
on 4 May. (Yes, yes, "May the Fourth be with you" and all that.)

I'd like to invite anyone who can to attend, and participate. Because this
one in particular is probably going to need some input and discussion. I've got a list of ethics "case studies" as some discussion starters.

Meeting time, May 4, 7 PM (Pacific). Meeting link: https://is.gd/dA1c3O

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

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

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