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.

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.

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

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

-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.

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.

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?

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.

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

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".

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.

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

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.

Yep. A proof of concept.

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

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.

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...

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

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.

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.