smaudet

Exactly.

> a stealth bot to access a website, digital platform, or online service in a manner that is reasonably likely to damage, impair, or burden the technical or commercial operation of a website or other internet service

"stealth" - what does that mean? This is largely a meaningless term. "damage, impair, or burden" - again, too vague. It would be good to specify something specific, e.g. so many tens of thousand of damage (reciprocal to the assumed fine - a journalist or user is unlikely to be reselling data at this scale, an AI scraper may incur or inflict such costs). "that is reasonably likely to" - this phrase is doing some heavy, heavy lifting, but like others have mentioned, there aren't very many "reasonable" examples, and those have to be defined in a court of law.

Like you and others have said, the immediate reaction would be legal departments essentially banning any and all access, because there would be room for someone to file a suit, and even if you win, there's no guarantee you get your fees back...

Then Law is both broken, and dumb -

This is not exactly your focus, but this means that it can be possible for there to be a set of laws in U, such that an action is required and illegal if not present, but that this same action is illegal in C...

I.e., the predication is both meaningless and pointless, unless the supposition is that the laws of U don't hold - if C extradites a citizen of U over said action, is then U's law not supreme?

And here you learn why security is often just theater (not saying a proper elliptic key is theater)...

It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?

The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".

It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...

I can see the headline now:

"Mosquito dunks linked to declining bear population - farmers struggling with deer populations"

If they were being held liable they would have never released the models into the wild, not until they had much much better understanding both of how they operated but also how to operate them...

They have never understood what they are doing, and have just been causing literal mayhem...

The company that made it available should be sued and pay damages.

> we will realize that our passion and pride in our work was not really valued by employers

Most of those employers are not valued by anybody... The big secret is they (mgmt) are the most replaceable here...

Of course they will say, well they have the money, and I suppose that is true, for now...

Coding was never the bottleneck...

And how many billions or trillions have we wasted on people who didn't understand that (or did, and are just busy generating hype).

Ultimately, this (llm) technology (as it is being developed/used), is not useful to us...

And meanwhile, did any human find the whole process useful - no, not all...

Hurrah!

I'm not sure if the parent comment means to say, but I could choose to interpret their meaning to be:

PNG/JPEG have strong support (nearly everywhere). I think of them almost as the modern TIFF - relatively simple, and almost everything supports one or both of them (few to no issues).

JXL may eventually get there (that indeed seems to be its goal), but for now I wouldn't drop e.g. PNG or JPEG support in favor of JXL now.

And arguably, perhaps never drop support; its such a prevalent format, even if all software (prevalent or otherwise) supports the format in 10 years, there will be such a huge stockpile of JPEG/PNG that something will need to be used to read/convert.

I think you're probably missing the forest for the trees here... broadly speaking, these multibillion "parameter" (whatever that actually means) models store a lot more than shakespeare, and have storage costs in the 100s of GB/TB (which translates to $$$$$$ in SSD/RAM costs), nevermind the (kilos/mega/giga)watts involved, all the pollution, etc...

Meanwhile, a template (maybe a couple KB) costs less than a couple cents to store and run. Large Languages Models are not really interesting, (smaller) LLMs that only contain "what you need" are.

>I expect the code to be exactly what has been reviewed by me under that hash

Sorry, no.

Again, hashes are by definition, insecure. I.e. you don't have a guarantee that the hash references the same commit, just a (very, very strong) probability that it does.

> Everything else would just be a crazy invitation to make supply chain attacks uncircumventable.

What? Uncircumventable? Logically equivalent, I read your statement as "So if all cars are not blue then they must be red"? This does not follow...

I like the last part of the article, which proposes a (very reasonable sounding) extension for people who care (more) about their code-sec. You should be able to swap out your hash algo without having to rebuild your content addressing system.

Separation of Concerns, people...

Your points are full of mistakes and misleading claims.

I don't simply mean to be disparaging - its important to security that the people making the decisions are a) competent b) can read, otherwise any "security" decisions they are making are at best probably insecure, and at worst, causing active harm and insecurity, DOS, etc...

Generally, I think you didn't read (or at least comprehend) the article:

1) Your assertion is factually incorrect. Practical proof of concepts are not "CVEs exploited in the wild". The article is not claiming that SHAttered is not correct, it in fact references it.

2) I don't think you read the article. The article claims the exact opposite, and in fact addresses the issue WRT to distribution.

3) Your sentence here is very confusing - I'm going to give you the benefit of the doubt and presume that you mean to say that the problem here is in the security of the naming. HTTPS itself has nothing to do with distribution security, that would be DNS/SecDNS (IFF you are using git+http protocol, then HTTPS is relevant, but not to git otherwise). But this is exactly what the article was talking about, the distribution is the security, not the hashing algorithm.

Google has become useless.

Possibly, it's worse than useless, even harmful now.