Certain technology just has too much potential to be misused / people repeatedly prove they can't use it properly. It also comes with risks of making authoritarian takeover easier.

However, here, it seems they used Flock a bit like a regular ANPR. The actions they took independent of Flock show there are better stories to use to criticise this technology.

Flock does have AI components (this one seems LLM based). Basically every ANPR system will also use some level of AI.

Also, on "reality would like a word". Why not just speak normally instead of using what seems like a high-school grade comeback?

The main Flock related issue here is that officers treat results that come out of the systems as gospel. The same thing has happened with face recognition systems. There is also the broader issue of access controls to Flock, 5A, and whether places should be building up a technology so powerful (surveillance infrastructure can easily be used for evil).

The complaint now shifts to that you'll still have files on your system, or can't control exactly what models are stored on your computer. Apple has reasons not to give this fine control: what you have on HN is a group of people who are vehemently anti-AI, use Apple products, and still want features very specific to their control of the system.

Apple caters to the general user. If they think a setting is going to be confusing or likely to be misused, they won't implement it. People know the reality that if Apple intelligence is successful and if this feature is implemented, the general user won't know which parts of their workflow use which features. Removing the models will be advertised as a cheap hack to save storage, and people will be confused when they can't turn intelligence on again.

The fact that the core premise of the article (repeated in the title and first sentence) is about "phoning home": > The nice thing about keeping a blog is that I can say at precisely 9:51am, Wednesday 5th February 2025, I discovered that macOS 15.3 had enabled a feature that was phoning home every 15 minutes with personal data. And that I said “no” and turned it off.

The entire basis of this complaint is not understanding the difference between "duration" and "interval". And not being able to click the link that is given to you in the settings menu or just search Apple's docs for the setting ( https://support.apple.com/en-mn/guide/mac-help/mchlfc0d4779/... )

I don't think they're trying to flex this as a large number. They don't want to give an exact number, as that may change etc / is fuzzy, but also want to give you an idea of the scale.

They say "In the future, we intend to expand our geographical reach much further". I imagine this commentary is somewhat related to the concerns that AI will create an even worse "global underclass". AI developments are first accessible to Americans, then allies, and then later the whole world.

But I'm not a sure a human on their own would've done better. There aren't enough resources to make the changes required.

The current ones I see are: * Can't build on Linux < 5.6. But people aren't complaining strongly about this, since it requires a build from source / isn't a result of an update from a distribution (and people can wait for updates / implement them themselves). * An issue hit with chroot false + daemon. People running this in an automated manner (as some claims suggest) are already using it in a way fairly likely to be insecure, chroot false is strongly discouraged here, and the whole point of these commits was that they fixed CVEs impacting precisely these people.

This happens frequently when there are fixes for CVEs, since regression tests can't catch many things which incremental rollouts can. It happened for example in 2025. People are right to imply the reaction is totally outsized here, and it's almost certainly the case that people are overreacting to AI (rather than the somewhat weak idea that it's because of the frequency of these issues).

What's really funny is that the people opposing AI here are showing far less literacy than those who wrote the code. People claiming to be affected by this bug severely are likely exposing themselves: * One bug is for Linux < 5.6, where it didn't hit distributions. This is a low severity bug where it can't build, where distribution maintainers may be reasonably expected to fix it themselves (although rsync will also fix it eventually too).

* The other bug affects precisely the people impacted by the CVE https://github.com/RsyncProject/rsync/issues/897

You probably don't want to revert in this scenario. If someone is hit by this bug and is running rsync in an automated manner, it is highly likely they're ignoring very many security practices: you're usually not supposed to run native rsync in an automated manner (the main use case is for public users, where you can't SSH etc; since it's unencrypted, you're supposed to check a checksum against a website etc); these cases are hit with chroot false, which is deeply discouraged and leads to far larger attack surfaces.

* People with linux < 5.6 can't build this from GitHub. This to me seems like a fairly minor regression: people using maintained versions of 5.6 (mostly extended security) will have distro maintainers pick up that the build is failing, allowing for it to be corrected in a timely manner.

* Hardening against path-traversals causes failures for users with: no chroot; using the native rsync protocol. Ironically: chroot = no is deeply discouraged; you shouldn't really be using native rsync in an automated manner (and perhaps it seems I wouldn't advise using it at all); the CVEs the commits fix apply exactly to this use case.

https://www.cve.org/CVERecord?id=CVE-2026-29518

Requires daemon + no chroot. " daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false."

So the workflows affected are those which are the most vulnerable, and yet people are recommending that people revert versions.

* Furthermore, if a regression test picked this up, it would've been written previously.

> Just look at the donors of Renaissance Misanthropy. If you're actually interested, who funds each project is listed in the PDF here. https://www.renaissancephilanthropy.org/annual-reports

As you can see, it's mainly philanthropic projects of wealthy families.

Not only would it be a leap to suggest that people automatically lose their integrity by taking funds for projects they believe are useful, especially after involvement with adjacent fields, but you are suggesting merely being impressed by a fund is enough to dismiss their views?

You also have no evidence that Renaissance Philanthropies is a front for VC companies. All news coverage indicates that they seek to be an alternative for high net worth individuals engaging in philanthropy.

Many people discovering Erdos results, engaging in Olympiads etc, are doing so with publicly available models and publish the resources used in the process.

The emissions per kWh of energy used in providing internet downloads probably is similar to that per kWh of energy used for washing clothes.

( https://apollojournals.org/afj/ap10fj/as10-day2-pt9.html )

It can be found in this video: https://www.youtube.com/watch?v=DQVEsfa15SY

There is nothing in the DPA implying companies it is applied to can't be acting in a hostile manner, or that it can't be applied when security interests of the US are being threatened. Of course they have no reason to state such a distinction repeatedly in law (claiming it doesn't apply to adversarial companies....), but 50 USC 4566 applies clearly when acts are being made against national interest (this pertains to foreign investment, which isn't the nature of the Anthropic rift, but shows clearly the DPA contains laws with intent of preventing adversarial action against the US).

Even without knowing the intent of the behaviour, it should be quite clear that companies that are vital to national security are more likely to be supply chain risks. Amodei's direct words were: > These latter two threats are inherently contradictory: one labels us a security risk; the other labels Claude as essential to national security. Being a security risk and essential to national security are not "inherently contradictory".

It is clear that the DPA can be invoked for companies posing risks to national security:

> On October 30, 2023, President Biden invoked the Defense Production Act to "require that developers of the most powerful AI systems share their safety test results and other critical information with the U.S. government" when "developing any foundation model that poses a serious risk to national security, national economic security, or national public health."

Furthermore, it should be quite obvious that companies very important for national security can act in manners causing them to be national security risks, meaning a varied approach is required.