flaminHotSpeedo

I was under the impression the purpose of that is to give an LLM a cheap (in terms of context window) understanding of a repo, and not at all for the benefit of humans?

Whether that's effective is another matter, even if the LLM generating the list does so correctly and updates the list consistently

I haven't personally tried, so I can't say for certain, but Lambda has publicly stated they run on bare metal EC2 instances, presumably the supply of whatever instance types they use should be fairly healthy

Most mature and/or security conscious providers don't consider containers to be a secure isolation boundary (with Microsoft being a notable exception, though it's unclear whether that's a failure of internal policy or incompetent enforcement of policy).

Containers provide a much broader attack surface than VM's, and since they're not considered secure as an industry standard there's likely to be less resources put towards managing container escape CVE's than VM escape ones.

I wasn't expecting a peer reviewed study, but I certainly was expecting more from that title

What makes you say that? The article is pretty clear that they had the llm working in a staging environment, then it decided to use some other creds it found which (unbeknownst to the author) had broad access to their prod environment.

I wish there was a mechanism to force shitty, bloated companies that have been mismanaged into a nosedive to divest "culturally valuable" IP early.

I enjoyed the early ghost recon and rainbow 6 games, but I don't even bother keeping up with news for newer ones.

350 was late last year. The text at the top of the linked page says prices are up about 30% over the past month. Directly prior to the war starting the price was about 470

> My opinion is that both should be liable in a case like this.

I totally agree, but if I went after every company I felt to be incompetent to the point of criminal negligence I'd be up to my eyeballs in lawsuits just over password requirements.

> The answer is always the same IMO. Break up big tech companies into a million little pieces.

Generally I agree, but in this case I think there's an even simpler solution: 1) hold Google accountable for entries in their safe browsing lists (as an adjacent poster pointed out, the legal precedent may be there) and 2) make companies legally liable for misusing 3rd party data.

Really just the second part would suffice, and frankly it's purely good for society. The inevitable outcome is that no one exposes data they can't guarantee, and maliciously consuming 3p data would nearly disappear

That's fair, if your domain is erroneously put on the block list, Google should be liable for the consequences.

But my point is that any knock on effects like domain suspension, email deliver-ability, etc. stem from 3rd parties misusing the safe browsing list outside the scope of safe browsing.

I don't see how Google can be blamed for other companies erroneously treating the safe browsing list as a source of truth for generally malicious domains

Self censorship requires a threat or risk of detriment if the party doesn't self censor, right? Where is that here?

What Radix does has no impact on Google, and I don't see how Google would be incentivized to pressure Radix. So I don't see how to make the leap blaming Google for Radix's incompetence. Yes, Google should recognize the risk of this happening, but they'd have to balance that against the rewards (or at least what they consider rewards)

Theoretically, the easiest way is to use a sub address (more commonly/colloquially known as email aliases or plus addresses, they're described in RFC 5233). You should be able to add a separator character (usually a plus, sometimes other characters instead/in addition) and arbitrary text to your email address, i.e. "myemail+somecompany@example.com" should route to "myemail@example.com"

In practice, this works about 95-99% of the time. Some websites will refuse the + as an invalid special character, and the worst of the worst will silently strip it before persisting it, and may or may not strip it when you input your email another time (such as when you're logging in or recovering your password).

I also suspect spammers strip out subaddresses frequently, very little of the spam I receive includes the subaddress.

So the only 100% reliable way is to use your own domain, but you don't need to run your own custom mail server

You might want to review the commenting guidelines, notably the first few.

Like you mention, big tech gravitates to a handful of tech hubs across the US, which drives up salaries for every company in the area. Which is more data suggesting something is wrong with BLS' numbers.

My expectation (based on anecdotal/personal data - if you have better data I'd love to see it) is that the median developer in a tech hub makes more than an entry level big tech kid. So unless there's either an error, omission, or unexpected inclusion in the BLS data, the data implies that nearly all of big tech, plus ~50% of developers in tech hubs, accounts for about 10% of the workforce.

That doesn't make sense. What does seem plausible is that this data doesn't account for bonuses, options, RSUs, and the like, which would put big tech entry level jobs right around the median for developers. I'm not certain if that's the case, but it at least passes the sniff test.

I think there's a fundamental misunderstanding where executives mistake software engineering for "code monkey with a fancy inflated title"

And coding agents are making that disconnect painfully obvious

I question their data if their p90 value is $211k

I recognize that not everyone makes big tech money, but that's somewhere between entry and mid level at anywhere that can conceivably be called big tech

Are you thinking of the Missouri department of education's teacher directory website?

https://krebsonsecurity.com/2022/02/report-missouri-governor...

Luckily someone eventually talked sense into the governor, despite him ignoring the FBI originally when they told him it wasn't a hack

Actually, it's really important to me to have a network of atomic clocks available to verify the times I clock in and out, I want to make sure I get paid for an accurate duration of time down to the nanosecond

> 103 drivers (41.9%) overall tested positive for THC, with yearly rates ranging from 25.7% to 48.9%.

The statistics for this seem suspect at best, I'll believe it once it's peer reviewed

> Researchers analyzed coroner records from Montgomery County in Ohio from January 2019 to September 2024, focusing on 246 deceased drivers who were tested for THC following a fatal crash.

This paper would need to go into way more detail to be at all useful.

40% is a staggering number, which makes me suspect that all it measures is Montgomery County police's pretty good track record for deciding when to test someone for THC during an autopsy

Yeah, in some (rare) situations physical isolation is a more appropriate level of security. Or if you want to land somewhere in between, you can use VM's with single tenant NUMA nodes.

But for a typical case, VM's are the bare minimum to say you have a _secure_ isolation boundary because the attack surface is way smaller.

Containers are never a security boundary. If you configure them correctly, avoid all the footguns, and pray that there's no container escape vulnerabilities that affect "correctly" configured containers then they can be a crude approximation of a security boundary that may be enough for your use case, but they aren't a suitable substitute for hardware backed virtualization.

The only serious company that I'm aware of which doesn't understand that is Microsoft, and the reason I know that is because they've been embarrassed again and again by vulnerabilities that only exist because they run multitenant systems with only containers for isolation

That's entirely incorrect. For starters, they didn't get unlucky. They made a choice to use the same system they knew was sketchy (which they almost certainly knew was sketchy even before 11/18)

And on top of that, Cloudflare's value proposition is "we're smart enough to know that instantaneous global deployments are a bad idea, so trust us to manage services for you so you don't have to rely on in house folks who might not know better"

There was another deployment system available. The progressive one used to roll out the initial change, which presumably rolls back sanely too.

Do you have a public source about an embargo period for this one? I wasn't able to find one

Like the other poster said, roll back should be the right answer the vast majority of the time. But it's also important to recognize that roll forward should be a replacement for the deployment you decided not to roll back, not a parallel deployment through another system.

I won't say never, but a situation where the right answer to avoid a rollback (that it sounds like was technically fine to do, just undesirable from a security/business perspective) is a parallel deployment through a radioactive, global blast radius, near instantaneous deployment system that is under intense scrutiny after another recent outage should be about as probable as a bowl of petunias in orbit

To clarify, I'm not trying to imply that I definitely wouldn't have made the same decision, or that cowboy decisions aren't ever the right call.

However, this preliminary report doesn't really justify the decision to use the same deployment system responsible for the 11/18 outage. Deployment safety should have been the focus of this report, not the technical details. My question that I want answered isn't "are there bugs in Cloudflare's systems" it's "has Cloudflare learned from it's recent mistakes to respond appropriately to events"

They kinda buried the lede there, 28% failure rate for 100% of customers isn't the same as 100% failure rate for 28% of customers

What's the culture like at Cloudflare re: ops/deployment safety?

They saw errors related to a deployment, and because it was related to a security issue instead of rolling it back they decided to make another deployment with global blast radius instead?

Not only did they fail to apply the deployment safety 101 lesson of "when in doubt, roll back" but they also failed to assess the risk related to the same deployment system that caused their 11/18 outage.

Pure speculation, but to me that sounds like there's more to the story, this sounds like the sort of cowboy decision a team makes when they've either already broken all the rules or weren't following them in the first place

My understanding of the contemporary argument against publicly traded companies, though I'm not completely convinced of them personally, are that the fiduciary obligations inevitably drive those bad behaviors, and/or that shareholders often demand short term returns at the expense of long term value.

As far as "fixing" the problem, I think it would be important to expand voters' influence over the company in addition to voting changes like you described. I don't know how to make it feasible, but IMO voters should be able to influence or directly decide much lower level business decisions than they currently do

That's what I was getting at, though I wasn't sure if my perceptions matched the general consensus (which it seems they do).

If a manufacturer has been broadly considered as unreliable for the past 20-40 years (JK's came out in 2007, and I still heard some people talking about jeeps as being reliable in the TJ era, though I'd personally disagree), I think it's fair to say they have a reputation of being unreliable.

Out of curiosity, what do you mean by Jeep riding on their reputation?

Based on everything I've seen and heard, Jeep's reputation is for unreliable vehicles that are increasingly difficult to repair. This seems pretty on-brand for that reputation.