HackerTrans
TopNewTrendsCommentsPastAskShowJobs

bostik

no profile record

Submissions

CyberSlop – meet the new threat actor, MIT and Safe Security

doublepulsar.com
3 points·by bostik·8 mesi fa·0 comments

comments

bostik
·14 giorni fa·discuss
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.
bostik
·14 giorni fa·discuss
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?
bostik
·14 giorni fa·discuss
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.
bostik
·15 giorni fa·discuss
Yeah, and Beacon was acquired a year ago. The acquiring company in turn went private. Yesterday.

Genius coder, yes. Nice guy, most definitely yes.
bostik
·17 giorni fa·discuss
> 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".
bostik
·17 giorni fa·discuss
"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.
bostik
·22 giorni fa·discuss
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.
bostik
·23 giorni fa·discuss
> 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.
bostik
·27 giorni fa·discuss
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
bostik
·28 giorni fa·discuss
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.
bostik
·mese scorso·discuss
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...
bostik
·mese scorso·discuss
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.
bostik
·mese scorso·discuss
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.
bostik
·mese scorso·discuss
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.
bostik
·mese scorso·discuss
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.
bostik
·mese scorso·discuss
The problem? Life imitates art.
bostik
·mese scorso·discuss
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.
bostik
·mese scorso·discuss
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.
bostik
·2 mesi fa·discuss
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.)
bostik
·2 mesi fa·discuss
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.