Coder Legion - Recent posts tagged automated

Changelog #8: Quota accuracy and deeper lead analyses

Fri, 15 May 2026 21:29:05 +0000

Late April was mostly about counting tests the way your charts already do, giving sysadmin leads a denser board and a proper read-only analysis page, and wiring related tags so thin blog archives still send readers somewhere useful. We also lined up marketing anchors and small UI fixes so the path from a feature page into signup or the waitlist behaves the same everywhere.

Monthly quota now follows scored PageSpeed runs

Your plan limit is PageSpeed tests per month. We only decrement the allowance when a run finishes with a Lighthouse performance score (the 0–100 headline number you see on site tests). HTTP failures, timeouts, or responses with no score no longer eat quota. That matches how we store a site test as worth charting only when there is a score to plot.

Customer dashboard numbers

On normal customer accounts (not sysadmin), the API usage strip at the top of the dashboard still shows three figures: successful runs today, this calendar month (we abbreviate thousands as “2.4k”), and errors today. Successful uses the same scored rows as quota; errors groups failed attempts so you can tell whether the lab or the URL is flaking without guessing from gaps in history. The strip still links to the day-by-day API usage table. The same ideas are spelled out for prospects on the API access and quota visibility feature page.

Pricing FAQ and product behaviour

The pricing page FAQ already described which runs count toward quota. Counters in the app now match that wording: success means a scored result you can act on, not a bare HTTP 200 with empty metrics.

When a scheduled test has no performance score

If automation gets a payload that cannot produce a score, we treat it as failed for quota and record an explicit failure instead of a row that looks healthy with no number. You spend less time hunting empty rows when PageSpeed Insights is intermittent or the URL blocks the lab.

Leads board and full-page analysis

The admin leads management and prospecting area is still in development with a small beta group. It is where agencies will run prospecting against sites that are not yet on a customer organisation: discovery jobs, scheduled lab tests, and the public report link you might send before someone becomes a paying tenant. The marketing page describes the intended workflow; the April changes already change how you work the queue inside the app.

Index table: scan before you open a lead

The index now shows enough signal on the first screen that you can sort and skim without opening every lead. Extra columns are on by default:

Pages discovered tells you how much of the site the crawler actually mapped (see automated page discovery for how that fits the wider product). A low number next to a large marketing site is often the first hint that auth walls, aggressive bot blocking, or a shallow sitemap will skew later scores.
Completed tests and pending tests compare what we have already run on mobile and desktop with what discovery says we should expect. Pending stays visible when a device lane has not caught up yet, so you are not guessing from a single “last tested” date in the row title.
Report shows the date of the latest public report plus a link that opens in a new tab, so you can sanity-check the customer-facing page before you paste it into an email.
Mobile and desktop render the latest analysis performance score as colour-coded badges: green from 90, amber from 50, red below, and “N/A” when we never got a scored run for that device.

Platform or CMS and priority remain in the column manager. Turn them on when you need taxonomy or routing metadata; leave them off when you want a wide table that still wraps long headers instead of crushing column widths.

Lead analysis: same report layout as monitored sites

Choosing View on a lead analysis opens a full-page, read-only record headed with the lead name and the URL we tested. Layout and sections match what you already know from monitored site tests: status and device, timestamps, a full-page or viewport screenshot when the stored response includes image data, and the headline 0–100 performance score.

Under that you get the same lab detail we surface for production monitoring: core timings (LCP, INP, CLS, and the rest of the Lighthouse set), optional Chrome UX Report field data when Google returns it, then diagnostics and optimisation opportunities, passed audits, and resource summaries. Nothing on the page is editable on purpose. When you are reconciling a PDF or a prospect email against what the crawler saw, you want a frozen snapshot of our store, not a second editor that could drift from the run you quoted.

If you already rely on the monitored-site test view for client conversations (the same framing as on the Core Web Vitals monitoring page), you should not have to learn a parallel “lead-only” dialect. Same sections, same ordering, different object in the database.

Blog archives and marketing pages

Thin blog tag pages can show related posts at the bottom when a tag only lists a few articles, so you still have onward reading. Across the public site, we cleaned up internal sign-up links, so you are less likely to land in the wrong place when you move from a post or feature page into the waitlist or account flow.

What to do next

If you are on a paid plan (pricing), run your next batch of tests and watch the API usage strip: successful totals should move with the scores you see on site tests, and error spikes should show up the same day. If you work leads in admin, sort by pages discovered or completed tests before opening a single row. For the public overview of that workflow, see leads management and prospecting.

The next changelog will cover the first half of May.

Passkeys vs Bots: Do They Really Solve the Human Verification Problem?

Sat, 25 Apr 2026 06:55:07 +0000

Passkeys authenticate users securely, but they do not prove a user is human. Passkeys replace passwords with device-bound cryptographic authentication. They prevent phishing, credential theft, and password reuse attacks.

However, passkeys only verify identity at login, not behavior after login. A bot can still operate inside a valid authenticated session. Automated browsers, scripts, and AI agents can interact with systems after authentication succeeds.

Passkeys solve authentication problems, not human verification problems.
Human verification requires analyzing behavior, context, and request patterns.

Modern security therefore separates two different questions:

Who logged in? → authentication
Is this activity human? → bot detection

Passkeys answer the first question extremely well. They do not answer the second question.

That distinction is critical for modern applications facing automated attacks. Bots today perform actions such as scraping APIs, creating fake accounts, and automating purchases. Many of these actions happen after authentication, not before it.

This means that even a system protected with passkeys can still experience bot abuse.

To fully protect modern applications, security must combine multiple layers:

Strong authentication (passkeys)
Bot detection systems
Behavioral analysis
Runtime identity verification

Understanding where passkeys help—and where they do not—is essential for building secure systems.

2. Quick TL;DR

Passkeys replace passwords with device-bound authentication.
Passkeys prevent phishing and credential theft attacks.
Passkeys verify identity but do not verify human behavior.
Bots can operate inside authenticated sessions.
Authentication does not prove human intent.
CAPTCHA was originally designed to detect bots.
Modern bots can solve or bypass many CAPTCHA challenges.
Bot detection relies on behavioral and device signals.
Passkeys improve authentication security but not bot detection.
Modern security requires authentication plus runtime verification.

3. The Core Question: Do Passkeys Prove You Are Human?

The short answer is no. Passkeys prove that a user controls a device credential. They do not prove that the actor using that device is human.

Passkeys verify identity ownership, not human intent.
Human verification and authentication are fundamentally different security goals.

Many developers confuse these two concepts because both appear during login flows. However, they solve different problems in system security.

Authentication vs Human Verification

Authentication answers one specific question:

Who is the user?

Human verification answers a different question:

Is this activity being performed by a human or a bot?

These two goals require completely different technologies.

Security Goal	Purpose	Example Technology
Authentication	Verify user identity	Passwords, Passkeys, OAuth
Authorization	Control resource access	RBAC, Access policies
Human Verification	Detect automated behavior	CAPTCHA, Behavior analysis

Authentication confirms identity credentials.
Human verification analyzes interaction behavior.

Authentication proves identity.
Human verification proves intent.

Identity vs Intent

Passkeys solve the identity problem extremely well. They replace passwords with cryptographic authentication tied to a device.

When a user signs in with a passkey:

The device proves ownership of a private key
The server verifies the cryptographic signature
The user is authenticated successfully

At that moment, the system knows:

A valid credential was used.

However, the system does not know:

Whether the interaction is automated
Whether a bot controls the browser
Whether an AI agent triggered the action

Passkeys prove device ownership, not human presence.

Why This Distinction Matters

Modern bots rarely try to guess passwords anymore. Instead, they operate through automated browsers or scripts that interact with websites exactly like real users.

Examples include:

automated account creation
ticket scalping bots
ecommerce checkout bots
API scraping bots

These bots can operate after authentication succeeds.

Most automated abuse happens inside authenticated sessions.

This means a system using passkeys can still experience bot-driven activity.

A Simple Example

Imagine a user logs into a website using a passkey.

The authentication process is secure and successful.

Now consider two scenarios:

A real human navigates the site normally.
A bot script controls the browser and performs automated actions.

From the authentication system's perspective, both sessions look valid.

The passkey successfully verified identity in both cases.

Authentication alone cannot distinguish humans from automated behavior.

The Key Insight

Passkeys are a major improvement for authentication security. They eliminate passwords and prevent many common attacks.

However, they do not replace bot detection systems.

Passkeys solve authentication.
Human verification requires additional security layers.

Understanding this difference is essential for building secure modern applications.

4. What Problem Passkeys Actually Solve

Passkeys were designed to solve the weaknesses of password-based authentication. They replace passwords with device-bound cryptographic credentials that are resistant to phishing and credential theft.

Passkeys solve authentication security problems, not bot detection problems.
They eliminate passwords while improving login success and security.

Passkeys are based on the FIDO and WebAuthn standards. These standards use public-key cryptography instead of shared secrets like passwords.

When a user registers a passkey:

The device generates a public-private key pair.
The private key stays securely on the user’s device.
The public key is stored on the server.

During login, the server sends a challenge that the device signs with the private key. The server verifies the signature using the stored public key.

The private key never leaves the user’s device.

Password Elimination

Passwords have been the weakest link in authentication for decades.

Common password problems include:

password reuse across services
weak passwords chosen by users
password database breaches
phishing attacks stealing credentials

Microsoft reports that more than 99% of identity attacks involve passwords.

Passkeys remove passwords entirely from the authentication process.

No password means nothing for attackers to steal or guess.

Phishing Resistance

Traditional phishing attacks trick users into entering credentials on fake websites.

Passkeys prevent this because authentication is tied to the website’s domain.

If a phishing site tries to trigger passkey authentication:

The browser detects the domain mismatch.
The passkey will not authenticate.

Passkeys are inherently phishing resistant.

This makes them far more secure than passwords, SMS OTPs, or many MFA systems.

Device-Bound Authentication

Passkeys are stored securely on the user’s device.

They rely on hardware-backed security features such as:

secure enclaves on smartphones
trusted platform modules (TPM) on computers
biometric authentication like Face ID or fingerprint

The authentication process requires the user to unlock the device.

This ensures the device owner is present during login.

Passkeys combine device possession with biometric verification.

Improved User Experience

Passwords introduce friction during login.

Users often forget passwords, reset them, or struggle with password policies.

Passkeys simplify login significantly.

Typical passkey login flow:

User enters username or email.
Device prompts biometric verification.
Authentication completes instantly.

Microsoft reports that passwordless authentication achieves 95% login success rates, compared to much lower success rates for password logins.

Passkeys improve both security and usability.

Protection Against Credential Theft

Credential stuffing attacks rely on leaked password databases.

Attackers reuse stolen passwords across multiple services.

Passkeys eliminate this attack vector because:

There is no shared secret to reuse.
Each passkey is unique to a specific domain.

Even if one service is compromised, the passkey cannot be reused elsewhere.

Passkeys eliminate credential reuse attacks entirely.

5. What Problem Passkeys Do NOT Solve

Passkeys dramatically improve authentication security. They prevent phishing, password theft, and credential reuse. However, they do not stop automated behavior or bots operating after login.

Passkeys verify identity credentials, not user behavior.
Bots can still interact with systems after authentication succeeds.

This distinction is important because most modern automated attacks no longer focus on breaking authentication. Instead, they target the application layer after login.

Passkeys Do Not Detect Automated Browsers

Modern bots often run inside automated browsers that behave like real users.

These tools include:

Selenium
Puppeteer
Playwright
headless Chrome

These automated browsers can load web pages, click buttons, submit forms, and interact with applications exactly like a human user.

Once authentication succeeds, the system sees only normal requests.

Passkeys cannot distinguish between human actions and automated browser actions.

Passkeys Do Not Detect Scripted Sessions

Many automated attacks occur inside valid authenticated sessions.

Examples include:

automated product purchases
fake account activity
automated social media posting
scraping user data

These actions happen after authentication has already succeeded.

From the server’s perspective, the requests are coming from a valid session.

Passkeys do not evaluate how a session is being used.

Passkeys Do Not Detect API Automation

Modern applications rely heavily on APIs.

Bots often interact directly with APIs instead of web interfaces.

For example:

automated scraping tools
mobile app reverse engineering
automated account creation
bulk data extraction

If the API accepts valid tokens or session cookies, the requests may look legitimate.

Passkeys secure login but do not analyze API behavior.

Passkeys Do Not Detect AI Agents

The rise of AI-driven automation introduces a new category of automated activity.

AI agents can:

navigate websites
interact with forms
simulate user actions
trigger workflows automatically

These agents may operate inside authenticated sessions.

Because authentication was valid, the system cannot easily distinguish between human actions and automated actions.

Passkeys authenticate the device, not the actor controlling it.

Passkeys Do Not Analyze Behavior

Human verification systems often rely on behavior signals.

These signals may include:

mouse movement patterns
typing speed
navigation patterns
request timing

Passkeys do not analyze these signals.

They only verify the cryptographic credential during login.

Passkeys do not evaluate behavioral patterns.

Passkeys Do Not Detect Intent

A valid login does not guarantee safe behavior.

A user may log in successfully and then perform malicious actions.

Examples include:

scraping competitor data
abusing APIs
automating high-volume transactions
launching spam campaigns

Authentication confirms identity, but it does not validate intent.

Intent can only be inferred through behavioral analysis.

The Key Insight

Passkeys solve one specific problem extremely well: secure authentication.

They eliminate passwords and significantly reduce account takeover attacks.

However, modern systems face additional challenges that occur after authentication.

Bots, automated scripts, and AI agents often operate inside valid sessions.

Passkeys secure the login event, not the entire user session.

To detect automation, systems need additional mechanisms such as:

bot detection systems
behavioral analysis
device fingerprinting
runtime identity evaluation

Understanding these limitations is essential when designing modern security architectures.

6. How Bot Detection Actually Works

Bot detection systems are designed to distinguish automated traffic from human users. Unlike authentication systems, bot detection focuses on analyzing behavior, patterns, and environmental signals.

Bot detection identifies automated behavior, not identity credentials.
Human verification depends on analyzing how a system is used.

Modern bot detection systems combine multiple techniques to detect suspicious activity.

CAPTCHA Challenges

CAPTCHA systems were originally designed to separate humans from automated scripts. The name CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart.

CAPTCHA systems challenge users with tasks that are assumed to be easy for humans but difficult for machines.

Examples include:

selecting images with traffic lights
typing distorted characters
solving puzzles

These tests attempt to ensure that the actor interacting with the system is human.

CAPTCHA systems challenge interaction rather than identity.

Behavioral Analysis

Behavioral analysis examines how users interact with a website or application.

Human users behave differently from automated scripts.

Common behavioral signals include:

mouse movement patterns
typing speed and rhythm
navigation flow across pages
click timing and interaction speed

Bots often generate extremely regular patterns that differ from human behavior.

Human behavior contains randomness that automated scripts struggle to replicate.

Behavioral analysis systems monitor activity throughout the session to detect anomalies.

Device Fingerprinting

Device fingerprinting identifies unique characteristics of a device and browser environment.

This technique collects signals such as:

browser type and version
operating system
screen resolution
installed fonts and plugins

These attributes can create a fingerprint that helps identify automated tools.

Bots often use headless browsers or simplified environments that differ from real user devices.

Device fingerprints help detect suspicious environments.

Rate Limiting

Rate limiting controls how frequently requests can be made to a system.

Bots often send large volumes of requests in short periods of time.

Rate limiting can prevent excessive traffic from automated sources.

Examples include:

limiting login attempts
restricting API request frequency
blocking repeated requests from the same IP address

Rate limiting reduces automated abuse by controlling request volume.

Network Reputation Analysis

Many bot detection systems analyze the reputation of IP addresses and networks.

Signals may include:</p