mmsc

99% countries, as they say, "acknowledge China's viewpoint".

There are other vulnerabilities in that library too. I reported some (with some PRs) https://github.com/indutny/elliptic/pull/338, https://github.com/indutny/elliptic/pull/337, https://github.com/indutny/elliptic/issues/339 but I assume they'll never get fixed.

The library is dead and should be marked as vulnerable on npmjs tbh.

It is eerily similar to our times, too, unfortunately.

I also recently wrote a similar policy[0] for my fork of a codebase. I had to write this because the original developer took the AI pill, and starting committing totally broken code that was fulled of bugs, and doubled down when asked about it [1].

On an analysis level, I recently commented[2] that "Non-coders using AI to program are effectively non-technical people, equipped with the over-confidence of technical people. Proper training would turn those people into coders that are technical people. Traditional training techniques and material cannot work, as they are targeted and created with technical people in mind."

But what's more, we're also seeing programmers use AI creating slop. They're effectively technical people equipped with their initial over-confidence, highly inflated by a sense of effortless capability. Before AI, developers were once (sometimes) forced to pause, investigate, and understand, and now it's just easier and more natural to simply assume they grasp far more than they actually do, because @grok told them this is true.

[0]: https://gixy.io/contributing/#ai-llm-tooling-usage-policy

[1]: https://joshua.hu/gixy-ng-new-version-gixy-updated-checks#qu...

[2]: https://joshua.hu/ai-slop-story-nginx-leaking-dns-chatgpt#fi...

and potentially not, too. totally overhyped

Does basically all network leaving China still get ratelimited at a few megabytes per second?

I do not think that exists. I imagine the diplomats and other foreigners living there will have this, though.

When I was there two times (in Pyongyang, and in villages in the north east & Rason) any access to the outside world was prohibited via a network other than telephone (I could make outgoing phone calls via the hotel). Even traveling very close to the border (which they use jammers to block outside connections), my guides were annoyed when they saw I was trying to connect to the Chinese network from my phone.

The only place I saw any access "to the outside world" was in Rason (https://en.wikipedia.org/wiki/Rason_Special_Economic_Zone), where one of the casinos had a computer which could be used to access the internet (through the Chinese GFW, of course).

  console.log(config.isAdmin); // true!

Mismatched smart quotes are visible in this archive.

  > let config = {};
  > Object.assign(config, JSON.parse('{"__proto__": {"isAdmin": true}}'));
  console.log({}.isAdmin); // true!

  > console.log({}['constructor'] ? {}['constructor']('THIS MUST NOT BE EXPOSED') :  'pub')
  [String: 'THIS MUST NOT BE EXPOSED']

There was a TC39 proposal a few years ago [0] that proposed to block the getting/setting of object prototypes using the bracket notation, which would have prevented this vulnerability.

At the moment, every single get/set with a square bracket, which uses untrusted data, needs to do some manual check to see whether variables contain "bad" keys like `__proto__`, `prototype,` `constructor`, and so on. This is incredibly annoying, and doesn't really fix the issue. It's possible also to freeze an object's prototype, but that causes other issues. It's also possible to use Object.create(null), and Object.hasOwn (also known as Object.prototype.hasOwnProperty), but again, this does not scale because it has to be done _every single time_.

Maybe it's time to revisit this from a language perspective, instead of continuous bandaid fixes for this language-specific vulnerability (a similar language-specific vulnerability exists in Python called class pollution, but it's .. extremely uncommon).

[0]: https://github.com/tc39/proposal-symbol-proto

> Numbers!

I do not see how such numbers are valuable to people reading this post, as the first indication of the existence of this vulnerability.

The Wiz post has significantly changed since it was first published (and how it looked when first posted to HN), FYI -- see [1]. When it was published, it was a summary of the React announcement, and was somehow longer than the original and yet provided less useful information than the original.

In any case, the "tell" is the syntactic structure (as Chomsky would say) and certain phrases used in the post.

[0]: https://news.ycombinator.com/newsguidelines.html

[1]: https://web.archive.org/web/20251203162416/https://www.wiz.i...

The important part to know:

- Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.

- The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack

- Some React frameworks and bundlers depended on, had peer dependencies for, or included the vulnerable React packages. The following React frameworks & bundlers are affected: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

Yes, Gmail for example will drop emails from mass-senders that don't implement both SPF and DKIM.

On the one hand, you're right, it is distasteful, I completely agree. On the other hand, GitHub and Google and the public domain internet isn't everybody's CV that they can pick and choose which of their actions are publicised, tailored towards only their successes.

How ironic, considering every time I've reported a complicated issue to a program on HackerOne, the triggers have completely rejected them because they do not understand the complicated codebase that they are triaging for.

Also the curl examples given in TFA completely ignore recent developments, where curl's maintainers welcomed and fixed literally hundred of AI-found bugs: https://www.theregister.com/2025/10/02/curl_project_swamped_...