DEV Community: Daniel J

Rebuilding Houston's Courier: New Site, Driver Portal, and a Dispatch System in Progress

Daniel J — Thu, 03 Sep 2026 15:38:30 +0000

Houston's Courier has been moving freight and time-critical deliveries around the Gulf Coast for decades. Their website had not kept up. This is what we rebuilt, what we surfaced, what we added, and what is still on the bench.

Starting with the part customers see

The old site was nearly a decade old. It had a mobile layout — it just did not work properly, with errors throughout that got worse the smaller the screen got. Underneath that, the site was thin where it counted: very little SEO foundation and effectively no structured data, so search engines had to guess at what the business did, where it operated, and what services it offered.

The service list had also fallen behind. Not because the company changed direction — Houston's Courier does what it has always done — but because it kept adding capabilities and the website never caught up. Work they were actively selling simply was not on the site.

The new site is a ground-up replacement: same-day delivery leads, the catalog reflects everything the company actually offers in 2026, structured data describes the business properly, and the client login sits on the homepage instead of behind a hostname nobody could remember.

One service the site was hiding, and one that is coming

A courier already sends a bonded, uniformed, background-checked person to a customer's door with a package. That position turns out to be worth more than a single delivery.

Mobile notary — already offered, never advertised. This is not a new service line; Houston's Courier has been doing it. It was nowhere on the old website. Documents that need a notary are frequently the same documents that need a courier, so one visit covers both — and the company was earning none of the search traffic for it, because as far as Google was concerned the service did not exist.
Electronic ID verification for age-restricted deliveries (18+ and 21+) — built, not yet launched. Alcohol, tobacco, vape, and certain pharmacy items carry a legal obligation to verify age at handoff. This is a genuinely new capability rather than an unadvertised one, and it ships with the new dispatch system described below — it is not orderable today.

Those two are worth separating clearly, because they are different kinds of work. One was a marketing failure with an easy fix — the service existed, the website just never said so. The other required building something that did not exist, and it launches when the new system does.

The driver portal, where the compliance actually happens

"We verify ID" is a claim. The driver portal is the evidence. Drivers work from a portal built for a phone in one hand and a package in the other:

Barcode scanning off the air bill. The driver scans rather than types. That kills transposed tracking numbers, which are the single most common cause of a package that is physically fine and administratively lost.
Photo delivery confirmation. A timestamped photo at the drop point, attached to the stop. "It was left at the side door" stops being a memory and becomes a record.
Electronic ID verification at handoff, over a secure network. Launching with the new system: the age check is performed and captured electronically at the point of delivery and transmitted over an encrypted connection — not written on a signature sheet, not photographed and emailed, and not reconstructed from memory weeks later when someone asks for proof.

The through-line is that each of these replaces something a driver used to remember with something the system holds, securely. That matters most on the day a client disputes a delivery: the answer is a record retrieved in seconds, rather than a phone call to a driver who has made two hundred stops since.

Dispatch: replacing the system, not skinning it

The largest piece of this engagement is roughly two-thirds built, and it is worth being precise about what it replaces.

Dispatch, driver management, and the customer portal all lived inside one integrated legacy application on manage.houstonscourier.com. That coupling is the problem. Every change to how dispatchers work risked the customer-facing side, and every change a customer noticed had to be regression-tested against dispatch. Nothing could be improved in isolation.

The replacement is a standalone system with three separate surfaces:

Admin and dispatcher — order intake, assignment, and the live board dispatchers work from all day.
Driver — the portal above: scanning, photo confirmation, electronic ID capture.
Client — and this one goes into the new website rather than beside it. Customers place and track orders on the same domain they landed on, not on a subdomain that looks and behaves like different software, because it was.

Three things ship with it:

A suite of new security controls across all three surfaces. A system holding delivery addresses, signed proof-of-delivery, and age-verification records is holding sensitive data, and the legacy application was not designed with that in mind.
A far easier experience end to end — from submitting an order to paying the invoice. The old flow worked if you already knew it. The new one does not require that.
Continuous route optimization using the current Google Maps platform APIs, re-optimizing as the day changes rather than planning once in the morning and hoping. Traffic in Houston does not hold still, and neither should the route.

Splitting one application into three surfaces on a shared core costs more up front than restyling the old one. It buys the ability to change a dispatcher's workflow on a Tuesday without touching anything a customer can see.

No AI in the workflow. That is a decision, not an omission.

It is worth stating plainly, because in 2026 the default assumption runs the other way: no AI touches the day-to-day operation of Houston's Courier. Every delivery ticket, every email, every phone call, and every delivery is handled by a real person.

The software's job here is to remove clerical work and to remember things accurately — scan instead of type, capture instead of recall, re-optimize a route as conditions change. The judgment calls stay with the dispatchers and drivers who know the accounts, the buildings, and which receiving dock actually opens at 7am.

For a same-day courier that is not nostalgia, it is the product. When a delivery is time-critical and something goes wrong, the customer wants a person who can fix it — not a queue.

What the search numbers did

A rebuild is a genuine risk to organic search. New URLs, new structure, and a decade of accumulated signals to carry across — sites lose traffic doing this. Six months on, compared against the six months before:

Impressions: 153K → 273K, up 78%
Clicks: 3.05K → 3.84K, up 26%

Worth reading those two together rather than separately. Impressions grew faster than clicks, which means the site now surfaces for a far wider set of queries — including broader, higher-funnel searches that were previously out of reach entirely and that convert at a lower rate by nature. Average click-through moved from about 2.0% to about 1.4% as a result. That is the arithmetic of a site appearing in a great many more places, not a site getting worse at earning the click, and the number that pays the bills — actual visits from search — is up by roughly 790 a month.

A good share of that is the unglamorous work: real structured data, a service catalog that lists the services, and pages for offerings like mobile notary that were previously invisible to search entirely.

Still to come

The dispatch and portal build is about two-thirds done. The remaining third is the part that has to be right rather than fast: cutting live operations off the legacy system without dropping an order mid-flight, and moving the client portal into the new site so customers stop seeing two different pieces of software.

Age-restricted delivery goes live at the same time, with its own service page — there is no point advertising a capability before the system that performs it is carrying real traffic.

We will write that up when it ships, including whatever goes wrong on the way.

Houston's Courier is a Tuxxin LLC client. If you are running a business on software a decade past its service life — and you can usually tell, because everyone has a workaround for it — get in touch.

Is curl | bash Safe? What qsa.sh Does Instead

Daniel J — Thu, 03 Sep 2026 12:52:57 +0000

You have seen the pattern in a hundred install docs:

curl https://example.com/install.sh | bash

It is convenient. It is also the single most-argued line in DevOps. Before you paste it into a root shell, it is worth being precise about what it actually does — and about what curl qsa.sh does not do, because the two look similar and are not the same thing at all.

What `curl <url> | bash` actually does

The pipe does exactly what it says. curl fetches whatever bytes the server sends, and bash executes them as a shell script — on your machine, with your privileges, right now. There is no preview, no diff, no confirmation step. Whatever the server returns is the program that runs.

That is not a hypothetical. It is arbitrary local code execution by design. The risk is not that the pattern is broken; it is that it works perfectly and hands full trust to a remote party. Specifically:

You cannot see what you ran. By the time the script executes, you have already run it. Auditing after the fact is not auditing.
Trust extends to the whole chain. You are trusting the domain, its TLS, its DNS, the CDN in front of it, and anyone who can compromise any of those. A server can also detect a piped shell (no TTY) and serve different bytes than it shows in a browser — this has been demonstrated publicly.
Failure modes get worse. A truncated download can leave a half-run script. sudo curl ... | bash runs remote code as root.

To be fair — and this matters — curl | bash is not automatically malicious. Downloading a release binary, an apt package, or a container image is also "run code you didn't read." The pattern's real sins are that it skips the checkpoint where you could have looked, and that it re-fetches live every time, so a good script today can become a bad script tomorrow with nothing pinned.

The safer way to run an install script

If you are going to run one, split fetch from execute so there is a moment to look:

curl -fsSL https://example.com/install.sh -o install.sh
less install.sh          # actually read it
sha256sum install.sh     # compare to a published checksum, if any
bash install.sh

Not glamorous. But now there is a checkpoint, and you are running a known artifact instead of a live stream. Prefer signed packages or checksummed binaries when the project offers them.

Why `curl qsa.sh` is a different animal

Here is the part people conflate. curl qsa.sh is not curl qsa.sh | bash. There is no pipe into a shell, and there is nothing on our end that expects one.

curl qsa.sh makes an HTTP request and streams text back to your terminal. That text is a scan report. Your shell prints it, the same way it would print a README. No script is downloaded to be executed, no code runs on your machine, and adding | bash would accomplish nothing useful because the output is a human-readable report, not a program.

The work happens on our side, not yours:

The scan runs from qsa.sh's own real, attributable scanner IP (reverse-DNS scanner.qsa.sh) — an outside-in view, exactly what an external attacker sees.
It scans only the public IP you are connecting from. There is no target field; you cannot aim it at anyone else. Your IP is shown with a countdown before anything starts.
The engine is the same open-source tooling you could run yourself: naabu for port discovery, nmap -sV --script vulners for service/version and CVE matching, then nuclei for templated checks (current engine versions). No black box.
Zero retention: results stream to your terminal and are gone. No stored scan output, no stored IPs, no user-agents, no history.

So the trust question inverts. With curl <url> | bash, the remote server runs code on your machine. With curl qsa.sh, your machine runs nothing — it just displays what our scanner found looking at your public IP from the outside.

Side by side

	`curl <url> \| bash`	`curl qsa.sh`
What comes back	A shell script	A text report
What runs it	Your shell, on your host	Nothing — it is printed
Where code executes	Your machine, your privileges	Our scanner, server-side
What it can touch	Your filesystem, your creds	Only your public IP, from outside
Retained	Whatever the script writes	Nothing

A fair caveat, because this is a security site

You should still know who you are talking to. curl qsa.sh streams text and runs nothing locally — that is true whether you trust us or not, because the output never touches your shell as code. But the report itself comes from us, so treat qsa.sh like any external scanner: it is a starting point, an attacker's-eye view of your exposed surface, not a full audit.

One practical note: plain curl qsa.sh is HTTP. To encrypt the request and response in transit, use curl https://qsa.sh. Same scan, same report — just protected on the wire. On a network you do not control, prefer the https:// form.

The short version

curl <url> | bash is not evil, but it is arbitrary local code execution with no checkpoint — read it, checksum it, or use a signed package first. curl qsa.sh is not that pattern: it prints a report, runs no local code, and does its scanning from our own IP against only your public IP.

Run it and read the output:

curl https://qsa.sh

See how it works, what we do and don't retain, or what the paid tiers add.

OAuth Consent Phishing: The Attack a Password Change Does Not Fix

Daniel J — Thu, 03 Sep 2026 08:07:27 +0000

The FBI's Internet Crime Complaint Center published PSA I-090126 on September 1, 2026, and it describes an attack that quietly defeats the two things most people rely on: changing your password, and having multi-factor authentication turned on.

Neither one helps here. That is not a flaw in either — it is that this attack never touches your password at all.

What consent phishing actually is

You have almost certainly done the legitimate version of this. You sign into some service with “Continue with Google,” a permission screen appears listing what the app wants — read your email, see your files, post on your behalf — and you click Allow. That grant is an OAuth token. It is how a scheduling tool reads your calendar without ever knowing your password.

Consent phishing is the same flow with a hostile app at the end of it. The attacker registers a real application with a real provider, requests broad permissions, and sends you a link. You land on a genuine login page — the actual Google or Microsoft one, correct domain, valid certificate — and authenticate normally. Then the permission screen appears, and if you approve it, the attacker holds a token that reads your mail and files whenever it likes.

The IC3 is blunt about the consequence. The access “can only be revoked by the victim invalidating the token in their application security settings; not by changing the password.”

Why your usual response does nothing

Think about what you would do if you suspected an account compromise. Change the password. Check MFA is on. Sign out other sessions, maybe.

None of that revokes an OAuth grant.

Changing your password does not invalidate the token. The token was never derived from your password.
MFA does not stop it. You completed MFA yourself, correctly, on the real login page. The attacker never needed to defeat it — you satisfied it and then handed over a key on the next screen.
There is no suspicious login to spot. The app is calling an API with a valid token, not signing in from a strange country. Your login history looks clean.
Nothing expires on a useful timescale. A refresh token can stay valid for months or longer, renewing itself quietly.

That last point is the one worth sitting with. This is not a break-in you notice and clean up. It is a key you handed out, filed under a permission screen you closed and forgot — genuinely out of sight, out of mind.

Who is being targeted

The PSA names prominent individuals, their family members, and personal acquaintances, approached through ordinary commercial messaging apps rather than email. The pretexts impersonate government officials, media figures, and event coordinators, and the ask is mundane: review this document, verify your identity, confirm attendance.

Family and acquaintances are in that list deliberately. If you are hard to reach directly, the people around you are the way in.

Go audit your grants — this is the useful part

Whether or not you have been targeted, this is worth twenty minutes. Most people have not looked at these lists in years, and find things they no longer recognize: a trial from four jobs ago, a plugin that asked for far more than it needed, a “free analyzer” that still reads everything.

Google — myaccount.google.com/connections. Sort by access level. Anything holding Gmail or Drive read access deserves a hard second look.
Microsoft / Entra — myapps.microsoft.com, then My Account → Privacy → Apps and services.
LinkedIn — Settings → Data Privacy → Permitted services.
GitHub — Authorized OAuth Apps, and check Installed GitHub Apps separately — they are two different lists and people routinely check only one.
Dropbox, Slack, Zoom, Meta — all keep an equivalent connected-apps page.

Revoke anything you do not actively use. Revocation is instant and free; if you break something you still need, you reauthorize it in a click. That asymmetry is the whole argument for being aggressive here.

What good scrutiny looks like

The moment that matters is the permission screen, and it is over in about two seconds. Slow it down:

Read the scopes, not the app name. The name is chosen by whoever registered the app and can be anything. The permissions are the truth. A PDF viewer does not need to send mail as you.
Ask why this needs an account at all. Reviewing a document rarely requires read/write access to your entire mailbox.
Verify the sender out of band. Not by replying to the message — through a number or address you already had.
Treat urgency as the tell. A deadline attached to a permission request is doing a job.

If you think you clicked Allow

Revoke the grant first, on the provider's connected-apps page. Do this before anything else — until the token is gone, the access continues.
Then change the password and re-check MFA. In that order; the reverse accomplishes nothing on its own.
Check mailbox rules and forwarding. A common follow-up is a quiet auto-forward or a rule that files security alerts straight into the trash.
Review sent mail. Access is frequently used to phish your contacts from your real address.
Report it — your local FBI field office, or ic3.gov.

The honest tension

Worth saying plainly: OAuth consent is not the problem. It is a genuine improvement over the thing it replaced, which was typing your actual password into third-party sites and hoping. Every grant that reads your calendar without knowing your password is that design working.

The weakness is that one screen carries an enormous amount of meaning and gets about two seconds of attention, and that what it hands over is durable in a way people do not expect. A password is something you can change. A consent grant is something you have to remember you gave.

So put it on the calendar. Once or twice a year, open those pages and prune. It takes twenty minutes and it is the only maintenance that actually closes this class of access.

issued.live is live

Daniel J — Thu, 03 Sep 2026 08:07:19 +0000

issued.live is open to the public today. This note is about how it is built and why it behaves the way it does, because those choices are the difference between a lookup you can rely on and one that quietly guesses.

Where the corpus stands

At launch the index holds 334 million domains and ingested roughly 15.9 million certificates in the preceding twenty-four hours, reading 56 of the 58 known Certificate Transparency logs. Ingest sustains tens of thousands of entries per second. Every domain's DNS is re-scanned on a rolling cycle so a record reflects a confirmed observation rather than a lookup performed while you wait.

Observational, not authoritative

The most important design decision here is what this service refuses to do.

We publish what we saw and when we saw it. We do not reconcile that against a registry, we do not fill gaps with plausible values, and we do not derive one field from another because the shapes happen to fit. Where we hold nothing, the field is null and the interface says so in words. A blank that means "unknown" and a blank that means "does not exist" are different facts, and collapsing them is how a monitoring tool starts lying to the person depending on it.

This is also why every record carries last_update. Freshness is yours to judge, not something you have to take on trust.

Built to be read by machines first

Most of what queries this service will not be a browser. So the same record is served three ways from one URL: JSON by default, Markdown by appending .md, and the Model Context Protocol at /mcp for agents that would otherwise scrape a page built for human eyes. Six MCP tools are exposed, three of which need no credential at all.

There is a /llms.txt at the root describing what is worth fetching, and the site root answers plain text to a terminal rather than dumping statistics at it. None of this is decoration — an agent that has to parse layout is an agent that breaks on the next redesign.

Free by default

A thousand domain lookups a day require no key, no account, and no sign-up. The rolling certificate feed and the corpus statistics are open on the same terms. A free key exists only for the reverse direction — asking which names sit on an address or a range, and following newly registered domains — because those queries are expensive to answer and worth rate-limiting honestly rather than degrading for everyone.

What comes next

Coverage of the remaining CT logs, longer retained history on address changes, and a tighter DNS re-scan interval as capacity allows. If something looks wrong in a record, that is worth reporting — a wrong observation is a bug here, not a rounding error.

Documentation lives at /developers. issued.live is built by Tuxxin.

issued.live: Certificate Transparency, ICANN Registrations and DNS in One API

Daniel J — Thu, 03 Sep 2026 08:05:57 +0000

Every certificate issued for every domain on the public internet gets written to a public log. Anyone can read them. Almost nobody does — because the raw feed is a firehose of tens of thousands of entries a second, and a certificate on its own doesn’t tell you much.

That’s the gap issued.live fills. It reads the Certificate Transparency logs continuously, joins them to ICANN zone-file registration data and to its own DNS scans, and keeps the result as one record per domain with a trail of what changed to get there.

It’s live now, and domain lookups are free with no key and no sign-up.

One record for one domain — certificate, hosting, network, and when each of those was last confirmed.

One URL, three ways to read it

The thing we care most about here is that the same record is available in whatever shape the thing asking for it actually wants. There are three, and they are the same data underneath.

1. JSON, for a script

Point curl at any domain:

curl issued.live/tuxxin.com

{
  "domain": "tuxxin.com",
  "registered": null,
  "expires": null,
  "ssl_expires": "2026-11-28T10:58:19Z",
  "ssl_cert": "431095AFAB96BC5C282ED931FC907068",
  "ssl_issuer": "Google Trust Services",
  "ip": "104.21.65.210",
  "last_update": "2026-08-30T11:16:06Z",
  "first_cert_seen": "2026-08-14T07:47:20Z",
  "tracked": false
}

That ssl_cert value is a stable identifier for the exact certificate, which is more useful than it looks: it lets you tell a genuine reissue from a routine renewal without diffing the whole chain. And last_update is there so you can judge freshness yourself rather than trusting that the record is current.

2. Markdown, for a human or a language model

Append .md to any lookup and you get the same record as a document — certificate, registration, hosting, address history and DNS records, as tables:

curl issued.live/tuxxin.com.md

This exists because a model quoting from a page wrapped in navigation and CSS gets it wrong more often, and burns a pile of tokens doing it. The markdown form is the same data at a fraction of the size. There’s a /llms.txt at the root that maps what’s worth fetching.

3. MCP, for an agent

issued.live speaks the Model Context Protocol directly, so an assistant can query it as a tool rather than scraping pages. Six tools are exposed:

lookup_domain — the full certificate and DNS record for one domain.
recent_certificates — a rolling 30-minute window of certificates as they are logged.
corpus_stats — how much the corpus holds and how fresh it is.
domains_on_ip — reverse lookup: which hostnames have been seen on an address. (key required)
domains_in_range — the same across a small CIDR range. (key required)
new_domains — newly registered domains from the ICANN zone-file feeds. (key required)

And there is, of course, the website — server-rendered, nothing behind a login, no client-side rendering step.

Three streams, joined

What makes a record worth reading is that it isn’t one source.

Certificate Transparency logs give you certificates as they are issued. ICANN zone-file feeds give you domains as they are registered. DNS scanning gives you where a name actually points — every domain in the corpus is re-scanned for freshness on roughly a 48-hour cycle, merged across four vantage points, so what you get is a confirmed observation rather than a live lookup you have to wait on.

Joined, those answer questions none of them answer alone: what a domain looks like right now, what addresses it has rotated through, and what has just appeared that didn’t exist yesterday.

What a null means

This is the part we’d point at if you only read one section.

Registration dates come from zone-file feeds, and they are genuinely absent for a lot of names. So registered: null means “we do not hold this” — it never means “this domain is not registered.” The record will not guess, and it will not quietly infer a registration date from a certificate date, because those are not the same thing and treating them as such produces confident nonsense.

Same discipline on first_cert_seen: it’s the first time any CT log carried a certificate for that name. An old domain that only recently got its first certificate will show a recent date there. That’s not a bug, it’s what the field means.

Every page says the same thing in plain language: this is an observation drawn from public logs — what was seen, and when.

Feeds and reverse lookups

Two feeds need no key at all. /api/feed is a rolling 30-minute window of certificates, newest first. /api/stats is corpus-wide counts — domains known, certificates in the last 24 hours, ingest rate, per-TLD breakdown and log health — served from a snapshot regenerated every ten minutes, so it’s cheap to poll.

The reverse questions need a key, and it’s free: /api/v1/ip/{ip} and /api/v1/range/{cidr} answer which domains resolve to an address or a small range, and /api/v1/nrd is the newly-registered-domain feed. That’s the half that matters for brand protection — a look-alike domain and its fresh certificate usually go live minutes before the first victim ever clicks.

Scale

At the time of writing the corpus holds 334,121,692 domains, saw 15,892,349 certificates in the preceding 24 hours, and is reading 56 of 58 known CT logs. Ingest runs in the tens of thousands of entries per second.

A thousand lookups a day need no key whatsoever. Beyond that, or for the reverse-IP endpoints, a key is free — just ask.

Try it

Pick any domain you own and run:

curl issued.live/yourdomain.com

If the certificate expiry surprises you, that’s the point.

issued.live — full API documentation at issued.live/developers. It joins qsa.sh, whack.sh and worldip.io in the Tuxxin Stack.

curlhub Now Speaks MCP: Correctly Quoted curl for AI Agents

Daniel J — Thu, 03 Sep 2026 08:05:28 +0000

curlhub.sh is now a Model Context Protocol server. If you use Claude Desktop, Cursor, or anything else that speaks MCP, your assistant can call curlhub as a tool instead of guessing at syntax and handing you something that almost works.

Point your client at it

One line of config. No key, no signup:

{ "mcpServers": { "curlhub": { "url": "https://curlhub.sh/mcp" } } }

The endpoint is https://curlhub.sh/mcp — JSON-RPC 2.0 over HTTP POST, sharing the same keyless quota as the rest of the site: 60 requests a minute per IP.

The tool: getting curl quoting right

There is one tool, validate_and_format_curl(url, method?, headers?, data?), and it exists because of a specific, boring failure that costs people real time.

Language models write curl commands constantly, and they get the quoting wrong. Not often — but when they do, it fails silently. Consider a header value containing an apostrophe:

curl -H 'X-Note: it's fine' https://api.example.com

That apostrophe closes the quoted string. The shell now sees X-Note:, its, and fine as three separate words, and the command either errors confusingly or — worse — runs and does something you did not ask for. Nothing about the text on your screen looks wrong.

curlhub builds the command by construction instead. Every interpolated value is wrapped in POSIX single quotes, with embedded single quotes rendered as '\'' — close the quoted run, emit an escaped literal quote, reopen. Inside single quotes the shell treats every other byte literally, so $, backticks, backslashes, semicolons, newlines and globs are all inert. There is exactly one metacharacter to handle, and it is handled. That is the whole trick, and it is why the result is correct rather than usually-correct.

The same request, formatted properly:

curl -H 'X-Note: it'\''s fine' 'https://api.example.com'

What it refuses

Some things should not be escaped into looking fine. These return a 400 with a reason instead of a command:

Non-http(s) schemes. curl also speaks file://, gopher:// and dict://. A generated command reaching for a local file is a footgun, so we will not write one.
Control characters in a URL or header name. Quoting makes them shell-inert but not terminal-inert — an escape sequence can make a pasted line render differently from how it executes.
Header names that are not RFC 9110 tokens, and non-UTF-8 input.

Bodies use --data-binary, not -d

A detail worth stating because it silently corrupts JSON: -d strips newlines and carriage returns, and treats a leading @ as a filename. Generated commands use --data-binary, so your body survives intact.

You do not need an agent

The same thing works over plain HTTP, and returns text to curl and JSON to an API client at the same URL:

curl -s https://curlhub.sh/format-curl \
  -H 'Accept: application/json' \
  -d '{"method":"POST","url":"https://api.example.com","data":"{}"}'

Nothing is fetched and nothing is stored — it is a pure transform, and no outbound connection is ever made. Because of that, private and link-local targets are allowed: building a command for 127.0.0.1 or 169.254.169.254 is a normal developer task, not a request we need to police.

In-browser agents too

Pages here also register the same tool through document.modelContext, the emerging W3C browser API — native in Edge 147, and in Chrome 149 behind its origin trial. That call is same-origin, so it uses your existing session and quota and no key ever enters the model's context.

Discovery

The server advertises itself the standard ways: a Link header with rel="mcp" on every response, and a server card at /.well-known/mcp/server-card.json. Machine-readable documentation for agents lives at /llms.txt.

#4 on MalwareBazaar — what that proves, and what it does not

Daniel J — Thu, 03 Sep 2026 08:04:48 +0000

whack.sh launched on August 6th. Nearly three weeks in, it is the fourth-largest contributor to abuse.ch MalwareBazaar over the trailing thirty days — listed alongside GovCERT.ch, Switzerland's national computer emergency response team, and researchers with unbroken streaks going back two, three and six years.

We did not set out to climb a leaderboard. But it is a useful thing to be able to point at, so here is what it does and does not mean.

What we have contributed

Every payload our scanners trip is captured, defanged, hashed and given back to the community's threat-intel platforms. Free, no account, no gate — the same feeds every defender already uses:

780 samples to MalwareBazaar
2,975 indicators to AlienVault OTX
673 samples to VirusTotal

Those are per-platform counts, not three slices of one number and not a total to be added up — a single sample frequently goes to more than one destination, and OTX counts indicators rather than payloads alone. The live figures, the family breakdown and the SHA-256 list are on our threat-intel contributions page, which updates every six hours.

What is actually in it

Twenty-four distinct families so far, and the shape is worth being honest about:

Mirai — 418 samples (55%)
Unclassified — 219 (28%)
CoinMiner — 52
ConnectWise, Vidar — 13 each
A long tail: PureLogsStealer, RemusStealer, njrat, AgentTesla, Formbook, AsyncRAT, QuasarRAT, Amadey, MassLogger and a dozen more, down to single samples

Mirai dominating is not a surprise and it is not a boast. Mirai droppers are among the most widely distributed payloads on the internet, and any pipeline pointed at live malicious URLs will surface them in volume. If you want to read that skew as "a lot of one common thing", that is a fair reading.

What this proves, and what it does not

The honest claim is narrow, so we will make it precisely.

It proves the detection pipeline works on real, current, live malware. Not on a curated test corpus, not on samples from a paper. These are payloads that were being served to real visitors at the moment we captured them, on infrastructure that was live, verified independently by three separate platforms that had no reason to take our word for anything. When a scanner tells you a URL is hosting something dangerous, the reasonable question is whether it is right. This is the third-party answer to that question, and anyone can check it — the submissions are public and attributed.

It does not prove we are finding things nobody else could. A leaderboard measures volume, and volume is the easiest thing to measure. Much of this corpus originates from URLs that were already known to be malicious. Being fourth by count is a statement about throughput and coverage, not about novelty, and we would rather say so than let you infer otherwise.

The interesting work is the part that does not show up in these numbers yet, and we will write about it when we can show it rather than assert it.

Why give it away

Every sample we contribute makes the feeds slightly better for everyone, including people who will never pay us anything, including our competitors. That is the correct trade. Threat intelligence that only circulates among paying customers protects the people who can afford it and leaves everyone else carrying the same risk with less warning. The economics of malware distribution already favor the attacker; hoarding indicators widens that gap.

abuse.ch in particular runs a set of platforms that a very large part of the defensive internet quietly depends on, largely without funding and largely without credit. Contributing to MalwareBazaar is the cheapest possible way for us to be a net positive to that, and it costs us nothing we would not have spent anyway.

What is next

There is a structural gap in the public corpora that we keep running into: payloads gated behind traffic distribution systems are systematically underrepresented, because the thing that makes a TDS a TDS is that it does not serve to whoever asks. A scanner that looks like a datacenter gets a harmless page. Someone on a residential connection with the right referrer gets the payload.

We are building toward measuring that properly. When we have something demonstrable we will publish the measurements, not the conclusions.

In the meantime, the contribution page is live and public: whack.sh/malware-bazaar. If you are a researcher and want the SHA-256 list or the JSON, both are one click from that page, and you do not need an account.

Webshot Now Speaks MCP: Screenshots as a Tool for AI Agents

Daniel J — Thu, 03 Sep 2026 08:04:27 +0000

Webshot.site now speaks the Model Context Protocol. If you use Claude Desktop, Cursor, or anything else that talks MCP, your assistant can render a page and look at it directly — no copy-pasting URLs, no describing what you see.

Point your client at it

One line of config, no key, no signup:

{ "mcpServers": { "webshot": { "url": "https://webshot.site/mcp" } } }

The endpoint is https://webshot.site/mcp, JSON-RPC 2.0 over HTTP POST. It exposes a single tool:

capture_sandbox_webshot(url, viewport?, full_page?, format?)

Ask your assistant to "take a screenshot of example.com and tell me what's above the fold" and it will call that tool, get back an image, and answer.

Why it returns a link, not the image

The obvious implementation is to base64 the PNG and hand it straight to the model. We deliberately don't. A modest screenshot is 25–200 KB, which becomes a wall of base64 in the model's context window and crowds out the actual conversation. Most agents can't do anything useful with those bytes anyway.

So the tool returns a short JSON envelope with a link:

{
  "ok": true,
  "image_url": "https://webshot.site/shot/<token>",
  "format": "jpg",
  "mode": "desktop_viewport",
  "bytes": 26600,
  "credits": 1
}

The link is public, session-free and reusable — you can hand it to another tool, drop it in a ticket, or open it yourself. The token is 128 bits of randomness, so it is unguessable, and it is the only thing that authorises access.

You don't need an agent to use this

The same JSON envelope is available over plain HTTP. Add &response=json to a normal capture request:

curl -s 'https://webshot.site/api/capture?url=https://example.com&response=json'

Without that parameter the response is still the raw image, byte for byte as before. Nothing about the existing API changed — this is strictly additive.

Credits, not captures

Worth being precise, because this is the thing people plan around wrongly. The keyless allowance is 5 credits per 15 minutes per IP, and credits are not captures:

A viewport capture costs 1 credit
A full-page or custom-size capture costs 2
The default mode is desktop_full, which is full-page

So a default anonymous call spends 2 credits, and you get two of them per window rather than five. Pass full_page=false (or mode=desktop_viewport over HTTP) to spend 1 and get five. Output format does not affect cost. Your live bucket is always readable at GET /throttle-status.

If you need more, API plans start at $1.99/month and keys are issued immediately at checkout.

One caveat: it is slow, and that is fine

A capture is a real headless-Chrome render — it loads the page, waits for it to settle, and photographs it. That takes 10–60 seconds. Set your MCP client timeout to 90 seconds or more, or you will see spurious failures on perfectly good captures.

In-browser agents too

Pages on this site also register the same tool through document.modelContext, the emerging W3C browser API for exposing page capabilities to AI. That works natively in Edge 147 and in Chrome 149 behind its origin trial. Because the call is same-origin it uses your existing session and quota, which means no API key ever enters the model's context — a property worth having if you are handing tools to something that might quote them back at you.

Safety

The capture runs in an isolated sandbox, and private, loopback and cloud-metadata addresses are refused. Pointing it at a suspicious URL is the intended use: you get to see what a page looks like without your own browser going there.

Docs

Machine-readable documentation for agents lives at /llms.txt, and the full human reference — including the MCP section — is on the developers page.

iNetPanel 1.26: Debian 13 (Trixie) Support and an HTTPS Setup Wizard

Daniel J — Thu, 03 Sep 2026 08:04:06 +0000

iNetPanel 1.26.0 is out. It adds support for Debian 13 (Trixie) and serves the setup wizard over HTTPS. If you are running Debian 12, nothing changes and there is nothing you need to do.

Most of this release is the unglamorous work of making a clean install actually finish on a new Debian release. The interesting part is what broke, because almost none of it is specific to iNetPanel — if you self-host on Trixie you will hit several of these regardless of what panel you use.

Both Debian 12 and Debian 13 are supported

Debian 12 (Bookworm) left regular support on 11 July 2026 but stays on LTS until June 2028. There is no need to migrate an existing server. Debian 13 (Trixie) is now a first-class target, verified by a full clean install: install, create an account, issue DNS and a certificate, then delete the account.

What actually broke on Trixie

dnsutils no longer exists

dnsutils was a transitional package and Trixie dropped it. This was the first hard failure — the installer died before installing anything at all. The installer now uses bind9-dnsutils, which exists on both releases.

The PHP repository was pinned to bookworm

This one failed later and far more confusingly. The bookworm suite still resolves on Trixie, so the repository added cleanly and the error surfaced much further into the install: sury's bookworm build depends on libssl3, and Trixie ships libssl3t64 instead.

cloudflared deliberately stays on bookworm

Cloudflare publishes no Trixie suite. The bookworm package is a static Go binary with no dependencies, so it runs correctly on Trixie and pinning it there is the right call rather than a workaround. There is now also a direct .deb fallback, so a repository outage cannot abort an install part-way through.

PHP pinning is now built dynamically

phpMyAdmin depends on php-cli and php-mysql, which on Trixie resolve to a complete PHP 8.4 stack. The old pin only blocked 8.6 and above, so you could finish an install with two full PHP stacks side by side. The pin is now generated from the PHP version actually in use.

The setup wizard now uses HTTPS

The wizard collects your admin password and, a few steps later, your Cloudflare API key. Both previously travelled over plain HTTP. There was an HTTPS option, but it required running panel_ssl.sh by hand — which happens after those credentials have already been sent.

The installer now generates a self-signed certificate, serves the panel over TLS on port 443, and redirects HTTP. Your browser will warn you once; that is expected for a self-signed certificate and the closing message explains it. Replace it with a trusted certificate whenever you like:

inetp panel_ssl <hostname>

Fixes worth knowing about

Certificates could silently be self-signed on Debian 13

The worst kind of bug: it reported success. Trixie ships certbot 4.0, and certbot-dns-cloudflare 4.x removed support for the Cloudflare Global API Key. Issuance would fail, the panel would quietly fall back to a self-signed certificate, and then report the domain as done.

It now uses a scoped API token (Settings → Cloudflare), refuses rather than degrading, and verifies the certificate issuer before calling a domain complete.

inetp db_repair did nothing

MariaDB 11.x ships most mysql* compatibility symlinks but not mysqlcheck. The error was discarded, so the command reported zero tables checked and exited successfully.

Changing the SSH port could lock you out

Under systemd socket activation the listening port comes from ssh.socket, not sshd_config — but the safety check used sshd -T, which reads the config file. It now verifies the actual listener and keeps the socket unit in step.

WireGuard failed where iptables was absent

iptables is not a dependency of wireguard-tools, and firewalld 2.x no longer pulls it in. The NAT rules now prefer nft.

A newly added domain could return 503

An API request that omitted the PHP version reloaded a PHP-FPM service that did not exist, so the new pool's socket was never created. A related case: a domain set to inherit the panel default produced an invalid service name, and its FPM reload silently never happened.

Also in this release

install_LAMP.sh is now tracked in the repository, so it is covered by the same linting and secret scanning as every other script.

Upgrading

Existing Debian 12 servers are unaffected and need no action. To move an existing install onto HTTPS, run:

inetp panel_ssl <hostname>

iNetPanel is free and GPL-3.0. Full release notes and downloads are on GitHub.

The FBI QTFY Advisory: When Attackers Rent the Same Proxies You Do

Daniel J — Thu, 27 Aug 2026 19:38:02 +0000

On August 26th the FBI, NSA and US Cyber National Mission Force published joint advisory JCSA-20260826-01 on a China-linked group tracked as QTFY. It is marked TLP:CLEAR and is freely available in full. Everything attributed below is the advisory's finding, not ours — we are reporting on a public government document, and we did not independently verify its attribution.

We are writing about it because one detail in it speaks directly to how URL scanning works, and because we checked our own data against it and found nothing. Both halves are worth saying.

-Read more

curlhub.sh Curl Based CLI Dev Tools

Daniel J — Fri, 31 Jul 2026 18:40:00 +0000

A suite of developer tools you run with the curl you already have: UUIDs, hashes, JSON End-points, JWTs, JSON, QR, File Transfers and more. Nothing to install, and no signup required. "curl curlhub.sh" to see list of commands or visit https://curlhub.sh to view all tools full details and soon contribute.

root@web01:~# curl curlhub.sh
curlhub.sh  —  CLI-first developer utilities
Zero-setup tools you curl straight from the terminal.

Generators
  /uuid      RFC 4122 v4 UUID.
  /pass      High-entropy password / API key / token. CLI: server-side CSPRNG over TLS; web: client-side. Never logged. (https)

Utilities
  /qr        ANSI/UTF-8 QR code from ?data. Nothing stored server-side; use HTTPS or pipe stdin for sensitive payloads (a ?data= value appears in request URLs).

Encoding
  /b64       Base64 encode / decode. (https)
  /hash      MD5 / SHA-1 / SHA-256 / SHA-512 of input. (https)

Developer
  /json      Validate + prettify + colorize JSON. (https)
  /jwt       Decode & pretty-print JWT header/payload. No verify; token never logged. (https)
  /status    Explain an HTTP status code + troubleshooting.
  /cron      Translate a cron expression to English + next run times.
  /ua        Parse the User-Agent you sent (browser / OS / engine / device).
  /headers   Echo the request headers you sent (+ the edge view). Your own request, not a remote audit.
  /hook      Webhook inspector: mint a temp endpoint, inspect incoming HTTP. (https)

Text & Logs
  /md        Render Markdown to colorized ANSI (safe, bounded parser). (https)
  /p         Pastebin: pipe text/logs to a short URL (plaintext in terminal, highlighted on web). (https)

Network
  /cidr      Subnet / CIDR math: range, netmask, broadcast, host count.
  /ip        Your public IP (thin). Geo/ASN live at worldip.io.
  /whois     Domain registration / registrar / dates (public OSINT; rate-limited + cached).

Security
  /ssl       Decode a PEM certificate or CSR you paste (expiry, issuer, SANs, key). No outbound connection. (https)

File Transfer
  /u         Ephemeral file drop (<=100 MB). ANSI QR; auto-purge after 1 download or TTL. (https)

Docs
  /man       Community CLI cheat-sheet wiki (read-only over CLI).

Family
  /port      Port scan of your own IP → hands off to qsa.sh.
  /scan      Vulnerability / threat scan of your IP → hands off to qsa.sh.
  /urlscan   Multi-egress URL scan → hands off to whack.sh.

Details: curl curlhub.sh/help/<tool>   ·   Spec: curl curlhub.sh/spec
Family:  qsa.sh (audit your IP) · whack.sh (scan a URL) · worldip.io (IP intel)

Please feel free to leave a comment with feedback, feature requests, etc.

Whack.sh - Multi-egress URL Threat Scanner

Daniel J — Fri, 31 Jul 2026 17:50:09 +0000

Traffic Direction Systems (TDS) have become a massive headache for analysts. By fingerprinting IPs, attackers can dynamically route traffic—hiding malicious payloads from security tools while successfully targeting residential, mobile, or specific ASNs.

The problem? Almost every URL scanner out there uses datacenter-based egress IPs. Attackers know this, so they block or cloak against datacenter ranges.

I ran into this wall while investigating malware distributed via a lapsed corporate domain. The standard scanners were returning clean results or blocked pages, but my home connection was still being served malware. Doing the analysis manually was a massive bottleneck, so I built a solution: whack.sh.

What it does: Whack allows you to scan any URL simultaneously through multiple egress options: Datacenter, Residential, Mobile, VPN, and even BYO IP. It then diffs the captures (HAR files) to expose the cloaking, TDS routing, phishing, and malware that traditional datacenter-only scanners miss.
The Origin & Investigation: I’ve been working on this for over a month and have already run over 150,000 scans of known threat URLs. The early MVP was basic but proved the concept: diffing HAR files of the exact same URL across different categorized ASNs immediately exposed the evasion tactics.

I actually reported my initial findings on this specific threat to the FBI IC3 on Monday, June 15th. Three days later, IC3 pushed out a PSA specifically regarding TDS. (I’ll be publishing a few in-depth articles on my company's site detailing these findings in the coming weeks).

Under the Hood (TDS-over-TDS): One of the most interesting things the tool exposed during this process is that TDS isn't just happening at the redirect layer. I found several instances of TDS-over-TDS (redirect layer + payload delivery layer). Malicious actors are using real-time API calls or compressed local IP intelligence to serve entirely different payloads based on the exact environment (e.g., Windows vs. Mobile/Android/Chrome vs. Mobile/iOS/Safari).

Community Integration: I want this data to be useful to the broader community, so any threats found by whack.sh are automatically published to Abuse.ch: https://bazaar.abuse.ch/user/42023/

I’m putting the final polish on the site and planning to officially launch on or before August 4th. In the meantime, I would love to hear your thoughts on the concept! What features would you want to see, or what specific evasion tactics would you want to test against it when it goes live?

DEV Community: Daniel J

Rebuilding Houston's Courier: New Site, Driver Portal, and a Dispatch System in Progress

Starting with the part customers see

One service the site was hiding, and one that is coming

The driver portal, where the compliance actually happens

Dispatch: replacing the system, not skinning it

No AI in the workflow. That is a decision, not an omission.

What the search numbers did

Still to come

Is curl | bash Safe? What qsa.sh Does Instead

What curl <url> | bash actually does

The safer way to run an install script

Why curl qsa.sh is a different animal

Side by side

A fair caveat, because this is a security site

The short version

OAuth Consent Phishing: The Attack a Password Change Does Not Fix

What consent phishing actually is

Why your usual response does nothing

Who is being targeted

Go audit your grants — this is the useful part

What good scrutiny looks like

If you think you clicked Allow

The honest tension

issued.live is live

Where the corpus stands

Observational, not authoritative

Built to be read by machines first

Free by default

What comes next

issued.live: Certificate Transparency, ICANN Registrations and DNS in One API

One URL, three ways to read it

1. JSON, for a script

2. Markdown, for a human or a language model

3. MCP, for an agent

Three streams, joined

What a null means

Feeds and reverse lookups

Scale

Try it

curlhub Now Speaks MCP: Correctly Quoted curl for AI Agents

Point your client at it

The tool: getting curl quoting right

What it refuses

Bodies use --data-binary, not -d

You do not need an agent

In-browser agents too

Discovery

#4 on MalwareBazaar — what that proves, and what it does not

What we have contributed

What is actually in it

What this proves, and what it does not

Why give it away

What is next

Webshot Now Speaks MCP: Screenshots as a Tool for AI Agents

Point your client at it

Why it returns a link, not the image

You don't need an agent to use this

Credits, not captures

One caveat: it is slow, and that is fine

In-browser agents too

Safety

Docs

iNetPanel 1.26: Debian 13 (Trixie) Support and an HTTPS Setup Wizard

Both Debian 12 and Debian 13 are supported

What actually broke on Trixie

dnsutils no longer exists

The PHP repository was pinned to bookworm

cloudflared deliberately stays on bookworm

PHP pinning is now built dynamically

The setup wizard now uses HTTPS

Fixes worth knowing about

Certificates could silently be self-signed on Debian 13

inetp db_repair did nothing

Changing the SSH port could lock you out

WireGuard failed where iptables was absent

A newly added domain could return 503

Also in this release

Upgrading

The FBI QTFY Advisory: When Attackers Rent the Same Proxies You Do

What `curl <url> | bash` actually does

Why `curl qsa.sh` is a different animal