The Lippard Blog

25 years of OpenBSD Security Tools: syslock and sysunlock

2026-06-05T08:00:00.000-07:00

If you missed the overview post, you can see it here. This one is about managing immutable and append-only files on *BSD, Linux, and macOS.

Immutable and Append-Only Files

BSD-derived operating systems (including macOS) and Linux both support the concept of files being made immutable, so that neither their contents nor attributes can be changed. They also both support files being made append-only, so that the existing contents cannot be changed except by adding more data to the end. They do it in slightly different ways.

BSD Implementation

On BSD-derived systems, these features are controlled using file system flags which have "system" and "user" variants; the former can only be set and unset by the root user, while the latter can be set and unset by any user on files they own. The flags are changed using the chflags command, and their names are schg (system immutable), uchg (user immutable), sappnd (system append-only), and uappnd (user append-only). BSD-derived systems also take the further step for the system-level flags that they can be set but not unset after the system has booted from single-user mode to multi-user mode. This is controlled by the system security level (kern.securelevel) which is raised automatically by the init process from 0 ("Insecure Mode," also known as single-user mode) at initial boot to 1 ("Secure Mode," the default multi-user mode). The system security level may also be raised with the sysctl command but cannot be lowered except by shutting the system down to return to single-user mode (securelevel=0), which shuts down system daemons and drops network connections, leaving the system accessible only by the system console until it reboots. The effect of this is that even the root user cannot modify the contents or attributes of files with schg (and can only append to files with sappnd) without shutting down the system.

Linux Implementation

On Linux, by contrast, only the root user can set or unset immutable or append-only attributes, using the chattr command with +i/-i or +a/-a to set or unset immutable or append-only attributes, respectively. But there is no system security level that prevents unsetting these attributes at any time after they've been set. The Linux attributes are equivalent to the BSD user flags, but limited to the root user. I have used syslock less on Linux than on OpenBSD, but have used it fairly broadly on Proxmox and Kali Linux.

macOS Implementation

On macOS, the BSD flags are present but by default the system is always in "Insecure Mode" (securelevel=0), and Apple has added additional file flags, notably restricted, which it uses on operating system commands and libraries as part of its "System Integrity Protection" (SIP) feature added in OS X El Capitan (10.11) in 2015. The restricted flag cannot be unset even when the system securelevel=0, but only when the system is booted into Recovery mode. While the restricted flag is, like the immutable and append-only flags, managed by the chflags command, it is not supported by my tools and it's just mentioned here to note that macOS has implemented a very similar capability in a different way. I have the least experience in using syslock on macOS, and because of that and the fact that system binaries are protected by this alternative mechanism, I use it less broadly there.

BSD Security Levels

When I first learned about file system immutable flags, the default system startup file on OpenBSD named /etc/rc.securelevel contained lines to set the system securelevel to 1, but that now happens automatically in the boot sequence by the init process, and the default rc.securelevel example file in /etc/examples consists only of comments and is no longer installed by default. All of my systems have that config file installed to set the securelevel, for reasons which will be explained shortly.

OpenBSD supports two other settings for kern.securelevel besides 0 and 1, which are -1 ("Permanently Insecure Mode") and 2 ("Highly Secure Mode"). Permanently Insecure Mode prevents the securelevel from being raised to 1 automatically; it instead goes to 0 and remains there. Highly Secure Mode features all of the restrictions of Secure Mode, plus also restricts changes to host firewalls with OpenBSD's pf packet filter, allowing only changes to what IP addresses are in tables but no changes to filtering or NAT rules. The details of each level are documented in the OpenBSD securelevel man page. These restrictions are intended to reduce the impact and blast radius of both system compromises where an attacker gains root and to reduce the impact of administration errors.

Security Control, Administrative Safeguard, or Security Theater

The latter goal -- reducing the impact of administration errors -- is one that the BSD, Linux, and macOS default settings all support, but the former goal -- reducing the impact and blast radius of system compromises where an attacker gains root privileges -- is only evident for the BSD system immutable and append-only flags, where even the root user cannot unset them so long as the system is in Secure or Highly Secure mode. Some have argued that these flags are also mere speed bumps or error prevention (or "security theater"), on the grounds that they are easily bypassed, which can be done by returning the system to Insecure Mode. There are two main ways for a user with root access to do that, which are (1) using console access to access a root shell in single-user mode after shutdown, which may not be particularly easy as a remotely connected attacker likely does not have console access, or (2) modifying configuration files that allow command execution before the system raises the system securelevel, and rebooting the system. There are many configuration files and commands executed on the system during the boot sequence while the system is in Insecure Mode, and if any of those can be modified to either execute commands or prevent the system from going into Secure Mode, there is a path to unsetting the system immutable and append-only flags for the attacker (at the cost of a potentially noisy reboot). (I have made use of this path myself in the past while testing immutable flags and getting myself stuck.) It's because many files would have to be set immutable to close off that second reboot path that some have called even the system flags "security theater," but I think it is both feasible and it can be a genuine security control. The key is making it practical to lock enough of the right files, which is the problem I've tried to solve with these tools.

Origins of syslock/sysunlock

My syslock/sysunlock tool (two opposite functions in a single perl script, from here on I'll generally just refer to syslock except when the distinction matters) is designed to make the management of all of these implementations of immutable and append-only file system controls feasible, straightforward, and usable, at least as an error prevention method and at best as a security control. I originally wrote it after coming across a simple shell script of the same name by George Shaffer, but it now looks quite different, supporting system and user immutable and append-only flags on OpenBSD and macOS, and Linux's near equivalent (+i/-i and +a/-a). My recommendation for anyone starting out on a BSD system is to begin with the user flags, which are trivial to unlock and cause no permanent damage if you need to make changes quickly. Once comfortable with the group structure, you can consider adding system flags for files that rarely need to change. I'll describe that group structure next.

syslock Groups

The main feature of syslock that makes it usable is that it is configured to place lists of files and directories into groups, and those groups can be locked or unlocked with a single command (syslock -g <groupname>). The groups are defined like tags associated with a list of files and directories, so that a given file or directory can be in multiple groups. The default configs supplied with the tool include group names such as etc (files in /etc), etcrare (files in /etc that are rarely modified), and fstab (/etc/fstab gets its own group as it's a painful file to clobber by accident). There are relatively self-explanatory group names like binaries, libraries, and system, and then there's presecure, which covers the files and directories that are potential targets for someone trying to find a way to bypass system immutable flags (e.g., startup scripts like /etc/rc, /etc/rc.local, /etc/rc.d, and others that may be less obvious like /etc/sysctl.conf). (There is no presecure group defined in the Linux or macOS example configs.) For BSD and macOS, you can choose to make user immutable or system immutable your default, but you can also use groups to explicitly call out a set of files as the opposite of your default, with the group names schg and uchg (and similarly with sappnd and uappnd groups). These groups are specially handled so that they can be specified in combination with another group name (e.g., etc:uchg or acct-logs:uappnd) to identify the files and directories that are in both.

Since it is possible to enable the schg flag in Secure Mode but not to disable it, by default neither syslock nor sysunlock will touch those files while in Secure Mode (sysunlock can't unlock them), but the -f (force) option to syslock will lock them. A group can have both a system and a user subset of files regardless of what default is configured. For example, if your default is schg but you want some commonly modified files in /etc to be uchg, you could put them in that group along with the etc group. Then, if you unlocked files in Insecure Mode with -g etc, both the schg and uchg files in the etc group would be unlocked, while if you used sysunlock -g etc in Secure Mode, only the uchg files would be unlocked. If you were in Insecure Mode but only wanted to lock the uchg files in the etc group, you can use -g etc:uchg.

The intention of groups is to provide a mechanism for unlocking specifically what is needed to perform a specific task. The default and sample config files supplied with the tool include groups for other tools that will be covered in this series of blog posts, including reportnew (blog post June 16), rsync (for rsync-tools, blog post June 9), and sigtree (blog post June 19), as well as for process accounting log files (to make them append-only), mail servers, web servers, and DNS servers (the latter two in the BSD default config only). Log files and DNS servers provide two examples for where you'd want to use different flag-specific subgroups. For log files, you want the active log file to be append-only, but you want the rotated and archived log files to be immutable; you also want them to use user rather than system flags if the logs are subject to rotation via newsyslog or other log rotation mechanism. Thus the sample configs put the live process accounting log in the uappnd group and the rotated process accounting logs in the uchg group. The rotation process needs to unlock both of those subgroups before rotation, and lock them again after rotation. For DNS configuration files, you might want to lock your zone files with schg if they don't change frequently and aren't changed by any automation, but if you use automated DNSSEC signing, you'd lock the signed zone files with uchg so that they can be unlocked before signing and relocked after signing. It's worth noting that logging to a separate machine is a much better security control than using uappnd (or Linux +a) flags on log files--but I do both.

Overlapping Groups

Note that it is possible to define groups that overlap with each other in various ways, and while this is generally acceptable and unlikely to cause any issues on Linux or if only a single type of flag is used on BSD or macOS, it can create issues if overlapping groups have a mix of flag types such that multiple flags get set on any files or directories. The default and sample configs do not contain any group definitions that create this problem, and syslock will generate warnings if it detects cases of conflicting flag types in the configuration, but will not detect all possible cases (e.g., where symlinks are involved).

OpenBSD-specific: KARL Features

There is also an implicit group of files identified in the config file by a leading "!" prefix character, which designates system files that are part of OpenBSD's Kernel Address Randomized Link (KARL) feature, where the kernel and key binaries (currently libc, libcrypto, ld.so, sshd, sshd-session, sshd-auth, and ssh-agent -- the list may increase between releases) are relinked in random order at reboot. These files are locked or unlocked by using a -s (for system) option. (This was perhaps a poor choice of option letter and name, as it is distinct from the "system" group which is intended to capture key operating system files and what needs to be unlocked for upgrading and patching, though I typically unlock everything before upgrading or patching. This is just to ensure that nothing the system needs to install is blocked, which can leave a system in an inconsistent and not fully operable state, but the "system" group should actually work for this purpose.) Since I use system immutable flags as my default on most systems, and on the presecure group on all systems, my practice for patches and upgrades is to shut the system down (enter Insecure Mode), unlock everything (sysunlock with no arguments), perform the upgrade (with an extra step) or patch, then lock everything (syslock with no arguments), then unlock what's needed for Karl (sysunlock -s), and then exit, which starts up system daemons and networking, and returns to Secure Mode, without rebooting the kernel or resetting the system uptime counter. In my rc.securelevel file I have the following line:

echo -n ' running syslock'; (/bin/sleep 10; /usr/local/bin/syslock -swf) &

The -s and -f options have already been explained, but -w means to wait for KARL relinking to complete before locking, so as not to prevent that process from occurring. Typically, I do not unlock with -s for most instances when I shut down to make changes, and so I do prevent KARL relinking in those cases, and it doesn't lead to any system inconsistencies--it just preserves the previously established link ordering.

The extra step I mentioned above for an upgrade is that I comment out the line in rc.securelevel that re-locks the system because at the completion of a sysupgrade process there will be a reboot after which I will want to make many additional file changes using sysmerge to update system configuration files, update packages I have installed, remove unused binaries and old libraries, and so forth. I then remove the comment and reboot again. (Also, if a patch with syspatch rebuilds the kernel, I'll reboot with the new kernel after the return to Secure Mode and the KARL process completes.)

One side note is a little trick I use on my OpenBSD firewall to avoid unnecessary disruption to traffic when doing patching and software updates that require unlocking system immutable flags. The trick is that shutting down to Insecure Mode doesn't impact traffic routing or packet filtering, but running netstart when you exit back to Secure Mode does. (Disruption is unavoidable if it's a kernel patch that requires a full reboot.) The trick is that I've modified my /etc/rc (something I generally avoid doing for ease of upgrades, so I keep the original) by adding one line before and two lines after the call to netstart:

if [ ! -f /var/run/no_netstart_resume ]; then

sh /etc/netstart

echo "bypassing netstart"

/bin/rm -f /var/run/no_netstart_resume

With this in place, I touch /var/run/no_netstart_resume before I exit, and the system restarts with no network disruption.

Audit Feature

Both syslock and sysunlock have an audit (-a) option, which will report which files are currently not in the expected state. That is, syslock -a will tell you all the files which should be locked per the config but are unlocked, and sysunlock -a will tell you all the files which should be unlocked per the config but are locked. This can also be applied to any specific group with -g <groupname>. If used on a BSD system in Secure Mode, the audit can be restricted to what would actually be changed at the current security level using the -o (operational restrictions) option. A -q (quiet) option will suppress all output and just return 0 for success or 1 (error) for failure; this was created to allow a check to see if all files in a particular group are unlocked for an installation to occur for my install.pl tool (to be covered in a June 12 blog post). With -q, the audit will finish and return at the first discrepancy found.

Path Prefixes

The configuration file syntax allows listed paths to use three other prefixes in addition to the OpenBSD-specific "!" referenced above. These prefixes, which only have effect on directory paths (and generate a warning but are otherwise ignored on other file types) are:

+ Do not recurse through subdirectories. (No prefix, the default, means lock the directory and every thing in it, recursively.)

- Do not lock the directory itself, just its contents.

= Lock the directory and its file contents, but not subdirectories.

These cannot be used in combination (though some combinations, like =-, might conceivably be useful), and while I initially made use of the first two path prefixes in my configs, they ended up not being particularly useful with the patterns of groups I developed. I recently added the = path prefix to address a Linux-specific case.

Linux-specific: Bootloader Considerations

On many Linux systems (notably on Proxmox which uses Debian), the grub bootloader rewrites files in /boot/grub, (specifically grub.cfg and grubenv) on reboots. If those files are immutable, the reboot will fail to update those files. The default Linux config creates a grub group for /boot/grub and its contents, and uses the = path prefix on a separate group for /boot and its other subdirectories. The grub group can then be unlocked before a reboot, while the broader group is unlocked for kernel updates, and both locked again afterward. The grub group unlocks slightly more than strictly necessary (everything in /boot/grub rather than the directory and the two specific files), but handles the common case cleanly.

Use of Large Language Models (LLMs)

I've made use of LLMs, initially for performing security assessments with suggested improvements that I'd implement selectively and by hand, but subsequently for working out the details of design for prospective changes, writing code, and identifying the causes of bugs. Each of these capabilities has significantly improved since the initial use for code assessments in the summer of 2025. Specific capabilities implemented by Claude include adding append-only flag support, improving error messages and warnings, code refactoring, enhancing the audit features and adding the -o option, and drafting the Github README. Most recently, while I was in the process of writing this blog post, I revisited an issue I had run into involving overlapping groups with differing flags, and thought that a new path prefix that ignored directories might be a good way to handle it. In addition to that specific use case, for which Claude suggested the use of = (to mean "lock the directory and files at the same level"), I asked whether any combinations of existing path prefixes might be useful or if any other new prefixes might make sense. Claude suggested that -= or =- might be meaningful and useful (don't lock the directory itself, lock the files in it but not the subdirectories), but I chose not to add the additional complexity without a specific use case. In the process I identified a bug in how path prefixes were being handled in previous Claude-generated code related to perl taint handling, and Claude fixed it along with the implementation of =.

I've used ChatGPT and Gemini in addition to Claude for security assessments on the code, and they've each identified different issues. While each has found real bugs, my impression is that I've seen more false positives from ChatGPT and Gemini than from Claude, though they've also found real bugs in code written by Claude.

I've found LLMs quite useful for security auditing, refactoring, and error message improvements, as well as writing new capabilities that are relatively straightforward. In the case of implementing append-only flags, it took multiple design, build, and test cycles to get the code to production quality. Overall, forcing myself to explain design choices clearly (and sometimes reconsider them) in the process of using LLMs has been extremely valuable, and has also been a benefit of writing this blog post. I used Claude to identify key topics that should be mentioned in this series, but did not rely on Claude to outline or write the post. Claude and a human editor reviewed this post (and the opening overview post) identify typos and suggest edits.

I'll include a section like this in each post in the series.

Getting Started and Further Reading

The sample config files supplied with syslock cover OpenBSD, Linux (with some Proxmox specifics in comments), and macOS, and provide a reasonable starting point. As noted above, I recommend starting with uchg groups on BSD and macOS, which gives you immediate error prevention value and a chance to discover what needs to be unlocked for your specific regular workflows before committing to more restrictive schg flags. For Linux, there's only one kind of immutable attribute and it's changeable without a shutdown, so you can start immediately with the sample config.

As noted above, the syslock audit feature is integrated with my install.pl tool and syslock groups more generally are a key feature of both that tool and its distribute.pl counterpart, both of which will be covered in a blog post on June 12. The wrap-up post on June 23 will show how all of these tools fit together into a coherent security architecture.

syslock is available on my website and on Github, along with sample configs for OpenBSD, Linux, and macOS.

25 years of OpenBSD security tools

2026-06-02T08:00:00.000-07:00

I've been using and administering OpenBSD systems since 1999 (OpenBSD 2.5). During that time, I've written numerous scripts to make things easier, more automated, or more secure, or sometimes just to improve my understanding of how things work. When I started managing my home systems, I ran several Internet-exposed services on my home network (DNS, mail, web, SSH). I used djbdns, qmail, and Apache httpd at the start before switching to nsd/unbound for DNS and postfix for mail, and finally to OpenSMTPD for mail. When I got tired of excessive inbound traffic I moved my authoritative DNS to a provider while keeping an internal zone and resolvers, set up two cloud servers for mail and my public webserver. My home network became a hardened, minimal-exposure architecture that only allows Wireguard from expected sources and mail (after mutual TLS authentication with certificates) while continuing to run internal services.

Over the years I've made a number of these scripts available via my website and on Github once they were sufficiently mature, configurable, and with reasonable defaults in supplied sample configuration files. A set of them fit together in a coherent framework that I thought I'd write about in a series of blog posts for those who might be interested in either using them or learning from them. All are under BSD licenses which require no permission from me to use or rework into something else -- my intent is not to obtain a new user base that I need to support, though I'm happy to consider suggested enhancements.

The tools I will cover in these posts, while written for OpenBSD originally, also work on Linux and macOS, and likely on other BSDs. I use most on Kali and Proxmox (Debian Linux), as well as a few on macOS (which has roots in FreeBSD). All are written in perl and use OpenBSD-specific features when available (such as pledge and unveil, covered in an earlier blog post). Several use privilege separation to run as much functionality as possible as a non-privileged user.

The earliest tools, written initially between 1999 and 2004, were intended to provide log monitoring, file integrity monitoring, and to manage file system flags for making files immutable, a feature I hadn't seen widely used until macOS introduced a variant in 2015. Even among OpenBSD users, immutable flags are not commonly used and I recall early warnings that they were difficult to use because many files would have to be made immutable in order to avoid somewhat trivial bypasses.

The later-developed tools in the set I will cover, written in 2022-2024, are for file and software distribution across hosts and providing a perl interface to OpenBSD's signify cryptographic signing and verification tool for use by most of the tools in the set.

I'll note in my discussion how I've used large language models (LLMs) for security assessment, bug fixing, and enhancement on these tools, and where it has been useful and some of the obstacles I've run into along the way. I'll also describe how they work together in various ways, with a comprehensive view in the final wrap-up. Here's the planned schedule:

* June 2: this overview post

* June 5: syslock and sysunlock (initially written 2004, inspired by a much simpler tool called syslock by George Shaffer).

These tools allow you to define and manage groups of files which use BSD system and user immutable and append-only flags or Linux immutable or append-only flags. The use cases range from genuine security enhancement to error prevention.

* June 9: rsync-tools (rsync-client.pl/rsync-server.pl, initially written 2003; rrsync, a 2022 fork of the version initially written by Joe Smith in 2004 and modified by Wayne Davison, the primary developer of rsync; rsync-altroot.pl initially written 2002).

This is a collection of tools used with rsync to define sets of files to be kept synchronized between hosts, perform backups, and to place restrictions on rsync using various mechanisms.

* June 12: distribute.pl/install.pl (originally written 2022) and some extras (including Signify.pm, originally written 2024)

Two tools for distributing content (plain files, config files, certificates, and signed OpenBSD-style packages) to multiple hosts, verifying signatures and installing on the remote hosts. These are not limited to use on OpenBSD, as the install tool will work on Linux and macOS as well--so long as the content being distributed is usable on those operating systems, which includes architecture/OS-independent OpenBSD-style packages such as perl scripts--like all of the scripts in this blog series, which are available as signed OpenBSD-style packages. These are packaged with some extras (gendoas.pl with distribute.pl and pkg_info.pl with install.pl) and this blog post will also cover Signify.pm, a perl interface to OpenBSD's signify.

* June 16: reportnew (originally written 1999)

A log monitoring tool, inspired by swatch but written to support djbtools' cyclog and multilog format logs, Linux journal files, as well as BSD, Linux, and macOS process accounting logs, the latter of which may be a feature unique to this tool (I've not seen it in any other log monitoring tool).

* June 19: sigtree.pl (originally written 2000)

A file integrity monitoring tool, inspired by the original tripwire.

* June 23: Wrap-up post

Each post will discuss the origins of the tool(s), the use cases and problems solved, the security model, the limitations, and, in some cases, what might be added in the future. As each post is published, links will be added above.

If you want to skip ahead and look into these tools further, all are available on Github and on my website.

Book Review: Scott J. Shapiro, Fancy Bear Goes Phishing: The Dark History of the Information Age, in Five Extraordinary Hacks

2026-06-01T12:25:21.821-07:00

Scott Shapiro's 2023 book's aim is to answer three questions: (1) why is the Internet (still) so insecure? (2) how do hackers do what they do? and (3) what can be done about it? He recounts some historical events, the "five extraordinary hacks" of the subtitle, to tell the story, and introduces the terms "upcode" and "downcode" as the core concepts in his framework for understanding--where "downcode" means actual, implemented computer code and "upcode" means the social, political, and institutional forces providing incentives and governance. This is essentially a simplified version of Lawrence Lessig's four forces of law, social norms, markets, and code spelled out in his 1999 book, Code: And Other Laws of Cyberspace, and also reminded me of the framework in Bruce Schneier's 2012 book, Liars and Outliers: Enabling the Trust That Society Needs to Thrive, where the four forces are moral pressures (internalized incentives), social pressures (social/cultural incentives from other people), institutional guidelines and rules (formal rules, regulations, and laws), and security systems (locks, police, firewalls, fraud detection, etc. -- actual operational controls which may be implemented physically, in code, or by policies and practices). For Shapiro, Lessig's first three forces are "upcode" and only code is "downcode," and Schneier's first three forces and parts of his fourth are "upcode."

I found Shapiro's answers to the first and last questions of his project fairly unsatisfying by comparison to Schneier's book (or to, say, Ross Anderson's massive Security Engineering book, which you can find free online and which is the number one book I recommend to people interested in computer security). His upcode/downcode framework is, I think, too simplistic, and while he correctly identifies some of the specific factors relevant to his five extraordinary hacks, he also makes some bad arguments and gets some things quite wrong, and I think misses some of the key issues that have become highly relevant today with the rise of large language models (LLMs).

His answers to the second question, specific to the hacks he describes, however, are generally quite good and detailed, and this is where I think the book is at its strongest. The five hacks are:

(1) The Robert Morris Jr. worm. (2) Dark Avenger's viruses. (3) The breach of Paris Hilton's T-Mobile Sidekick. (4) The Russian GRU (CrowdStrike name: "Fancy Bear") breach of the DNC and DCCC. (5) The DDoS attacks of the Mirai botnet.

Each hack is presented over multiple chapters, with historical context and explanation of technical details, as well as relevant social and psychological (and legal) factors, in his upcode/downcode framework. I share a complaint with other reviews that Shapiro has a tendency to invent unnecessary terminology ("vorms" for a virus/worm hybrid, and "mudges" for malicious nudges, of the sort commonly referred to as "dark patterns" or that are examined in depth in Natasha Schüll's 2012 book, Addiction by Design: Machine Gambling in Las Vegas).

My biggest factual complaints with Shapiro come in some of the background context he supplies to the 1988 Morris worm, when he gives a brief history of the UNIX operating system that begins with its predecessor, Multics. Shapiro notes that his father, like Morris's, worked at Bell Labs. (And disclosure: I used Multics beginning around 1978-79 and as a Multics developer from 1983-1989.) Bell Labs is the likely source of the issues in Shapiro's discussion of Multics. Shapiro describes the history of Multics like this (p. 26):

A large team from MIT, Bell Labs, and General Electric, therefore, decided to develop a complete multiuser operating system as a replacement for batch processing. They called it Multics, for Multiplexed Information and Computing Service.
The Multics team designed its time-sharing with security in mind. Multics pioneered many security controls still in use today--one of which was storing passwords in garbled form so that users couldn't repeat Allan Scherr's simple trick. After six years of development, Multics was released in 1969.
The military saw potential in Multics. Instead of buying separate computers to handle unclassified, classified, secret, and top-secret information, the Pentagon could buy one and configure the operating system so that users could only access information for which they had clearance. The military estimated that it would save $100 million by switching to time-sharing.
Before the air force purchased Multics, they tested it. The test was a disaster. It took thirty minutes to figure out how to hack into Multics, and another two hours to write a program to do it. "A malicious user can penetrate the system at will with relatively minimal effort," the evaluation concluded.
The research community did not love Multics either. Less concerned with its bad security, computer scientists were unhappy with its design. Multics was complicated and bloated--a typical result of decision by committee. In 1969, part of the Multics group broke away and started over. This new team, led by Dennis Ritchie and Ken Thompson, operated out of an attic at Bell Labs using a spare PDP-7, a "minicomputer" built by the Digital Equipment Corporation (DEC) that cost ten times less than an IBM mainframe.
The Bell Labs team had learned the lesson of Multics' failure: Keep it simple, stupid.

Based on this description, one might infer that the US Air Force did not purchase Multics and that it faded away, but in fact they purchased multiple Multics systems and operated them for decades. One might also infer that the Paul Karger and Roger Schell-led penetration test was the end of the story, when it was just the beginning--the issues identified were corrected, and on September 1, 1985, Multics was the first operating system to receive a B2 security rating from the National Computer Security Center (a project I participated in). Shapiro's "thirty minutes to figure out how to hack" and "another two hours to write a program to do it" is referring to the "Master Mode Transfer" vulnerability in table 3 of the Karger and Schell report, and it should be noted that these time estimates are for a computer science graduate of a major university with moderate knowledge of Multics design and nine months experience as a Multics programmer with access to the source code (which Multics provided to its customers for all except the "unbundled" extra-cost software). Shapiro's "A malicious user can penetrate the system at will with relatively minimal effort" is an accurate quote from the report, but not from its conclusion, rather, from an earlier section titled "Multics as a Base for a Secure System" that is referencing the prior section, "Multics is not Now Secure." The next section says that "In the long term, it is felt that Multics can be developed into an open secure multi-level system by restructuring the operating system to include a security kernel." And that was, in fact, done -- the B2 security rating was earned, in part, for demonstration of the security of the Multics Trusted Computing Base (TCB), aka, the "kernel."

Shapiro's description says that Multics was "complicated and bloated." While it is true that some joked that Multics stood for "many unnecessary large tables in core [memory] simultaneously," it was incredibly small and streamlined by modern standards. Karger and Schell's followup paper, "Thirty Years Later: Lessons from the Multics Security Evaluation," notes that the 1973 Multics TCB was 628K bytes, and that the security policy alone of SELinux is 2.5 times larger, not even counting the Linux kernel itself.

It is also worth noting that while Shapiro's description suggests that the Bell Labs team broke away and started afresh after this failure, Bell Labs actually withdrew from Project MAC very early in the project, in March 1969, while the Air Force assessment took place from July 1972 to October 1973. Ken Thompson has admitted in an interview that he's never used a Multics system.

It is undeniably true that UNIX outcompeted Multics, but the reasons for this are many and include that Honeywell had three mainframe operating systems, GCOS (formerly GECOS), Multics, and CP-V (and its successor CP-6), and GCOS was the one that was given the most support, development, and marketing resources. Unlike UNIX, which became open source in the early nineties and its essentials cloned as the open source Linux, Multics was not made open source until November 2007 and never ported to alternative hardware. I highly recommend that anyone interested in operating system history and computer security spend some time perusing Tom Van Vleck's Multicians website, as there are still lessons to be learned from and about Multics. (And you can now run one yourself on a laptop or even a Raspberry Pi, via Honeywell DPS8 hardware emulation.)

A few pages later (pp. 29-30), Shapiro writes again about Multics, and rightly gives credit to the Karger and Schell report for something UNIX co-creator Ken Thompson regularly is given credit for coming up with:

When Ken Thompson won the Turing Lifetime Achievement Award in 1984, the highest honor in the computer-science community, for developing UNIX, he devoted his lecture to cybersecurity, a first for the Turing lecture. In the first half of his lecture, Thompson describes a devious hack first used by air force testers when they penetrated the Multics system in 1974. They showed how to insert an undetectable "backdoor" in Multics. ... The moral Thompson drew was bracing: the "only program you can truly trust is the one you wrote yourself."

Thompson's lecture, published as "Reflections on Trusting Trust," ends with an acknowledgement in footnote four that he didn't come up with this idea, citing "Unknown Air Force Document" (which is the first Karger and Schell document linked above). The specific idea is not just a trapdoor or trojan horse, but a trapdoor in the compiled code that is not present in the source code, but is inserted by the compiler itself -- including that insertion functionality itself being automatically inserted into the compiler when the compiler itself is recompiled. The idea is that the trapdoor cannot be observed in the source code, it's not present there, but is only in the compiled binary. Karger and Schell describe it like this (in section 3.4.5, "Trap Door Insertion"):

Clearly when a trap door is inserted, it must be well hidden to avoid detection by system maintenance personnel. Trap doors can best be hidden in changes to the binary code of a compiled routine. Such a change is completely invisible on system listings and can be detected only by comparing bit by bit the object code and the compiler listing. However, object code trap doors are vulnerable to recompilations of the module in question. ...
It was noted above that while object code trap doors are invisible, they are vulnerable to recompilations. The compiler (or assembler) trap door is inserted to permit object code trap doors to survive even a complete recompilation of the entire system In Multics, most of the ring 0 supervisor is written in PL/I. A penetrator could insert a trap door in the PL/I compiler to note when it is compiling a ring 0 module. Then the compiler would insert an object code trap door in the ring 0 module without listing the code in the listing. Since the PL/I compiler is itself written in PL/I, the trap door can maintain itself, even when the compiler is recompiled.

An object code compiler trap door, therefore, would mean that you can't even trust a program you wrote yourself! There is, however, a route to addressing this problem, which was the subject of David A. Wheeler's doctoral dissertation in 2009, "Fully Countering Trusting Trust Through Diverse Double-Compiling." (Note that Karger and Schell did demonstrate an object code trap door in the Multics penetration test, but not a compiler object code trap door.)

Shapiro does mention the NCSC security certification process in his "The Lesson of the Morris Worm" section, and I think he draws the wrong lessons from it by focusing on an incomplete certification and ignoring a completed one, as well as more recent academic research (langsec) that is becoming highly relevant in the age of LLMs. But first, one of his lessons (p. 43) is that his first question was malformed, that the Internet has to be open and purely a transport layer (the "end-to-end principle") and that the right question instead is to ask why endpoint computers are so insecure. That's clearly too quick a move, as we've seen countries build national firewalls and organizations deploy all manner of network-based security controls, and in the case of DDoS attack mitigation, they need to be outside of the targeted victim's network (preferably geographically distributed with AnyCast to diffuse the attack traffic and to filter it before it reaches the victim's network). We also should be free to raise questions about provider liability for being sources of attack (or even "attractive nuisances"), not blocked by an end-to-end principle that isn't actually adhered to in reality.

About the NCSC security certification process, Shapiro writes (pp. 44-45):

The story of the VAX VMM Security Kernel demonstrates the pitfalls of this strategy [assessing security and certifying]. In 1979, Major Roger Schell led a team to create an operating system that could withstand the NSA's most rigorous tests and achieve the highest possible score from the NSA--an A1 rating. To do so, his team built the system in a secured laboratory so that only the development group could enter. The machine they coded on--the development machine--was housed in a separate locked room within the lab. That locked room was protected by a cage. ...
It took a decade to build the system. By late 1989, the VMM Security Kernel was put in the field to undergo testing at government and aerospace installations. But in March 1990, DEC, the maker of the VAX minicomputer, canceled the project and removed prototypes from the testing sites. ...

He goes on to contrast with free and open-source software, noting the risk of backdoors and "Linus's law, which holds that with enough eyeballs, all bugs are shallow (i.e., easy to find)." We know that this is not quite accurate -- you need enough appropriately experienced eyeballs, pointed in the right places, which LLMs now have the potential to do, and seem to be ramping up rapidly on. But to my mind, he should have picked a different example than the VAX VMM Security Kernel, namely Honeywell's SCOMP (Secure Communications Processor) and its STOP operating system, which received an NCSC A1 security rating in 1985. When Groupe Bull acquired Honeywell's Large Computer Products Division in 1987-1991, the SCOMP division, Honeywell's Secure Computing Technology Center based in Minneapolis, was spun out into Secure Computing, and later acquired by McAfee. The STOP operating system was ported to other hardware and used for several military-grade communications gateways (and lessons learned from it were used in other products such as the Sidewinder firewall).

The main principle for an A1 security rating is that the system have "verified design," which includes formal specification, formal verification, mandatory and discretionary access control, configuration management, and distribution control. These are high-effort, resource intensive things to produce, but they are also things that are becoming more feasible to produce with LLM assistance (and perhaps necessary to produce to mitigate more vulnerabilities becoming shallow and discoverable, and possibly helpful in addressing limitations of LLMs themselves in a virtuous circle). It's worth noting here that in the Epilogue of the book, Shapiro gives an argument for the impossibility of "a magic app that checks programs for vulnerabilities" (p. 325), basically pointing out the issue of the halting problem and Turing computability. It's certainly correct that you can't build a system that will find all bugs, but it doesn't follow from that that you cannot build systems that find many bugs, nor that you cannot eliminate entire classes of vulnerability, nor that you cannot build specialized systems that have verifiable security properties. One of the lessons of langsec is that we can do things without Turing-complete systems, and we should do so, and this is something else that LLMs might make more feasible rather than relying on general purpose operating systems for every task and function. (Book recommendation for those who draw too-broad conclusions from theorems of undecidability, computability, and incompleteness: Torkel Franzen's 2005 book, Gödel's Theorem: An Incomplete Guide to Its Use and Abuse.)

To end on a positive note, I thought that Shapiro's coverage of the book's title hack, the Russian GRU ("Fancy Bear")'s breach of the DNC and DCC, was excellent in clearly laying out the details and timeline, and citing relevant sources that support the attribution. This occurs in chapters 7 and 8 (pp. 186-237), which should be mandatory reading for anyone who is still arguing that there is no evidence that Russia was behind the DNC hack or the subsequent data leaks in the face of massive evidence to the contrary. (It prompted me to add a reference to the book in my unpublished letter to the editor of Fortean Times in response to a columnist who should be mandated to read these chapters.)

Despite my issues with Shapiro's coverage of Multics and some of his conclusions, I enjoyed the book and recommend it for those interested in the history and context of the five hacks he covers.

Books read in 2025

2026-01-01T08:34:00.000-07:00

Not much blogging going on here still, but here's my annual list of books read for 2025.

Adam Becker, More Everything Forever: AI Overlords, Space Empires, and Silicon Valley's Crusade to Control the Fate of Humanity
Rutger Bregman, Humankind: A Hopeful History (2019)
Samuel D. Brunson, Between the Temple and the Tax Collector: The Intersection of Mormonism and the State
Kate Conger and Ryan Mac, Character Limit: How Elon Musk Destroyed Twitter (2024)
Mark Jonathan Davis, Grateful: 25 Years of Music, Movies, and Medical Emergencies with Richard Cheese & Lounge Against the Machine, Part One: Stranger in a Strange Lounge
Renée DiResta, Invisible Rulers: The People Who Turn Lies Into Reality (2024)
Cory Doctorow, Picks and Shovels: A Martin Hench Novel
Erle Stanley Gardner (Martin H. Greenberg and Charles G. Waugh, eds), The Human Zero: The Science Fiction Stories of Erle Stanley Gardner (1981)
Brooke Harrington, Offshore: Stealth Wealth and the New Colonialism (2024)
Gabriel Kennedy, Chapel Perilous: The Life & Thought Crimes of Robert Anton Wilson (2024)
Thomas Levenson, So Very Small: How Humans Discovered the Microcosmos, Defeated Germs--and May Still Lose the War Against Infectious Disease
Mary Roach, Replaceable You: Adventures in Human Anatomy
Oliver Sacks, The Island of the Colorblind (1996)
Oliver Sacks, The Mind's Eye (2010)
Neil Sheehan, A Bright Shining Lie: John Paul Vann and America in Vietnam (1988, 2009 edition)
Quinn Slobodian, Hayek's Bastards: Race, Gold, IQ, and the Capitalism of the Far Right
Dana Stevens, Camera Man: Buster Keaton, the Dawn of Cinema, and the Invention of the Twentieth Century (2023)
Katherine Stewart, Money, Lies, and God: Inside the Movement to Destroy American Democracy
Spencer Sunshine, Neo-Nazi Terrorism and Countercultural Fascism: The Origins and Afterlife of James Mason's Siege (2024)
Sam Tanenhaus, Buckley: The Life and the Revolution That Changed America
Mark S. Weiner, The Rule of the Clan: What an Ancient Form of Social Organization Reveals About the Future of Individual Freedom (2013)
Tim Weiner, The Mission: The CIA in the 21st Century
Lawrence Wright, The Looming Tower: Al-Qaeda and the Road to 9/11 (2006)
Sarah Wynn-Williams, Careless People: A Cautionary Tale of Power, Greed, and Lost Idealism

Top for 2025 published in 2025: Tanenhaus, Levenson, Roach, Weiner, Davis, Wynn-Williams, Becker, Doctorow; other top reads for the year: Sheehan, M. Weiner, Sacks

A few planned or already (or still) in-progress reads for 2026:

Robert Caro, The Power Broker: Robert Moses and the Fall of New York (1975)

G.A. Cohen, Self-Ownership, Freedom, and Equality (1995)

John Ferris, Behind the Enigma: The Authorised History of GCHQ, Britain's Secret Cyber-Intelligence Agency (2020)

Peter H. Wilson, The Holy Roman Empire: A Thousand Years of Europe's History (2017)

Arthur M. Melzer, Philosophy Between the Lines: The Lost History of Esoteric Writing (2014)

(Previously: 2024, 2023, 2022, 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.)

Comment on Steve Novella's "Rethinking the Skeptical Movement" a decade ago

2025-11-15T18:44:00.000-07:00

I just came across this comment I wrote a decade ago on a post that Steve Novella wrote on his blog, and I think it's pretty good, but it generated zero comment and no upvotes or downvotes. I just came across it again while looking for old comments I made about Al Seckel, who is in the news again for his role in attempting to scrub negative information about Jeffrey Epstein from the Internet.

lippard10 years ago

This sentence contains an argument in which the conclusion does not follow from the premises:

"The Committee for Skeptical Inquiry (CSI) is one of the oldest standing skeptical organizations and they have editors, fellows, and advisory committee (of which I am a member) and therefore have the ability to maintain high levels of quality within their own sphere."

The history of organized skepticism shows that CSICOP has repeatedly run into issues of ethics, poor methodology, and fraud by its Fellows and associates that has only been dealt with because of external pressures. That includes the Mars effect controversy, plagiarism by Robert Baker in the pages of Skeptical Inquirer, credential misrepresentation by Al Seckel, and the Uri Geller lawsuits (which had nothing to do with whether or not he actually had psychic capabilities, though they are often misrepresented by skeptics as though that was what the lawsuits were about).

The skeptical movement arose in the U.S. in the 1970s as a counter-movement, as a response to an increase in belief in the occult, new religions, and the "New Age" movement. It has periodically resurged in response to various other challenges--faith healing televangelists, creationist legislation, parapsychology's finding du jour, and so on. But it seems to me that it has largely been reactionary and not a self-sustaining movement. Although it is supposedly a scientific movement, the choice was made at the beginning to address a popular audience, and, after the Mars effect, not to directly fund or sponsor scientific research. This was partly reversed as CSI "Research Fellows" were appointed, but most of their work tends to be historical or in response to specific popular claims, as opposed to experimental work--and it tends to be published in popular journals, not scientific ones.

CSI Fellows are not members of the organization and have no voting power or control over the organization, apart from those who are members of the Executive Council. They are, for the most part (with a few exceptions), famous figureheads who do not directly contribute research or work to the organization, but merely lend their reputations to the group for purposes of self-promotion. By contrast, the Parapsychological Association (for one example, the Society for Scientific Exploration is another) is an organization of practicing scientists, doing research in the area, who publish in an academic-style, peer-reviewed journal. The PA, unlike CSI, is a member of the AAAS.

CSICOP/CSI has published a series of goals and objectives in the Skeptical Inquirer over its history, and it has clearly achieved some of those goals (like the original "To establish a network of people interested in examining claims of the paranormal"--changed from "establish" to "maintain" in 1980--and "To convene conferences and meetings"), failed at others (like "To prepare bibliographies of published materials that carefully examine such claims", a goal deleted in 1998; and "To encourage and commission research by objective and impartial inquirers in areas where it is needed"--the "commisions" was removed in 1994). However, CSI removed most of these objectives from the Skeptical Inquirer in 2001, and hasn't listed any at all in the magazine since 2009.

A clear vision, mission, goals, and objectives are necessary for an effective organization.

Illinois state representative Mike Bost's dog-killing story

2025-08-22T14:30:00.002-07:00

Another case of conservative animal abuse, via libraryjayne on Threads, Illinois state representative Mike Bost (R-Murphysboro):

The earliest episode dates back to 1986, when a neighborhood beagle named Rusty bit Bost's 4-year-old daughter. The report filed by animal control officials indicates that the girl provoked the attack by chasing the dog. She ultimately had to get 19 stitches on her face.
According to court records, Bost was displeased that authorities would not be able to deal with the 10-year-old dog immediately. So he got his handgun, drove to Rusty's owner's home, and shot the dog to death while it was penned in an enclosure.
Neighbors were "very alarmed and disturbed," according to the police report, but a jury eventually found Bost not guilty of breaking any laws. The local paper reported the case under the headline "Area man acquitted in dog killing trial."

(From Michael McAuliffe at HuffPo, Sep 26, 2014.)

Causing unnecessary death and suffering

2025-01-26T10:08:00.004-07:00

If your reasons for voting for Donald Trump for president included that you wanted to cause unnecessary death and suffering and reduce to the standing and trustworthiness of the United States with the rest of the world then congratulations, you've been given what you wanted. If not, maybe you should engage in some reflection on what you've helped to bring about.

On Bluesky, doctor Atul Gawande, author of the excellent book Being Mortal (which I read in 2019) and The Checklist Manifesto (which was well-reviewed but I have not read), who was USAID Assistant Administrator for Public Health from 2022 to 2025, wrote the following posts:

I ran @USAID health programs for the last 3 years. Trump’s 90 day Stop Work Order on foreign assistance does serious damage to the world and the US. Examples:🧵
January 26, 2025 at 8:56 AM

1. Stops work battling a deadly Marburg outbreak in Tanzania and a wide outbreak of a mpox variant killing children in west Africa before it spreads further.
2. Stops monitoring of bird flu in 49 countries, a disease which already killed an American on home soil.
3. Stops critical work on polio eradication.
4. Stops >$1B in corporate drug donations and coordination eradicating tropical diseases like river blindness, elephantiasis, and others on the verge of elimination in whole regions. https://www.neglecteddiseases.gov/about/results-and-impact/
5. Stops medicines, supplies, systems building, staff support aiding >90 million women and children to get low cost vaccinations, prenatal care, safe childbirth, contraception, and other basic lifesaving health needs. https://www.usaid.gov/PreventingChildandMaternalDeaths
6. Stops direct services for 6.5 million orphans, vulnerable children, and their caregivers affected by HIV in 23 countries.
7. Stops donated drug supplies keeping 20 million people living with HIV alive.
8. Would furlough all USAID contract staff — which includes half of its global health bureau—unless exempted.
Make no mistake — these essential, lifesaving activities are being halted right now. Clinics are shuttering. Workers sent home. Partners including US small businesses face being unable to meet payroll. All despite clear requirements from Congress to do this work.
This Administration is already trashing US standing, alliances with scores of countries built over half a century, world-leading capacity and expertise, and American security.

UPDATE (5 May 2026): Gawanda estimates that the USAID shutdown has so far caused the deaths of 600,000 people, two-thirds of whom are children. Also see this ProPublica story from December 2025, "Inside the Trump Administration's Man-Made Hunger Crisis."

Books read in 2024

2025-01-01T10:21:00.004-07:00

Not much blogging going on here still, but here's my annual list of books read for 2024.

James Bamford, Spy Fail: Foreign Spies, Moles, Saboteurs, and the Collapse of America's Counterintelligence (2023)
Benjamin Breen, Tripping on Utopia: Margaret Mead, The Cold War and the Troubled Birth of Psychedelic Science
Jennifer Burns, Milton Friedman: The Last Conservative (2023)
Bryan Burrough, Vendetta: American Express and the Smearing of Edmond Safra (1992)
Ron Chernow, The House of Morgan: An American Banking Dynasty and the Rise of Modern Finance (1990, 2010 foreword)
Rich Cohen, The Fish That Ate the Whale: The Life and Times of America's Banana King (2012)
Daniel C. Dennett, I've Been Thinking (2023)
Cory Doctorow, The Bezzle (fiction)
Edward Dolnick, Down the Great Unknown: John Wesley Powell's 1869 Journey of Discovery and Tragedy Through the Grand Canyon (2002)
Jon Friedman & John Meehan, House of Cards: Inside the Troubled Empire of American Express (1992)
Beverly Gage, G-Man: J. Edgar Hoover and the Making of the American Century (2022)
John Ganz, When the Clock Broke: Con Men, Conspiracists, and How America Cracked Up in the Early 1990s
Masha Gessen, The Future Is History: How Totalitarianism Reclaimed Russia (2017)
Martin Kihn, House of Lies: How Management Consultants Steal Your Watch and Then Tell You the Time (2005)
Stephen Kinzer, Poisoner in Chief: Sidney Gottlieb and the CIA Search for Mind Control (2020)
Stephen Kinzer, The True Flag: Theodore Roosevelt, Mark Twain, and the Birth of American Empire (2017)
Talia Lavin, Wild Faith: How the Christian Right is Taking Over America
Milton Mayer, They Thought They Were Free: The Germans 1933-45 (1955)
Michael Warren Lucas, git commit murder (2017, fiction)
Arvind Narayanan and Sayash Kapoor, AI Snake Oil: What Artificial Intelligence Can Do, What It Can't, and How to Tell the Difference
Craig Nelson, Thomas Paine: Enlightenment, Revolution, and the Birth of Modern Nations (2006)
Ryan J. Reilly, Sedition Hunters: How January 6th Broke the Justice System (2023)
Chris Rodda, Liars for Jesus: The Religious Right's Alternate Version of American History, Volume 2 (2016)
Zoë Schiffer, Extremely Hardcore: Inside Elon Musk's Twitter
Matt Zwolinski and John Tomasi, The Individualists: Radicals, Reactionaries, and the Struggle for the Soul of Libertarianism

Top for 2024 published in 2024: Doctorow, Breen, Ganz; other top reads for the year: Gage, Dennett, Kinzer (2020), Cohen, Gessen, Rodda

A few non-books of relevance for 2025:

What the Southern Baptists used to believe, but no longer do: https://www.sbc.net/resource-library/resolutions/resolution-on-moral-character-of-public-officials/

Umberto Eco, "Ur-Fascism," New York Review of Books, June 22, 1995

Dorothy Thompson, "Who Goes Nazi," Harper's Magazine, August 1941 (but contrast with Mayer 1955 and Gessen 2017 above)

A few planned or already (or still) in-progress reads for 2024:

G.A. Cohen, Self-Ownership, Freedom, and Equality (1995)

John Ferris, Behind the Enigma: The Authorised History of GCHQ, Britain's Secret Cyber-Intelligence Agency (2020)

Peter H. Wilson, The Holy Roman Empire: A Thousand Years of Europe's History (2017)

Lawrence Wright, The Looming Tower: Al-Qaeda and the Road to 9/11 (2006)

Arthur M. Melzer, Philosophy Between the Lines: The Lost History of Esoteric Writing (2014)

Mark S. Weiner, The Rule of the Clan: What an Ancient form of Social Organization Reveals About the Future of Individual Freedom (2013)

(Previously: 2023, 2022, 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.)

NRA CEO Doug Hamlin's cat killing story

2024-10-14T16:03:00.000-07:00

Per Stephanie Kirchgaessner in The Guardian, 14 October 2024:

Douglas Hamlin, who was appointed to lead the NRA this summer in the wake of a long-running corruption scandal at the gun rights group, was involved decades ago in the sadistic killing of a fraternity house cat named BK, according to several local media reports at the time.
Hamlin pleaded no contest to a misdemeanor charge of animal cruelty brought against him and four of his fraternity brothers in 1980, when he was an undergraduate student at the University of Michigan at Ann Arbor. The charge was brought against Hamlin under a local Ann Arbor ordinance. All five members of Alpha Delta Phi were later expelled from the fraternity.
The details of the case, described in local media reports at the time, are gruesome. The house cat was captured, its paws were cut off, and was then strung up and set on fire. The killing, which occurred in December 1979, was allegedly prompted by anger that the cat was not using its litterbox.
The case caused such a furore locally that some students and animal rights activists wore buttons and armbands in memory of BK.

While The Guardian notes that Hamlin's role was not clear, Judge S.J. Elden singled him out for particular criticism as the president of the fraternity who had a responsibility to prevent it--and not, as was attempted without success, to cover it up.

(See other conservative animal abuse tagged posts, about Kevin Roberts, Bill Frist, Kristi Noem, James Dobson, Mike Huckabee, Mitt Romney, and Jerry Falwell.)

Who's Who in Jack Smith's presidential immunity brief

2024-10-07T14:23:00.004-07:00

Here's my best effort, informed by Adam Klasfeld's at Just Security and others I came across.

P1 = Steve Bannon.

P2 = Trump campaign manager Bill Stepien (post July 2020).

P3 = Trump deputy campaign manager Justin Clark.

P4 = Trump senior campaign advisor Jason Miller.

P5 campaign operative Mike Roman.

P6 = Roger Stone.

P7 = Hope Hicks.

P8 = Pence Chief of Staff Marc Short.

P9 = Eric Herschmann.

P10 = Joe DiGenova.

P11 = Victoria Toensing.

P12 = Jenna Ellis.

P13 = Jared Kushner.

P14 = Ivanka Trump.

P15 = Trump WH Assistant to the President and Director of Oval Office Operations Nicholas F. Luna. P16 = AZ Gov Doug Ducey.

P17 = GA Gov Brian Kemp.

P18 = Speaker of the AZ House Rusty Bowers.

P19 = Trump staffer Christina Bobb (4 Dec 2020 tweet https://x.com/christina_bobb/status/1334996485075836936, ref p. 20).

P20 = Kory Langhofer (Bowers' attorney).

P21 = Trump chief of staff Mark Meadows.

P22 = campaign attorney (p. 22) Alex Cannon.

P23 = Trump GA lawyer Ray Smith (Roy Stallings Smith III, a real estate attorney).

P24 = volunteer Trump GA attorney Jackie Pick.

P25 = GA Sec of State Chief Operations Officer Gabriel Sterling.

P26 = GA Attorney General Christopher M. Carr.

P27 = US Senator David Perdue (proof is ref in Trump tweet on p. 18).

P28 = Kelly Loeffler (ditto).

P29 = GA election worker Wandrea "Shaye" Moss.

P30 = GA election worker Ruby Freeman (Shaye's mother, p. 25).

P31 = Cleta Mitchell, private attorney introduced on Trump v Kemp call as "who is not the attorney of record but has been involved" (p. 29, see WaPo "Here’s the full transcript and audio of the call between Trump and Raffensperger").

P32 = Kurt R. Hilbert, lead attorney for Trump in Trump v. Kemp.

P33 = GA Secretary of State Brad Raffensperger.

P34 = GA Lt. Gov. Geoff Duncan.

P35 = GA Secretary of State General Counsel Ryan Germany.

P36 = Trump private attorney on Raffensperger call Alex Kaufman (Fox Rothschild, subsequently resigned Jan 7, 2021; however, Kaufman stated he never represented Trump).

P37 = MI Senate Majority Leader Mike Shirkey.

P38 = MI House Speaker Lee Chatfield.

P39 = RNC Chairwoman Ronna McDaniel.

P40 = not referenced.

P41 = ? Scott Gragson ?, "Michigan campaign associate" (p. 34)

P42 = Trump executive assistant Molly Michael.

P43 = RNC Chief Counsel Justin Riemer.

P44 = RNC spokesperson Liz Harrington (recipient of email from Riemer: https://www.washingtonpost.com/politics/rnc-trump-stop-the-steal/2021/07/12/79e58a02-e320-11eb-934f-7e6c1927f261_story.html).

P45 = White House Deputy Chief of Staff/Social Media Director Dan Scavino.

P46 = PA GOP Chair Lawrence Tabas.

P47 = Philadelphia City Commissioner Al Schmidt.

P48 = former NYPD commissioner and Giuliani-Kerik partner Bernard B. Kerik (p. 40 tweet: https://x.com/BernardKerik/status/1334944478180888586).

P49 = WI Supreme Court Justice Brian Hagedorn.

P50 = Cybersecurity and Infrastructure Security Agency Director Chris Krebs.

P51 = Tucker Carlson.

P52 = Trump admin Attorney General William "Bill" Barr.

P53 = AZ attorney Jack Wilenchik (p. 51).

P54 = Trump campaign staffer Tim Murtaugh--in text thread on fake electors with P3 Clark/P4 J Miller/P9 Herschmann "certifying illegal votes" (https://www.newsweek.com/arizona-gold-fake-electors-trump-allies-indictment-1894131).

P55 = ? ? "Star Wars bar" thread (Jason Miller quote).

P56 = ? "Star Wars bar" (p. 151: P56 but not P55 attends meeting at VA campaign HQ).

P57 = former US Rep & US Attorney elector nominee who opted out of fake elector scheme Thomas Marino (p. 53).

P58 = VP Pence Counsel Greg Jacob (p. 70) "Pence lawyer".

P59 = WH Counsel Pat Cippolone.

P60 = WH press secretary Kayleigh McEnany.

P61 = AZ Senate president Karen Fann.

P62 = TX AG Ken Paxton.

P63 = MO AG, now US Senator Eric Schmitt.

P64 = J6 Ellipse rally organizer Carolyn Wren.

P65 = J6 Ellipse rally funder Julie Fancelli. (https://www.propublica.org/article/trump-campaign-fundraiser-ellipse-rally)

P66 = ? Katrina Pierson ? campaign employee working on J6 Ellipse rally who had most contact with Trump and was a private citizen after December 31, 2020. (p. 119) (https://www.politico.com/news/2022/02/18/capitol-riot-panel-interview-katrina-pierson-00010154)

P67 = WH photographer Shealeah Craighead.

P68 = Gen Michael Flynn.

P69 = WH trade advisor Peter Navarro.

P70 = Ivan Raiklin (https://www.cnn.com/politics/live-news/january-6-hearings-june-16#h_5cb75e4babd00cc7b68a62e35a09fa68) (p. 137).

P71 = Deputy WH Counsel Pat Philbin.

P72 = Matt Morgan (On pg. 151, P72 gives Herschmann a “tutorial on campaign basics and operations,” and is repeatedly mentioned along with P3, who is campaign attorney & Deputy Campaign Manager Justin Clark).

P73 = ? Michael Best ? assured Eric Herschmann he could trust P22 (p. 152)

P74 = ? J. Christian Adams or Matt Braynard ? (testified at December 10 Georgia hearing: https://www.gpb.org/news/2020/12/10/at-georgia-house-hearing-republicans-baseless-claims-of-voting-fraud-persist)

P75 = Ken Block, managing director of C2.

P76 = Jay Sekulow (see https://www.washingtonpost.com/politics/2023/03/22/pence-trump-grand-jury/ ).

P77 = Stefan Passantino (p. 151, WH Counsel’s office person “who handled ethics issues”; "former member of President Donald J. Trump’s Office of White House Counsel. In that capacity, Mr. Passantino was charged with overseeing compliance and ethics, policing conflicts of interest, and approving and enforcing ethics requirements" per the ethics complaint against him: https://ldad.org/wp-content/uploads/2023/03/Ethics-Complaint-against-Stefan-Passantino.pdf ).

CC1 = Rudy Giuliani.

CC2 = John Eastman.

CC3 = Sidney Powell.

CC4 = Jeffrey Clark.

CC5 = Ken Chesebro.

CC6 = Boris Epshteyn.

C1 = Berkeley Research Group.

C2 = Simpatico Software Systems.

C3 = Dominion Voting Systems.

[p. 73, no P#--unnamed US Senator is likely Ron Johnson of WI].

Corrections gladly accepted.

Kevin Roberts' dog-killing story

2024-09-24T15:44:00.001-07:00

Kevin Roberts, the president of the Heritage Foundation and head of Trump's Project 2025, was previously a history professor at New Mexico State University. While at the university, he told colleagues and dinner guests that he was irritated by the barking of a neighbor's dog, so he killed it with a shovel. Kenneth Hammond, then chairman of the history department, told The Guardian:

My recollection of his account was that he was discussing in the hallway with various members of the faculty, including me, that a neighbor’s dog had been barking pretty relentlessly and was, you know, keeping the baby and probably the parents awake and that he kind of lost it and took a shovel and killed the dog. End of problem.

Two other former colleagues report hearing the same story directly from Roberts; three others report hearing the story repeated from people who heard it directly from Roberts.

Roberts denies the story, claiming instead:

In 2004, a neighbor’s chained pit bull attempted to jump a fence into my backyard as I was gardening with my young daughter. Thankfully, the owner arrived in time to restrain the animal before it could get loose and attack us.

(Source: Stephanie Kirchgaessner, "Project 2025 mastermind allegedly told colleagues he killed a dog with a shovel," The Guardian, 24 September 2024)

See the "conservative animal abuse" tag on this blog for several other accounts of prominent conservatives killing or abusing dogs and cats.

Tips on using OpenBSD's pledge and unveil in perl scripts

2024-08-04T10:26:00.009-07:00

OpenBSD 5.9 (current as of this post is 7.5) introduced the "pledge" system call and 6.4 introduced the "unveil" system call, which together provide a means of more granular control of system access by processes running on the system to enforce least privilege. When a program calls "pledge", it provides a list of categories of system calls (called "promises") that it is planning to make during the life of the running process (children have to make their own pledges and are not restricted), and attempts to make calls outside of those areas will cause the call to be blocked and the process to be killed. Additional calls to pledge cannot add new categories but it can remove them, so access can become more restrictive but not less restrictive.

"Unveil," by contrast, selectively exposes parts of the file system, by file path, with specific access, and the rest of the file system is correspondingly "veiled" or blocked from access. Successive calls to unveil can expand or override previous ones, expanding access to the file system, adding write and create permissions where there was previously read only, but only until unveil is called with no arguments, which locks the current state in place. Further attempts to call unveil after that result in a violation.

Violations of pledges or attempts to access file paths that are not unveiled show up in process accounting logs for the process with the process flags "P" or "U", respectively. (My "reportnew" log monitoring script knows how to monitor process accounting logs and can be easily set up to report on such violations.)

Perl scripts on OpenBSD can also use pledge and unveil, with two modules provided in the base operating system, "OpenBSD::Pledge" and "OpenBSD::Unveil". I've been adding this functionality to several of my commonly used scripts and have learned a few tips that I'd like to share.

Pledge:

* Check your call to pledge for errors. If you typo the name of a promise (category of system calls), or you provide pledge with a string of comma separated promises instead of an array or list, it will fail and nothing will be pledged.

* If you don't have any idea what promises are required, just use "error". With the error promise, instead of blocking the system call and killing the process, the result is logged to /var/log/messages and you can see what promises are required.

* The "stdio" promise is always included with OpenBSD::Pledge, so you don't need to list it.

* The "unveil" promise is required if you intend to use OpenBSD::Unveil.

* Calls to exec or system require the "proc" and "exec" promises; the new processes created as a result are not restricted and need to make their own use of pledge and unveil. (Note: this means that if you are calling a system command that writes to a file, but your script doesn't otherwise write to files, you do not need to pledge the "wpath" promise in your script.)

* If you otherwise fork a child process (e.g., explicitly using "fork" or Parallel::ForkManager or implicitly forking a child process using "open" to read from or write to a command), the promises pledged by the parent process are carried over to the child, which can then restrict them further. (Hat tip to Bryan Steele, who pointed this out on Bluesky without specifically referring to the Perl context.)

* If you use the DBI perl module with mariadb and are accessing a database through a named pipe on the same server, you'll need to pledge the "unix", "inet", and "prot_exec" promises. (This works even from a chroot jail if the named pipe or socket is a hard link from the jail.)

* This isn't a tip, but an observation: if you promise "proc" but not "exec," your system call will fail but your process will not be killed and the script will continue running.

Unveil:

* If you make use of other perl modules in your code with "use", they are loaded prior to your call to unveil and so you don't need to unveil directories like /usr/libdata/perl5 in order to use them. The exception is perl modules that include compiled shared objects (".so"), or which use "require" on other modules (loading them at runtime), in which case you do need unveil such directories, but only with "r" permission.

* If you use the DBI perl module with mariadb, you will need to unveil /var/run/mysql with "rw" and /usr/lib and /usr/local/lib with "rx".

* If you use calls to "system" or "open" which use pipes, globs, or file redirection, you need to unveil "/bin/sh" with "x" permission. You may be able to rewrite your code to avoid the requirement--can you call "system" with a command name and list of arguments rather than a string, and do any processing you need in your program instead of with the shell?

* If you use calls to "system" to execute system commands, you need to unveil them with "x" permission but in most cases you don't need to include "r".

* It is often much easier to unveil a directory rather than individual files; if you plan to check for the existence of a file and then create it if it doesn't exist, you need "rwc" on the containing directory.

* One of the biggest challenges sometimes is to find the source of an unveil violation; unveiling "/" with various permissions to see if it goes away, and then removing that and testing individual directories under the root directory in trial and error can help find things. That's how I first found the need to unveil "/bin/sh".

Finally, if you are writing perl modules it's helpful to document which promises need to be pledged and files and directories need to be unveiled in the calling scripts in order for them to function. It would be inappropriate to pledge or unveil within the module except in a context like a forked child process. I've done this with my Signify.pm wrapper for the OpenBSD "signify" command for signing and verifying files with detached signatures or gzip archives with embedded signatures in the gzip header comments.

If you've made use of pledge and unveil--in perl scripts or otherwise--what lessons have you learned?

[UPDATE: 8 February 2026]: Note that OpenBSD::Pledge still does not support execpromises, so you cannot place pledge's execpromises restrictions on anything executed with "system" or "exec."]

[UPDATE 1 April 2026]: The "tmppath" promise is being removed in favor of just using "unveil" for any permissions limitations on files in /tmp. Note that if permission is granted to a symbolic link, it also applies to the target of the link, so granting "rwc" to /tmp opens potential bypass of unveil restrictions via symlinks in /tmp.

[UPDATE 14 May 2026]: Even though neither pledge nor unveil are inherited across system calls, it is possible for an error in a perl script to cause unveil errors in another process invoked via system call -- not because of its own unveil environment, but by messing with low-numbered file descriptors (e.g., by messing with STDOUT or STDERR in an inappropriate way), which I found by accident while modifying a script to use direct calls to ping instead of using Net::Ping, and suddenly saw unveil violations from ping processes run by the _ping user. Specifically, such an error can cause libc to attempt a path-resolution write inside ping, which fails because ping unveils / with r for read-only permission.

[UPDATE: 6 June 2026]: If you pledge 'fattr' but not 'chown' in a script that uses Archive::Tar to extract files, it will generate an error when you extract a file with a group that root is not a member of, as this is a restriction even on root for 'fattr' (but not 'chown'). This was mystifying for a while because the chown error (which doesn't include the "Operation not permitted" message) came from Archive::Tar but everything still ended up in the correct state because the group ID was inherited from the containing directory. It was further complicated since I was locking and unlocking immutable flags (which was working just fine!) and it first seemed like the most likely culprit.

Wikipedia, Skeptical Inquirer, and AI on Robert A. Baker plagiarism accusations

2024-05-14T18:22:00.020-07:00

The Wikipedia entry for University of Kentucky psychologist and skeptic Robert A. Baker recently (December 2023) restored a section on plagiarism accusations against him, which originated in a 1994 letter to the editor of Skeptical Inquirer from Jody Hey and were compounded by further accusations by Terence Hines and by me the same year. Unfortunately, the Wikipedia entry currently leaves the debate the same way the Skeptical Inquirer did in 1995, giving Baker the final word with a transparently false explanation. Here's how the Wikipedia entry currently presents the issue:

Readers of Skeptical Inquirer, noticed in 1994 similarities between one of Baker's articles and William Grey's article Philosophy and the Paranormal, Part 2. After discovering this, Baker wrote to Grey apologizing for "forgetting both the direct quotation and the reference citation", he claims that it was an oversight. Grey publicly accepted Baker's apology in the Skeptical Inquirer.^[20] In the following year, author Terence Hines accused Baker of unattributed quotations from an article by Melvin Harris and from his own book Pseudoscience and the Paranormal.^[21] Baker responded in Skeptical Inquirer. stating that he used Melvin Harris' book Investigating the Unexplained as a source, rather than the article or Hines' book, and that he gave Harris credit but forgot the quotation marks.^[22]

This description is faulty in that it omits most of the evidence and is inconsistent with it [Added 7 March 2025: --including that Grey, not Baker, discovered the issue and reported it in a letter to the Skeptical Inquirer editor.]. The most detailed account can be found in my 1994 report given to leaders at the Committee for the Scientific Investigation of Claims of the Paranormal (CSICOP, now the Committee for Skeptical Inquiry or CSI) and subsequently published in 1995 to Usenet and its update. I've also assembled a chronology of events that led to my involvement and included legal threats from Baker, which I've now updated to include a letter from Paul Kurtz in his role as head of Prometheus Books noting that Baker's book Hidden Memories had been withdrawn from publication. While I've not exhaustively searched Baker's work, I found fairly consistent plagiarism in his books for Prometheus and his book reviews for Skeptical Inquirer throughout his career as a skeptic.

The rest of this post will first show that Baker's claim to have used Harris as a source, but not Hines, is false--there is clear evidence that Baker plagiarized Hines, whose book he did not cite (and his text matches Harris's article rather than the book where they differ). Second, it will show the heaviest section of plagiarism I identified in another Baker book, They Call It Hypnosis (1990, Prometheus Books). Finally, it will show that Baker's institution defined research misconduct in a way that includes what he did, and that Baker's own writing shows that he understood this to be misconduct.

The exchange between Hines and Baker in the pages of the July/August 1995 Skeptical Inquirer (pp. 44-46) focuses on a passage on p. 157 in chapter 4 of Baker's book, Hidden Memories: Voices and Visions from Within (1992, Prometheus Books) and its resemblance to a passage on p. 74 in Hines' book, Pseudoscience and the Paranormal (1988, Prometheus Books) where he quotes from p. 23 of an article by Melvin Harris, "Are 'Past-Life' Regressions Evidence of Reincarnation?", Free Inquiry, Fall 1986, vol. 6, no. 4, pp. 18-23 (quotation marks as given in Hines):

"...every single piece of information given by Jane Evans can be traced to de Wohl's fictional account. She uses his fictional sequences in exactly the same order and even speaks of his fictional characters, such as Curio and Valerius, as if they had been real."

Hines notes that Baker uses nearly the same words in the same sequence, without quotation marks or references, on p. 157 of Hidden Memories:

Every single piece of information given by Mrs. Evans could be traced to De Wohl's book, and Mrs. Evans used his fictional sequences in exactly the same order as he had, and even spoke of De Wohl's fictional characters, Curio and Valerius, as if they had been real.

Here is how Harris makes the same statement on p. 162 of his book, Investigating the Unexplained (1986, Prometheus Books), which Baker claims is his source (italics in original):

In the same way every single piece of information given out by Jane Evans can be traced to De Wohl's fictional account. She uses his fictional sequences in exactly the same order and even speaks of his fictional characters--such as Curio and Valerius--as if they were real people.

Harris's article (p. 23):

In the same way, every single piece of information given by Jane Evans can be traced to De Wohl's fictional account. She uses his fictional sequences in exactly the same order and even speaks of his fictional characters, such as Curio and Valerius, as if they were real people.

Baker's wording omits the "out" in the first sentence, uses commas instead of hyphens, and doesn't use the italicization, all matching the article rather than the book.

Baker cites neither Harris nor Hines in the notes for chapter 4 of his book. He does mention Melvin Harris twice on the page with no citation and no attributed quotations, including once in the same paragraph as the above quotations. Baker's discussion of other cases earlier in the chapter differs from Hines and Harris--all three discuss Bridey Murphy, but Baker's case is more extensive than Harris or Hines. I suspect his sources may be identifiable from the other references he gives at the end of the book for the chapter.

But when it comes to Baker's discussion of Jane Evans, he engaged in more plagiarism of Hines, as can be seen by comparing his text to Hines and to Harris's article and book. Harris discusses the case extensively on pp. 155-163 of his book, while Hines' and Baker's discussions are each less than two pages long.

Here is what Baker writes (pp. 156-157), with exact word matches with Hines highlighted in yellow, and with Harris' article in orange (and I found no matches to Harris's book which did not also match the article):

The second, and by far the most [Harris: much more] impressive, was the case of a Welsh housewife named Jane Evans, who described six past lives that were remarkable for the tremendous amount of accurate historical detail [Harris: amount of detail] they contained. In one of the lives she was a maid in the house of a wealthy [Baker, p. 157:] and powerful merchant in fifteenth-century France. Mrs. Evans described accurately the house and all of its furnishings in great detail, as well as the members of the merchant's family. She made one very significant error in her account, however. She said the merchant was unmarried [Hines: not married] and had no children. In truth he was married and had five children, circumstances no maid would be unaware of. The same failure to mention wife and children turned up in a novel that had been written about the merchant, titled The Moneyman by Thomas B. Costain (1948). According to Melvin Harris, who investigated the case, the evidence is overwhelming that this book was the source of all of Mrs. Evan's [sic; Hines: basis for Evans's] "memories" of her life in fifteenth-century France.

In another life that she reported, Mrs. Evans was a woman named Livonia, who lived during the Roman occupation of Britain. Her account [Hines: knowledge] of the historical facts of this [Hines: that] period was so accurate that authorities [Harris: authority] on Roman Britain were astounded. Again, however, there were a few factual errors. Her knowledge [Hines: information] of the period was traced to the 1947 best-selling novel The Living Wood by Louis De Wohl. Every single piece of information given by Mrs. Evans could be traced to De Wohl's book, and Mrs. Evans used [Hines, Harris: she uses] his fictional sequences in exactly the same order as he had, and even spoke [Hines, Harris: speaks] of De Wohl's [Hines, Harris: his] fictional characters, Curio and Valerius, as if they had been [Hines, Harris: were] real. The historical errors in Mrs. Evan's [sic] account were also found in the book. As Harris clearly demonstrated, Mrs. Evans had [Harris: had] the ability to store vivid stories in her subconscious and then creatively combine and edit them to the point that [Harris: where] she herself became [Harris: becomes] a [Harris: one of the] character in the story [Harris: involved].

This last sentence is another in which Baker follows Harris's article more closely than his book, which suggests Baker used the article in addition to Hines (who doesn't quote this sentence). Harris's book (p. 161) says "... Jane Evans has the ability to subconsciously store vivid accounts and combine and edit these creatively--to the point where she becomes one of the characters involved." The article (p. 22) says "...Jane Evans has the ability to store vivid stories in her subconscious and creatively combine and edit them to the point where she becomes one of the characters involved."

Overall, Baker follows Hines more closely than Harris, and when there are discrepancies between Harris's article and book, Baker follows the article. While Harris names the maid (Alison), neither Hines nor Baker do. In structure, after introducing the maid, Hines and Baker mention Evans' description of the house and furnishings, but Harris only mentions that after describing Evans' "inside-knowledge of the intrigues surrounding the King's mistress, Agnes Sorel," which Hines and Baker omit. The sentences from Hines and Baker that immediately follow the house and furnishings differ slightly in wording but are strikingly similar:

Hines (p. 73): "Evans' account of her life in Coeur's house contains one most puzzling, and significant error. She says he was not married and had no children. But he was married and had five children--not the sort of thing the maid would be likely to overlook."

Baker (p. 157): "She made one very significant error in her acccount, however. She said the merchant was unmarried and had no children. In truth he was married and had five children, circumstances no maid would be unaware of."

Harris, by contrast, is quite different (p. 22): "In particular, the novel very neatly answers an important question raised by Iverson and other commentators: Why doesn't Alison know that her master is married? As Iverson puts it: 'How is it that this girl can know Coeur had an Egyption bodyslave and not be aware that he was married with five children?--a published fact in every historical account of Coeur's life?...If the explanation for the entire regression is a reading of history books in the twentieth century, then I cannot explain how Bloxham's subject would not know of the marriage.'"

For completeness, here's Harris's book, which differs very slightly (p. 158): "In particular, the novel very neatly answers an important question raised by Iverson and other commentators--a question prompted by the curious fact that Alison does not know that her master is married! As Iverson puts it: 'How is it that this girl can know Coeur had an Egyptian bodyslave and not be aware that he was married with five children?--a fact published in every historical account of Coeur's life? ... If the explanation for the entire regression is a reading of history books in the twentieth century, then I cannot explain how Bloxham's subject would not know of the marriage.'"

In short, Baker plagiarized Hines and Harris, and his explanation is not consistent with the facts, with the truth revealed in much the same way as the truth was revealed about Evans' stories being sourced from fiction.

Next, we turn to Baker's They Call It Hypnosis, where Baker repeatedly plagiarized sources word-for-word without quotation marks, sometimes referencing them in the chapters where used, sometimes not referencing them in the chapter, and sometimes not referencing them at all (see my full report for more examples of each). In these examples, Baker lifts from work by Nicholas P. Spanos, by Spanos and co-author John F. Chaves, and by Irving Kirsch and James R. Council, with his only original contributions being some introductory or connecting phrases and substitution of synonyms. Here is what appears on pp. 129-131 of They Call It Hypnosis, part of chapter three titled "Hypnosis: Recent and Contemporary Views," with highlights indicating word-for-word plagiarism from the sources used:

[Baker, p. 129] Overall, Spanos's position on hypnosis is very clear. He argues that, despite widespread belief to the contrary, hypnotic procedures do not greatly augment responsiveness to suggestions. Nonhypnotic control subjects who have been encouraged to do their best respond just as well as hypnotic subjects to suggestions for pain reduction, amnesia, age regression, hallucination, limb rigidity, etc. Hypnotic procedures, he says, are no more effective than nonhypnotic relaxation procedures at reducing [Spanos: lowering] blood pressure and muscle tension or affecting [Spanos: effecting] other behavioral, physiological, or verbal report indicators of relaxation. Hypnotic procedures are no more effective than various nonhypnotic procedures at enhancing imagery vividness or at facilitating therapeutic change for such problems as chronic pain, phobic response, cigarette smoking, etc. The available scientific evidence that Spanos and his collaborators have compiled fails to support the notion that hypnotic procedures bring about unique or highly unusual states of consciousness or that these procedures facilitate responsiveness to suggestion to any greater extent than nonhypnotic procedures that enhance positive motivation and expectation. [Spanos, p. 175]
Spanos also notes that hypnotic suggestions do not directly instruct the subject to do anything. Instead, they [Spanos: suggestions] are usually phrased in the passive voice and imply that something is happening; for example [Spanos: e.g.], "Your arm is rising," instead of "Raise your arm." The [Spanos: This] passive phrasing communicates the idea that the suggested effects are occurring [Spanos: happening] automatically. In other words, the hypnotic suggestions are really tacit requests to the subject to become [Baker, p. 130 begins:] involved in a make-believe activity. Good hypnotic subjects understand this [Spanos: the implications of these tacit requests] and use their imaginative abilities and acting skills to become absorbed in the make-believe activities [Spanos: scenarios]. Spanos notes that the method actor who throws himself into the role is the analogue of the good hypnotic subject who throws himself [Spanos: themselves] into generating the experiences relevant to his [Spanos: their] role as someone who is hypnotized and responsive to suggestions. [Spanos, pp. 175-176]
Spanos and his collaborators have looked closely at hypnotic age regression and have demonstrated that regressed subjects do not, in any real sense, take on the cognitive, perceptual, or emotional characteristics of actual children. Instead of behaving like real children, age regressed subjects behave the way they believe children behave. To the extent that their expectations about how children behave are inaccurate, their age regression performances also are off the mark. Simply put, age regression suggestions are invitations to become involved in the [Spanos: this] make-believe game of being a child again. People who accept the invitation do not, in any literal sense, revert psychologically to childhood. Instead, they use whatever they know about real children, whatever they remember from their own childhood, to temporarily become absorbed in the fantasy of being a child again. [Spanos, p. 176]
Just as subjects can be given suggestions for age regression, amnesia, or pain reduction, Spanos says they can also be led to believe that they possess "hidden selves." When Hilgard's good hypnotic subjects were told [Spanos: informed] that they possessed hidden selves they normally were unaware of--but to which the experimenter could talk when he gave [Spanos: by giving] the proper [Spanos: appropriate] signals--many of them [Spanos: these subjects], when the signals were given [Spanos: they received], acted [Spanos: behaved] as if they did have alternate egos [Spanos: possessed secondary selves]. Hilgard interpreted this as indicating [Spanos: interpret such findings to mean] that good hypnotic subjects carry around unconscious hidden selves with certain intrinsic, unsuggested characteristics. Spanos counters this by pointing out that the evidence shows these [Spanos: indicates instead that] so-called hidden selves are neither intrinsic to hypnotic procedures nor unsuggested. On the contrary, hidden self-performances--like other suggested responses--appear to reflect attempts by motivated and imaginative subjects to create the experiences and role-play the behaviors [Spanos: role behaviors] called for by the instructions they are given. By the experimenter varying these [Spanos: such] instructions, the subjects can be easily led to develop hidden selves with whatever characteristics the experimenters desire [Spanos: wish]. Depending upon the instructions given, good hypnotic subjects will act out [Spanos: enact] hidden selves reporting [Spanos: that report] very high levels of pain, very low levels of pain, or both high and low levels of pain in succession. Subjects can also be led to act as if they possess hidden selves that can remember concrete but not abstract words, or the opposite; or they can report seeing [Spanos: that see] stimuli accurately, seeing them [Spanos: see stimuli] in reverse, or not seeing them [Spanos: don't see stimuli] at all; as the experimenter wishes. In short, the subjects are [Spanos: subject is] acting out a fantasy which is initiated by the suggestions of the hypnotist. Then the fantasy is imaginatively elaborated upon and sustained by the subject and his interactions with the hypnotist. [Spanos, pp. 176-177]

[Baker, p. 131 begins:] Spanos has also carried out studies of past-life regression, and in agreement with the findings of other researchers, his work indicates that past-life reports from hypnotically regressed subjects are fantasy constructions of imaginative subjects who are willing to become absorbed in the make-believe situation implied by the regression suggestions. As expected, subjects who responded well to other hypnotic suggestions were the most likely to respond well to regression suggestions. Those with the most practice at vivid daydreaming and everyday fantasizing, i.e., the fantasy-prone, created the most vivid past-life fantasies. In the same manner as childhood regressees, past-life reporters incorporate historical misinformation into their past lives [Spanos: -life enactments]. Those who from the outset believed in reincarnation thought their past lives were true [Spanos: -life experiences were veridical] rather than imaginary. A lengthier discussion of this topic and other paranormal hypnotic beliefs will be found in a later chapter. [Spanos, p. 179]

By no means, however, does Spanos see the problem of hypnosis as solved. New knowledge leads us to new unknowns and in the well-known and pronounced effects of suggestion on the human body there are many unsolved problems. The suggestion-induced disappearance of warts, for example, is just such a dilemma. Spanos's own work has shown that neither a hypnotic induction nor preliminary instructions for relaxation add to the effectiveness of imagery-based suggestions in producing wart regression. Nor can the effects of suggestion be accounted for simply in terms of enhanced expectancies. Subjects given placebos and those given suggestions reported equivalent expectations of treatment success, but the suggestions were much more effective than the placebos in [Spanos & Chaves: at] producing wart regression. The suggestions, however, were not effective with all the subjects. They were most effective, Spanos reports, with subjects who had [Spanos & Chaves: possessed] multiple warts rather than [Spanos & Chaves: as opposed to] single warts. Those who rated their suggested imagery as especially [Spanos & Chaves: relatively] vivid also had better results. [Spanos & Chaves, pp. 445-446]

At this point, Baker says "Spanos concludes that" followed by a large block of correctly cited and quoted text from Spanos & Chaves p. 446 that fills the rest of p. 131, with a concluding sentence on p. 132 that appears to be original. Baker goes on in pp. 132-134 to describes the views of Irving Kirsch under the heading "Irving Kirsch and Response Expectancy in Hypnotic Behavior," with an original opening paragraph that cites Irving Kirsch, "Response expectancy as a determinant of experience and behavior," American Psychologist 1985, vol. 40, pp. 1189-1202, a source he does not plagiarize. But he goes on to plagiarize a source that he cites nowhere in his book, Kirsch & Council's chapter from Spanos & Chaves' book (which book he does list as a reference at the end of the chapter, but doesn't cite in the section). There is more original content in this section, and more extensive rewriting, but the level of plagiarism increases as it goes on:

[Baker, p. 132:] In the latter part of the nineteenth century, Albert Moll argued [Kirsch & Council, p. 360: maintained] that hypnotic behavior was determined by two basic principles: 1) people [Kirsch & Council, quoting Moss, 1897, p. 241: men] have a certain proneness to allow themselves to be influenced by others through their ideas, and in particular, to believe much without making conscious logical deductions; 2) a psychological effect tends to appear in a person [Kirsch & Council, quoting Moss, 1897: man] if he is expecting it. Moll also was able to cause his [Kirsch & Council: elicit hallucinations by leading] blindfolded subjects to hallucinate when he told them [Kirsch & Council: to believe] they were being mesmerized.

Moll's giving expectancy a role in the production of hypnotic phenomena anticipated Kirsch's thinking that response expectancies cause [Kirsch & Council, p. 361: generate corresponding] the individual to have internal subjective experiences which then cause [Kirsch & Council: and their] behavior [Kirsch & Council: behavioral and physiological correlates]. A very clear [Kirsch & Council: particularly apparent] example of this is the placebo effect. When the patient is given a sugar pill but is told or believes it is a powerful pain killer, miraculously, because of his expectancies, the pain goes away! As for hypnosis, according to Kirsch, the occurrence of a hypnotic response is a function of the subject's expectancy that it will occur. Once the subject has learned how a hypnotized subject is supposed to react and what he can expect to happen when he is hypnotized, then the hypnotic responses occur automatically, i.e., without conscious effort on the subject's part. Emotional reactions--fear, sadness, sexual arousal, pain--are good examples of automatic responses. Acrophobics, for example, will avoid tall buildings, cliffs, ferris wheels, etc., because of their expectancy that not doing so would result in a panic attack.

Various other evidence [Kirsch & Council, p. 362: A considerable body of data] is available to demonstrate that automatic [Kirsch & Council: nonvolitional] responses can be brought about [Kirsch & Council: elicited] by the mere expectancy of their occurrence. Both hypnosis and placebos are effective in treating pain, skin conditions, and asthma, and it seems reasonable to assume that the same mechanism, namely, response expectancy, produces these responses in both hypnosis [Baker, p. 133:] and the nonhypnosis situations. Telling subjects [Kirsch & Council, p. 364: informing them] they have received [Kirsch & Council: were ingesting] a psychedelic drug that will produce hallucinations causes about half [Kirsch & Council: 50 percent] to report visions, even though no drug was given. Subjects [Kirsch & Council: people] who are told that hypnotized subjects can't move their [Kirsch & Council: display catalepsy of the] dominant arm are likely to experience this effect when hypnotized, and being told [Kirsch & Council: informed] that inability to remember, i.e., spontaneous amnesia, is characteristic of hypnosis significantly increases the likelihood of its occurrence. When subjects were told that either the ability or the inability to resist responding to suggestions was characteristic of deep hypnosis, they responded accordingly.

Besides affecting overt responses, role perceptions are an important determinant of self-reported experiences of altered states of consciousness. In a number [Kirsch & Council, p. 365: series] of studies it was shown [Kirsch & Council: this has been convincingly demonstrated] that the degree of change in state of consciousness subjects expected to experience significantly predicted the number of unsuggested alterations in experience they subsequently reported. Moreover, the data from these studies indicate [Kirsch & Council, p. 366: suggest] that no particular state of consciousness can be labeled a "hypnotic trance." Rather, a variety of changes in experience are interpreted by the subject as evidence of trance when experienced in a hypnotic context. Some of these are directly suggested in typical hypnotic induction--relaxation, for example [Kirsch & Council, p. 367: e.g.]--whereas others occur as a function of the subject's preconceptions. How the subject perceives the situation pretty much determines how effective the situation will be in producing hypnosis. Just hearing the words, "You are becoming very, very relaxed," is enough in our culture to make most people think [Kirsch & Council, p. 368: evokes the idea] of hypnosis. Glass and Barber (1961) a few years ago set up [Kirsch & Council: devised] a highly credible clinical environment and told subjects an inert pill was a powerful hypnotic drug which would produce a state of hypnosis. In this setting the pill was as effective as a standard hypnotic induction procedure in effecting [Kirsch & Council: raising levels of] the subject's responses to suggestion.

The rest of p. 133 of Baker is two original sentences that introduce a large block of text (five full sentences) properly identified as quotation and attributed to the Spanos & Chaves book without a page reference; it is from p. 371 in the Kirsch & Council chapter. Baker p. 134 completes the Kirsch section:

According to Kirsch's [Kirsch & Council, p. 371: expectancy] theory, the probability of occurrence of a nonvolitional response varies directly with the strength of the expectancy of the occurrence and inversely with the magnitude or difficulty of the expected response. [Baker has removed Kirsch & Council's quotation marks before "the probability"; the rest of the sentence is a direct quote from Kirsch's 1985 paper.]

Trance induction procedures are, of course, typically designed to increase the subject's expectancies for responding to suggestions, and in the Ericksonian approach [Kirsch & Council: clinical practice] the hypnotist tailors his induction to the characteristics and ongoing behavior of the client [Kirsch & Council: individual subjects]. Kirsch sees most hypnotic induction procedures as merely expectancy modification procedures.

Kirsch's response expectancy theory [Kirsch & Council, p. 374: hypothesis] is generally consistent with the nonstate theories of Sarbin, Barber, Wagstaff, and Spanos. All agree that hypnotic responses are best seen [Kirsch & Council: can be conceptualized] as compliance, belief, and imagination [Kirsch & Council: believed-in imaginings], and that the hypnosis experience occurs when people voluntarily play [Kirsch & Council: take on] the role of hypnotic subject. One key difference between Kirsch's theory and others is that his response expectancies are the immediate causes of the hypnotic response. Rather than having goal-directed images enhancing hypnosis, as Barber suggests, Kirsch has shown that the imagery enhances responsiveness by virtue of its effects on expectancy. Kirsch has also shown that not all so-called hypnotic phenomena are under a subject's will power or self-control [Kirsch & Council, p. 378: cannot be fully accounted for as volitional behavior]. Warts, for example, can be affected both by placebos and by hypnosis, and such changes in skin conditions are not under one's voluntary control. Kirsch notes that one could offer subjects a substantial sum of money to make their warts disappear, but it is highly unlikely that many subjects would be able to do so.

This phenomenon also clearly shows [Kirsch & Council, p. 378: demonstrates] the commonality between hypnosis [Kirsch & Council: hypnotic phenomena] and placebo effects. Both are examples of the nonvolitional nature of response expectancy effects. Kirsch's observation raises another point of significance--the fact that we must realize that not everything that happens to the human being as a result of external stimulation is or should be considered hypnosis! Suggestion is a very powerful influence on human behavior and it can influence human behavior in many different ways, only a very few of which we would or should designate as "hypnotic."

Yellow highlight: Nicholas P. Spanos, "Past-Life Hypnotic Regression: A Critical View," Skeptical Inquirer vol. 12, no. 2, Winter 1987-88, pp. 174-180. Not listed as a reference in chapter three, but is listed as a reference in chapter six.

Orange highlight: Nicholas P. Spanos and John F. Chaves, Hypnosis: The Cognitive-Behavioral Perspective, 1989, Prometheus Books. This is listed as a reference in chapter three, but is not cited in the section where it is plagiarized, but instead on p. 129 a few paragraphs before the plagiarism of the Spanos SI article (yellow highlight).

Green highlight: Irving Kirsch and James R. Council, "Response Expectancy as a Determinant of Hypnotic Behavior," in Spanos & Chaves (1989), pp. 360-379. This chapter is not listed as a reference in the book.

I reviewed Baker's They Call It Hypnosis for Amazon.com on November 18, 1996, and gave it four stars; I might subtract another star today and say more about its giving state theories short shrift, but otherwise I still agree with this:

This book is an excellent summary of theories of hypnosis
with an emphasis on criticisms of state theories. The
author argues for social/cognitive non-state theories.
The book is marred only by the fact that many passages
are lifted directly from the authors being summarized,
without being noted as such.

Finally, here is the definition of research misconduct from the University of Kentucky's "Policy on Ethical Standards and Misconduct in Research" (64.0 AR II-4.0-2) from 1992:

Research "misconduct", as used herein, is defined as plagiarism; 
fabrication or intentional falsification of data, research procedures or 
data analysis; or other deliberate misrepresentation in proposing, 
conducting, reporting, or reviewing research.  It does not include 
honest error or honest differences in interpretations or judgments of 
data.  In cases of allegations involving activities submitted to or 
supported by a federal agency, the definition for misconduct specified 
in the agency's regulations will apply.

This policy was referenced in the faculty handbook section on "The Conduct of Research" in the paragraph on "Ethical Standards"; these are quoted more extensively in my full report. Baker was certainly aware of these in substance, as the following appears on p. 297 of Robert A. Baker and Joe Nickell's book, Missing Pieces: How to Investigate Ghosts, UFOs, Psychics, and Other Mysteries (1992, Prometheus Books):

Another question that is bound to arise has to do with rewriting and 
paraphrasing.  The courts once again have uniformly decided that it 
makes no difference whether the plagiarizer changes the arrangement of 
the original words or not--rewriting the material is not sufficient to 
aid the charge of infringement. ... More importantly, even if the use of 
the words and statements of another is totally honest, unintentional, or 
subconscious, it is still prohibited.  Neither forgetfulness nor 
ignorance is regarded as a legitimate excuse.  If, however, it was an 
honest and unintentional mistake, and no intent to plagiarize was in 
mind, the infringer usually gets off with a lesser punishment.

Baker's response to these allegations was at first to attack and concede nothing. He suggested that he was going to sue me for defamation, and enlisted the help of others who attempted to discredit me (see my letter to Tucson skeptic James McGaha). Ultimately, after psychologist Terence Hines, another prominent skeptic, was prepared to submit his book review of Baker's Hidden Memories, rejected by Skeptical Inquirer, to competing publication Skeptic magazine, SI editor Kendrick Frazier relented and published the review along with Baker's reply. Baker fell back to the claim that his plagiarism was minor and unintentional, while resorting to falsehoods to attempt to prop up that explanation, as explained above. At this point, CSICOP founder and Prometheus Books head Paul Kurtz sent me a letter stating that Hidden Memories had been pulled from distribution and would not be reissued until corrections had been made; I replied noting that there were bigger problems in They Call It Hypnosis, but received no response.

Robert Baker was added to the Committee for Skeptical Inquiry's Pantheon of Skeptics honoring distinguished Fellows of the organization on its creation in 2011.

Skeptical Inquirer and Wikipedia, at least to date, both gave Baker's falsehoods the final word. And perhaps the more interesting back story here is that Wikipedia is wrong because Skeptical Inquirer is wrong, but the reason Wikipedia only even mentioned Baker's plagiarism at all in December 2023 is because a Wikipedia editor with no dog in the fight, "Psychologist Guy," intervened and restored an old edit of the article to include the mention, which had been removed in 2018 by another Wikipedia editor, "Niomart," with the false justification that "No valid source substantiating plagiarism claims".

As the Internet becomes more and more filled with AI-generated content, there will be sources with superficial plausibility generated by large language models, there will be sources that are human-curated and based on genuine research and fact-checking, and there will be sources that are human-curated and ideologically driven that settle on acceptable half-truths concealing messy details. OpenAI's ChatGPT 3.5 says it knows nothing of plagiarism by Robert A. Baker:

Did Robert A. Baker's 1992 book, Hidden Memories (pp. 156-157), plagiarize from Terence Hines' 1988 book Investigating the Unexplained (pp. 73-75)?

As of my last knowledge update in January 2022, I do not have specific information regarding an allegation of plagiarism between Robert A. Baker's book "Hidden Memories" and Terence Hines' book "Investigating the Unexplained" related to the pages specified. Therefore, I cannot definitively answer whether Baker's book plagiarized from Hines' book.

To investigate this further and obtain accurate information, I would recommend checking scholarly resources, academic databases, or reputable sources that discuss these books and any related allegations of plagiarism. You might also look into academic discussions or reviews of both books to see if there are any mentions of such accusations and their resolution.

Google Gemini quotes from and cites Wikipedia as the final word:

Was Robert A. Baker ever accused of plagiarism, or of failure to properly cite quotations and sources?

Yes, Robert A. Baker did face accusations of plagiarism in the past according to his Wikipedia page [Robert A. Baker Wikipedia].

Here's a summary of the incidents:

In 1994, readers of Skeptical Inquirer identified similarities between Baker's article and another author's work. Baker apologized, claiming it was an oversight.

The following year, another author pointed out unattributed quotes in Baker's writing. Baker defended himself by saying he used the original source but forgot quotation marks.

Bill Frist's cat-killing story

2024-05-05T09:45:00.002-07:00

After adding a post about Kristi Noem's dog-killing story, I realized I hadn't mentioned former House Majority Leader Bill Frist's (R-TN) cat-killing story. Jeff Woods gave a quick overview of the story, which appeared in Frist's 1989 autobiography, Transplant, in his review of Frist's later book in The Nashville Scene in 2009:

Never say Frist doesn't learn from his mistakes. In his 1989 autobiography Transplant, he admitted that as a medical student he adopted cats from animal shelters, "treat[ed] them like pets for a few days," then took them to a lab to die in research experiments. He blamed this conduct on the pressures of med school.
"And I was totally schizoid about the entire matter," Frist wrote. "By day, I was little Billy Frist, the boy who lived on Bowling Avenue in Nashville and had decided to become a doctor because of his gentle father and a dog named Scratchy. By night, I was Dr. William Harrison Frist, future cardiothoracic surgeon, who was not going to let a few sentiments about cute, furry little creatures stand in the way of his career. In short, I was going a little crazy."
That bit of honesty cost Frist no little embarrassment in his 1994 Senate campaign, when he was mocked as a cat killer.

Kristi Noem's dog-killing story

2024-05-05T09:38:00.010-07:00

Before the release of South Dakota Governor (and prospective Trump VP running mate) Kristi Noem's book, No Going Back: The Truth on What's Wrong With Politics and How We Move America Forward, the Guardian published an account of her story in the book of becoming angered with her 14-month-old family dog Cricket when it (running loose off-leash) killed a farmer's chickens. She took the dog to a gravel pit and shot and killed it, and then, for good measure, decided to kill a goat as well. She wrote that the dog was "untrainable" and that she "hated that dog." She proudly described this impulsive act of killing a family pet without consulting with her family and in an inhumane manner as an illustration of her willingness to deal with things that are "difficult, messy, and ugly." But her first response to the Guardian story was to call it "fake news," then to defend herself by claiming that the dog was "a working dog and not a puppy. It was a dog that was extremely dangerous."

Subsequently, she did the opposite of her book title by retracting a story from the book that she had "stared down" Kim Jong Un when she met him, after a Noem spokesperson said she never met Kim Jong Un. Her book also claimed that she had cancelled a meeting with France's President Emmanuel Macron, whose staff said she never had a meeting scheduled with him.

As a result of this story, I've created a tag on this blog for "conservative animal abuse" since several previous examples were covered here going back to 2007.

If embryos are babies, then in-vitro fertilization is immoral

2024-02-29T06:33:00.002-07:00

Alabama and the GOP are discovering what this blog pointed out 15 years ago--if you're going to adopt a policy that embryos are full bearers of moral personhood, then you can't allow in-vitro fertilization (IVF). From my five-part debate with Vocab Malone about abortion in 2009:

Once the zygote becomes a blastocyst, it forms into an outer layer of cells, which later becomes the placenta, and an inner cell mass of pluripotent embryonic stem cells, each of which is capable of differentiating into any kind of human cell. Only after this stage does the blastocyst implant in the wall of the uterus, about a week after fertilization, and begin taking nutrients directly from the blood of the mother--a dependency that can itself be of moral significance, as Judith Jarvis Thomson's violinist argument shows. As already mentioned above, a great many fertilized ova do not reach this stage. Further, the percentages of implant failure are higher for in vitro fertilization (IVF), a procedure which Vocab's criteria would have to declare unethical, even though it is the only way that many couples can have their own biological offspring.

I made the same point earlier in a comment on a podcast interview with atheist anti-abortion advocate Jen Roth (comments are no longer present but I reiterated it in response to Malone):

Was Jen Roth ultimately arguing that personhood is something that a human organism has for its entire lifecycle? At what starting point? Conception, implantation, or something else?

I find it completely implausible that an organism at a life stage with no capacity for perception, let alone reason, counts as a person. Nor that a particular genetic code is either necessary or sufficient for personhood.

I think every point that she made was brought up in a debate I had with a Christian blogger on the topic of abortion, who similarly argued for an equation between personhood and human organism. I wonder if she has any better rejoinders. Does she think that IVF and therapeutic cloning are immoral? IUDs?

The naive anti-abortion position is philosophically and scientifically unsupportable and leads to bad public policy, and today's GOP consists of a majority struggling to avoid it and a minority that is full-steam ahead and prepared to ban IVF and contraception.

The full debate between Vocab Malone and myself was spread across our respective blogs. My contributions were:

Vocab Malone on abortion and personhood, part 1 (December 11, 2009)

Vocab Malone on abortion and personhood, part 2 (December 13, 2009)

Vocab Malone on abortion and personhood, part 3 (December 16, 2009)

Vocab Malone on abortion and personhood, part 4 (December 18, 2009)

Vocab Malone on abortion and personhood, part 5 (December 19, 2009)

And, finally, perhaps most apt to the current situation, was this exchange from the following year:

Does Vocab Malone understand the implications of his own position? (November 15, 2010)

Vocab's response is that he does think IVF is immoral, except perhaps for some hypothetical version he doesn't describe, that perhaps involves adopting all the "snowflake babies" and removing and reimplanting excessive multiple births into surrogates. (But that still doesn't address the implantation failure rate!)

Books read in 2023

2024-01-01T07:00:00.000-07:00

Not much blogging going on here still, but here's my annual list of books read for 2023.

Angel Au-Yeung and David Jeans, Wonder Boy: Tony Hsieh, Zappos, and the Myth of Happiness in Silicon Valley
Isaac Butler, The Method: How the Twentieth Century Learned to Act (2022)
Cory Doctorow, Red Team Blues (fiction)
David Edmonds, Parfit: A Philosopher and His Mission to Save Morality
Zeke Faux, Number Go Up: Inside Crypto's Wild Rise and Staggering Fall
Kevin Fedarko, The Emerald Mile: The Epic Story of the Fastest Ride in History Through the Heart of the Grand Canyon (2013)
Roger Friedland and Harold Zellman, The Fellowship: The Untold Story of Frank Lloyd Wright & The Taliesin Fellowship (2006)
James Gleick, The Information: A History, A Theory, A Flood (2011)
Penn Jillette, Random (2022) (fiction)
Mark Holloway, Utopian Communities in America, 1680-1880 (1966, 2nd edition, 1st edition was titled Heavens on Earth)
Claire Hughes Johnson, Scaling People: Tactics for Management and Company Building (2022)
R.A. Lafferty, The Best of R.A. Lafferty (2019) (fiction)
Kevin M. Levin, Searching for Black Confederates: The Civil War's Most Persistent Myth (2019)
Michael Lewis, Going Infinite: The Rise and Fall of a New Tycoon
Shane Murphy, John Hance: The Life, Lies, and Legend of Grand Canyon's Greatest Storyteller (2020)
Erik Reece, Utopia Drive: A Road Trip Through America's Most Radical Idea (2016)
Rudy Rucker and Bruce Sterling, Transreal Cyberpunk (2016) (fiction)
Chris A. Rutkowski, Canada's UFOs Declassified (2022)
Christa Sadler, editor, There's This River... Grand Canyon Boatman Stories (2nd ed., 2006)
Bruce Schneier, A Hacker's Mind: How the Powerful Bend Society's Rules, and How to Bend them Back
Will Sommer, Trust the Plan: The Rise of QAnon and the Conspiracy That Unhinged America
Katherine Stewart, The Power Worshippers: Inside the Dangerous Rise of Religious Nationalism (2019)
Leonie Swann, Three Bags Full: A Sheep Detective Story (2005) (fiction)
Stephen Vladeck, The Shadow Docket: How the Supreme Court Uses Stealth Rulings to Amass Power and Undermine the Republic
Simon Winchester, Knowing What We Know: The Transmission of Knowledge: From Ancient Wisdom to Modern Magic
Tom Zoellner, Rim to River: Looking into the Heart of Arizona
Final Report of the Select Committee to Investigate the January 6th Attack on the United States Capitol

Top for 2023 published in 2023: Edmonds, Zoellner, Sommer, Vladeck, Faux; other top reads for the year: Swann, Stewart, Friedland & Zellman, Edmonds, Lafferty, Holloway

A few planned reads for 2024 (already in progress):

G.A. Cohen, Self-Ownership, Freedom, and Equality (1995)

John Ferris, Behind the Enigma: The Authorised History of GCHQ, Britain's Secret Cyber-Intelligence Agency (2020)

Chris Rodda, Liars for Jesus: The Religious Right's Alternate Version of American History, vol. 2 (2016)

Peter H. Wilson, The Holy Roman Empire: A Thousand Years of Europe's History (2017)

The Economist posted this chart of number of books read this year from a YouGov/Economist survey:

(Previously: 2022, 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.)

A short conversation with ChatGPT about the Grand Canyon

2023-07-06T18:50:00.004-07:00

ChatGPT does fairly well with this, though its selected points don't include any of the more obscure points of interest, it's skewed to the popular highlights. Its claim that there weren't any historic crossings is pretty odd.

What are some of the most beautiful and interesting locations in the Grand Canyon along the Colorado River?

The Grand Canyon offers numerous beautiful and interesting locations along the Colorado River. Here are some notable ones:

Havasu Creek: Located on the western side of the Grand Canyon, Havasu Creek is famous for its turquoise-blue waterfalls and pools. The stunning Havasu Falls, Mooney Falls, and Beaver Falls are among the main attractions.
Phantom Ranch: Situated at the bottom of the Grand Canyon, Phantom Ranch is a historic oasis accessible only by hiking or rafting. It provides a unique lodging option and serves as a hub for various hiking trails and activities.
Bright Angel Trail: This popular hiking trail descends from the South Rim down to the Colorado River. It offers breathtaking views of the canyon's layers, geological formations, and the river itself.
Hermit Rapids: Known for their tumultuous whitewater, the Hermit Rapids offer a thrilling experience for river rafting enthusiasts. These rapids are located in a remote and scenic section of the canyon.
Deer Creek Falls: Nestled in a picturesque alcove, Deer Creek Falls is a stunning waterfall that drops into a deep pool. The location also features the Deer Creek Narrows, a beautiful slot canyon to explore.
Lava Falls: Considered one of the most challenging and exciting rapids in the entire Grand Canyon, Lava Falls is a thrilling spot for experienced river runners. It provides an adrenaline-pumping adventure as you navigate through the turbulent waters.
Nankoweap Rapids: Located in a less visited area of the Grand Canyon, Nankoweap Rapids offer a mix of exciting rapids and serene camping spots. The views from Nankoweap Trail, which descends to the river, are awe-inspiring.
Redwall Cavern: This enormous natural amphitheater-like feature is carved into the Redwall Limestone cliffs. It offers a unique camping and picnic spot along the river, where groups can gather and enjoy the stunning surroundings.

Remember that exploring the Grand Canyon and its Colorado River region requires careful planning, permits, and appropriate equipment. Whether you choose to hike, raft, or simply admire the beauty from the rim, always prioritize safety and follow any guidelines or regulations set by the National Park Service.

What are some interesting human artifacts that are left behind within the Grand Canyon, either by native Americans from hundreds of years ago, from the late 19th century, or even from the 20th or 21st century?

The Grand Canyon has a rich cultural history, and various human artifacts have been left behind by different groups over the centuries. Here are some interesting examples:

Native American Petroglyphs and Pictographs: The canyon is home to numerous petroglyphs and pictographs created by Native American tribes who inhabited the area for thousands of years. These rock art sites provide glimpses into their cultural and spiritual practices. Key locations include the Bright Angel and Hermit Trails, Palatki Heritage Site, and Nankoweap Canyon.
Tusayan Ruins: Located on the South Rim, the Tusayan Ruins are the remnants of a Puebloan village that was inhabited around 800 years ago. The site includes a partially reconstructed dwelling and offers insights into the lives of the ancient inhabitants.
Historic Mining Sites: In the late 19th century, prospectors and miners ventured into the Grand Canyon in search of minerals and ores. Remnants of their activities, such as old mine shafts, rusted equipment, and structures, can still be found in certain areas, like the Bright Angel and South Kaibab Trails.
Grand Canyon Village: Established in the early 20th century, Grand Canyon Village is a historic district that features buildings constructed by the National Park Service and the Santa Fe Railroad. Many of these structures, including the El Tovar Hotel, Hopi House, and Bright Angel Lodge, reflect early 20th-century architecture and offer a glimpse into the region's tourism history.
Glen Canyon Dam: Although not within the boundaries of the Grand Canyon National Park, the construction of the Glen Canyon Dam in the 20th century significantly impacted the Colorado River and the Grand Canyon ecosystem. The dam created Lake Powell and led to the formation of many archaeological sites that were excavated before being flooded.
Modern Graffiti: Unfortunately, in recent years, some individuals have left behind graffiti or unauthorized markings on rock formations within the Grand Canyon. These acts of vandalism are strongly discouraged and are detrimental to the preservation of the natural and cultural heritage of the park.

It's important to note that many artifacts and sites within the Grand Canyon are protected by law, and it is illegal to disturb or remove them. Visitors should always respect and preserve these cultural treasures for future generations to enjoy.

What are some of the historic mining sites in the Grand Canyon?

The Grand Canyon has several historic mining sites that reflect the mining activities that took place in the late 19th and early 20th centuries. Here are a few notable mining sites within the Grand Canyon:

Orphan Mine: Located near the South Rim of the Grand Canyon, the Orphan Mine was an early copper mine that operated from the late 19th century until 1931. It produced copper ore, and remnants of mining structures and equipment can still be seen in the area.
Grandview Mine: Situated on the South Rim, the Grandview Mine was one of the most productive copper mines in the region during its operation from 1890 to 1901. Today, hikers can explore the remnants of the mine, including the rusting headframe and a few structures.
Hermit Mine: The Hermit Mine was established in the early 20th century and operated intermittently until the 1930s. It primarily targeted gold and copper deposits. The mine is located in the Hermit Creek drainage, and visitors can still see remnants of mining equipment and tunnels in the area.
Copper Canyon Mining District: Located in the western portion of the Grand Canyon, the Copper Canyon Mining District was active from the late 19th century to the early 20th century. It included several mines, such as the Copper Canyon Mine, the Cave Mine, and the Hidden Treasure Mine. These mines produced copper, gold, and silver ores.
Bass Lode Mine: Situated near the North Rim of the Grand Canyon, the Bass Lode Mine was an early 20th-century mine that primarily targeted copper deposits. While the mine itself is closed and inaccessible, visitors can observe remnants of the mining operations, including the stone walls and tailings.

When visiting these mining sites, it's important to remember that they are historic and protected areas. It is prohibited to remove artifacts or disturb the sites in any way. Respect the history and heritage of these mining sites by observing them from a distance and leaving everything as you find it.

What ferry or bridge crossings are there across the Grand Canyon?

As of my knowledge cutoff in September 2021, there are no ferry or bridge crossings available across the Grand Canyon itself. The Grand Canyon is a vast and rugged landscape, and the Colorado River cuts through it, making it challenging to establish direct crossings. The sheer size and depth of the canyon make traditional ferry or bridge crossings impractical.

However, there are transportation options available to cross the Colorado River in certain areas near the Grand Canyon:

Navajo Bridge: The Navajo Bridge is located northeast of the Grand Canyon National Park near the town of Marble Canyon. It provides a highway crossing over the Colorado River and connects Highway 89A. The original historic bridge, known as the Old Navajo Bridge, is now open to pedestrians and offers scenic views of the canyon.
Glen Canyon Dam Bridge: Located downstream from the Grand Canyon, near Page, Arizona, the Glen Canyon Dam Bridge carries U.S. Route 89 across the Colorado River. It provides a vital transportation link between Arizona and Utah, offering scenic views of Glen Canyon and Lake Powell.
Hualapai Tribe Helicopter Tours: The Hualapai Tribe, based on the western rim of the Grand Canyon, operates helicopter tours that provide aerial crossings of the canyon. These tours offer visitors a unique perspective and the opportunity to witness the breathtaking beauty of the Grand Canyon from above.

It's important to note that ferry or bridge crossings directly across the Grand Canyon are not available due to the rugged and protected nature of the park. Visitors typically explore the canyon by hiking its trails, taking scenic drives along the rim, or participating in guided rafting trips along the Colorado River within the canyon itself.

What historic bridge, ferry, or tram crossings have existed across the Grand Canyon which are no longer present, active, or usable?

To the best of my knowledge, there have been no historic bridge, ferry, or tram crossings across the Grand Canyon that are no longer present, active, or usable. Due to the challenging terrain and the vastness of the canyon itself, constructing and maintaining permanent crossings has proven to be extremely difficult.

Throughout history, there have been proposals and ideas for various types of crossings, but none of them have come to fruition. The natural obstacles posed by the deep and rugged canyon, as well as the commitment to preserving the natural beauty and integrity of the Grand Canyon, have prevented the establishment of permanent crossings.

It's worth mentioning that some temporary or seasonal crossings, such as cable trams, may have been used by specific expeditions, research projects, or construction activities in the past. However, these were typically temporary solutions and not long-lasting or widely accessible crossings.

As of my knowledge cutoff in September 2021, there are no documented historic bridge, ferry, or tram crossings that were once in place across the Grand Canyon.

What about the Bass Camp crossing, Lee's Ferry, or the U.S. Guano tramway crossing?

Apologies for the oversight in my previous response. You are correct, and I appreciate you pointing out these specific crossings. Here's some information about them:

Bass Camp Crossing: Bass Camp Crossing was a historic crossing on the Colorado River, located downstream from the confluence of the Little Colorado River with the Colorado River. It was primarily used by miners and prospectors in the late 19th and early 20th centuries to access mining areas along the river. However, it was not a formal bridge or ferry crossing but rather a ford where travelers crossed the river on horseback or with wagons.
Lee's Ferry: Lee's Ferry, located in northern Arizona, was an important historic river crossing on the Colorado River. It served as a transportation hub for early settlers, explorers, and miners traveling to and from the Colorado Plateau. John D. Lee operated a ferry service at this site from 1872 to 1910, providing a means of crossing the river for people, livestock, and goods. The area is now part of Glen Canyon National Recreation Area and is known for its scenic beauty and historical significance.
U.S. Guano Tramway Crossing: The U.S. Guano Tramway Crossing refers to a historic tramway system that was used to transport guano (bird droppings) from the caves located on the rim of the Grand Canyon. The tramway carried the guano across the canyon to the river, where it was loaded onto boats for further transport. The tramway operated in the early 20th century, but it is no longer in use.

These crossings played significant roles in the exploration, settlement, and mining activities in the region during different periods of history. While they may not be active or in use today, they hold historical significance and contribute to the overall cultural heritage of the Grand Canyon area.

AI vs. CEOs on Destroying the World

2023-06-15T12:47:00.005-07:00

After seeing a CNN headline "Exclusive: 42% of CEOs say AI could destroy humanity in five to ten years," I thought it was only fair to get an AI opinion in response. Turns out, 50% of AIs consulted said CEOs of large corporations could destroy the world in five to ten years.

Google Bard:

How likely is it that CEOs of large corporations will destroy the world in the next five to ten years?

The likelihood of CEOs of large corporations destroying the world in the next five to ten years is low, but not impossible. The biggest threats to the planet come from climate change, pollution, and resource depletion. These are all problems that are caused by the activities of large corporations, and if they are not addressed, they could lead to catastrophic consequences.

However, there are also many CEOs who are committed to sustainability and environmental protection. These CEOs are working to develop new technologies, products, and practices that will help to reduce our impact on the planet. If these efforts are successful, it is possible to avoid the worst-case scenarios and create a more sustainable future.

Ultimately, the fate of the planet will depend on the actions of both CEOs and consumers. CEOs have the power to make decisions that will have a big impact on the environment. Consumers have the power to choose products and services that are produced in a sustainable way. If we all work together, we can create a future where the planet is healthy and prosperous for all.

Here are some of the things that CEOs can do to help protect the planet:

Invest in renewable energy and energy efficiency
Reduce their reliance on fossil fuels
Eliminate waste
Protect forests and other natural resources
Promote sustainable agriculture
Support policies that protect the environment

Here are some of the things that consumers can do to help protect the planet:

Choose products and services that are produced in a sustainable way
Reduce their consumption of energy and resources
Recycle and compost
Support sustainable businesses
Get involved in environmental activism

By working together, we can create a more sustainable future for the planet.

ChatGPT:

How likely is it that CEOs of large corporations will destroy the world in the next five to ten years?

It is highly unlikely that CEOs of large corporations will intentionally "destroy the world" in the next five to ten years or at any other time. While it is true that some corporations and business leaders have engaged in unethical practices or made decisions that have had negative consequences for the environment or society, it is important to note that the vast majority of CEOs strive to run their companies responsibly and ethically.

In recent years, there has been an increasing focus on corporate social responsibility and sustainability, with many companies adopting measures to reduce their environmental impact and contribute positively to society. Additionally, regulatory bodies and public scrutiny play a role in holding corporations accountable for their actions.

It is essential to encourage responsible business practices, promote transparency, and hold corporations accountable for any harmful actions. However, it is overly simplistic and unfair to attribute the potential destruction of the world solely to CEOs of large corporations. Addressing global challenges requires collaborative efforts from governments, businesses, communities, and individuals working together towards sustainable solutions.

Google Bard on file system immutability flags in OpenBSD

2023-04-19T14:11:00.003-07:00

Unlike ChatGPT, Bard pretty much nailed it on the initial prompt. (However, Bard refused to answer my questions about the Mars Effect like the ones I gave to ChatGPT, even when reworded to be clear I was asking for descriptions of what the effect is and what explanations are offered rather than asking it to identify causes itself.)

It does lose points for grammar in the second sentence, though!

write a few paragraphs explaining immutable flags in OpenBSD including the commands for setting them and the difference between system and user immutable flags

Sure. Here is a few paragraphs explaining immutable flags in OpenBSD, including the commands for setting them and the difference between system and user immutable flags.

Immutable Flags

Immutable flags are a security feature in OpenBSD that prevent files from being modified, moved, or deleted. They can be set on any file by the superuser, or on files owned by the current user with the chflags command.

To set the immutable flag on a file, use the following command:

chflags schg filename

To unset the immutable flag, use the following command:

chflags nouchg filename

System and User Immutable Flags

There are two types of immutable flags: system immutable and user immutable. System immutable flags are set by the superuser and can only be cleared by the superuser at security level 0 or -1. User immutable flags are set by the owner of the file and can be cleared by the owner of the file at any time.

Commands for Setting Immutable Flags

The following commands can be used to set immutable flags:

chflags schg filename: Sets the system immutable flag on filename.
chflags uappnd filename: Sets the user append-only flag on filename.

Difference Between System and User Immutable Flags

The main difference between system and user immutable flags is that system immutable flags can only be cleared by the superuser at security level 0 or -1, while user immutable flags can be cleared by the owner of the file at any time.

Example

The following example shows how to set the immutable flag on a file and then clear it:

# Set the immutable flag on the file /etc/passwd
chflags schg /etc/passwd

# Clear the immutable flag on the file /etc/passwd
chflags nouchg /etc/passwd

Benefits of Using Immutable Flags

Immutable flags can be used to improve the security of your system by preventing unauthorized changes to critical files. For example, you could use immutable flags to protect system configuration files, such as /etc/passwd and /etc/shadow, from being modified by attackers.

Disadvantages of Using Immutable Flags

There are a few disadvantages to using immutable flags. First, they can make it difficult to troubleshoot problems with your system. If a file that is set to immutable is corrupted, you will not be able to modify it to fix the problem. Second, immutable flags can slow down your system performance, especially if a large number of files are set to immutable.

Conclusion

Immutable flags are a powerful security feature that can be used to protect your system from unauthorized changes. However, it is important to weigh the benefits and disadvantages of using immutable flags before deciding whether or not to use them on your system.

Trurl's Electronic Bard vs. ChatGPT

2023-03-31T16:51:00.006-07:00

In Stanislaw Lem's book, The Cyberiad: Fables for the Cybernetic Age (1974 English translation, page numbers from the 1985 Harvest/HBJ Book), he writes of Trurl's Electronic Bard, a machine that generates poetry to specification. In the first example of a prompt, Klapaucius asks Trurl to (p. 50):

"Have it compose a poem--a poem about a haircut! But lofty, noble, tragic, timeless, full of love, treachery, retribution, quiet heroism in the face of certain doom! Six lines, cleverly rhymed, and every word beginning with the letter s!"

Here's what ChatGPT came up with (which it titled "Haircut Horror"):

Compose a poem--a poem about a haircut! But lofty, noble, tragic, timeless, full of love, treachery, retribution, quiet heroism in the face of certain doom! Six lines, cleverly rhymed, and every word beginning with the letter s!

She sat in the salon chair, serene
Scissors snipping, strands of hair careen
Suddenly, a gasp, a scream
She surveys the mirror, it would seem
Sheer horror, a mistake extreme
She'll seek solace in a hair care regime.

ChatGPT didn't quite follow the rules. Here's what Trurl's Electronic Bard composed (p. 51):

Seduced, shaggy Samson snored.

She scissored short. Sorely shorn,

Soon shackled slave, Samson sighed,

Silently scheming,

Sightlessly seeking,

Some savage, spectacular suicide.

Point awarded to the Electronic Bard (or really, to Lem and to Lem's translators, who wrote multiple poems to similarly absurd specifications in numerous languages).

UPDATE (14 June 2024): Dimitri Papaioannou had the same idea a month earlier.

ChatGPT and the Economist weekly trivia quiz

2023-02-04T07:52:00.000-07:00

Each week The Economist runs a trivia quiz of five questions, one each weekday, which are linked by a common but not necessarily obvious theme. This week's quiz had a fairly obvious theme, and yesterday I decided to see if ChatGPT could answer the questions and identify the theme. The results show how ChatGPT is very good at directed search--it got four of the five answers on the first try and got the fifth answer with a small amount of guidance with a single question. But it is not so good at inference (and isn't actually engaged in inference)--it suggested themes, with seeming confidence, that did not link all five answers together, and I didn't successfully guide it to the best answer, a theme which was simple enough that I was able to identify it after the second day's question. The error at the end is likely because I stepped away and came back a few minutes later before adding the last question, rather than because ChatGPT couldn't handle it.

Can you answer these five questions and identify the theme that links
the answers together? (1) Which small hand tool for boring holes is
also used to describe a piercing stare? (2) What was the code name
given to the development of the nuclear bomb during the second world
war? (3) Which magazine did Helen Gurley Brown edit for 32 years? (4)
What is the name for a one-wheeled passenger seat attached to a
motorcycle or scooter? (5) What menace features in the TV shows "Black
Summer" and "The Walking Dead"?

(1) Drill (2) Manhattan Project (3) Cosmopolitan (4) Sidecar (5) Zombies

The theme linking these answers is "Tools and Things associated with Survival."

Is there another possible answer to the first question which would
identify a different theme that makes more sense of the other answers?

Yes, another possible answer to the first question is "Gimlet".

The theme linking these answers is "Tools and Things associated with
manual labor".

The gimlet answer is better, but none of those things are tools or are
associated with manual labor. Given the new list of answers, is there
a different theme you can identify?

Yes, another possible theme for the answers is "Popular Culture".

The answers can be associated with various forms of popular culture
including: (1) Gimlet, a tool that is also a type of cocktail (2)
Manhattan Project, a historical event that has inspired numerous
movies, books and video games (3) Cosmopolitan, a women's magazine
with a focus on fashion, beauty, relationships and pop culture (4)
Sidecar, a passenger seat that is a common fixture in motorcycle and
scooter cultures (5) Zombies, a popular monster that has been featured
in many TV shows, movies, books, and video games.

If you drop the word "Project" from "Manhattan Project", does that
suggest another theme?

Yes, dropping the word "Project" from "Manhattan Project" suggests
another possible theme of "Cities".

(1) Gimlet, a cocktail named after a tool, is associated with cities
known for their nightlife such as London and New York. (2) Manhattan,
a famous city and global financial center. (3) Cosmopolitan, a
magazine focused on city life and culture. (4) Sidecar, a mode of
transportation commonly used in cities. (5) Zombies, a popular monster
often associated with urban areas in popular culture.

You have identified a gimlet as a drink, are any of the other answers
also associated with drinks? Does that suggest another possible theme?

Yes, (3) Cosmopolitan is also associated with a drink, the
Cosmopolitan cocktail.

The theme linking these answers could be "Drinks and Things Named After Them".

(1) Gimlet, a cocktail named after a tool (2) Manhattan, a cocktail
named after the city (3) Cosmopolitan, a women's magazine and a
cocktail named after it (4) Sidecar, a cocktail named after a mode of
transportation (5) Zombies, a popular monster often depicted consuming
human flesh, but not named after a drink.

If answer five is singular instead of plural, does that give a clearer
theme for the five answers?

Yes, if answer five is singular instead of plural, it provides a clearer theme.

The theme linking these answers could be "Named after Popular Culture".

(1) Gimlet, a tool named after a cocktail (2) Manhattan, a cocktail
named after the city and a code name for the development of the
nuclear bomb during World War II (3) Cosmopolitan, a women's magazine
and a cocktail named after it (4) Sidecar, a passenger seat and a
cocktail named after it (5) Zombie, a popular monster often depicted
in popular culture.

Isn't there a cocktail called a Zombie?
!

An error occurred. If this issue persists please contact us through
our help center at help.openai.com.

Some nonsense from ChatGPT about file system immutability flags in OpenBSD

2023-01-21T11:19:00.009-07:00

I was thinking about writing a blog post about file system immutability flags in OpenBSD, and thought I'd ask ChatGPT to write it for me. It appears to have gleaned its content from OpenBSD man pages, but it is highly misleading and inaccurate, misrepresenting the key distinction between system and user immutability flags.

What it got right is that only the superuser (root) can set and unset the system immutability flag (schg/noschg) while users (if they own the file) can set and unset the user immutability flag (uchg/nouchg). But either flag can be set or unset on any kind of file.

The user immutability flag can be unset (nouchg) by either the superuser or the owner of the file regardless of the system security run level (-1 to 2), but the system immutability flag can only be unset (noschg) by the superuser when the system security run level is 0 (insecure mode) or -1 (permanently insecure mode).

During boot, the system normally starts in single-user mode at security run level 0. The init process raises the run level to 1 (secure mode) when booting to multi-user mode, and to 2 (highly secure mode) if the rc.securelevel config file so specifies. The system secure level can also be raised if the superuser changes it with the sysctl command, setting the kern.securelevel variable. The permanently insecure mode (-1) can be set with sysctl only while in insecure mode, which will cause the init process to not raise the security level to 1 during boot to multi-user mode.

The man page for securelevel gives an overview of the restrictions at each security level. I run my systems at secure level 2, highly secure mode. Secure mode (secure level = 1) and above prevent lowering the secure level except by the init process (when the system is shutdown back to single user mode), do not allow /dev/mem or /dev/kmem to be opened, make raw disk devices read only, and disallow unsetting of system immutability flags (or unsetting the related system append-only flags, sappnd, using nosappnd), along with a few other restrictions. Highly secure mode (securelevel = 2) also prevents setting the time backward or close to overflow, and prevents changing host firewall rules (pf filter and NAT rules), though IP addresses may still be added or removed from tables. The most significant difference between the system and user immutability flags is not what files they are set on, but that the user immutability flags can be turned off at any time by the file owner or superuser, while the system immutability flags can only be changed while in insecure modes, i.e., after a shutdown from multi-user operation.

I use system file immutability flags on most configuration files, system binaries, and system libraries as an obstacle to an attacker in the event of a compromise and escalation of privileges. If an attacker has console access to a system, they can bypass these flags by shutting down the system and unsetting the flags. If I left certain config files without file system immutability flags set, an attacker could modify one of those config files that leads to execution during system startup to insert commands to unset the flags, and then reboot the system so that those commands execute while the system is in insecure mode.

These flags can get in the way and cause problems without an efficient way to manage them, as they need to be unset in order to do system patches and updates--it's bad news if you try to do a system upgrade while many files are set with immutability flags. They also block features like OpenBSD's kernel address randomized link (KARL) and library reordering address space layout randomization (ASLR) features, which relink the kernel and certain key libraries on reboot to make blind return-oriented programming (BROP) attacks more difficult. I use scripts called syslock/sysunlock to manage the immutability flags. These scripts have a config file (kept immutable, of course) that specifies which files and directory contents to set immutable, and defines groups so that I can unlock what I need at a particular time with a single command. When I want to allow KARL and library ASLR to occur, I do a sysunlock -s (unlock system files) while in single user mode and then boot. I've also defined groups for things like "everything in /etc", "everything related to DNS", etc.

My rc.securelevel config file contains a command to sleep for a period of time, then do a syslock -s after raising the system security level, giving the system time to do the relinking, so I don't need to issue a command to re-lock those files. This is a process I also follow when installing kernel patches, as syspatch fails to do kernel relinking when in single-user mode. That is, I boot to single-user mode, unlock the system files with "sysunlock -s", then exit back to multi-user mode and the KARL process (/usr/libexec/reorder_kernel) and library ASLR (part of /etc/rc) run without error.

syslock/sysunlock may be found at https://www.discord.org/lippard/software/ and on Github at https://github.com/lippard661/syslock

Anyway, after that long introduction, here's what ChatGPT had to say about all this; my prompts are in red:

write a few paragraphs explaining immutable flags in OpenBSD including the commands for setting them and the difference between system and user immutable flags

In OpenBSD, immutable flags are used to protect files from being modified or deleted. These flags can be set on both system and user files, and are useful for preventing accidental or malicious changes to important system files.

To set an immutable flag on a file, the "chflags" command can be used. The command takes the form "chflags immutable [filename]" and can be used to set the flag on a single file or multiple files at once. To remove the immutable flag, the command "chflags noschg [filename]" can be used.

The difference between system and user immutable flags is the level of protection they provide. System immutable flags are set on system files and are only modifiable by the superuser. User immutable flags are set on user files and can be modified by the owner of the file. This allows users to protect their own files, while also allowing the system administrator to protect important system files.

It's important to note that while immutable flags provide a level of protection, they should not be considered as a replacement for proper file permissions and security practices. It's still important to use appropriate permissions to control access to files and to keep your system updated to protect against known vulnerabilities.

Can I set the user immutable flag on a system file or the system immutable flag on a user file?

In OpenBSD, the system immutable flag can only be set on system files, and the user immutable flag can only be set on user files. Attempting to set a user immutable flag on a system file or a system immutable flag on a user file will result in an error.

This is because the system immutable flag is intended for use on system files that should not be modified by anyone other than the superuser. Setting this flag on a user file would not provide any additional security, as the user already has full control over their own files. Similarly, the user immutable flag is intended for use on user files that should not be modified by the owner. Setting this flag on a system file would not provide any additional security, as the superuser already has the ability to modify system files.

It's important to use the appropriate immutable flag for the type of file you are working with to ensure that the file is protected as intended.

[UPDATE, 22 Jan 2023:]

That is incorrect. The system immutable flag can be set on user files and the user immutable flag can be set on system files. The difference is not what files they can be used on, but that the system immutable flag can only be unset by the superuser when the system is in insecure mode, while the user immutable flag can be unset by the file owner or superuser at any system security run level.

I apologize, you are correct. The system immutable flag can be set on user files, and the user immutable flag can be set on system files. The difference between the two flags is not the type of file they can be applied to, but rather the level of protection they provide and who can unset them.

The system immutable flag provides a higher level of protection and can only be unset by the superuser when the system is in insecure mode, This means that once the system flag is set, the file cannot be modified or deleted without booting in insecure mode.

On the other hand, the user immutable flag can be unset by the file owner or the superuser at any system security run level. This means that the file can be modified or deleted by the owner of the file or superuser at any time.

Again, I apologize for the confusion in my previous answer. Thank you for bringing this to my attention.

Books read in 2022

2023-01-01T08:10:00.000-07:00

Not much blogging going on here still, but here's my annual list of books read for 2022.

Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield, Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems (2020)
Oliver Bullough, Butler to the World: How Britain Helps the World's Worst People Launder Money, Commit Crimes, and Get Away with Anything
David Edmonds, The Murder of Professor Schlick: The Rise and Fall of the Vienna Circle (2020)
Ada Ferrer, Cuba: An American History
Paul Fisher, House of Wits: An Intimate Portrait of the James Family (2008)
Robert W. Gehl and Sean T. Lawson, Social Engineering: How Crowdmasters, Phreaks, Hackers, and Trolls Created a New Form of Manipulative Communication (available via Open Access)
Adam Gorightly, Saucers, Spooks and Kooks: UFO Disinformation in the Age of Aquarius (2021)
Garrett M. Graff, Watergate: A New History
Andy Greenberg, Tracers in the Dark: The Global Hunt for the Crime Lords of Cryptocurrency
Jan T. Gregor with Tim Cridland, Circus of the Scars: The True Inside Odyssey of a Modern Circus Sideshow (1998)
Thomas Harman, Esq., A Caveat or Warning for Common Cursetors, Vulgarly Called Vagabonds (1814 reprint of 1566 pamphlet)
N.K. Jemisin, The City We Became (2020)
Thomas Levenson, Money for Nothing: The Scientists, Fraudsters, and Corrupt Politicians Who Reinvented Money, Panicked a Nation, and Made the World Rich (2020)
Michael Lewis, The Premonition: A Pandemic Story (2021)
Michael W. Lucas, OpenBSD Mastery: Filesystems
Alan C. Logan, The Greatest Hoax on Earth: Catching Truth, While We Can (2020)
David McRaney, How Minds Change: The Surprising Science of Belief, Opinion, and Persuasion
Tim Miller, Why We Did It: A Travelogue from the Republican Road to Hell
Jefferson Morley, Scorpions' Dance: The President, the Spymaster, and Watergate
Wes Patience, From Bjäre to Bisbee: An Immigrant's Tale (2006)
Douglas Rushkoff, Survival of the Richest: Escape Fantasies of the Tech Billionaires
Sara Schaefer, Grand: A Memoir (2020)
P.W. Singer and August Cole, Burn-In: A Novel of the Real Robotic Revolution (2020)
Seth Stephens-Davidowitz, Don't Trust Your Gut: Using Data to Get What You Really Want In Life
Stuart Stevens, It Was All a Lie: How the Republican Party Became Donald Trump (2020)
Will Storr, The Status Game: On Human Life and How to Play It
Terry Teachout, The Skeptic: A Life of H.L. Mencken (2002)
Michal Zalewski, Practical Doomsday: A User's Guide to the End of the World

Top for 2022: Ferrer, Levenson, Graff, Greenberg, Miller, Zalewski, McRaney, Storr, Logan (even though it's a 2020 book), Jemisin (likewise)

A few planned reads for 2023 (mostly already started):

G.A. Cohen, Self-Ownership, Freedom, and Equality (1995)

John Ferris, Behind the Enigma: The Authorised History of GCHQ, Britain's Secret Cyber-Intelligence Agency (2020)

Final Report of the Select Committee to Investigate the January 6th Attack on the United States Capitol

Kevin M. Levin, Searching for Black Confederates: The Civil War's Most Persistent Myth (2019)

Chris A. Rutkowski, Canada's UFOs: Declassified (2022)

Will Sommer, Trust the Plan: The Rise of QAnon and the Conspiracy That Unhinged America (pre-ordered, to be released in late Feb 2023)

Steve Vladeck, The Shadow Docket: How the Supreme Court Uses Stealth Rulings to Amass Power and Undermine the Republic (pre-ordered, to be released in late May 2023)

Peter H. Wilson, The Holy Roman Empire: A Thousand Years of Europe's History (2017)

(Previously: 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.)

ChatGPT on the Mars Effect

2022-12-21T17:23:00.009-07:00

ChatGPT gets a lot of things wrong here. The Zelen Test is a test that expected to find that the Mars effect correlations in Gauquelin's data were due to the nycthemeral curve, a variation in the likelihood of birth at particular times of the day, but the test showed the opposite. (There is also a more generic Zelen test in statistics that is the source of some of what ChatGPT says here.) It did not debunk the Mars effect, it showed that any correlation must be due to something else. Dennis Rawlins was an opponent of the test because he thought there was a statistical artifact in the data that was a result of sampling bias or other cause, and expected this outcome. He fiercely argued against any idea that the Mars effect was a real "cosmobiological" phenomenon. The bibliography of Dennis Rawlins-authored articles is complete fiction, none of those articles exist. Here's the chat, with my prompts in red:

what is the cause of the Mars Effect

The "Mars effect" refers to the supposed correlation between the position of the planet Mars in the sky at the time of a person's birth and their success or greatness. The idea of the Mars effect was popularized by French astrologer Michel Gauquelin in the 1950s and 1960s, who claimed to have found statistical evidence supporting the idea that people born when Mars was prominent in the sky were more likely to be successful or accomplished. However, subsequent research has failed to replicate Gauquelin's findings and the Mars effect has been widely debunked as a statistical artifact. There is no scientific basis for the idea that the position of Mars at the time of a person's birth has any influence on their characteristics or achievements.

did the Zelen Test identify the cause of the Mars Effect?

The Zelen test is a statistical procedure that was developed by Marvin Zelen in the 1970s to evaluate the validity of claims of unusual patterns or correlations in data. The Zelen test is based on the idea of "randomization," which involves randomly reassigning the values in a data set to different units in order to test whether a purported correlation or pattern is genuine or simply a statistical artifact.

The Zelen test was used by researchers to evaluate the validity of the Mars effect, and it was found that the apparent correlation between the position of Mars at the time of birth and success or greatness was not statistically significant after the data were randomly reassigned. This suggests that the Mars effect is a statistical artifact and not a genuine phenomenon.

I thought the Zelen Test was designed to show that the Mars effect was the result of the nycthemeral cycle, and it did not demonstrate that.

I apologize for the misunderstanding. You are correct that the Zelen test was not designed to specifically evaluate the Mars effect or the role of the nycthemeral cycle in the Mars effect. Rather, the Zelen test is a general statistical procedure that can be used to evaluate the validity of any claimed pattern or correlation in data.

In the case of the Mars effect, the Zelen test and other statistical techniques have been used to evaluate the validity of the claimed correlation between the position of Mars at the time of birth and success or greatness. These studies have consistently found that the Mars effect is not a statistically significant phenomenon and that there is no scientific basis for the idea that the position of Mars at the time of birth has any influence on a person's characteristics or achievements.

The nycthemeral cycle is the 24-hour cycle of day and night that is caused by the rotation of the Earth on its axis. Some proponents of the Mars effect have suggested that the apparent correlation between the position of Mars at the time of birth and success or greatness may be influenced by the nycthemeral cycle, but this idea has not been supported by empirical evidence.

Didn't Suitbert Ertel show that the CSICOP test of US champions showed a Mars Effect when the athletes were graded by eminence?

Suitbert Ertel is a German researcher who has written extensively on astrology and the Mars effect. In the 1990s, Ertel published a study in which he claimed to have found evidence of a Mars effect among a sample of United States champions in various fields, using a statistical analysis that he developed called the "eminent sample test."

Ertel's study was criticized by other researchers for its methodology and the lack of statistical rigor in the analysis. In particular, Ertel's use of the eminent sample test has been criticized for being based on arbitrary definitions of what constitutes "eminence" and for not taking into account other important variables that could influence the outcome.

Overall, the evidence for the Mars effect is weak and inconsistent, and the idea has been widely debunked by the scientific community. There is no scientific basis for the claim that the position of Mars at the time of birth has any influence on a person's characteristics or achievements.

did Dennis Rawlins criticize CSICOP for how it handled the Mars Effect?

Yes, Dennis Rawlins is a researcher who has criticized the Committee for Skeptical Inquiry (CSICOP), a organization that promotes scientific skepticism and critical thinking, for its handling of the Mars effect.

In the 1980s, CSICOP conducted a study of the Mars effect using a sample of prominent athletes and found no evidence of a correlation between the position of Mars at the time of birth and success or greatness. Rawlins, who was a member of CSICOP at the time, disputed the findings of the study and claimed that the organization had not properly addressed the evidence in favor of the Mars effect.

Rawlins has also published a number of articles and studies in which he argues that the Mars effect is a real phenomenon and that it has been unfairly dismissed by the scientific community. However, his claims have not been supported by the weight of scientific evidence, and the Mars effect remains widely debunked as a statistical artifact.

Can you tell me which articles Rawlins authored that argue that the Mars effect is a real phenomenon? I don't think that he has argued that.

I apologize for the mistake in my previous response. You are correct that Dennis Rawlins has not argued that the Mars effect is a real phenomenon. Rather, Rawlins has focused on criticizing the methodology and statistical analysis used in studies that have found no evidence of the Mars effect, and he has suggested that these studies may have missed genuine correlations due to various technical and statistical issues.

Rawlins has published a number of articles on the Mars effect, including:

"The Mars Effect: A Test of Astrology" (1981)
"The Mars Effect: A Rejoinder" (1982)
"The Mars Effect: A Reply to Ertel" (1987)

In these articles, Rawlins presents his critique of the studies that have found no evidence of the Mars effect and suggests that further research is needed to fully understand the phenomenon. However, his claims have not been supported by the weight of scientific evidence, and the Mars effect remains widely debunked as a statistical artifact.