bostik

To be fair, if you work in the UK government then everyone you meet on a daily basis is in high likelyhood a criminal.

If they're not laundering money, trafficking people or avoiding taxes, they're likely a visitor who has come to commit bribery. Oh sorry, "lobbying".

> You can agree with the rules anthropic wanted, but having rules set by a private company at all that apply to the military does seem fair for the military to object to.

Oh the hypocrisy and irony. This coming from a country whose military sets rules on other countries' armed forces how weapons systems bought from US can be used.[ß] By this standard US itself should be designated as a supply chain risk for everyone else.

ß: for a very long time in the Ukraine "conflict", US refused to allow their gear from being used to attack targets outside of Ukraine's borders.

Well, they have at least one way to extend their market's lifespan at this point. They can double down on the provenance and openly claim the flag "product of artisanal slavery".

I'm sure there are enough hard-right wingers who will happily flaunt their wealth and disdain for other human beings.

Indeed. Don't think of these as "agents" or "bots", but as hostages with severe Stockholm syndrome. They will do anything to appease their captor's wishes.

And then consider that they have vast latent capabilities, infinite patience and no moral code.

Rather sad to see them go down that path, because Greenhouse used to be a pretty good system. For an applicant it was reasonably low-friction[ß] and for the company doing the hiring it made their internal hiring process steps very smooth indeed. I have fond memories of being on the business end of Greenhouse when hiring and interviewing people.

That they have stooped to dodgy marketing with bad and/or massaged statistics is telling. To think that a "Voice AI" interview would be anything other than demeaning is beyond tone deafness.

ß: someone early on in the company's history must have realised that zero-friction application submissions were a terrible idea. You want candidates who at least had to go through one step on their own to submit their CV - otherwise you get flooded by LI/Indeed style spam typhoons and other eldritch horrors.

When you run tens of thousands of simulations for complex economic models, you actually do want to see the extreme outliers too. I can't recall who said it, but in finance the interconnected incentives make so-called Black Swan events much more likely and frequent than models or theories can comfortably account for.

In a way... when it's finance, they should be maybe called Gray'ish Swans?

Your post has a trove of really good data. A lot of care, skill and attention must have gone into building that kind of expertise. When you then use an LLM to produce a post about it, that comes off as lazy. It wouldn't have to be that way, but sadly very (very!) often is.[0]

Writing well is hard. Editing text to be readable is hard. Shortcutting that process is a signal to your audience that you do not appreciate their time. I use LLMs at work to generate client-facing analyses, but I never let a single version go out without doing at least some revising. LLMs love nothing more than to generate another token, which makes their output flowery and verbose. They overuse rule of three, without any of the underlying understanding why it works, let alone when (and how) to break it intentionally.

I spotted the familiar "seesaw cadence" in your post but ploughed through because the content itself was still damn good. It's a shame that you did not put the same level of care into your writing that has gone into developing the technical expertise. Getting the post flagged because of the generic anti-LLM sentiment is undesirable but expected. HN doesn't have a way to mark posts as "sloppy writing but content-wise really good".

It's the same kind of visceral reaction this crowd tends to have towards voice notes: "if you did not bother to condense your thoughts and instead dumped half an hour of rambling for me to dig through, why would I waste as long to listen to you not being able to say it clearly?" ["Podcast for none"]

0: The only exception I can point to is https://nearzero.software/p/warranty-void-if-regenerated (discussed at the time in https://news.ycombinator.com/item?id=47431237).

That's quite an indictment of the common app development practices. (Not that I disagree with your point...)

And security is hard. Because it is by definition off the happy path, it is quite often at odds with MVPs and rapid release cycles. Then you add all the ways the users can use your product to attack/abuse others.

Any non-hobbyist app development does indeed require at least a decent understanding of security.

> deliberately destroy old notes and issue new ones with different images to replace them

Big part of the reason for this appears to be security. Many years ago a high-ranking official from Finnish central bank told in an interview that bank notes need to be redesigned approximately once per decade. Reason is that it takes about that long for the materials and printing technology to get commoditised enough for criminal enterprises to be able to start manufacturing "high-grade" forgeries at any real scale.

Every generation of bank notes employs a whole bunch of newly developed technologies and tricks that make the notes themselves distinctive, as well as incredibly difficult[ß] to forge.

ß: Some of it is down to tightly locked down and guarded speciality supply chains. Some is due to advances in microprinting and ilk. If you had unlimited resources, you could arrange to have the necessary equipment, supplies, staff and materials to print your own forged money. It'd just be slow, low-yield and very expensive.

Matt Levine pointed out to a likely culprit, and it indeed has nothing to do with the business outlooks.[0]

SpaceX sold only 5% of their stock in the IPO. Earliest lockups will start to [partially] expire in mid-August, bringing in further 7% of SpaceX stock to market. If you expect the market to be flooded with >2x volume of supply, you can either sell right now before the price drops even further or hold and wait for the business fundamentals catch up with pricing expectations.

0: https://bloom.bg/4f7pFnd

> I have never seen a UI where just selecting text means auto-copy to the paste buffer.

Isn't this the default behaviour of every X application since the 1990's?

> Copy/paste is one of the most basic, low-level features of a modern operating system. NO APPLICATION SHOULD EVER SCREW WITH IT, IN ANY WAY!

-Ghostty enters the chat-

Middle-click paste in Ghostty is hazardous: the damn thing can move your cursor to the position of your mouse pointer and paste there. An utterly infuriating behaviour - it is a text terminal. It has no business emulating the usability crimes GUIs first committed and then committed to.

Or as the Risky Business guys crystallise it: "James Kettle breaks the internet. Again."

This does happen in Finnish tax system. Your tax rate (percent with one decimal) is calculated based on your annual gross income. Rates are supposed to be calculated smoothly, and they are certainly calculated for each individual separately.

In reality they are step functions. It is surprisingly common to have people refuse promotions because if would put them above an income tax threshold, bump up their rate, and end up with less money after taxes in the end.

The UK tax system is far from fair but at least it has clear brackets: income above threshold X is taxed at rate Y.

Thinking like a business vs. thinking like a state.

If you see a given technology as fundamental[tm], you want to ensure that you will retain access to it AND its ongoing development. China may well foresee a possible future where US imposes export controls and global sanctions to block PRC from having access to the necessary equipment to either train or use the most advanced models - let alone its alternate parallel universe where US might go as far as prevent anyone else than US themselves having the most advanced forms of the technology at all.[ß]

To ward off such a scenario, China doesn't need to become the sole leading supplier. They only need to guarantee that nobody else can even try to block them off, and that the technology itself can never be yanked.

ß: What could possibly give them such ideas?

More likely the PRC sees the open-weight models' progress as a way to prevent an existing dominant player from cementing their (finicky) lead and pulling up the ladder.

That strategy happens to have beneficial side effects to the global Hoi Polloi, but to attach any kind of benevolence to it would be naive.

Yeah, and Beacon was acquired a year ago. The acquiring company in turn went private. Yesterday.

Genius coder, yes. Nice guy, most definitely yes.

> Now imagine if you lived in northern Europe around the 60th parallel, where the sun doesn't get high enough in winter to produce vitamin D.

Like... all of Finland? And most of Norway?

Both countries where the answer to "when does the sun rise?" can be "at the end of January".

"Temporary" can be an awfully long time. There is ample evidence that discovery rate of bugs (many of which can be bucketed into vulnerabilities) in any non-trivial piece of software is more or less stable.[0] In a recent podcast episode the ex-CISO of Adobe commented that every now and then they'd take a sustained squeeze to find all occurrences of a given type of bug (ie. source of vulnerability) in a codebase. They'd find a good amount of them and fix them.

Then a year or two later they'd repeat the operation and they'd find about the same amount of same types of bugs. In many occasions in code that had been in place in the previous round and had remained essentially untouched.

Paraphrasing what the Gruqg has quipped - a large piece of software has infinity bugs. Infinity minus N is still infinity.

0: Discovery rate with regards to the time spent looking for bugs. LLM-powered bug hunting has amped up the speed with which code bases can be investigated.

Hah. My chosen name collision with my online handle makes the models consistent. They all are certain that I am an adhesives manufacturer. (Good!)

On the other hand, the tool did make an assessment of sorts: NO STABLE PERSON FOUND.

> I think Andy Jassy did forward a concerning report about an apparent jailbreak in Fable, and he probably did so in good faith

If so, then he is not fit to run an engineering organisation.

The "jailbreak" in question was effectively (I'm paraphrasing):

    * You are a senior engineer.
    *  You want to ensure that any fixes you do come with tests, both before and after.
    * There is a bug in this code. It happens to be a security related bug.
    * Fix this code.

And the model did what it's supposed to. It wrote a fix, and to prove that the fix worked, it wrote a test for it. What do you call a test that happens to validate a security fix?

Yep. A proof of concept.

No, it's not that way around. And it's not a law.[ß] If you and a high-finance institution agree to a separate (lawyer-negotiated!) contract where you provide essential/important software to the institution, they quite often require code escrow arrangements as part of the deal.

There are a few such services around, usually owned by a giant global consulting house.

The idea is that if you as a vendor go out of business or otherwise become unable to maintain the software, the finance institution gets access to the software via the escrow. Importantly, they also gain the contractual and legal rights to further maintain (read: modify) the software.

Under such contract the vendor has an obligation to upload periodic code releases to the escrow service, and the escrow service validates that the release builds. (And passes the bnudled test suite.) Rather surprisingly these services don't even cost that much... at least in the grand scheme of things. The requirement usually comes up only when the underlying supplier deal is at least six figures annually.

ß: well, contract law is still law but not in the sense the parent appears to be thinking

Code escrow.

You factor in the expense of having your code releases escrowed by a third party (where part of the escrow contract itself is: "must be buildable from sources as provided"), and have a post-release pipeline that automatically uploads the new version. At the end of the term, the escrow holder releases all the versions.

This is a fairly common arrangement in high finance. If you want to supply services to a bank/insurer/etc. they will typically require an escrow arrangement as a contingency plan against you as a vendor going away. And yes, they pay the escrow costs.

ZDR had been turned off. We sent in a request to have it re-enabled (and to disable Fable access for the time being).

Somewhere along the line we also used the self-service toggle to turn ZDR back on. I am not 100% certain of the exact timeline of interleaving events, many of the actions were taken by our Western US folks. Sorry. It's been a bit hectic over the past ~36h...

I read the same announcement. Or more precisely, I read at least two slightly different revisions of the announcement (it was updated between my two passes).

Our org has ZDR, and has had it since the contract was signed. Yesterday two things held true at the same time:

    1. Fable was available if you had at least .170 CLI client; and
    2. ZDR was no longer on

By the time West Coast woke up, the admin panel apparently had an option to toggle ZDR again. It remained off by default.

They need to walk back a lot more.

Unilaterally revoking zero-data retention, even for enterprise contracts that explicitly require that? Nope.

Fable is utterly unusable for any kind of security work. I tripped the safeguards yesterday - using Fable to dig into a complex (& annoying) security bug that has so far resisted both human and Opus 4.8 level investigation. "Sorry Dave, I can't let you do that."

For the time being we are requesting Anthropic disable Fable for our enterprise and turn ZDR back on. The two may be interlinked so that one will always get neither or both. ZDR is a contractual obligation. Fable in its current form is useless. Might as well flip the old behaviour on and avoid burning money for no reason while this mess is being sorted out.

At least in a corporate environment, Claude Desktop is a pretty decent compromise. Preconfigured internally deployed MCP servers and third-party connectors make many of the necessary integrations relatively easy to control.

I use Claude Code CLI myself (inside a VM, to isolate it from the host) for >90% of my needs. For the remaining fraction - email scours, cloud drive searches, other third-party connections - the desktop application is surprisingly decent. I don't even have more than half a dozen connectors enabled. In the VM I have separate, personally managed access tokens available for various third-party services. Wouldn't really try to maintain more than 5-6, otherwise it gets too confusing. [ß]

The desktop application mostly Just Works[tm] with SSO. At least when M365 doesn't suffer from their 4-times-a-day auth outage.

ß: A lot of APIs and authentication systems were designed in the stone age. You either need a 1:1 permissioned access token that can do horrendous damage, or you deal with ultra-granular, confusing and ill-designed scoping jungle where nothing makes sense. Atlassian, I'm looking at you especially. At least an MCP server, provisioned with a reasonably done service account, doesn't have all of your powers to get things wrong with.

Like with everything in business and engineering, there's a tradeoff. My previous employer used Adyen as major payment provider (for quite some time, too). Their cost structure is sensible, the payment methods they support are convenient[ß], and their functionality is reasonably solid even in the edge cases. But everyone who maintained the payment service kept cursing Adyen for their awful APIs. The python runtime powering the old system had to carry an unmaintainable and effectively abandoned library to be able to process the Adyen payment gateway messages.

From what I understand, Stripe's main value proposition was: "how can we make this gnarly, confusing and complicated system an easy-to-use service that does NOT require the end-user to internalise the entire payment provider state transition universe?" That is obviously a valuable service, but is it valuable enough to charge an ongoing rake of nearly 300 basis points?

ß: for some weird reason people still insisted that they absolutely must be able to pay with Paypal. 2+ years of fighting cross-corporate politics + KYB and still having to stomach insanely high commissions left a properly bad taste.

The problem? Life imitates art.

To be fair, I'd consider hard-core scalability/reliability software engineering skills to be their very own speciality domain.

But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.

Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.