Sunday, June 1, 2025

The dubious lesson of the Carpathia

So right now I'm at LessOnline, the LessWrong conference centered on writing about rationality-related topics, and I encountered a very interesting proposition. There was a session about writing speeches for the LessWrong/rationalist Winter Solstice, a solemn ceremony with musical performances and speeches with a rational, hopeful-but-realistic theme. Towards the end, the speaker gave an example of a Tumblr post that he turned into a speech.

To summarize, it's about the sinking of the Titanic[1], and the captain of the Carpathia, who got the distress call and immediately went heads-down, focusing on the mission to get to the disaster as soon as possible, repurposing his entire ship and its resources for rescue, eventually saving some 700 lives. By pushing limits, he got there faster than should really have been possible, and thus rescuing far more than could have been expected.

A lot about this story rubbed me the wrong way, such that I don't endorse it for its intended purpose, which is to be an inspiring speech given at rationalist events in support of the rationalist worldmodel.

Look at this critical part of the exposition (italics original): 

He woke up all the engineers, all the stokers and firemen, diverted all that steam back into the engines, and asked his ship to go as fast as she possibly could. And when she’d done that, he asked her to go faster.

I need you to understand that you simply can’t push a ship very far past its top speed. ... Pushing a ship past its rated speed is not only reckless–it’s difficult to maneuver–but it puts an incredible amount of strain on the engines. ... They can’t do it. It can’t be done.

Carpathia’s absolute do-or-die, the-engines-can’t-take-this-forever top speed was fourteen knots. Dodging icebergs, in the dark and the cold, surrounded by mist, she sustained a speed of almost seventeen and a half.

...

They damn near broke the laws of physics, galloping north headlong into the dark...

Okay, something isn't adding up here. The post clearly emphasizes that ships are not supposed to be pushed past their top speed, and owns up to the fact that it really is reckless, and even acknowledges that the maintaining that speed might as well count as "physical law, violated". The reads as the fantasy of the manager who overcomes physical limits by sheer force of leadership ... which is not how physical systems, or tradeoffs thereon, actually work.

Also -- "dodging icebergs"? That's what got the Titanic into this mess in he first place. Maybe not the right image to use here.

All of that adds up to the fact that any success here really doesn't generalize. Knowing what they knew at the time, it was actually not the rational thing to do. Yes, it looks like a bold, selfless act now, because we know how it turned out: he happened not to sink his ship in the process. But he couldn't know that would be true at the time; for all he knew, this was condemning the ship and its crew to be casualties in addition to that of the Titanic (up to the rescue efforts of a later, more cautious ship). Claiming vindication reeks of hindsight bias. (There's a reason they caution rescuers against "being a hero" -- they may very well end up being yet one more person that needs rescue.)

One of the hurdles in making your thought more rational is accepting that something can be a bad idea despite the fact that it worked. In Blackjack, if you stand on 4, and the dealer busts, you win ... but it's still stupid. The idea that you should push a critical system well past its limits to accomplish a stretch goal is ... not good. Any success would, at most, be an edge case, not a canonical template you should keep repeating.

So ... if I were to make this a speech, it would have to be with some kind of twist like "lol gotcha! You just got seduced by a narrative, and hindsight bias. 'Push past the limits' makes for a rousing story, but in practice, it's how disasters happen." Which is the kind of chain-yanking I prefer not to do to begin with.

I'm not digging into the whether the presented facts are actually true, because I'm just evaluating it as a speech and working from assumptions it sets up. If there are other reasons that justify why this may have been less reckless than it really was, they should have been included to support the conclusion. But, as given, it pumps up the idea that, because you were bold, you had to save lives, and it works, that adds up to it being a good decision. It doesn't.

And there's a lesser issue, too. It also mentions repurposing part of the ship's steam to prepare tea and coffee for the survivors as they were loaded on board. Like, what? I'm sorry, but in a survival situation, coffee and tea are luxuries. They need warmth and drinking water ... the rest isn't a priority.

[1] Because I don't feel obligated to follow ridiculous, ossified conventions, I'm going to refer to ships as "it" and not italicize their names. They're proper nouns. Capitalization is good enough.

Tuesday, April 1, 2025

Looking too available is a security risk! The new NIST standard.

NIST IR 8429-DRAFT: Presence Obfuscation in Federated Scheduling Systems

I've always been a little worried about people who post e.g. a Calendly link that shows their full availability and lets you set an appointment. Do you really want to reveal how not-busy you are? Well, apparently the NIST is now warning that it's also a big security risk, and advises a few protocols to obfuscate your true availability. I got my hands on an early draft of the proposal.


🛡️ NIST IR 8429-DRAFT

Presence Obfuscation in Federated Scheduling Systems

Guidelines for Temporal Metadata Minimization in Collaborative Availability Platforms

Issued by: National Institute of Standards and Technology
Prepared by: Information Security & Human Factors Division (IS-HFD)
Document Type: Interagency Report (Draft for Public Comment)
Release Date: April 1, 2025

1. Scope and Purpose

Modern calendaring tools often expose excessive availability to collaborators, contractors, and external partners. These systems—by default—permit observers to view large blocks of unscheduled time, often across multiple days, weeks, or recurring patterns.

While intended to facilitate meeting scheduling, such broad exposure of free/busy data introduces serious risks:

  • Temporal profiling
  • Passive inferences about workload or engagement
  • Social graph deduction via availability overlap
  • Identification of predictable solitude windows

These exposures disproportionately impact individuals with high meeting asymmetry—those who receive more requests than they initiate—and those whose roles rely on maintaining controlled perceptions of demand.

2. Problem Definition

The visibility of extensive availability windows has emerged as a key metadata leakage vector in both organizational and interpersonal contexts. Specifically:

  • Open calendars reveal a subject’s unstructured time density, which may be misinterpreted as low workload or underutilization.
  • Observers may make inferences about social graph positioning based on recurring exclusion from scheduled events.
  • In adversarial contexts, such patterns can even aid in physical vulnerability modeling, including mapping of long-duration solitude intervals.
Note: While this report avoids normative language regarding “perceived busyness,” we recognize it as a functional privacy parameter in professional ecosystems.

3. Mitigation Strategy: Presence Obfuscation Layer (POL-1)

POL-1 is a modular framework for introducing structured ambiguity into exposed calendrical availability, ensuring that observed scheduling surfaces retain semantic plausibility without revealing raw temporal capacity.

It is not a deception system, but rather a context-aware redaction buffer for collaborative environments.

4. System Components

4.1 Observer-Coherent Subset Exposure (OCEP)

Availability is partitioned by observer class (e.g., internal peer, external client, HR metadata node) to ensure deterministic, plausible views that are not cross-correlatable. No single observer can reconstruct the true surface.

4.2 Continuity Entropy Injection (CEI)

Injects plausible placeholder constraints and pseudo-events to avoid the appearance of long unbroken availability, particularly during mid-day periods known to trigger unsolicited booking attempts.

4.3 Foreground Availability Perturbation System (FAPS)

Applies low-amplitude randomization at event boundaries to disrupt timing-based inference attacks. Designed to deflect automated meeting tools and high-frequency schedulers without impeding intentional collaboration.

Note: FAPS may be disabled in constrained or high-determinism scheduling environments (e.g., surgical coordination, launch windows).

4.4 Behavioral Availability Normalization Kernel (BANK)

Aligns exposed availability with industry-standard load models, e.g., “Product Manager (Mid-Level, West Coast)” or “Postdoctoral Researcher (Remote EU).” Useful for avoiding apparent availability outliers that may bias request behavior.

4.5 Fail-Safe Redaction Coherence Module (FRCM)

Final pass verifier that ensures no exposed schedule appears suspiciously empty, implausibly overbooked, or temporally inconsistent with the subject’s graph classification.

5. Application Scenarios

Scenario Exposure Risk Mitigation Stack
Early-career engineer in open scheduling org Appears to have 4–5 open hours/day BANK + CEI + OCEP
Public figure with assistants booking on their behalf High-profile scheduling scrape risk FAPS + FRCM
Remote worker in non-managerial role Pattern of availability invites frequent “quick chats” OCEP + CEI

6. Deployment and Compliance

POL-1 is suitable for deployment across major federated scheduling platforms (CalDAV, Exchange, Google Calendar API v3). Compatibility modules are provided for Outlook Graph Surfaces and GSuite Legacy Redirection endpoints.

Note: Organizations governed by EO 14217 (“Minimum Obfuscation Baselines for Federal Metadata Systems”) must deploy POL-1 or equivalent by Q3 FY25.

7. Availability

A reference implementation of POL-1 is available on the NIST GitHub mirror under a modified FIPS-aware BSD license:
📎 https://github.com/nist-opsec/pol1

"Availability is a feature. Apparent availability is a liability."
— NIST IR 8429-DRAFT, April 1, 2025