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

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

Leaked Google initiative: No more passwords!

I have an inside source that's claiming Google will be rolling out a new replacement for passwords and other secrets for authenticating users. They shared the upcoming blog post/press release with me. They're moving to a more "holistic" authentication system? Let's see if this pans out. In any case, here's the not-yet-released announcement.

***

Are you who you claim to be?

User logins protect websites from malicious actors, like spammers and trolls. So when you go online, only people with legitimate credentials can access the useful features of the site -- and others can't impersonate you. For years, you've used logins -- such as a username and password -- to prove to the site that you are who you claim to be, like this:

Some go even further and add a second factor to authenticate with, like an SMS code or one-time-password generator like you might have in the Google Authenticator app.

But, we figured it would be easier to just directly ask our users who they are -- so, we did! Following on our earlier success with No CAPTCHA reCAPTCHA, we’ve begun rolling out a new API that radically simplifies the login experience. We’re calling it "Credential-Free Authentication" and this is how it looks:

On websites using this new API, a significant number of users will be able to securely and easily verify their identities without (separately) having to provide credentials: no password, no rotating code. Instead, with just a single click, they’ll validate who they claim to be.

A brief history of user authentication

While the new login API may sound simple, there is a high degree of sophistication behind that modest interface. Authentication has long relied on attackers not having critical secrets, like a password or random number generator seed or other private information. You may have heard the traditional formulation, that authentication requires you to provide something you have, something you are, or something you know.

However, our research recently showed that it's about as likely for the genuine user to be missing the credentials as it is for a malicious actor. How many times have you forgotten your password or encountered a bug with your password manager? (Not GPM, of course!) Thus, challenging users for credentials is no longer a dependable test.

Furthermore, attackers are often able to steal user credentials, forcing providers to rely on a secondary layer of fraud identification, so as to lock accounts when users behave suspiciously. You've seen this if you've ever had a credit card declined for an unusually large or remote purchase.

Introducing Credential-Free Auhentication

That got our security engineers thinking: if we already have to analyze a user's behavior in order to catch account compromises, why not just use that as the authentication? It would cut two carrots with one knife! After all, an attacker might be able to guess your password or your credit card information, but they will never be able to mimic the full depth and breadth of how you interact with websites, from your browing history, to your cookies set, to the way you move your mouse.

Following the "No CAPTCHA" model above, we developed an Advanced User Analysis backend for logins that actively considers a user’s entire engagement with the the Internet to determine who that user is. This enables us to rely less on "Do you have the secret?" and, in turn, offer a better experience for users. Now, users can just click a radio button, and in most cases, they’re logged in. In fact, you'll rarely have to log in at all, because sites will "recognize" you, just like you don't have to show your ID to go into an event venue a second time if the bouncer recognizes you.

But are you really that person?

However, authentication challenges aren't going away just yet. In cases where our tracking cookies and other behavioral metrics can't confidently predict who someone is, we will prompt the user for additional information, increasing the number of security checkpoints to confirm who the user really is. For example, you might need to turn on your webcam or upload your operating system's recent logs to give a fuller picture.

Adopting the new API on your site

As more websites adopt the new API, more people will see Credential-Free Authentication. Early adopters, like Snapchat, WordPress, Twitch, and several others are already seeing great results with this new API. For example, in the last week, the number of support tickets for account resets on WordPress went down by 90%. Twitch reported similar figures -- and also was able to unmask several sockpuppets who had been manipulating discussions and vote totals.

To adopt the new CFA API for your website, visit our landing page for more.

Good users, we'll continue to keep the internet safe and easy to use. Bad users, it'll only get harder to hide yourselves and take over legitimate accounts -- sorry we're (still) not sorry.

***

Edit: Yes, this was an April Fools joke.

Solving my first (Ghidra) reverse engineering challenge

I was pointed to this challenge by this article, and had heard about the NSA's new Ghidra reverse engineering tool. I was able to solve it without reading much of the article! Here's what I did.

Setup: They give you a compiled ELF binary that runs a program that prompts you for a password. It will tell you if you guessed correctly.

I was going to use this as a change to learn the Ghidra tool, with help from the article.

First problem: It's compiled to run on Linux Debian x86. I was doing it on a MacBook. So, it wouldn't run.

I noticed that Ghidra offers you the option to export the binary as C code (which makes sense, as part of Ghidra's reverse engineering is to convert a binary into assembly and slightly-more-readable C-like code). So, I figured I could just compile that to run on my Mac.

It didn't work though, since Ghidra exports an incomplete version of the code that uses some invalid types, and doesn't define all of its labels properly, which required a lot of manual work that was increasingly appearing like it would take too long.

So I figured I'd just run the binary in a Docker container. I found the Debian i386 version and pulled it down. (I had a long side diversion here getting a setup so I could edit files on my machine that would appear as I want in the Docker container, but the details are uninteresting besides this clever hack for getting the "copy file" command into your docker one-liner.)

So, I was able to run the binary.

Second problem: Somehow, it thought I was using a "debuguer" -- which I would be, at some point, but is strange, because I wasn't using one yet:

Don't use a debuguer !

I looked through the decompiled code to see where it might be doing this and found:

lVar1 = ptrace(PTRACE_TRACEME,0,1,0);
if (lVar1 < 0) {
    puts("Don\'t use a debuguer !");
    /* WARNING: Subroutine does not return */
  abort();
} 

Hm, okay, well that "if" statement maps to this part of the assembly:

0804868c 79 11 JNS LAB_0804869f

That is, according to this handy reference, "Jump if not sign." Well, whatever "sign" is, I want it to do the opposite -- change "JNS" to "JS", so it "jumps if sign" and skips that block -- the one that gives the mean message and exits the program.

I haven't figured out a good way to format that line, but 0804868c is the (hexadecimal) location within the binary, 79 11 is the hex version of the binary command itself, JNS the assembly term (just a mnemonic device) for that command, and LAB_0804869f is the argument passed to the command -- in this case, a label for where to jump to in the program.

According to that spec, the JNS command maps to 79, and if I want it to be JS, I need to replace it with 78. But...

Third problem: I don't have an easy way to edit binaries.

A convenient way to look at them is as a hex(adecimal) dump in a "hex editor", but I hadn't done that for a few months. Hex editors are useful because they show you the raw hex, the offset where it appears in the file, and, off to the side, the ASCII/text equivalent of that hex. Fortunately, I found this comment, showing how to repurpose my text editor, vim, to double as an easy hex editor. I can just open it up, edit the hex values, save, and it updates everything.

You can then run a utility, "gobjdump", to see the code as assembly and verify that e.g. JNS changed to JS as expected.

Fortunately, when I ran that edited binary, it did what I wanted: not accuse me of using a debugger, and proceed with the rest of the program.

The rest of the hurdles are similar: there's some if-test that can send the execution into a block that you don't want it to. Fortunately, this binary is structured ... stupidly, from a security perspective. It has that same kind of if-block for validating whether you entered the right password. Right afterward, if the check succeeded, it prints the password. Not your input, no -- it prints the correct password, which you can later validate on an unmodified run.

So, it's just a matter of tweaking the code so that the you always enter the block that outputs the password. (They were smart enough not to have the password itself appear as an obvious string in the binary, at least.)

Once I saw the output, I could submit it at the challenge site and very it was correct.

Now for something harder!