unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#42075: gnus-summary-enter-digest-group spurious empty digest item
@ 2020-06-27  1:32 積丹尼 Dan Jacobson
  2020-06-30 17:19 ` bug#42075: notsp: triggered by a dot Dan Jacobson
  0 siblings, 1 reply; 3+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-06-27  1:32 UTC (permalink / raw)
  To: 42075

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Very odd.
C-d runs the command gnus-summary-enter-digest-group

When used on the attached article, it wipes out two http links,
turning them into a message break:

 .  1 200627||Rob Slade     :Risks for charities, non-profits, small groups
 .  1 700101||nobody        :(none)
 .  1 200626||Gabe Goldberg :AI Ethics: IP Protection for AI-generated and AI-assisted works

Gnus v5.13
GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
 of 2020-05-17, modified by Debian


[-- Attachment #2: article --]
[-- Type: application/octet-stream, Size: 34398 bytes --]

From nobody Sat Jun 27 09:25:02 2020
Return-Path: <risks-bounces+jidanni=jidanni.org@csl.sri.com>
Received: from imap.dreamhost.com (64.90.62.162:993) by jidanni8.jidanni.org
  with IMAP4-SSL; 26 Jun 2020 22:36:15 -0000
X-Original-To: jidanni@jidanni.org
Delivered-To: x20540300@pdx1-sub0-mail-mx9.g.dreamhost.com
Received: from vade-backend12.dreamhost.com (fltr-in2.mail.dreamhost.com [66.33.205.213])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by pdx1-sub0-mail-mx9.g.dreamhost.com (Postfix) with ESMTPS id 67ECEA56F2
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:43 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2060.outbound.protection.outlook.com [40.107.89.60])
	by vade-backend12.dreamhost.com (Postfix) with ESMTPS id C17AE4015C789
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:42 -0700 (PDT)
Authentication-Results: vade-backend12.dreamhost.com; dkim=pass
	reason="1024-bit key; unprotected key"
	header.d=sriit.onmicrosoft.com header.i=@sriit.onmicrosoft.com
	header.b=dkU8Rxqk; dkim-adsp=pass; dkim-atps=neutral
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=TwWKYbk63170pijeR+2p5k8yGo3ecqLpyuXVm66iT9azANnKCml/yw3EOO6wHGKcQ2IKq+eOo3OsSaEvEOTkYBmQHt8XN0dZ8eHHbuYtCRg3nMCRwv0IM7v/dpZAACbT+AdWLKI4WndIiyptlbzgmELc/mD6r8ueu9GYNBNRYT7CsktD03I+B7qo5ATR5RmYeWdocJTy4+GCAir7vSwpE6C0qru9sd3riV/iIuP9Ys+dFH8RagljkC6bB3jrQF9rOzI8LrgxIU9d7wL7TokhEUg3YHGD6YBbt+rX/QsHtSRi2YkcCwCyb/UrnD5Shy7PgpZrjqWrbK5H4R24z0f91A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LNdTp0xGdMIKlBGuhYshPQUTv7dlxZktEEj509LlCT0=;
 b=kLIpu48x1DrochV7c3lAP7+8qJsiF5M+RPdEfItlQ3gwtXgZj3Aq8fUkf6rrpXAeA9la+jiL8CiIGHISZLoa4ehzZVdjzxfWO3T6bKuj0s5ulX3GYC/lw45PShfAu6t4WSss+z07NuuLRD8P9jccTWLcKCOli3OxmLPzOUl5aNKChE+Lf6hvc6pbzTguLgSu2z7rMfOrlVP3ZBNjOrBZ/oxxWUIu8/XECQhzNscbadLA4WfgVlHhh34Jp9H5+fwft/cPHxmKdnl7EYhi9F5NaaQURt2fgVp7urOwSj8jan8LQlh+SphHJDKMDUyeY4Uiz7rxAuVcBzcUIkfvALMzFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 128.18.241.12) smtp.rcpttodomain=jidanni.org smtp.mailfrom=csl.sri.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=csl.sri.com; dkim=pass (signature was verified)
 header.d=csl.sri.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sriit.onmicrosoft.com;
 s=selector2-sriit-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LNdTp0xGdMIKlBGuhYshPQUTv7dlxZktEEj509LlCT0=;
 b=dkU8Rxqkkc9UsDEsvjxZ9kC6UA1Y1kSFUHlj93RU9LiqKcL0Q5bY+IpkHQzKVj5b1+lHW98ZE/fMMKqMsnUZ6QW09Hti0TNr1bVGDoXh4qozyCc02Yq3Ux0aTSXIQegUKFeKS7tO8jjYweK49KolOP6KMLrI0YU3E+X1tyKMuL0=
Received: from CY4PR09CA0090.namprd09.prod.outlook.com (2603:10b6:903:c7::28)
 by BL0PR0901MB4498.namprd09.prod.outlook.com (2603:10b6:208:1c3::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Fri, 26 Jun
 2020 21:50:38 +0000
Received: from BL0GCC02FT016.eop-gcc02.prod.protection.outlook.com
 (2a01:111:f400:7d05::204) by CY4PR09CA0090.outlook.office365.com
 (2603:10b6:903:c7::28) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend
 Transport; Fri, 26 Jun 2020 21:50:38 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 128.18.241.12)
 smtp.mailfrom=csl.sri.com; jidanni.org; dkim=pass (signature was verified)
 header.d=csl.sri.com;jidanni.org; dmarc=pass action=none
 header.from=csl.sri.com;
Received-SPF: Pass (protection.outlook.com: domain of csl.sri.com designates
 128.18.241.12 as permitted sender) receiver=protection.outlook.com;
 client-ip=128.18.241.12; helo=itmp-smtprelay.sri.com;
Received: from itmp-smtprelay.sri.com (128.18.241.12) by
 BL0GCC02FT016.mail.protection.outlook.com (10.97.10.110) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3131.20 via Frontend Transport; Fri, 26 Jun 2020 21:50:38 +0000
Received: from mx-dkim-out.csl.sri.com (f5-30-fip.sri.com [128.18.30.110])
	by itmp-smtprelay.sri.com (Postfix) with ESMTPS id 4D5A05F78F
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:36 -0700 (PDT)
Received: from mxzero.csl.sri.com (mxzero.csl.sri.com [130.107.1.30])
	by mx-dkim-out.csl.sri.com (8.15.2/8.15.2/Debian-3) with ESMTP id 05QLoaRD023187
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=csl.sri.com;
	s=mail20190530; t=1593208236;
	bh=IHOxoz/Qeg7VDeia++YzIYuZ4MoYcH4APxeDnWOeaCk=;
	h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Post:List-Help:
	 List-Subscribe;
	b=h29nwISxZvrDSFWcURLHlXvGkmc/8ppIphq72qiQFgdrn+wf2r3ahYd5ezHAw+m7z
	 wo3xlpHvfWfITgy4AQGKdDjMrzVavLfHcf7LubLUuxRJt80Rr878VLimr7wVVys8gY
	 77CjlgVnOziaaFyRcvXDsNIQ7/aQEakUpD8YOgm4=
Received: from mls.csl.sri.com (mls.csl.sri.com [130.107.1.19])
	by mxzero.csl.sri.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 05QLoZQk023791
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:35 -0700
Received: from mls.csl.sri.com (localhost [127.0.0.1])
	by mls.csl.sri.com (8.15.2/8.15.2/Debian-3) with ESMTP id 05QLoZWq026637
	for <jidanni@jidanni.org>; Fri, 26 Jun 2020 14:50:35 -0700
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mls.csl.sri.com
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
 SPF_HELO_NONE autolearn=ham autolearn_force=no version=3.4.2
From: RISKS List Owner <risko@csl.sri.com>
Date: Fri, 26 Jun 2020 14:48:02 PDT
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
precedence: bulk
To: risks-resend@csl.sri.com
X-Gnus-Mail-Source: maildir:~/Maildir/new
Message-ID: <CMM.0.90.4.1593208082.risko@chiron.csl.sri.com>
Subject: [RISKS] Risks Digest 32.04
X-BeenThere: risks@csl.sri.com
X-Mailman-Version: 2.1.20
List-Id: RISKS <risks.csl.sri.com>
List-Unsubscribe: <https://mls.csl.sri.com/cgi-bin/mailman/options/risks>,
 <mailto:risks-request@csl.sri.com?subject=unsubscribe>
List-Post: <mailto:risks@csl.sri.com>
List-Help: <mailto:risks-request@csl.sri.com?subject=help>
List-Subscribe: <https://mls.csl.sri.com/cgi-bin/mailman/listinfo/risks>,
 <mailto:risks-request@csl.sri.com?subject=subscribe>
Errors-To: risks-bounces+jidanni=jidanni.org@csl.sri.com
Sender: "RISKS" <risks-bounces+jidanni=jidanni.org@csl.sri.com>
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: 	CIP:128.18.241.12;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:itmp-smtprelay.sri.com;PTR:InfoDomainNonexistent;CAT:NONE;SFTY:;SFS:(39850400004)(346002)(396003)(376002)(136003)(46966005)(7846003)(81166007)(82740400003)(966005)(83080400001)(83380400001)(5660300002)(66574015)(47076004)(478600001)(316002)(34206002)(18074004)(356005)(70586007)(82310400002)(6636002)(6666004)(19810500001)(8676002)(16670700002)(8936002)(2906002)(30864003)(26005)(7126003)(336012)(426003)(9036002)(33310700002)(70206006)(186003);DIR:OUT;SFP:1101;
X-MS-PublicTrafficType: Email
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1591a549-b02c-44e6-c860-08d81a1af6a4
X-MS-TrafficTypeDiagnostic: BL0PR0901MB4498:
X-Microsoft-Antispam-PRVS: 	<BL0PR0901MB449843128F0EA094C653750FF3930@BL0PR0901MB4498.namprd09.prod.outlook.com>
X-SafeList: Domain-whitelisted
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0446F0FCE1
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 	8DiPap86adxRNRkMJwh405PJBIouZ6ro8bC54/Y8T4U3wVa20YWheOM3Zaw4WQqiELrNMSE8g5r32qdf5tML4QlGBv7NzRiEG/0c75BhZ6CfNlsL4kX+cbazEPb62JZROju0o2l7XYXCfwobUeBP8atoFR26AEESWRla99rfN9NV8teL3Qb9nYH3ZBffY0/miYhJ9Ez3kTLPUyoye32atgjXvR2S2n9D1sG0xTAeRArdWJ+W8jg26WEUpLFw7ktiXqhHD3hF36s3LSc3NhE2Li2i6RxuQDe8m2xDNoIbd0AtKkZQAWrpDROLnGxdIK+FOIaFZTcVrXv7+wEd+KwO81G8kD7x4r2cTJTKT3xZMiDvgKk8qhtHj3Vz9eTyww0UFj3WW14oP2iVxloxRHnJac/doGsRr8XesycBC9DZnY+xknvM5EeOHAKl0yRu3ynaspOFWyzpNTiHu1fRTEqerTIWSYMkr+SYwvijLKPv6mtm+6s88qtGhcZw0QrWI0ME
X-OriginatorOrg: sri.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2020 21:50:38.0652
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1591a549-b02c-44e6-c860-08d81a1af6a4
X-MS-Exchange-CrossTenant-Id: 40779d33-79c4-4626-b8bf-140c4d5e9075
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=40779d33-79c4-4626-b8bf-140c4d5e9075;Ip=[128.18.241.12];Helo=[itmp-smtprelay.sri.com]
X-MS-Exchange-CrossTenant-AuthSource: 	BL0GCC02FT016.eop-gcc02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4498
X-VR-STATUS: OK
X-VR-SCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgtdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhffgtgfhpvffkufejjfdufedtvghsggesthekredttddtjeenucfhrhhomheptffkuffmufcunfhishhtucfqfihnvghruceorhhishhkohestghslhdrshhrihdrtghomheqnecuggftrfgrthhtvghrnhepveeijeeijedufefhjedtvdevjeekfffgtdefueehgfdtgfeuffdtheffjefhiedtnecuffhomhgrihhnpehrihhskhhsrdhorhhgpdhntghlrdgrtgdruhhkpdhsrhhirdgtohhmpdgrrhhmhihtihhmvghsrdgtohhmpdhnrghtuhhrvgdrtghomhdpfigrshhhihhnghhtohhnphhoshhtrdgtohhmpdifihhrvggurdgtohhmpdhmohgsihhlvgifrghllhgrrdgtohhmpdhhuhgsshhpohhtuhhsvghrtghonhhtvghnthegtddrnhgvthdpsghuiiiifhgvvggunhgvfihsrdgtohhmpdgvnhhgrggughgvthdrtghomhdpiigunhgvthdrtghomhdpsghlohhomhgsvghrghdrtghomhdpthhruhhsthifrghvvgdrtghomhdpmhhsnhdrtghomhdpkhhrvggsshhonhhsvggtuhhrihhthidrtghomhdpfhgvnhhitghhvghlrdhnvghtpdgtsggtrdgtrgdpfihiphhordhinhhtpdgvvhgvnhhtsghrihhtvgdrtggrpdhprghnihigrdgtohhmpdhsvggtlhhishhtsh
 drohhrghdprggtmhdrohhrghenucfkphepgedtrdd
X-getmail-retrieved-from-mailbox: INBOX
Lines: 511
Xref: jidanni8 mail.misc:38091

RISKS-LIST: Risks-Forum Digest  Friday 26 June 2020  Volume 32 : Issue 04

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

  Contents:
The Army will soon allow users to access classified info from home
  (Army Times via Gene Spafford + PGN)
CRISPR gene editing in human embryos wreaks chromosomal mayhem (Nature)
More than 1 million coronavirus stimulus checks went to dead people
  according to the GAO (WashPost)
How Thousands of Misplaced Emails Took Over This Engineer's Inbox (WiReD)
Demographic report on protests shows how much info our phones give away
  (Engadget)
FBI warns K12 schools of ransomware attacks via RDP (ZDNet)
Hidden Back Door Embedded in Chinese Tax Software, Firm Says (Bloomberg)
80,000 printers are exposing their IPP port online (ZDNet)
FEMA IT Specialist Charged in ID Theft, Tax Refund Fraud Conspiracy (Krebs)
The US-China Battle Over the Internet Goes Under the Sea (WiReD)
Google Will Delete Your Data by Default in 18 Months (WiReD)
Re: Medical decision tools (Dr. Robert R. Fenichel)
Re: Only Sort of Wrongfully Accused by an Algorithm (John Levine)
Risks for charities, non-profits, small group (Rob Slade)
AI Ethics: IP Protection for AI-generated and AI-assisted works
  (Eventbrite/Wipo via Gabe Goldberg)
Abridged info on RISKS (comp.risks)

--------------------------------------.--------------------------------

Date: Thu, 25 Jun 2020 12:22:56 -0400
From: Gene Spafford <spaf@purdue.edu>
Subject: The Army will soon allow users to access classified info from home
  (Army Times)

Gee, I foresee this as a great innovation with no downsides at all.  I can't
wait for phase 3, when I convert my kitchen to a SCIF.

https://www.armytimes.com/2020/06/22/the-army-will-soon-allow-users-to-access-classified-info-from-home/

  [Seriously: All efforts at using untrustworthy computer-communication
  systems for trusted information currently seem to be doomed by our
  inherently comprimisible infrastructures.  This would seem to be insane
  with today's technology.  PGN]

  [Less seriously: This will undoubtedly create many new opportunities to
  "classify" all sorts of illegal activities.  Furthermore, Spaf's SCIF
  would have to prevent all emanations of power usage, smoke, and scents --
  and other effluents as well as everything that comes in..  Just my
  two-scents worth.  However, I can't wait to have access to Spaf's secret
  recipes for Scytl Skittles (big in the voting business), Tarte Putin
  (French gourmet), and Fits-all Schnitzel.  PGN]

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

Date: Thu, 25 Jun 2020 08:04:42 -0700
From: Lauren Weinstein <lauren@vortex.com>
Subject: CRISPR gene editing in human embryos wreaks chromosomal mayhem
  (Nature)

https://www.nature.com/articles/d41586-020-01906-4

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

Date: Thu, 25 Jun 2020 15:53:40 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: More than 1 million coronavirus stimulus checks went to dead people
  according to the GAO (WashPost)

https://www.washingtonpost.com/us-policy/2020/06/25/irs-stimulus-checks-dead-people-gao/

No time to check for dead recipients -- what could go wrong?

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

Date: Thu, 25 Jun 2020 20:44:16 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: How Thousands of Misplaced Emails Took Over This Engineer's Inbox
  (WiReD)

Kenton Varda gets dozens of messages a day from Spanish-speakers around the
world, all thanks to a Gmail address he registered 16 years ago.

Two weeks ago, longtime software engineer Kenton Varda got an email that
wasn't meant for him. It was from AT&T Mexico to a customer named Jorge,
whose most recent phone bill was attached. You've probably gotten an email
intended for someone else at least once. But then Varda got another AT&T
Mexico bill for Gloria. And then a third for Humberto, who is overdue on
paying more than 6,200 pesos, about $275.

To Varda, the incident wasn't a surprise. As the owner of the email account
temporal@gmail.com, he gets dozens of messages a day from Spanish-speakers
around the world, all sent by people who thought they could use his address
as a dummy input: "Temporal" translates to "temporary." Varda says he
frequently receives private documents, even medical bills and collection
notices. Many of the most sensitive emails contain legal notices that the
messages are confidential and should not be disclosed to other parties aside
from the intended recipient. Varda doesn't speak Spanish, but he uses Google
Translate when possible to understand what's going on and reply to senders
saying they have the wrong address.

"Recently I had a few people send me what appeared to be photographs of
handwritten notes. Maybe notes from a class?" Varda says. "Also, I received
several job evaluations of one Jose Gomez, who appears to be a janitor. And
a pretty good one!"

https://www.wired.com/story/misplaced-emails-took-over-inbox-temporal/

  [Also noted by Dave Lesher: NO PLATE is back again!
     Maybe try /dev/null? (RISKS-37.37, RISKS-6.40)
  PGN]

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

Date: Thu, 25 Jun 2020 13:58:30 -1000
From: geoff goodfellow <geoff@iconia.com>
Subject: Demographic report on protests shows how much info our phones give
  away (Engadget)

*Mobilewalla gathered cellphone data from Black Lives Matter protesters in
four cities.*

If you marched in recent Black Lives Matter protests in Atlanta, Los
Angeles, Minneapolis or New York, there's a chance the mobile analytics
company Mobilewalla gleaned demographic data from your cellphone use. Last
week, Mobilewalla released a report
detailing the race, age and gender breakdowns of individuals who
participated in protests in those cities during the weekend of May 29th.
What is especially disturbing is that protesters likely had no idea that the
tech company was using location data harvested from their devices.
<https://www.mobilewalla.com/about/press/new-report-reveals-demographics-of-protests>

Mobilewalla observed a total of 16,902 devices (1,866 in Atlanta, 4,527 in
Los Angeles, 2,357 in Minneapolis and 8,152 in New York).
<https://f.hubspotusercontent40.net/hubfs/4309344/Mobilewalla%20Protester%20Insights%20Methodology.pdf>
As *BuzzFeed News* explains, Mobilewalla buys data from sources like
advertisers, data brokers and ISPs.  It uses AI to predict a person's
demographics (race, age, gender, zip code, etc.) based on location data,
device IDs and browser histories. The company then sells that info
<https://www.mobilewalla.com/about> to clients so they can ``better
understand their target customer.''
<https://www.buzzfeednews.com/article/carolinehaskins1/protests-tech-company-spying>

``This report shows that an enormous number of Americans -- probably without
even knowing it -- are handing over their full location history to shady
location data brokers with zero restrictions on what companies can do with
it,'' Senator Elizabeth Warren told *BuzzFeed News*.  ``In an end-run around
the Constitution's limits on government surveillance, these companies can
even sell this data to the government, which can use it for law and
immigration enforcement.''

Mobilewalla CEO Anindya Datta told *BuzzFeed *that the company produced the
report to satisfy its employees' curiosity. Supposedly, Mobilewalla doesn't
plan to share info about whether specific individuals attended the protests
with clients or law enforcement.

But the incident is a reminder that data brokers have access to massive
amounts of data from unassuming individuals. There's a chance that data
could be used by law enforcement or be leaked -- as we've seen happen in
past data breaches.
<https://www.engadget.com/2018-06-28-exactis-leak-340-million-records.html>
 Some fear that individuals concerned about their data being swiped might
avoid protests, so in effect, the practices of collecting data may suppress
free speech. [...]

https://www.engadget.com/mobilewalla-data-broker-demographics-protests-214841548.html

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

Date: Thu, 25 Jun 2020 13:56:30 -1000
From: the keyboard of geoff goodfellow <geoff@iconia.com>
Subject: FBI warns K12 schools of ransomware attacks via RDP

*The FBI has issued a security alert warning K12 schools of the "ransomware
threat" during the COVID-19 pandemic.*

The US Federal Bureau of Investigation sent out on Tuesday a security alert
to K12 schools about the increase in ransomware attacks during the
coronavirus (COVID-19) pandemic, and especially about ransomware gangs that
abuse RDP connections to break into school systems.

The alert, called a Private Industry Notification, or PIN, tells schools
that "cyber actors are likely to increase targeting of K-12 schools during
the COVID-19 pandemic because they represent an opportunistic target as
more of these institutions transition to distance learning."

Schools are likely to open up their infrastructure for remote staff
connections, which in many cases would mean create Remote Desktop Protocol
(RDP) accounts on internal school systems.

Over the past two-three years, many ransomware gangs have utilized
brute-force attacks or vulnerabilities in RDP to breach corporate networks
and deploy file-encrypting ransomware. [...]
https://www.zdnet.com/article/fbi-warns-k12-schools-of-ransomware-attacks-via-rdp/

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

Date: Thu, 25 Jun 2020 13:55:31 -1000
From: geoff goodfellow <geoff@iconia.com>
Subject: Hidden Back Door Embedded in Chinese Tax Software, Firm Says
  (Bloomberg)

** Malware targeted UK vendor starting to do business in China*
Cybersecurity firm said it has briefed FBI on its discovery*

When a U.K.-based technology vendor started doing business in China, it
hired a cybersecurity firm to proactively hunt for any digital threats that
could arise as part of doing business in the country. The firm discovered a
problem, one with such major implications that it alerted the FBI.

A state-owned bank in China had required the tech company to download
software called Intelligent Tax to facilitate the filing of local taxes.
The tax software worked as advertised, but it also installed a hidden back
door that could give hackers remote command and control of the company's
network, according to a report published Thursday by the SpiderLabs team at
Chicago-based Trustwave Holdings Inc.
<https://www.bloomberg.com/quote/TWAV:US> (The cybersecurity firm declined
to identify the bank).

``Basically, it was a wide-open door into the network with system-level
privileges and command and control server completely separate from the tax
software's network infrastructure,'' Brian Hussey, vice president of
cyber-threat detection and response at Trustwave, wrote in a blog post
<https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/the-golden-tax-department-and-the-emergence-of-goldenspy-malware/>,
also published Thursday. The malware, which Trustwave dubbed GoldenSpy,
isn't downloaded and installed until two hours after the tax software
installation is completed, he said.

Trustwave researchers determined that the malware connects to a server
hosted in China.

It isn't known how many other companies downloaded the malicious software,
nor is the purpose of the malware clear or who is behind it, according to
the report. Trustwave said it disrupted the intrusion at the tech company in
the early stages.  ``However, it is clear the operators would have had the
ability to conduct reconnaissance, spread laterally and exfiltrate data,''
according to the report, adding that GoldenSpy had the characteristics of an
Advanced Persistent Threat campaign. Such efforts are often associated with
nation-state hacking groups. [...]

https://www.bloomberg.com/news/articles/2020-06-25/hidden-back-door-embedded-in-chinese-tax-software-firm-says
https://www.msn.com/en-us/finance/other/hidden-back-door-embedded-in-chinese-tax-software-firm-says/ar-BB15Y2So

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

Date: Thu, 25 Jun 2020 09:59:54 -0400
From: Monty Solomon <monty@roscom.com>
Subject: 80,000 printers are exposing their IPP port online (ZDNet)

Printers are leaking device names, locations, models, firmware versions,
organization names, and even WiFi SSIDs.

https://www.zdnet.com/article/80000-printers-are-exposing-their-ipp-port-online/

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

Date: Thu, 25 Jun 2020 10:04:20 -0400
From: Monty Solomon <monty@roscom.com>
Subject: FEMA IT Specialist Charged in ID Theft, Tax Refund Fraud Conspiracy
  (Krebs)

An information technology specialist at the Federal Emergency Management
Agency (FEMA) was arrested this week on suspicion of hacking into the human
resource databases of University of Pittsburgh Medical Center (UPMC) in
2014, stealing personal data on more than 65,000 UPMC employees, and selling
the data on the dark web.

https://krebsonsecurity.com/2020/06/fema-it-specialist-charged-in-id-theft-tax-refund-fraud-conspiracy/

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

Date: Thu, 25 Jun 2020 00:41:36 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: The US-China Battle Over the Internet Goes Under the Sea (WiReD)

The DOJ’s opposition to Facebook and Google's 8,000-mile cable to Hong Kong
highlights how physical infrastructure is as contentious as the virtual
world.

https://www.wired.com/story/opinion-the-us-china-battle-over-the-internet-goes-under-the-sea/

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

Date: Thu, 25 Jun 2020 00:45:12 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: Google Will Delete Your Data by Default in 18 Months (WiReD)

Starting today, the search giant will make a previously opt-in auto-delete
feature the norm.

Google already announced security and privacy upgrades to Android 11 earlier
this month. But Wednesday's changes focus on the data that Google services
like Maps and YouTube can access -- and how long they keep it for.

Pichai wrote in a blog post: ``We’re guided by the principle that products
should keep information only for as long as it’s useful to you.  Privacy is
personal, which is why we're always working to give you control on your
terms.''

Google has been criticized for collecting and retaining data that users
don't even realize it has. A year ago, the company added auto-delete
controls that allowed you to set your Google account to delete history --
like Web and App Activity and location -- every three months or 18
months. Such a mechanism was long overdue, but Google would still collect
this data indefinitely by default. You had to find the right toggle in your
settings to set the auto-delete in motion.

Google's announcements on Wednesday flips this policy around. Newly formed
Google accounts will auto-delete activity and location every 18 months by
default. YouTube history will delete every 36 months. Existing accounts,
though, will still need to proactively turn on the feature, as Google
doesn't want to force a change on users who, for whatever reason, want the
company to maintain a forever-record of their activity. (You can find our
complete guide to limiting Google's tracking here.) As soon as you do, the
company will nuke your accumulated activity and location data that's 18
months or older, and continue to do so going forward.  Google will also push
notifications and email reminders to get existing customers to review their
data retention settings.

https://www.wired.com/story/google-auto-delete-data/

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

Date: Wed, 24 Jun 2020 22:44:52 -0700
From: "Robert R. Fenichel" <bob@fenichel.net>
Subject: Re: Medical decision tools (RISKS-32.03)

The NYT article cited by Monty Solomon was ill-informed.  In a nutshell, it
confused decision rules with estimation tools.

One of its central examples had to do with the glomerular filtration rate
(GFR), an important measure of renal function.  To measure the GFR
accurately, one infuses a specialized, non-physiological, non-metabolized
substance and observes how rapidly it is cleared into the urine.  This is a
tricky procedure, rarely done outside research laboratories.

Medical decisions are often made on the basis of an *estimated* GFR (eGFR),
obtained by measuring the serum concentration of some physiological solute
that is (mostly) eliminated into the urine.  The solute most frequently used
is creatinine, a byproduct of muscle metabolism.  With creatinine data and a
body of true GFR data, it is a curve-fitting exercise to see what eGFR
formula best predicts the true GFR.

As a matter of empirical fact, the fit is improved by formulas that include
age, sex, and self-reported race.  Decisions about medical care (for
example, when to begin hemodialysis) should be based on the best estimates
of patients' physiological state.  If GFR were estimated using simpler
formulas, blind to sex, age, and race, patient care would be worse.

The conventional eGFR formulas are not restricted to medical systems that,
like those of private medical care in the US, have been credibly charged
with providing poor service to racial minorities and to women..  The same
formulas are used in socialized systems, including that of the US military
and, of course, those of developed countries around the world.

Robert R. Fenichel, M.D.:  http://www.fenichel.net

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

Date: 25 Jun 2020 16:46:01 -0400
From: "John Levine" <johnl@iecc.com>
Subject: Re: Only Sort of Wrongfully Accused by an Algorithm (RISKS-32.03)

> In what may be the first known case of its kind, a faulty facial
> recognition >match led to a Michigan man's arrest for a crime he did not
> commit.

If you read the article, you will find that the headline doesn't match what
actually happened:

  After Ms. Coulson, of the state police, ran her search of the probe image,
  the system would have provided a row of results generated by NEC and a row
  from Rank One, along with confidence scores.  Mr. Williams's driver's
  license photo was among the matches. Ms. Coulson sent it to the Detroit
  police as an *Investigative Lead Report*.

  ``THIS DOCUMENT IS NOT A POSITIVE IDENTIFICATION.  IT IS AN INVESTIGATIVE
  LEAD ONLY AND IS NOT PROBABLE CAUSE FOR ARREST.''  [The file says this in
  bold capital letters at the top.]

This is what technology providers and law enforcement always emphasize when
defending facial recognition: It is only supposed to be a clue in the case,
not a smoking gun. Before arresting Mr. Williams, investigators might have
sought other evidence that he committed the theft, such as eyewitness
testimony, location data from his phone or proof that he owned the clothing
that the suspect was wearing.

In this case, however, according to the Detroit police report, investigators
simply included Mr. Williams's picture in a *6-pack photo lineup* they
created and showed to Ms. Johnston, Shinola's loss-prevention contractor,
and she identified him. (Ms. Johnston declined to comment.)

The photo match algorithm indeed did a lousy job, but the people who used
the picture did a worse job. False identification from photo lineups has
been a problem for a very long time. There are some well known mitigations
that they didn't use here, in particular showing the pictures one at a time
rather than in a group. The latter tends to make people pick the closest
match even if the match isn't close at all.

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

Date: Fri, 26 Jun 2020 10:26:45 -0700
From: Rob Slade <rmslade@shaw.ca>
Subject: Risks for charities, non-profits, small groups

Gloria belongs to a quilting group and an embroidery group.  Neither group
is meeting right now.  The church where both groups normally meet is giving
them a break on rent, because of the public health restrictions on meetings,
but there are still some ongoing expenses.  In addition, with no meetings
going on, some members are starting to question their membership and dues.

They aren't alone.  This article focuses on charities, but a number of small
groups are in serious trouble over the pandemic.  Many amateur sports
leagues are already collapsing.

https://www.cbc.ca/news/business/nonprofits-charities-pandemic-closures-1.5625165
http://newsletters.cbc.ca/c/1172n42cXIEJwxO1WDX0kiIMyBQ

Our industry and technical groups are facing related issues.  We may be in a
slightly different situation, since most of us have the technical chops to
set up virtual meetings, but getting people to attend these meetings is
surprisingly difficult.  (Apparently if nobody is providing free coffee and
donuts, we won't go.)

We need contacts.  We need to get ideas from peers.  We need to bounce ideas
off each other.  We need to mentor, even if informally, the newcomers to our
profession (and recruit students in technical areas *into* our profession).

Support your local chapter, LUG, SIG, meetup or whatever.

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

Date: Thu, 25 Jun 2020 19:33:47 -0400
From: Gabe Goldberg <gabe@gabegold.com>
Subject: AI Ethics: IP Protection for AI-generated and AI-assisted works

 Tickets, Sun, 5 Jul 2020 at 11:45 AM | Eventbrite

Session to share our insights with World Intellectual Property Organization
on IP protection for AI-generated and AI-assisted work

About this Event

We are hosting this session to share our insights with the World
Intellectual Property Organization on IP protections for AI-generated and
AI-assisted works drawing from our diverse perspectives and experience and
having done so before for various other public consultations. Given that
this will be a shorter session and focused on providing concrete
recommendations, we encourage you to read the document beforehand and frame
your contributions in line with the questions.

Link to the reading:
https://www.wipo.int/edocs/mdocs/mdocs/en/wipo_ip_ai_2_ge_20/wipo_ip_ai_2_ge_20_1_rev.pdf

Questions that we will cover in the session:

1. Should the law require that a human being be named as the inventor or
should the law permit an AI application to be named as the inventor?

https://www.eventbrite.ca/e/ai-ethics-ip-protection-for-ai-generated-and-ai-assisted-works-tickets-110841044548

New horizons in AI planning... AI is a tool; naming it as inventor seems to
make as much sense as naming the computer on which a patent application is
typed.

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

Date: Mon, 1 Jun 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
     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.04
************************


^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#42075: notsp: triggered by a dot
  2020-06-27  1:32 bug#42075: gnus-summary-enter-digest-group spurious empty digest item 積丹尼 Dan Jacobson
@ 2020-06-30 17:19 ` Dan Jacobson
  2020-07-19  0:16   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Jacobson @ 2020-06-30 17:19 UTC (permalink / raw)
  To: 42075; +Cc: risko

It turns out https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42075 was
triggered by a dot in a separator bar:
--------------------------------------.--------------------------------
there in that Risks Digest Volume 32 : Issue 04.
Odd that a dot could trigger such problems deep later in the document.

It also triggers the smaller separator bars to appear after each article
after pressing ^D.

Good thing the dot only appeared in that issue of Risks Digest.





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#42075: notsp: triggered by a dot
  2020-06-30 17:19 ` bug#42075: notsp: triggered by a dot Dan Jacobson
@ 2020-07-19  0:16   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 3+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-19  0:16 UTC (permalink / raw)
  To: Dan Jacobson; +Cc: 42075, risko

Dan Jacobson <jidanni@jidanni.org> writes:

> It turns out https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42075 was
> triggered by a dot in a separator bar:
> --------------------------------------.--------------------------------
> there in that Risks Digest Volume 32 : Issue 04.
> Odd that a dot could trigger such problems deep later in the document.
>
> It also triggers the smaller separator bars to appear after each article
> after pressing ^D.
>
> Good thing the dot only appeared in that issue of Risks Digest.

The digest parser is just guessing what the separators are, and it will
guess wrongly when the format is unregular, as it is here.  So I don't
think there's anything to fix here, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-07-19  0:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-27  1:32 bug#42075: gnus-summary-enter-digest-group spurious empty digest item 積丹尼 Dan Jacobson
2020-06-30 17:19 ` bug#42075: notsp: triggered by a dot Dan Jacobson
2020-07-19  0:16   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).