bostik

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.

I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:

    * Internal services that never had real APIs are getting them retrofitted via the MCP layer
    * MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions

The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.

The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.

MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:

> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.

I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.

And in a way this feels like a good thing (from a corporate strategy perspective). If MS really wants to compete with Claude Code they will need to dogfood to have even a hope of ever catching up.

As much as I may dislike MS, their software or their practices I have to admit that they have pulled this off at least once before. Back in 2019/2020 their Teams web client was absolutely atrocious and utterly unusable on Linux. Sometime in 2023/2024 it had become quite tolerable and worked mostly better than Google Meet. (Screen sharing options in Teams suck to this day, though.)

Many of Ikea's wood (wood-like?) products are pretty flimsy, designed to be built once and never moved or taken apart. (cough - all cupboards, most cabinets - cough)

But somewhat ironically their steel kitchenware is competitive with catering equipment. It may not be as well designed for maximum functionality and storage packing efficiency, but costs about the same or even less than comparable Vogue gear. Over the years I've spotted an increasing number of street food vendors using Ikea bowls and trays, so the price and availability advantage appears to be real.

Part of this is likely driven by regulations. Github has plenty of clients that fall under DORA, NIS2 or both.

I don't remember the exact wording about what qualifies as "incident" or "major incident" but the TL;DR is that the regulated entities are required to notify their regulators of impactful supplier incidents within 24h with initial information and within 72h with more complete details.

Which in turn means that Github will have signed contracts that bind them to accommodating timelines.

I used Claude about a week ago to do a pretty intensive refactoring. Cleanup, initial modularisation, beginnings of a test suite, and better isolated build. In a span of couple of hours, and over a sequence of 20+ new commits, I burned a hair over $100 in tokens.

If you are working on a seriously large legacy code base, I can see how you'd get to >$250 on a bad day.

The assassination of an investigative journalist and its subsequent handling is certainly a symptom of the island's embedded corruption. (And I say this as someone who likes the place!) When gambling and international finance make up >10% of the GDP, that's not unexpected. IIRC gambling and online gaming alone used to be >15% of Malta's economy but that balance has shifted over the past decade.

I'd think that the country's regressive anti-abortion laws are a bigger stain on its reputation. You can root out corruption. Moving the nation's Overton window towards a less illiberal stance tends to take a few generations.

This should be on your "About" page, ideally coupled with direct link(s) to Companies House.

You need to be flaunting your sovereignity, not merely wielding it.

Sports betting exchanges have been doing that for a very long time. There is never a good time to take the system down for maintenance - event settlements happen every few minutes, and live games with in-play betting are going on somewhere in the world at any given time.

Makes things damn hard indeed, because you have to truly learn asynchronicity, CQRS and complex live migrations. (Incidentally, engineers who have worked on such systems tend to be over-represented in extreme HA businesses.)

Already happening. UK airlines are desperately culling flights, and have been doing so for the past month. The pace of cancellations is also increasing, with the last week seeing cancellation waves that from the outside look quite paniccy.

Likely combination of both.

CC demonstrated that one can have a powerful, flexible and responsive interface in a terminal, and to have that for a piece of software that has wide mass market appeal. I don't think we've seen this since WP5.1 . (Personal opinion: the CC terminal application beats their desktop software hands down in usability. That said, the desktop software is a lot better for corporate email trawls and helping to iterate on visualisations.)

Then for prospective devs, CC makes it easy to sling (and debug!) code that handles the various terminal vagaries with much less headache. No need to care about manually maintaining control code state machines; no worries about a missed SIGWINCH handler screwing up your in-window layout on resize or font size change; much easier integration with available CLI tools.

I have written some ncurses/C code in my time. I wouldn't want to do that by hand again.

Keep in mind: the only thing a capitalist fears is a truly free market.

The highest ROI for any business is to buy their own politician. That allows you to block competition and other inconveniences at a legislative level.

> have claude read all your emails every day...

To be fair, I do that. 2-3 times a day, in fact. Not all of my emails (the archive has ballooned to several hundred thousand messages total), but the most recent ones certainly.

My standard prompt is along the lines of "go through the last N days of my emails, identify all threads that I need to know about, action on or follow up with". N is usually a number between 2 and 5. I've specified a standing of set of rules to easily know what is likely a source of noise to aid in skipping the bot spam.

The company is charged API pricing through an enterprise contract, and I remain persistently curious how much I burn. My daily admin-related token expenses appear to fluctuate between $1 and $5. For something that saves me up to 2h of time a day I consider that a rather tolerable deal. (When I dive in to code to do refactors or deep investigations, I can spend as much as $25 a day.)

Maybe because Anthropic are trying to get to an IPO and everything is securities fraud?

If their CEO was just flapping his mouth without any other comparable baseline, it'd probably be different. But as the GP points out, open-weight model providers are charging comparable rates and very likely have positive profit margins. That would imply that with API pricing tokens are sold at above cost.

That cost may well be "inference only", so excludes everything apart from hardware and power. Whether that's enough to cover the enormous training costs and other overheads is a different question.

The best way to describe AI agents I've heard: treat them as hostages that will do anything to appease their captor.

They have a vast latent knowledge base, infinite patience and zero capacity for making personal judgement calls. You give one a goal and it will try to meet that goal.

> Did any of the ITU standards win?

Maybe X.500 - also known as LDAP, and widely deployed across enterprises in the form of Active Directory.

They're already crippling their AI to perform what look like sponsored searches.

The plural of anecdote is not data but this does not feel like a one-off thing: I was trying to find where it would be possible to get to have a reasonable holiday, and asked Gemini to list me all the international airports in two named countries that had direct flights from my preferred departure airport. The response came back with a single proposed flight destination with "book here" prominently available.

Only once I told it that the search was NOT an impulse purchase intent and I really wanted to know the possible destinations - then did it actually come back with the list of airports that satisfied my search criteria.

Although if we are looking for the bright side, it did provide a valid and informative answer on the second try. I haven't had that kind of experience on SEO-infested Google search for quite a long time now.

It's a bit more nuanced than that, because we're not talking about outright market manipulation. Absent any other information, the market makers always assume that they might be trading against a better informed counterparty - so absent any other signal, the prices at which executions happen are themselves a signal.

Think about it: you have N market makers offering both sides of the trade with a spread between them. When there is no other meaningful activity, the best prices are more or less stable. Now someone comes in and buys one side of the trade. Each marker maker will, individually, make the same two decisions:

    1. "If you bought at that price, I should raise my price and charge you more"
    2. "Since you bought at that price, I must assume you have more information and I should get out the way to avoid an expensive mistake"

The magnitude of the decisions made depends on various factors, but as a short-hand the size of the made trades in respect to the overall liquidity available near the midpoint directs how strongly the market makers react. A tiny trickle of insignificant trades does not move the price in any meaningful way (unless the sizes are so small that the execution commission starts to make a difference). A sustained directional flood of trades will cause the midpoint (and volume) to move to the direction where the market makers can sell at higher prices and avoid accumulating any further losses.

Unless the prosecution can prove that the trades meaningfully moved the market prices, it's probably going to be really hard to use the term "leaking".

I can't shake the feeling that there may be political reasons to not even attempt that angle. What legal precedent would it set if a judge actually ruled on that and the prosecution won? Which entities within the government would be financially inconvenienced?

> unless you keep the poisoning attack strictly inaccessible to the public

This is likely impossible. As the in-vogue breed of model extraction methods ("distillation attacks") demonstrates, you can infer the underlying training and/or fine-tuning of a model with a series of carefully constructed prompts.

Another name of model poisoning? Adversarial fine-tuning.

Well, that's the entire point.

If we take a completely utilitarian and amoral viewpoint, the insiders are selling their material, non-public information. The rest of the market participants are buying. From the latter's utilitarian perspective the former are providing a valuable service and getting paid for it. I'm pretty sure there was a legal term for such sales activity...

The only people playing fair are those who don't know how to cheat well enough.

Okay. You win.