I also run mail servers for others, mostly non-profit adjacent groups who don’t have the capital to be extorted by cloud service providers.
Sure, there are some things to learn, but like anything – if you do it properly, it’s not hard and can work properly. Never had any deliverability issues over that time (yes, even to the big providers). I also almost never touch the boxes (I do about one architectural overhaul a decade and am working on the next right now).
If you’re willing to invest the time and resources to do it properly, I agree, it works fine.
I know that. Just because SSH automatically sends my local $USER doesn't mean they have to report the value received in the SSH username automatically on the game platform to other users, without first having prompted me "your username has been reported as <greengreengrass>. Is it okay to show this?".
A simple flag in my user profile in the platform to say whether I've said that's okay or not.
Or instructions to advise people to choose their username /before/ first connect. These are reasonable, privacy-preserving things to call out in a good and user-friendly design.
I would prefer the connection instructions made clear that the default SSH username would be used to set up my username on the platform and display that to other users without initially seeking my consent. On $machine[work], I don't get to pick that $USER is my full name.
If this affects you, make sure you connect with `ssh [pseudonymous name]@late.sh`.
I see this also purports to link to secondary regulation, but there's a reason lawyers pay huge chunks of cash to professional firms that ingest court decisions and other sources of applicable regulation. Meh, there's a reason _lawyers_ are paid huge chunks of cash to be kept on retainer and give their opinions to begin with.
It's harder to solve some of these problems than prompting an LLM to vibe a solution. I wish we'd stop.
> SOC2, ISO27001 and all that shit is not the same thing.
Hard agree. SOC2/ISO27001 are a thing that might be useful, but are mostly a framework dreamt up by auditors and other people who like wearing suits (and making lots of money).
They have some normative controls. But a SOC2 audit is not going to survive contact with an engineer who can push code and whose job depends on the company they work for making money. Where they have to ship product features, and don't have weeks to justify every line of code they write.
A SOC2 audit is not going to survive contact with a script kiddie in their bedroom (or, a nation-state APT) who has plenty of time and an LLM to help them find vulnerabilities or weird edge cases they can compose to attack a system.
These frameworks might serve a purpose, but corporate 'compliance' departments have been lulled into a false sense of security that a satisfactory SOC2 audit means the product is secure and obviates them from asking more technical details or for a fuller audit. It's not. That doesn't matter in a lot of cases, but probably does for a network security solution - I would absolutely be asking deeper questions if I was deploying any of these products en masse.
But then again, the insurers probably asked for a SOC2 certificate, so I guess like most things in life, it's not about whether the systems are secure - it's about whose insurance is ultimately covering the loss.
> SOC2, ISO27001 and all that shit is not the same thing.
Hard agree. SOC2/ISO27001 controls are a thing. They might be a useful thing. But they're mostly a bureaucracy/compliance thing dreamt up by auditors and other people wearing suits and who like money as a system of paperwork that has been thrust onto the world.
Arguably getting their standard to be the 'accepted' one was a great achievement, because now anyone serious in the enterprise software space needs to pay someone else in order to get some paperwork about their thing, in order to sell that thing to other people.
These standards serve a purpose and I'm not denying they have some normative requirements. But no SOC2 audit goes deep enough, or is offensive enough, to catch pernicious quality issues in the implementation of software like this.
The gulf between "what people think the audit report says" and "what the audit report actually says" is sufficiently wide to be scary, given the extent these reports are relied upon as a checkbox exercise in "yes we can buy this system".
No amount of paperwork or process in the world is going to survive contact with a developer who can push code with undetected bugs like this, unless perhaps the development process is slowed to such a glacial pace and lines of code pored over for weeks. That would be unacceptable to any typical VC-backed product org that is required to show progress towards profitability.
No amount of paperwork from people wearing suits is going to protect you from the script kiddie hacker in their bedroom (or, equivalently, nation-state APT) with all the time in the world (and now, LLMs) to help them find and exploit vulnerabilities in some product/system.
At least in this case the user already needed to be on the tailnet to exploit this vulnerability. But writing daemon software that's exposed to the internet and is relied upon (or can reasonably be expected to be relied upon) by users as a fundamental part of their network security arrangements has a special obligation to protect those users. And a SOC2 report or whatever just isn't going to cut it.
The normalization of SaaS and software in enterprise has created a checkbox compliance environment where non-technical stakeholders evaluate the security of critical dependencies based on non-technical evaluation matrices, and most of the time have no comprehension of the classes of defects that the model doesn't prevent.
Yes. You're still running the native Tailscale client code on the hosts, which this evidence reveals can't be as trusted as Tailscale would like us to believe.
I also wouldn't trust Headscale fully. It had a critical defect at some point that, IIRC, would allow an attacker to rotate the key of a registered node without auth to a value chosen by the attacker. And its primary maintainer is a member of the Tailscale team, apparently maintained with full approval of their employer and with reasonable transparency between the projects, but nonetheless the overlap is a little close for comfort.
Frankly, as you've said, I don't trust any of these solutions to be anything more than a convenient way to jump onto a bastion or another host of minimal consequence to get into the network and jump onwards.
Exactly this. Most of my time writing code is now not necessarily spent writing the said code, but going through whatever Claude or some other agentic process produced and tidying the comments to be less temporally sensitive to the conversation that produced it.
The problem is that process of not writing the code, but just editing what the LLM produced – and somewhat mindless editing at that (I'm editing comments, not LoC!) – leads to a loss of focus and all the perils of human procrastination that entails (hello, writing comments on HN).
I've tried to prompt Claude et al. not to do this - but whatever I've tried so far, even meta-prompting it to ask why it ignored my instructions, it doesn't work, doesn't stick, and I can't find a good way to stop it.
Seeing the level of thought that went into user experience design, research, and arguing for the _right_ page to redirect to is such a delight.
Engineering (as with so many professions) is about so much more than just shipping features as quickly as possible, and it pleases me when I see fellow engineers taking care and showing thorough consideration over the potential impact of their design decisions on people from all walks of life and circumstances.
My first name can be shortened, and I go by either. When I first signed up to Claude, I thought we were entering the world of artificial “intelligence”, so I told it my name was “<long form> or <short form>”.
Well, it hardcodes that field rather than running it through the model, but I’ve kept it so I get an evil chuckle to myself (or perhaps pyrrhic reassurance) at its lack of smarts and a reminder that it’s still a somewhat subservient product experience that isn’t all that smart after all.
Thanks! Oh I have every confidence we are still studying this, and that it's a thriving field – forgive me for implying that it wasn't.
I was (badly) getting at the fact that back then, as a function of the totality of knowledge we had, discovering a new knot could be quite transformational – whereas now it's just one of many professional fields of modern research. Not implying it was then, or now, merely a hobby.
Agree with the other commenter - this is very charming! I find it a wonderfully romantic idea to contemplate that, at some point in human past, studying and developing new knots (or even stumbling upon new knots and sharing that idea) would have been a realistic endeavour that expanded the boundary of human knowledge and gave us newer or safer ways of building and achieving things.
Nice site, but I'm really missing any altitude reference for the satellites. It's hard to use any satellite tracker with any degree of utility other than as a toy website when it's exceedingly difficult to determine and compare basic altitude information across different satellites.
Possibly a separate concern, but I have some degree of confidence that the requirements and oversight of the CA/B forum (or whomever else determines which root certs go into bundles) are sufficiently strict, and issuers kept under sufficient scrutiny, that I tend to trust those more than I trust myself to secure my own root CA keys adequately. The ideal would be for people setting up their own PKI to ensure their root uses the Name Constraints extension, but the default “can sign anything for any host” I fear makes it easy for people to install their own self-pwn device, and probably left the private key lying around on a box exposed to the Internet.
* with some notable root certs that I have… questionable… trust and confidence are not simply controlled by certain state actors.
The article lets itself down when it reveals it's had some marketing "polish" added: "where certain resources (like an AI model instance) are stored"
They could have picked something far more concrete (for Cloudflare's business and the type of services they deploy) than "AI model" there, which is clearly picked just to make it seem 'current' and on-trend.
I’ve consciously not used Fable because I want some usage allowance to remain for the rest of the week. The 2x billing is just too aggressive for me when I tried it (max x20 plan user currently).
I believe some Tube stock uses wheel revolution counters to track where the train is and trigger announcements, although a lot of signalling will be going over to using balises to tell the trains where they are (if not already) and to provide supervision.
> If trains were made cheaper, some of them would become extremely unpleasant to use.
Yes, it is a fact of modern life that one reason there's no political will to reduce ticket prices is that it's an effective pricing mechanism for limiting demand or pushing travellers to other modes of transport to avoid further overcrowding – as perverse as that sounds for a rail network.
I also run mail servers for others, mostly non-profit adjacent groups who don’t have the capital to be extorted by cloud service providers.
Sure, there are some things to learn, but like anything – if you do it properly, it’s not hard and can work properly. Never had any deliverability issues over that time (yes, even to the big providers). I also almost never touch the boxes (I do about one architectural overhaul a decade and am working on the next right now).
If you’re willing to invest the time and resources to do it properly, I agree, it works fine.