Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Daniel De Laney
Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. The problem, counterintuitively, was lack of interruption. Sure, I was doing a lot of stuff. But I never paused to ask whether I was doing the right stuff. Or whether my approach was working. Or if I was spending the right amount of time on it. So I needed a reliable way to interrupt my “unproductive productivity,” and refocus on what’s important. The obvious first-thought solution was a timer. Unfortunately, if you use timers a lot, you learn to dismiss them reflexively. And it’s really easy to forget to set the next timer. A week later I’d think “Hey, that timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer. It does 2 unique things: My timer asks me a question. It gradually blurs my screen if I don’t set a new timer. Every few minutes it asks me the same question: “What will you focus on?” I answer in a word or two, hit enter, and keep working. Having to name my intention keeps me fully aware of my trajectory. If I’m in danger of drifting, it’s obvious. If I’m flying on something simple and don’t need to reorient frequently, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something more open-ended, I might tighten the leash all the way down to 3 minutes. Then I can’t get off track. Unlike a regular timer, I can’t fail to set the next one. If I don’t restart it promptly, the screen gradually becomes less readable until I do. If I wanted to avoid answering, I’d have to make a conscious decision to close the app just so I could see the screen clearly. I’d have to decide to be less productive. I never do. This small intervention has worked beautifully. Not only am I catching unproductive divergences earlier, I’m noticing fewer of them over time. It seems to be training me to do more and better thinking. It’s not a replacement for a more extensive journaling practice. I love to journal, but that only happens once per day. What about the rest of the day? There’s a lot of benefit in reflecting more often than once every 24 hours. If you’re running macOS, I recommend giving Intention a try. I use it every day, and I think it’s the superior way of working.
Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. The problem, counterintuitively, was lack of interruption. I never paused to ask whether I was doing the right thing. Or whether my approach was working. Or if I was spending the right amount of time on it. The obvious first-thought way to interrupt myself was a timer. But I discovered those are too easy to dismiss, and too easy to forget about. A week later I’d think, “That timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer that asks me a question: “What will you focus on?” Every few minutes I answer in a word or two, restart the timer, and keep working. This keeps me fully aware of my trajectory. If I’ve drifted, it’s obvious. If I’m flying on something simple and don’t need the reminders, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something open-ended, or my attention is wandering, I might tighten the leash all the way down to 3 minutes. Unlike a regular timer, I can’t ignore it. If I don’t answer the question, the screen gradually blurs until I do. Drifting requires making a conscious decision to close the app. I have to decide to be less productive. This tiny intervention has worked beautifully. At first, I caught myself drifting constantly. Over time, I naturally became more focused. It’s training me to stop wasting time. Setting a recurring timer every few minutes sounds like it could be too much. Instead, it’s a relief. There’s nothing worse than spending all day accomplishing nothing useful. All I have to do to prevent that is type a word or two and hit enter. Importantly, it’s not a blocker. It doesn’t try to stop me from using distracting apps or sites. I’d just disable that, anyway. Instead of trying to take control away from me, it gives me more control, because I’m more aware. Plus, this makes blockers unnecessary. I can tell you from experience: by the third time you set a 3-minute timer you’ve titled “Aimless scrolling,” you’ll feel ridiculous enough to stop. It’s also not a journal, or a log. Those are harder to keep up with, and they don’t help minute-to-minute. Journaling once per day is great, but then I’m still potentially spending a full 24 hours off course. This is every few minutes, and it only takes a couple of seconds. All I have to do is name what I want to focus on. If you’re running macOS, I recommend giving Intention a try. I use it every day, and I think it’s the superior way of working.
I’m the person my friends and family come to for computer-related help. (Maybe you, gentle reader, can relate.) This experience has taught me which computing tasks are frustrating for normal people. Normal people often struggle with converting video. They will need to watch, upload, or otherwise do stuff with a video, but the format will be weird. (Weird, broadly defined, is anything that won’t play in QuickTime or upload to Facebook.) I would love to recommend Handbrake to them, but the user interface is by and for power users. Opening it makes normal people feel unpleasant feelings. This problem is rampant in free software. The FOSS world is full of powerful tools that only have a “power user” UI. As a result, people give up. Or worse: they ask people like you and I to do it for them. I want to make the case to you that you can (and should) solve this kind of problem in a single evening. Take the example of Magicbrake, a simple front end I built. It hides the power and flexibility of Handbrake. It does only the one thing most people need Handbrake for: taking a weird video file and making it normal. (Normal, for our purposes, means a small MP4 that works just about anywhere.) There is exactly one button. This is a fast and uncomplicated thing to do. Unfortunately, the people who have the ability to solve problems like this are often disinclined to do it. “Why would you make Handbrake less powerful on purpose?” “What if someone wants a different format?” “What about [feature/edge case]?” The answer to all these questions is the same: a person who needs or wants that stuff can use Handbrake. If they don’t need everything Handbrake can do and find it bewildering, they can use this. Everyone wins. It’s a bit like obscuring the less-used functions on a TV remote with tape. The functions still exist if you need them, but you’re not required to contend with them just to turn the TV on. People benefit from stuff like this, and I challenge you to make more of it. Opportunities are everywhere. The world is full of media servers normal people can’t set up. Free audio editing software that requires hours of learning to be useful for simple tasks. Network monitoring tools that seem designed to ward off the uninitiated. Great stuff normal people don’t use. All because there’s only one UI, and it’s designed to do everything. 80% of the people only need 20% of the features. Hide the rest from them and you’ll make them more productive and happy. That’s really all it takes.
An objective, external world is a non-falsifiable assumption. The prevailing theory is that our subjective experiences correspond to an external reality. However, they may simply be subjective through and through. That which we claim to be evidence of external reality is actually subjective experience, which may or may not have an external and objective cause. Any test devised to prove objectivity is evaluated within subjectivity and therefore does not require objectivity to explain the result. Some object to this, claiming that the consistency of experience is best explained by an external world. However, consistent experience does not require any external mechanism, let alone the specific one we have assumed. Claiming that belief in an external world is simpler is like claiming that belief in God is simpler; in truth we are inventing something vast and complex without evidence and agreeing not to question it. This is not science, it is a substitute for epistemic humility. Much as dreams appear consistent while dreaming, that which we consider waking experience may not actually be as consistent as we believe. However, questioning this is unproductive reasoning because it undermines the value of reason itself. We must assume our experiences are rational and consistent, or else give up thinking altogether. Experience is the only reality which is detectable. Whatever experience is, it is real and directly perceptible, unlike objectivity. Claims that experience is an illusion presuppose an objective world to which experience does not correspond. Pragmatic truth is supportable, correspondence is not. If an objective world can’t be proven, neither can we prove that knowledge does or does not correspond with it. That which produces a consistent effect in experience is useful in influencing experience in the desired way, therefore science is useful. Materialism is religious faith. Just as we once invented a spirit world to help explain our experiences, we invented an objective world for which there is similar quality evidence. Both are assumed to explain experience, yet neither is directly known. The assertion that matter gives rise to experience is no more compelling than the assertion that experience gives rise to matter. The assumption of an external world has zero explanatory power, as consistent experience does not require it. Materialism is superior to classical religions in that it responds to pragmatic truth, but it still accepts unsupportable metaphysical claims and regards them as unquestionable. By contrast, noting that we have experiences does not require extrapolation or invention. Modern civilization is optimizing materials, not experiences. Focus on economic metrics has allowed us to make tremendous progress in reducing starvation and otherwise improve the experience of the least fortunate. Nonetheless, the subtle error of conflating material improvement with improvement in well-being has consequences. In advanced societies, increases in abstract indicators of material wealth like GDP have been accompanied by negative changes in consciousness: stress, social disconnection, and increased suicide. The materialist assumption that improving external conditions will always trickle down to better experiences is demonstrably unreliable. Often, this assumption results in methods which improve economic indicators by reducing experiential well-being, and in these cases it is worse than nothing. In addition to misallocating its priorities, modern civilization also conditions people to feel powerless over their own well-being. As materialist structures (corporations, governments, economic systems) become more dominant, individuals are increasingly absorbed into mechanisms designed to optimize external conditions rather than subjective experience. People come to believe that their quality of life is dictated by forces beyond their control. The best way to improve experience is to optimize it directly. The only rational goal is maximizing satisfaction. Long-term positive changes in consciousness are what is best in life. If a person achieves material or hedonistic aims but is unsatisfied in the long term, they are having a negative experience and are working against themselves. Secure, nourish, nurture, and build yourself and your community. Seek what is satisfying and aesthetic—that which feels good and true and beautiful. Unlike materialist assumptions, this requires no external faith, only a direct commitment to improving the reality we actually experience.
More in technology
Well, well, well, well, well, well, well, well, well, well, well, well, well, well, well. We're back. Sorry. We've been watching the onslaught of vulnerabilities flood the internet. Every man, dog, and their grandmas (apparently?) are now using LLMs to find and reproduce vulnerabilities - it’
You want less of them. That’s the reason. You may find that it’s too hard to stop people from doing the thing, literally blood, sweat, and tears trying to prosecute people, but that’s a different thing.
Solitaire Alone Together I made a new game. It's called Solitaire Alone Together. It's Windows 98 solitaire, but you can play with everyone else on the internet. Read the full post on my blog! Here's a raw link, if you need it: https://eieio.games/blog/solitaire-alone-together
This post is a living diary of all the times I messed up something with my website in a funny way. I value those who have the confidence to own their mistakes and share the learning with others, and so this is me doing just that! That Time I Accidentally Made a Tarpit That Time I Accidentally Made Really Large Headers That Time I Accidentally Made a Tarpit Back to Top A "tarpit" is an unofficial term used in computing to describe an intentionally slow response to a request. In these modern times many people are using tarpits as a way to combat the relentless theft of data by AI companies, although there's little to no evidence of that actually being in any way effective. I don't use tarpits, at least not intentionally, but there was that one time when I accidentally created a tarpit and trapped all visitors in it. As I've shared previously, I refuse connections from IP addresses that are blocked or belong to a blocked subnet, and I enforce this firewall during the TCP handshake. The logic here is straightforward: there's no reason to waste resources doing a TLS handshake, accepting an HTTP request, and then rejecting the connection if I already know I'm going to reject it at the earliest step. At the time, the code worked like this: the HTTP server would repeatedly call the Accept() function below expecting a new connection. I've added some comments to help explain the logic. func (l *firewallListener) Accept() (net.Conn, error) { // Accept the connection from the TCP listener. This blocks until there is a connection to accept or the listner was closed. conn, err := l.l.AcceptTCP() if err != nil { return conn, err } // Separate the IP address out from the remote address (which includes the port) ip := utils.SocketStringToIPAddress(conn.RemoteAddr().String()) if ip == nil { return nil, nil } // Check if it's blocked, if so close the connection and return a refuseError if IsBlocked(ip, true) { conn.Close() return nil, &refuseError{} } // Otherwise return the connection on to the HTTP server return conn, nil } If the incoming connection was from a blocked IP then I'd return a refuseError. I need to use a specific error interface because the HTTP server will halt if it encounters a non-temporary error from the call to Accept(), so I need to return an error that satisfies the definition of a temporary error. I defined refuseError like this: type refuseError struct{} func (e *refuseError) Error() string { return "." } func (e *refuseError) Timeout() bool { return true } func (e *refuseError) Temporary() bool { return true } func (e *refuseError) Is(err error) bool { return err == context.DeadlineExceeded } This did accomplish the goal of rejecting connections before the TLS handshake for blocked addresses, but it had one really unintended and difficult to track down side-effect. Accepting connections is done serially, after which servers typically then process that request on a dedicated thread (or in Go's case a goroutine). This means that any delays during the accept loop will block all incoming connection. What I had missed while reviewing the code for Go's HTTP server is that when it receives a temporary error from Accept() is that while it doesn't abort, it does sleep for up to a maximum of 1 second. This sleep blocks the entire server for all incoming connections. You can see a trimmed copy of the code that does this below, with some marks I've added which I will explain. // src/net/http/server.go // Copyright 2009 The Go Authors. All rights reserved. // Use of this source code is governed by a BSD-style // license that can be found in the LICENSE file. for { // (1) rw, err := l.Accept() if err != nil { if s.shuttingDown() { return ErrServerClosed } // (2) if ne, ok := err.(net.Error); ok && ne.Temporary() { if tempDelay == 0 { tempDelay = 5 * time.Millisecond } else { tempDelay *= 2 } if max := 1 * time.Second; tempDelay > max { tempDelay = max } s.logf("http: Accept error: %v; retrying in %v", err, tempDelay) // (3) time.Sleep(tempDelay) continue } return err } connCtx := ctx if cc := s.ConnContext; cc != nil { connCtx = cc(connCtx, rw) if connCtx == nil { panic("ConnContext returned nil") } } tempDelay = 0 c := s.newConn(rw) c.setState(c.rwc, StateNew, runHooks) // before Serve can return // (4) go c.serve(connCtx) } At mark 1 the server calls the Accept() function, this is the exact function that I defined above where I might return a temporary error. At mark 2 it checks if an error was returned, and if so if that error is temporary. If there was a temporary error, at mark 3 it sleeps for an increasing amount of time up-to 1 second, otherwise, at mark 4 it processes the connection on a dedicated goroutine, which allows the server to accept the next connection. I'm not entirely sure why the Go developers added this sleep delay and the change when it was introduced doesn't provide any meaningful insight. Regardless, it caused significant latency connecting to my website when a flood of rejected requests was coming in. It just goes to show how important it is to write meaningful commit messages, because you never know when somebody might come back years later wondering "why was this done?". I sure home I don't come to eat those words later. Coincidentally, you can actually see this happening if you look carefully at one of the metric graphs I shared in my first post about my server's security model: Securing My Web Infrastructure. This is the graph I shared in that blog post and while I didn't know it at the time, the fact that these request spikes all cap-out at around 60 requests per minute was not a coincidence. These requests were not being made with a limit in mind, attackers rarely ever care about things like that, instead it the accidental tarpit I had created. The downside to this was that while the malicious requests were being rate-limited, all requests were being rate-limited, up to a point of taking so long they timed out. The Fix Fixing the issue was relatively straightforward enough. Instead of returning a temporary error to the HTTP server during the accept loop, just don't return anything at all and wait for the next valid connection. func (l *firewallListener) Accept() (net.Conn, error) { for { conn, err := l.l.AcceptTCP() if err != nil { return conn, err } ip := utils.SocketStringToIPAddress(conn.RemoteAddr().String()) if ip == nil { return nil, nil } if IsBlocked(ip, true) { conn.SetLinger(0) conn.Close() continue } return conn, nil } } Now, when the HTTP server calls Accept(), the only time it returns is with a connection from an IP that isn't blocked, or if there genuinely is an error. No more sleep delays, no more excessive timeouts. That Time I Accidentally Made Really Large Headers Back to Top For about 10 years now all major browsers have support for a security feature known as a Content Security Policy or CSP. A CSP is an HTTP header provided by the server that instructs the browser on where it can load assets from, this could be scripts, images, stylesheets, fonts, etc. The objective of using a CSP is to prevent against injected HTML that tries to load assets, such as a malicious Javascript file, from a remote source. With so much user-provided content being available online, it's very possible for this to happen without an attacker compromising the entire web server. CSP protects against that by saying "scripts can only be loaded from these domains". That's a really simplified way of looking at it, anyways. My web server supports injecting the CSP header automatically, but before I go on I need to explain a little bit about the structure of my web server. When an incoming HTTP request is accepted (having passed all firewall checks and assertions), we look at the destination host for the request. This can either be the value of the Host header or as specified during the TLS handshake. We then look at a map of hosts to apps. Apps are just an interface that accept a few methods: type App interface { Cleanup() ReloadConfig() ServeHTTP(rw http.ResponseWriter, r *http.Request) Setup(dataDir string) error Shutdown() } One of the apps is the Proxy app, which is a reverse proxy - it accepts the incoming HTTP request and then proxies it on to another host. This is a very common design, especially with increasingly complex TLS setups. Because each app is unique to a host, and different hosts have different requirements for CSP rules, the proxy app includes a CSP preset that we use to build the header value, or skip it entirely. When the proxy app was going to copy an HTTP request to the downstream host, it would build the CSP header, however there was a slight bug... func (a *App) ServeHTTP(rw http.ResponseWriter, inRequest *ht2.Request) { // --snip -- if a.CSP != nil { a.CSP.ConnectSrc += " " + inRequest.Origin } CopyHttpRequest(inRequest, outRequest, rw, CopyHttpRequestOptions{ Origin: inRequest.Origin, Csp: a.CSP, Cors: a.CORS, AddHeaders: !a.SkipHeaders, UseHTTP3: a.UseHTTP3, InsecureTLS: a.InsecureTLS, }) } I'm really unsure as to what I was doing with the line to append to the ConnectSrc, but the impact is that I'm appending to a variable that lives on the App, rather than a variable that is per-request. This meant that every time there was a request to the app, any request at all, the origin would be appended to the header value. This went on for quite a long time unnoticed and unresolved, largely because I am constantly tweaking and tinkering with my web server, after all, it's how I made having a website fun again. Each time I restarted the server process, the header value would be reset, but only for it to continue to grow and grow. Eventually, after a period of being busy with other matters, the server process stayed running for long enough that the header value grew too large and HTTP clients began to reject it. There is no defined maximum for an HTTP header value, however most HTTP clients use 100KiB, which is perfectly reasonable, and this header value would continue to grow well beyond that. Diagnosing this issue turned out to be difficult as tools like Curl would fail with errors relating to entities being too large, but stopped short of saying what specifically. I eventually used openssl s_client to send an HTTP request by hand and observed my terminal window being filled with a domain name repeated thousands of times. Looking at the commit history, it was really unclear why I added the culprit lines of code. The commit message just says "Improved CSP support". It just goes to show how important it is to write - hey look it's those words I'm now having to eat! The Fix The fix was to just delete those three lines of code. Yup, it really was that simple, and fixing this bug actually made a larger positive impact than I had expected, as it was immediately clear when I fixed the bug by looking at outbound network bytes: So much traffic was being wasted on excessive header sizes. You might look at these mistakes I've made and think "wow, Ian, these are some obvious mistakes, I never would have made them!" to which I say "good for you!" with the utmost sarcasm and disdain. I enjoy making and refining software, and making anything means making mistakes along the way. Each time I make mistakes such as the ones above, I improve my skills of investigation, diagnosing, and repair. Skills that, judging by my peers in the industry, seemingly everyone is quickly willing to throw away because a robot does it "better" than you. Header Image: "Car accident on the Ffestiniog to Bala road. Nobody was hurt" by Geoff Charles, CC BY-SA 4.0, via Wikimedia Commons.
