Daring FireballModify

2026-03-03 08:20:21

npx workos launches an AI agent, powered by Claude, that reads your project, detects your framework, and writes a complete auth integration directly into your existing codebase. It’s not a template generator. It reads your code, understands your stack, and writes an integration that fits.

The WorkOS agent then typechecks and builds, feeding any errors back to itself to fix.

See how it works →

2026-03-03 07:41:11

Back in December I linked to a sort-of stunt project from Tyler Hall called Alan.app — a simple Mac utility that draws a bold rectangle around the current active window. Alan.app lets you set the thickness and color of the frame. I used it for an hour or so before calling it quits. It really does solve the severe (and worsening) problem of being about to instantly identify the active window in recent versions of MacOS, but the crudeness of Alan.app’s implementation makes it one of those cases where the cure is worse than the disease. Ultimately I’d rather suffer from barely distinguishable active window state than look at Alan.app’s crude active-window frame all day every day. What makes Alan.app interesting to me is its effectiveness as a protest app. The absurdity of Alan.app’s crude solution highlights the absurdity of the underlying problem — that anyone would even consider running Alan.app (or the fact that Hall was motivated to create and release it) shows just how bad windowing UI is in recent MacOS versions.

Turns out there exists an app that attempts to solve this problem in an elegant way that you might want to actually live with. It’s called HazeOver, and developer Maxim Ananov first released it a decade ago. It’s in the Mac App Store for $5, is included in the SetApp subscription service, and has a free trial available from the website.

What HazeOver does is highlight the active window by dimming all background windows. That’s it. But it does this simple task with aplomb, and it makes a significant difference in the day-to-day usability of MacOS. Not just MacOS 26 Tahoe — all recent versions of MacOS suffer from a design that makes it difficult to distinguish, instantly, the frontmost (a.k.a. key) window from background windows.¹ Making all background windows a little dimmer makes a notable difference.

Longtime DF reader Faisal Jawdat sent me a note suggesting I try HazeOver back in early December, after I linked to Alan.app. I didn’t get around to trying HazeOver until December 30, and I’ve been using it ever since. One thing I did, at first, was not set HazeOver to launch automatically at login. That way, each time I restarted or logged out, I’d go back to the default MacOS 15 Sequoia interface, where background windows aren’t dimmed. I wanted to see if I’d miss HazeOver when it wasn’t running. Each time, I did notice, and I missed it. I now have it set to launch automatically when I log in.

HazeOver’s default settings are a bit strong for my taste. By default, it dims background windows by 35 percent. I’ve dialed that back to just 10 percent, and that’s more than noticeable enough for me. I understand why HazeOver’s default dimming is so strong — it emphasizes just what HazeOver is doing. But after you get used to it, you might find, as I did, that a little bit goes a long way. (Jawdat told me he’s dropped down to 12 percent on his machine.) I’ve also diddled with HazeOver’s animation settings, changing from the default (Ease Out, 0.3 seconds) to Ease In & Out, 0.1 seconds — I want switching windows to feel fast fast fast.

Highly recommended, and a veritable bargain at just $5.

2026-03-03 06:59:41

Marcin Wichary, writing at Unsung (which is just an incredibly good and fun weblog):

Half of my education in URLs as user interface came from Flickr in the late 2000s. Its URLs looked like this:

flickr.com/photos/mwichary/favorites
flickr.com/photos/mwichary/sets
flickr.com/photos/mwichary/sets/72177720330077904
flickr.com/photos/mwichary/54896695834
flickr.com/photos/mwichary/54896695834/in/set-72177720330077904

This was incredible and a breath of fresh air. No redundant www. in front or awkward .php at the end. No parameters with their unpleasant ?&= syntax. No % signs partying with hex codes. When you shared these URLs with others, you didn’t have to retouch or delete anything. When Chrome’s address bar started autocompleting them, you knew exactly where you were going.

This might seem silly. The user interface of URLs? Who types in or edits URLs by hand? But keyboards are still the most efficient entry device. If a place you’re going is where you’ve already been, typing a few letters might get you there much faster than waiting for pages to load, clicking, and so on.

In general, URLs at Daring Fireball try to work like this.

• This post: /linked/2026/03/02/wichary-flickr-urls
• In Markdown: /linked/2026/03/02/wichary-flickr-urls.text
• This day’s posts: /linked/2026/03/02/
• This month’s posts: /linked/2026/03/

I say “in general” because the DF URLs could be better. There should be one unified URLs space for all posts on DF, not separate ones for feature articles and Linked List posts. Someday.

Wichary subsequently posted this fine follow-up, chock full of links regarding URL design.

2026-03-03 05:10:50

During the most recent episode of The Talk Show, Jason Snell brought up a weird issue that I started running into last year. On my Mac, sometimes I’d drag an image out of a web page in Safari, and I’d get an image in WebP format. Sometimes I wouldn’t care. But usually when I download an image like that, it’s because I want to publish (or merely host my own copy of) that image on Daring Fireball. And I don’t publish WebP images — I prefer PNG and JPEG for compatibility.

What made it weird is when I’d view source on the original webpage, the original image was usually in PNG or JPEG format. If I opened the image in a new tab — just the image — I’d get it in PNG or JPEG format. But when I’d download it by dragging out of the original webpage, I’d get a WebP. This was a total WTF for me.

I turned to my friend Jeff Johnson, author of, among other things, the excellent Safari extension StopTheMadness. Not only was Johnson able to explain what was going on, he actually made a new Safari extension called ChangeTheHeaders that fixed the problem for me. Johnson, announcing ChangeTheHeaders last year:

After some investigation, I discovered that the difference was the Accept HTTP request header, which specifies what types of response the web browser will accept. Safari’s default Accept header for images is this:

Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Although image/webp appears first in the list, the order actually doesn’t matter. The quality value, specified by the ;q= suffix, determines the ranking of types. The range of values is 0 to 1, with 1 as the default value if none is specified. Thus, image/webp and image/png have equal precedence, equal quality value 1, leaving it up to the web site to decide which image type to serve. In this case, the web site decided to serve a WebP image, despite the fact that the image URL has a .png suffix. In a URL, unlike in a file path, the “file extension”, if one exists, is largely meaningless. A very simple web server will directly match a URL with a local file path, but a more complex web server can do almost anything it wants with a URL.

This was driving me nuts. Thanks to Johnson, I now understand why it was happening, and I had a simple set-it-and-forget-it tool to fix it. Johnson writes:

What can you do with ChangeTheHeaders? I suspect the biggest selling point will be to spoof the User-Agent. The extension allows you to customize your User-Agent by URL domain. For example, you can make Safari pretend that it’s Chrome on Google web apps that give special treatment to Chrome. You can also customize the Accept-Language header if you don’t like the default language handling of some website, such as YouTube.

Here’s the custom rule I applied a year ago, when I first installed ChangeTheHeaders (screenshot):

Header: Accept
Value: image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
URL Domains: «leave blank for all domains»
URL Filter: «leave blank for all URLs»
Resource Types: image

I haven’t seen a single WebP since.

ChangeTheHeaders works everywhere Safari does — Mac, iPhone, iPad, Vision Pro — and you can get it for just $7 on the App Store.

2026-03-03 04:27:52

Jesper, writing at Take:

My hope is that Macintosh is not just one of these empires that was at the height of its power and then disintegrated because of warring factions, satiated and uncurious rulers, and droughts for which no one was prepared, ruining crops no one realized were essential for survival.

My hope is that there remains a primordial spark, a glimpse of genius, to rediscover, to reconnect to — to serve not annual trends or constant phonification, but the needs of the user to use the computer as a tool to get something done.

2026-03-03 04:03:02

Julien Khaleghy, CEO of SerpApi:

Google thinks it owns the internet. That’s the subtext of its lawsuit against SerpApi, the quiet part that it’s suddenly decided to shout out loud. The problem is, no one owns the internet. And the law makes that clear.

In January, we promised that we would fight this lawsuit to protect our business model and the researchers and innovators who depend on our technology. Today, Friday, February 20, 2026, we’re following through with a motion to dismiss Google’s complaint. While this is just one step in what could be a long and costly legal process, I want to explain why we’re confident in our position.

Is Google hurting itself in its confusion? Google is the largest scraper in the world. Google’s entire business began with a web crawler that visited every publicly accessible page on the internet, copied the content, indexed it, and served it back to users. It did this without distinguishing between copyrighted and non-copyrighted material, and it did this without asking permission. Now Google is in federal court claiming that our scraping is illegal.

I’ve come around on SerpApi in the last few months. My initial take was that it surely must be illegal for a company to scrape Google’s search results and offer access to that data as an API. But I’ve come around to the argument that what SerpApi is doing to obtain Google search results is, well, exactly how Google scrapes the rest of the entire web to build its search index. It’s all just scraping publicly accessible web pages.

This December piece by Mike Masnick at Techdirt is what began to change my mind:

Look, SerpApi’s behavior is sketchy. Spoofing user agents, rotating IPs to look like legitimate users, solving CAPTCHAs programmatically — Google’s complaint paints a picture of a company actively working to evade detection. But the legal theory Google is deploying to stop them threatens something far bigger than one shady scraper.

Google’s entire business is built on scraping as much of the web as possible without first asking permission. The fact that they now want to invoke DMCA 1201 — one of the most consistently abused provisions in copyright law — to stop others from scraping them exposes the underlying problem with these licensing-era arguments: they’re attempts to pull up the ladder after you’ve climbed it.

Just from a straight up perception standpoint, it looks bad.