If it is cheaper, then it isn't the same cost. Yes, there are various ways to reduce cost and reducing the volume of work is only one of them. It doesn't work to accuse the article of being 'strange' for saying that using less of the services is cheaper. Because that is obviously one of the ways to be cheaper.

Could you please stop with the condescending tone of acting like people don't know about these things.

One, the severity score in many contexts does not matter because some security group thinks they are being extra secure by having a 'zero tolerance' policy, that the severity doesn't matter, no CVEs shall be detectable.

For another, the score is super subjective. Take CVE-2026-7210 and CVE-2026-41080. The exact same issue (one is in a C library, and one is tracking python wrapping that library). MITRE said the C library one was 2.9, but CISA-ADP said it was 7.5, and the python one was graded 6.3 (despite being the *exact* same issue as the C library was graded at 2.9). So between those two CVE numbers, the same issue is considered 2.9, 6.3, or 7.5, depending on who filled out the form. The score is by no means immune to the poor quality of the 'vulnerability' reports.

Reducing tokens would be a path to cheaper AI.

You seem to assume cheaper AI *must* only be about cost per tokens, but practically speaking they don't care about that detail so much as they care about the overall cost.

This has been playing out in my organization, where the consensus has been that folks burning through tokens like mad are, at their best, doing only as well as people using it in a more curated way. So the guidance has come down that people are only to be using it in a curated way, to reduce expense.

My take is based on pretty nuanced analysis of hundreds of CVEs over the past few years.

A common 'vulnerability' area that I find dubious is that some utility can be made to crash instead of exiting cleanly. Usually the rationale is that "imagine someone is using this in a kiosk-like context and they can crash out unexpectedly to a shell".... For utilities like wget and such that would never ever be in such a position. Even if such a kiosk application existed, the utility would crash back into the calling utility, and hard to imagine that sort of Kiosk design this century anyway.

Or things like "if an attacker just gets you to run this 4GB "script" in vim script then it could run arbitrary code... Except vim script can already run arbitrary commands already by design, so if a user would just run a script blindly, then just malicious commands would be so much easier. If a human does double-check, then the 4GB is even more suspicious than a script with commands. This isn't about issues that are exploitable but not exploited, this is about issues that as far as anyone can figure are not realistically exploitable in the first place.

One vulnerability in curl was that you could pass arguments to get curl to emit c code (but not compile it or run it), and someone could get it to emit arbitrary C code. So the attack scenario would be "you have a user who is somehow allowed to run curl and a compiler but not run anything else and be able to write the intermediate C file". I cannot imagine a situation where the user has free control to curl arguments but cannot simply write a file and also be able to invoke a compiler without having some other more trivial way to write a c file first.

Note that I'm not talking about AI specifically, AI is just continuing the trend. The security industry has long had a human issue that makes people understandably be a bit dismissive of CVEs at first glance because Wolf is cried just constantly. A "security researcher" finds a bug, particularly one where the user has to be explicitly trying to use it wrong, and get a CVE issued instead of accepting it may be "just a bug".

You have CVEs that are very real and very severe. But by the numbers, most of them are like the above, where someone has to invent pretty stupid scenarios in order to fairly consider it a security issue.

Note that while it notes that over 98% of "discoveries" seem to not be exploited, it also notes this is the rate for the pre-AI world as well.

Which is consistent with my experience with security "findings", very poor signal to noise ratio. At least in my time with the security industry, it's always hard to know whether to take something seriously, as they keep coming up with duds and claim victory. They tend to be eternally in "the sky is falling" mode, and sometimes it is very much falling, but most of the time it is nothing of consequence.

It's a pretty nice position because generally it's a bad move to call it out because then you would be branded as "not taking security seriously" if you express doubt over the potential consequences of a "security" finding.

Nothing in the summary really conveys why this raises to the level of news. Digging in it doesn't really have consequences for the users in the short term.

Plausibly a good change, but a change among countless other good changes that pass without notice.

Well, I never promised as good as google, just saying that so long as android auto is an option, then nothing lost by the built in map going to Apple.

They could, but that runs counter to what they want.

They want to kill resale and while they are at it, take control of whether you can play your game as purchased a few years ago, or make you have to buy a remaster, or just not be able to play them and play something new they can get revenue for instead.

They have sorted out that the vast vast majority of their user base will run games on whatever terms the console picks. Alienating the minority is worth it to assert that much control over the experiences of the majority.

So there's not any detail on whether this means iOS will be running or if this 'MapKit' supports another platform.

Apple did go out of their way to say *Carplay* would be supported, but no one has mentioned whether android auto will be supported.

This seems like a broadly fine concept, so long as they didn't toss Android Auto support to get this partnership with Apple going. The built in nav was, at it's best, never better than google maps and, I presume, Apple.

So that's describing the sane way to go. Problem is security teams aren't "sane".

For example, security team demands we account for CVEs, and we reply we use RedHat so RHSAs are the better curated source and here's all the information.

Nope, they don't "trust" vendors and we should independently account for CVEs. To the extent RHSAs cite CVEs, ok, but they don't speak to *every* CVE (notably, a lot of Android specific CVEs that don't apply to the RHEL builds), and we aren't allowed to just take RedHat's word for it that they cover the CVEs...

And so many CVEs are "won't fix" and that drives the security team to great anger despite RedHat making pretty reasonable calls in every single one of these I've ever had to investigate...

Think the root is that folks see GenAI as their ticket to unskilled participation in a very highly paid industry.

However things go, that will not be the outcome, and I at least look forward to people being disinterested when it doesn't work that way (either they don't get to participate, or the industry won't be a high pay one anymore).

Problem is that ultimately, the CVEs tend to lose meaning. The relative risk of a CVE becomes impossibly diluted because most of them aren't of practical security consequence. It's a lot of work to keep up the charade that CVEs are something that need to be handled as "more than bugs" and that you can somehow get a better consistent experience by avoiding bugfixes but still get CVEs to maintain security..

Very critical things have CVEs that are really important, but the CVE facet of it does not really set off alarm bells since they've been overused. We instead create "brands" for the "actually important" vulnerabilities.

Maybe a good tool for entities like linux distributions to start their advisories, but it's a complete disaster for end-users to think they should be managing CVEs directly, which is precisely what the security community frequently demands. Also precisely why this is vaguely controversial.

Evidently they do at least have a rationale for that.

Instead of LIDAR in every car, they push LIDAR maps that they maintain by regularly driving the supported roads.

Of course, a LIDAR unit in the car would bring it back to a one-time purchase making sense, but initially that was too expensive, and now... well... they like the recurring revenue....

GM has a 'fix' for that:
https://news.dealershipguy.com...

Why make infotainment systems better, when you can just make phone integration worse?

I can't speak to it as I don't have a GM car, but do note they removed Android Auto and Apple Carplay from many of their vehicles, precisely to drive people to buy OnStar to have the big driving friendly displays be able to do the things many folks just started using their phone for when CarPlay/Android auto became a thing.