Calm and considered news
I don’t miss much from the UK, but after almost 15 years I still miss the BBC.
Since 2010
I don’t miss much from the UK, but after almost 15 years I still miss the BBC.
David Heinemeier Hansson on hey.com.
Yeah I think he’s spot on with this. Passkeys solve a problem, but I’m not sure they solve the correct problem. The technology is bulletproof - we’ve been using public/private keys for decades - and when implemented properly is unquestionably more secure at the bits-and-bytes layer. But the problem with passwords is almost always human, and passkeys don’t really solve that.
As pointed out by John Gruber at Daring Fireball, passkeys only work if you use some kind of password manager. In my case that means I can only use passkeys when I’m using my own Mac or my own iPhone, which is a pretty big hurdle in some cases. And if you’re the kind of person who already uses a password manager then there’s a good chance that - like me - all your accounts already have long, unique, high-entropy passwords.
I suspect this explains why most services I’ve enabled passkeys for leave the traditional username/password login path enabled, meaning my accounts are still vulnerable to that kind of attack, so… what’s the point of the passkey?
I though this suggestion to add an “open a random post” button sounded fun, so I’ve just added that feature to zerosleeps.com. You’ll find it in the navigation bar. A simple way for someone to get a feel for the nonsense that I’ve posted here over the years.
I didn’t want to generate a link to a random post every time the navigation bar is rendered. Instead, I wanted the random thingy to have it’s own URL, which in turn redirects the requestor to the absolute URL for a random post.
On top of that I didn’t want to do this using HTTP 302. Django’s RedirectView makes it easy to serve 302 responses, but the semantics of that status code didn’t feel quite right - it’s supposed to indicate “that the target resource resides temporarily under a different URI”.
HTTP 303 felt like a better fit to me: “the server is redirecting the user agent to a different resource … which is intended to provide an indirect response to the original request”. A subclass of HttpResponseRedirectBase made light work of that requirement.
After deployment I discovered that Safari (and only Safari as far as I can tell) was caching the 303 response: you could visit /random_post/ as many times as you wanted, but you’d always get the same page back within the same 180 second period. Fair enough I suppose: I’ve told my web server to add a Cache-Control header to anything generated by Django, so it’s not unreasonable for Safari to cache the response to the initial redirect in addition to caching the final page. It’s interesting that other browsers don’t do that though.
I acquired an iPhone 15 Pro at the weekend, which is the first modern pocket-computer I’ve owned with an always-on display. It’s really nice being able to glance at the thing to see if there are any notifications.
While I was thinking about this new trick, I realised that this is the way phones always were! My first half-dozen mobile phones were things like the Nokia 5110 and Nokia 3310. I remember a Samsung A300, and a Nokia 3100. Oh and the outstanding Sony Ericsson T68i.
They all had always-on LCD displays. The last few were even colour!
Then in 2010 I replaced my can’t-remember-the-model-number Nokia for an iPhone 4 and that was the end of that.
Yeah they were terrible displays when you hold them up to what we have now. Terrible devices compared to what came after. But isn’t there something amusing about the fact that it’s taken 15 years to get back to where we were?
Maybe next year’s iPhone will have a status LED like that goddamned amazing Sony Ericsson T68i did!