A more likely scenario is to focus on the model users as potential victims, e.g. by logging internal infrastructure descriptions, capturing private access tokens from chats, etc. That is very deniable, because it's hard to prove where the compromised data originated.

> Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ?

Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-potentially-harmful functionality, although I expect people have done that in the past. But, I think overall we're agreeing here.

For the purposes of model selection, it's irrelevant to an attacker if a model achieves an offensive objective 70% of the time, when that model refuses to participate 100% of the time. However, a model that always participates but "only" succeeds 10% of the time is golden -- just run it more often, or give it more tokens. Attackers are patient, and many of them are well-resourced.

The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073. That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a....

Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.

Hmmn. All of this information should live in the monitoring system, in which case any frontier model will be able to get to grips with it in short order. It feels like the author doesn't really fully understand the changes brought about by the systems they are writing about.

That's a hard one for Cloudflare, no? They got to where they are by being (if you want to be cynical, playing the role of) the benevolent, neutral guardians of the internet, a one-stop shop that makes most of the bad nonsense go away without much effort on the part of the developer. Continuing that stance probably does mean some basic AI crawler blocking by default, unfortunately. At least they document it [1].

[1] https://developers.cloudflare.com/bots/additional-configurat...

The problem is going to become that there's no incentive for anyone to run the stupidly-expensive training phase. May God have mercy on the stock market.

So, overall, you get more done that without AI, at the cost of spending almost all of your time writing specs and doing code review and almost none of it writing code.

Do you get 3.3x the work done? Probably not. Do you get 2x the work done? I think maybe, if you can hack the dynamics of the new job as a manager of eager robots. For me the jury's still out on the second point.

Real-world observations suggest batteries are likely to be serviceable for around 20 years, which is around the same lifetime of an average ICE car. Users who can tolerate a much reduced range (which is most of us) can likely extend this even further.

Are you advocating for legislation? How would that work?

Tesla is doing poorly here. That's almost entirely down to Musk's public image, not because BYD make better cars.

[1] https://www.smmt.co.uk/vehicle-data/car-registrations/

Why are Spain's courts allowing this injunction to stand? It's clearly being used to bring the court system itself into disrepute at this point.