Connection Allowlists is a feature designed to provide explicit control over external endpoints by restricting connections initiated using the Fetch API or other web platform APIs from a document or worker.

It sounded a bit like Content Security Policy (CSP). CSP is a set of specifications that make the web a tremendously safer place by allowing web sites to specify what can and can't be done, in general terms, by content that is referenced by the web page. For example, a web site that accepts payments can serve a carefully-crafted CSP header that would prevent malicious browser extensions, compromised ads, or the site's own poorly sanitized user-generated content from allowing threat actors to access your payment data. It's not the only mechanism a site should use, but it's one layer of defense-in-depth. Defense-in-depth (that is, multiple layers) is absolutely crucial in a system with a lot of moving parts like, oh, say...the web.

"Carefully-crafted CSP header" is doing a lot of work in that last paragraph -- as I might put it in my East Texas vernacular: CSP can be a real pain in the ass.

I say that despite my very strongly-held opinion that CSP plays an absolutely crucial role in making the web a much safer place, and should be implemented anywhere that privacy and security are important...which is pretty much everywhere. So CSP is critical, but it's hard for teams -- especially small teams -- to get right. It seems pretty far down on the list of things most front-end devs I know care about, which is unfortunate, because front-end devs are the ones who generally know what the CSP should actually contain. And it's even further down on the list of things most of the back-end devs I know care about. The Infrastructure/DevSecOps/Platform Engineering/SRE folks I know care a LOT...but in any given situation, they're unlikely to have the context to craft the CSP, so spend a lot of time in confusing conversations with the front-end folks.

Full-stack generalists like me are probably in the ideal spot to understand and implement CSP, but speaking as a full-stack generalist, when you wear a lot of hats, you get spread thin, and it's hard to focus, and CSP deserves a bit of focus.

So anyway, I got a little excited and took a look at the Connection Allowlists Draft Community Group Report document published by the Web Platform Incubator Community Group (WICG). The WICG is a group that incubates ideas from the web developer community, until they can be migrated to a more formal World Wide Web Consortium (W3C) Working Group. Basically these are the folks that design the web.

It didn't take me long to figure out it's a LOT like CSP -- but less redundant, less error-prone, and with a more workable syntax. The WICG didn't bury the lede -- they spelled it out right there in the first few paragraphs of the Draft Community Report doc.

OK! So I went from intrigued (while reading the Chrome release notes) to excited (while reading the Draft Community Report) to motivated. Time to play.

First, I signed up for the corresponding Chrome origin trial by clicking through the link in the Chrome 148 Release Notes, which allowed me to get a token value to serve in the Origin-Trial header, alongside the new Connection-Allowlist. As I write this, I'm not 100% certain this is necessary after Chrome 148, but it seemed logical at the time. If I get a chance I may go back and see if Chrome 148 honors Connection-Allowlist without it. But it was quick and easy in any case.

After that, I went to the specification and cooked up my Connection-Allowlist header (or, more precisely, Connection-Allowlist-Report-Only - the non-enforcing version that only reports violations rather than blocks them). I also noticed that the reporting endpoint for Connection-Allowlist is specified by a Reporting-Endpoints header, which differs from the mechanism I was originally using for CSP on the site I was experimenting with. (Side note: that makes at least three flavors of reporting-endpoint specification I'm juggling -- between CSP, COOP, NEL, etc., and now Connection-Allowlist, which means I should probably go look up the latest on which are deprecated by the latest Reporting-Endpoints, clean all that up in my headers if I can, and write about that as well. Another day.)

After a bit of experimentation and some trial-and-error, I ultimately had my headers:

Origin-Trial: <ORIGIN_TRIAL_TOKEN_GOES_HERE>
Connection-Allowlist-Report-Only: (response-origin "https://api.dev.epicroadtripplanner.com"); report-to=default
Reporting-Endpoints: default="https://<redacted>.com/report-to"

By serving these headers, my site tells Chrome that it's in the origin trial for the Connection-Allowlist (and Connection-Allowlist-Report-Only) headers, and that it should report any JavaScript fetch (or other supported request type) that goes anywhere besides the site itself and api.dev.epicroadtripplanner.com.

(I've redacted my actual reporting endpoint in the snippet above.*)

To test it, I added a bit of JavaScript to one of the pages on my personal dev site, to try to fetch campground data for Fort Casey:

try {
  console.log("Fetching from dev (allow-listed)...")
  const response = await fetch("https://api.dev.epicroadtripplanner.com/v1/campgrounds/3a198528-95cf-4235-a40e-c9597d0a877a", {
    headers: {
      'accept': 'application/json'
    }
  });
  console.log("Response:", response);
} catch(e) {
  console.error(e)
}

try {
  console.log("Fetching from prod (not allow-listed, reported)...")
  const response = await fetch("https://api.epicroadtripplanner.com/v1/campgrounds/84af4262-6dff-4121-b22d-70b6173b15f6", {
    headers: {
      'accept': 'application/json'
    }
  });
  console.log("Response:", response);
} catch(e) {
  console.error(e)
}

Since I'm using the report-only variant (Connection-Allowlist-Report-Only) rather than the enforcement variant (Connection-Allowlist), both calls succeed -- but only the prod call is reported.

I got this single connection-allowlist report on my reporting server, for the call to the prod server:

I also tried the enforce version and played around with a few other items. Now that I know this all works at a high level, I'm looking forward to going deeper -- reviewing the actual CSP headers on a few of my sites and seeing just how much simpler and more specific the corresponding Connection-Allowlist headers can be. I'll also be watching how the WICG draft evolves. Good stuff!

-Tim

*I'm redacting my default reporting endpoint, not because it's a secret -- it can't be, since it's served publicly in the header -- but because I don't want anyone or an LLM copying the headers above verbatim and inadvertently sending a bunch of their own error reports to my reporting site, filling it with noise and probably blowing out my quotas. A former co-worker had that happen with his public NTP server, and I really hope he can laugh about it now 20+ years later, but I'm sure it wasn't funny at the time. But I digress. Shoot me an email and let me know if I should write up how to deploy a very lightweight reporting endpoint just for experimentation; it's pretty easy.

I learned a couple of things:

That is something that a fair number of folks NEED -- but not necessarily something a lot of folks will pay for.

In other words: the market is small. Especially in terms of dollars.

I also learned that a lot more people seem to TAKE road trips than PLAN road trips, and a lot of those folks just want to know they're going to have a place to sleep tonight. That's a larger market -- but a more saturated one. There are a surprising number of established players in this space.

I also learned that I am pretty good at the wrong kind of marketing. I can create rather compelling, cost-effective ads that folks click through. And then don't purchase. Because:

A. The PROBLEM is compelling, but the product is not. It's still not.

B. See above comment about the market - folks just aren't willing to spend money on this. The problem is compelling, but most folks solve it on their own with a shared Google Doc, a group chat, and a little effort.

So if cost-effective high performing ads are the WRONG kind of marketing, what's the right kind?

Content marketing. Specifically, for something like Epic Road Trip Planner, YouTube videos and TikTok are the obvious platforms - there are some pretty amazing content creators out there with audiences who just follow them for pure entertainment. Roaming Reckless, Living the Van Life, etc. are doing quite well all on their own. I needed to be like them. OR partner with them -- but going back to the product problem (it's just not that good), that essentially means just paying them. Which I didn't want to do because the product just isn't that great.

Yet.

So I made a fundamental personal shift, and I'm refocusing my efforts here on building a compelling product AND leaning into content marketing. Specifically, that shift has led me to do these two crucial steps:

1. I took a full-time job, and shifted Epic Road Trip Planner from a full-time gig to a complementary side project. There's a lot more to this than I can get into here, but the bottom line is that gives me a platform to experiment, learn, and grow, which is a lot easier to do when I don't also have to figure out how I'm going to pay my mortgage while burning through my retirement. So now my efforts here are mostly Saturday mornings.

2. I'm setting up Patreon! Patreon will allow me to invest -- literally -- by providing funds that I can use (along with my paycheck from my day job, lol) to hire some experts to actually make this product better, instead of just trying to wear all those hats myself. I was already spread way too thin trying to do everything -- which meant I was doing most things badly or not at all. Patreon is also very much geared toward content creators, and is an excellent way for me to get my feet wet in that area. I'll learn the vocabulary, make some connections, and have a means to test out what folks are interested in.

Next up: figure out my Patreon tiers. Stay tuned!

-Tim (Patreon-curious)

The expression is frequently attributed to the U.S. Navy SEALs, but the concept itself comes from nature, and I'm most interested in applying the principle to software engineering leadership. I've delivered many projects throughout my career, in roles ranging from individual contributor to CEO, and it's certainly an invariant that time is of the essence. All other things being equal, delivering sooner is always better.

But all other things are not equal. There are almost always tradeoffs, usually fairly obvious and intentional ones, but sometimes they're more insideous and troublesome.

One of the more typical and well-known tradoffs is schedule vs quality. Unfortunately, "quality" is a vague and subjective concept, and therefore very difficult to reason about. Quality of the end user deliverable and quality of the workmanship that goes into it are entirely different concepts, and are barely even related. You can easily trade off bugs and missing features against schedule, but it gets complicated and counterproductive real fast if you try to trade off code quality and engineering process shortcuts against schedule.

The impact of bugs and missing features is relatively easily quantified. The impact of crappy code and shoddy engineering practice is not. I can tell you this, however -- if the team is checking in code that is difficult to understand and maintain, and cutting other corners in the process, all in an attempt to move fast -- you're actually moving slowly. Quite possibly backward.

Why? Because SOME of that crappy code or skipped steps will, in fact, never matter, and it's really easy to focus on that. But SOME of it will matter immediately. That shortcut that someone took? That's cognitive load that someone has to deal with as soon as you discover some previously unknown bug or critical missing piece. Those discoveries happen MORE frequently as you near delivery, not less. So that hypothetical "later" frequently turns out to be "right now", and dealing with the cognitive load will therefore slow you down "right now", too.

So how does going "slow" ultimately make us "fast"? Emphasis goes to the word "smooth". A big clue to that point is that it's repeated twice in the expression. The word "slow" is just shorthand for "only as quickly as you actually can smoothly". If the wheels are about to fly off the cart, if you're flailing, if people are showing signs of distress, then you're going too fast. Take a step back, breathe, and ground yourself, then proceed smoothly.

In some ways, this SHOULD be obvious, but it's also not easy to tell when the wheels are about to go flying off the cart. Flailing doesn't always LOOK like flailing. Bottom line is that it is really hard to tell a healthy sense of urgency from counter-productive rushing just by looking.

Here's one of my favorite examples -- a couple of Marines racing to see who can disassemble and reassemble the M240B machine gun more quickly.

Slow is smooth, smooth is fast

It doesn't really look like the Marine in the foreground is flailing, does it? Or even rushing, for that matter. He seems to be moving with a sense of urgency, right? But if you didn't catch this the first time through, go back and watch carefully. You don't have anything "smooth" to compare against until about the 20 second mark, where the difference starts to become more and more obvious once the Marine in the background joins the race.

Those guys are Marines, and I mentioned the expression is popularly attributed to the U.S. Navy SEALs, but I also mentioned that the concept itself comes from nature. There's literally a term for it in fluid dynamics: laminar flow.

Laminar flow is the smooth, parallel movement of fluid particles in layers, which is the opposite of chaotic, turbulent flow. It occurs at low speeds and in viscous fluids, where particles move in straight, parallel lines without mixing. Laminar flow is tremendously more efficient than turbulent flow. For a given amount of applied energy, a system optimized for laminar flow will result in more throughput, and the fluid in the center of the pipe, analogous to the main features of the software, will reach the end of the pipeline tremendously more quickly and predictably with laminar flow than with turbulent flow. Literally slow is smooth, smooth is fast.

So the next time you need to be faster, don't just look for ways to be faster. Look for ways to be smoother. Faster WILL follow. Accept that you may need to slow down a bit to do so. Move with a sense of urgency. Have a purpose. Do the thing as fast as you can -- but not faster. Slow is smooth, smooth is fast.