dhx

Some relevant information:

[1] Federal Vehicle Safety Standards (US) § 571.206 Standard No. 206; Door locks and door retention components. https://www.ecfr.gov/current/title-49/subtitle-B/chapter-V/p...

[2] Interpretation of standard 206 mentioned above in relation to central electronic locking systems. https://www.nhtsa.gov/interpretations/11503wkm

[3] Interpretation of standard 206 mentioned above in relation to child safety door locks. https://www.nhtsa.gov/interpretations/11345wkm

[4] Video tear down and analysis of how two versions of a Tesla external door handle assembly operate. https://youtu.be/Bea4FS-zDzc?t=278

In [1], the standard appears to be concerned primarily with preventing external intrusion of a vehicle and making sure door latches and hinges won't easily pry apart. It's _very_ lightweight on requirements. No wonder vehicle manufacturers at examples of [2] and [3] have to ask even the most basic questions about underspecified car door, latch and locking mechanisms.

From what [4] shows, Tesla external door handles have a default position of recessed (inaccessible) due to use of a spring. Hence if the car loses power (accident cuts wiring loom etc) or there is another control system or electrical fault, the external door handle defaults to being inaccessible. Further, the door handle assembly does not appear to contain a local controller so the wiring loom between the door handle assembly and controller elsewhere in the vehicle becomes safety critical. Control and power wiring looms also appear to have no redundancy to door handle assemblies. The only redundancy which appears to be possible, _may_ be, depending on failure mode such as cut to a wiring loom for one door only, trying to open another door.

From a quick search, it appears the school of thinking in the past has been in a vehicle impact where occupants inside are unable to escape, it's assumed doors and door frames are crushed and cannot be opened anyway until emergency services arrive and pry/cut them open.

From a safety engineering perspective, particularly in relation to vehicle fires, external doors should have a default mechanical position of unlocked/openable and only lock under positive control and power of the vehicle. Ideally there would be a mechanical circuit breaker designed too which cuts power to door handle/latch assemblies in the event of vehicle impact, causing them to automatically unlock. There are a few problems though--battery drain to keep the doors locked when the car is idle and external tampering to trick the vehicle into unlocking doors and providing access to thieves (in my view not an important requirement--just don't store valuables in vehicles).

Most discussion in recent years about chip fabrication shortages, expansion, etc has focussed on leading nodes (<7nm) and AI/computer chips. But perhaps more quietly in the background, China has been rapidly building other semiconductor capacity such as power semiconductors used in electric vehicles, wind turbines, solar modules, train traction systems, etc. For example, Chinese-produced motor vehicles (37% of global motor vehicle production in 2025) in a year or two are targeted to use 100% domestically produced chips, and this production is decreasingly dependent on imports, even for factory tooling.

The report at [1] is a good summary of long term trends for China's rise in domestic self-sufficiency for semiconductor manufacturing. The report predicts "At current pace, China may achieve self-sufficiency in semiconductor manufacturing by 2027-2028, though trailing at leading-edge nodes". By contrast, before the first Trump presidency in 2017, a chart shows China importing 30% of all globally manufactured semiconductors (and increasing). Other reports on semiconductor fabrication equipment sales show the means, which is China having been and continuing to be in number (1) position for expenditure on semiconductor fabrication equipment.

The reports at [2] and [3] are also a good summary of long term trends for semiconductor foundry capacity predictions to 2031. A prediction is made that China's current 12% global semiconductor foundry supply capacity (across all semiconductor categories) in 2025 will expand to ~30% by 2031.

[1] https://www.yolegroup.com/product/report/china-semiconductor...

[2] https://www.yolegroup.com/product/report/status-of-the-semic...

[3] https://www.yolegroup.com/press-release/the-global-race-for-...

I've contributed a bit on the infrastructure side of things to OpenStreetMap--high voltage transmission lines, pipelines, etc. I also have contributed to alltheplaces.xyz which whilst mostly known for collating shop locations, also collates infrastructure point data such as substations, traffic cameras, bins in parks, etc. As I'm in Australia, I naturally have more of an interest in Australia.

Sometimes when trying to improve OSM with a new substation, wind farm or otherwise, you might have missing information such as a wind farm that is covered with stitched imagery--left half is a 2024 swath showing construction underway and concrete foundations prepared, or a pad excavated, right half is a 2026 swath showing turbines installed and operating. Sometimes it can be helpful to double check assumptions made about an excavated pad being a wind turbine foundation against public data--e.g. press release stating how many turbines have been ordered for the wind farm, or a low resolution map in a company report indicating rough placement of turbines.

Or for a new substation with a 330kV bus and 110kV bus confirmed by tracing transmission lines to other substation buses, there could be a dangling transmission line traced to a tower next to the new substation, but it's not clear which bus it may connect to. This is where some more detailed public data, in the rare case it may be available (such as in Australia), can be useful to combine together to confirm an assumption. A real case I found recently was in Saudi Arabia where a press release from a company stated something to the effect of "We just successfully installed a 330kV feeder 9281 to substation G40", which confirmed how the the transmission lines connected to the substation.

I have however mostly mapped in countries where OSM is most lacking--and for electricity infrastructure that is China--by orders of magnitude. An example I worked on previously is Hainan, which was previously mostly missing from OpenInfraMap.[2] China publish nothing and even require their street view imagery providers to blur substations. Even so--this is largely a pointless effort because with a bit of extra puzzle solving (such as switching between 4 historic satellite images to find the one where a shadow or a tower or pole is visible) it's almost always possible to get an accurate map produced. Gaps are mostly limited to out of date satellite imagery which for China is a huge accuracy problem because the scale of electricity grid expansion is absurd. It's commonplace to start tracing a transmission line to only find half way along, the transmission line disappears on a stitch in satellite imagery, and then more recent imagery on the other side of the stitch shows 3 new 500kV+ (including HVDC) transmission lines routed in parallel, replacing the old line. You can open an OSM editor almost anywhere in China and scroll around for a minute to find an unmapped high voltage transmission line, wind farm, substation, etc (having a list of coordinates where new satellite swaths are available would help most here).

For a global list of electricity grid data sources, [1] is very detailed list that is well maintained. Countries in Africa are particularly challenging--some you'd be lucky to find even a single 800x800px image of the electricity grid... or even a website for the transmission network operator.

[1] https://github.com/open-energy-transition/Awesome-Electrical...

[2] https://openinframap.org/#8.28/19.121/110.058

I found [1] which appears to offer state-of-the-art performance of ~1000s latency for a FHE GPT-2 transformer block, equating I think to 3.33h inter-token latency (0.00008 token/s) for GPT-2(small) which has 12 transformer blocks. This result is using optimised packed arithmetic operations on a GPU as well--so seemingly is unlikely to have much performance upside from further optimisation.

I'm not sure I've interpreted [1] correctly though, and would appreciate correction if necessary.

[1] https://arxiv.org/pdf/2604.04783 -- GPU Acceleration of TFHE-Based High-Precision Nonlinear Layers for Encrypted LLM Inference -- Guoci Chen, Xiurui Pan, Qiao Li, Bo Mao, Congming Gao, Chengying Huan, Mingzhe Zhang, Jie Zhang -- Apr 2026

To throw out some real and up-to-date numbers from [1] for FHE at "128-bit security level", to sort 8x 8-bit unsigned integers on the most ordinary of desktop PCs, wait 3 seconds for the result. Want to sort 32x 8-bit unsigned integers instead? Come back 34 seconds later for the result.

update: also see [2] for some primitive unsigned 64-bit integer operation benchmarks with the TFHE-rs library (winner in the sorting performance comparison of [1]). Equality at 80ms, addition and subtraction at 100ms, division at 8 seconds, etc.

[1] https://eprint.iacr.org/2026/1495.pdf Oblivious Sorting under Fully Homomorphic Encryption: A Comprehensive Survey and Performance Analysis, Omar Ahmed and Rostin Shokri and Nektarios Georgios Tsoutsos, 2026

[2] https://docs.zama.org/tfhe-rs/tfhe-rs/1.0/get-started/benchm...

Distribution infrastructure capacity is a current and ongoing concern for summer peak loads (every house turning on air conditioners at once) even with the large government subsidies that have existed for residential solar panels, residential batteries, reverse cycle heat pump cooling/heating and insulation. The cost to rebuild every distribution substation, change every pole-top transformer and rewire suburbs would be much higher if these subsidies never existed.

For most of Australia's population you can look up an annual report that each transmission and distribution operator is required to publish annually for their predicted demand on substations, transmission lines and distribution lines. For example in Victoria this report is the TCPR, an example available at [1]. For many distribution substations, the 10th percentile maximum demand is predicted to occur in the early 2030's, meaning that at least transformers at substations would need upgrading, or the substation rebuilt or expanded. The reasons include higher density development in urban areas, electric vehicle charging and for winter, electrification of gas heating.

As an example of the impact of residential solar generation, [2] states that for an urban growth corridor of Melbourne being built largely in the era of residential solar panels being a standard housing feature, a distribution substation ATS West has 2x 150MVA transformers operating at combined peak of 200MVA, also with 125MW of embedded residential solar generation. Without that 125MW embedded residential solar generation, this substation and feeders perhaps would have had to be replaced years earlier to allow import of ~325MVA rather than ~200MVA. Also not mentioned explicitly in this report is residential battery storage which may be reducing maximum demand from predictions made before residential batteries were widely installed.

As a side note, perhaps Australia perhaps has the most open and transparent electricity market in the world? I don't know any other country where the entire electricity grid down to 230/400VAC distribution lines running on poles in every residential street is available publicly on a map, including serial numbers of poles and ratings of pole-top transformers. And substation schematics and constraint reports, etc are all available through various public reports. I think the transparency demonstrates a great deal of confidence in the electricity grid and how it is managed.

[1] https://www.powercor.com.au/network-planning-and-projects/ne... -- refer to the PDF document in the TCPR zip file download for a substation-by-substation analysis in easy to read format.

[2] https://media.powercor.com.au/wp-content/uploads/2025/06/121...

I take it from [1] (transcript of recent DeepSeek CEO discussion with investors) that DeepSeek would disagree on the immediate catastrophic impact to the likes of OpenAI or Anthropic. The reason is even though technology parity mostly exists, only OpenAI, Anthropic et al have the inference capacity to gain market share and generate revenue. Chinese vendors don't have the chips needed to scale up inference and gain market share, and the DeepSeek CEO doesn't think this would happen in optimistic circumstances in the next 3 years, but thinks it might be possible in 5 years.

In summary, regardless of country of origin, availability of inference capacity is the moat protecting the likes of OpenAI and Anthropic, not technology superiority.

[1] https://www.fredgao.com/p/deepseeks-liang-wenfeng-breaks-his

It would have to be reproduced on a CUDA stack because AFAIK Huawei don't sell the Ascend 950PR (for inference) to anyone, rather, they operate them as part of the Huawei Cloud and only allow select customers (such as DeepSeek) to rent them.

The CEO of DeepSeek recently revealed to investors a lot about the resources available to DeepSeek, and the gap between Huawei and NVIDIA. Select quotes from the transcript (translation is a bit patchy on the source website though):

"We currently have roughly 20,000 H-equivalent compute cards"

"Huawei 950—right now Huawei gives us 16,000 cards, this should be publicly stateable."

"Like Huawei gives us roughly 16,000 cards of capacity, internet giants maybe get a hundred-something thousand, we get ten-something thousand—I think this ratio is also relatively... but this is probably just how much capacity Huawei has."

"16,000 Huawei 950 cards only equal 4,000 B-series cards."

"Huawei’s supernode, Huawei’s 950 supernode, in performance and price can completely substitute for NVIDIA’s GB200, GB300. The price is definitely more expensive, but limitedly so. Fifty percent more expensive, a hundred percent more expensive—a hundred percent more doesn’t matter, two hundred percent more doesn’t matter. For example, a hundred percent more expensive—I think it can already be considered a price-level substitute."

"I think domestic hardware might need a few years."

"I don’t quite believe that five years from now, we’ll still be stuck on the production capacity problem. Right now we’re definitely stuck on the production capacity problem—this year, next year, the year after, I think we might still be stuck on the production capacity problem, but five years later, I think maybe not necessarily—I’m still relatively optimistic."

[1] https://www.fredgao.com/p/deepseeks-liang-wenfeng-breaks-his

Now that people have played with the model for a bit, there is one reported real world win for DeepSeek v4 Pro 0813 that is perhaps quite consequential given the drama in the US about Mythos.

In a benchmark, DeepSeek v4 Pro 0813 found 87.5% of selected real world software vulnerabilities publicly reported and with CVEs assigned, which is above runner ups Opus 5 and Qwen 3.8 which both found only 81.3%. However there is a downside to this--DeepSeek v4 Pro 0813 is less accurate with a 35% false positive rate versus GPT-5.6-Sol's 15% false positive rate. For vulnerability analysis though, it's probably worth finding that one extra vulnerability no other model has found even if requires significantly more triage to remove false positives, or additional cost to run every vulnerability detection through other models to verify.

[1] https://nitter.net/pilvar222/status/2087691659953815783#m

Old DeepSeek Flash 0731 prices have been independently reproduced.[1] The issue is DeepSeek being inundated and not having capacity to serve the demand, hence the price increases to significantly dampen demand. Never mind international demand either--just think about the magnitude of Chinese domestic demand. Prices for anything related to AI or computing in general (mobile phones, cloud data centre hosting, etc) will continue to climb fast as demand for computer chips _far_ exceeds supply. DeepSeek doesn't have an option other than to just work away on improving their technology in the period of time before computer chips once again become a commodity. For example, DeepSeek's cache ratio for their models apparently leads to 1/2 GPU time requirement versus the second best provider.[2]

[1] https://nitter.net/thdxr/status/2085377844515922210#m

[2] https://nitter.net/thdxr/status/2087610161636471289#m

Also of interest: DeepSeek V4-Pro-0813 (1.6T-A49B) benchmark scores have apparently just been announced on the DeepSeek WeChat channel and they're sitting about Fable 5 level.[1]

[1] https://www.reddit.com/r/LocalLLaMA/comments/1vmi0fg/deepsee...

They're going to rely on a fuel source which only has 9-17 years of domestic supply at current production rates and proven reserves?[1]

And a fuel source with largest proven reserves in countries that are currently or can be foreseen to be problematic to extract and purchase from: Russia, Iran, Qatar, Turkmenistan, Saudi Arabia, China, UAE, Venezuela and Nigeria rounding out the top 10.[1]

[1] https://en.wikipedia.org/wiki/List_of_countries_by_natural_g...

For lumber, data at [1] indicates much volatility in North American lumber prices from January 2023 to February 2026. Trough-to-peak prices for 2023, 2024 and 2025 have been over 30% across a given year. The main difference for 2026 so far is the stability of prices which have remain peaked for half a year.

Now is the perfect time for someone being overly dramatic to say "In the 2 years since July 2024, lumber prices have increased 47%, significantly higher than inflation".

But someone else could also say "Lumber prices are the same as July 2025 even though inflation has risen" or "Lumber prices are up just 10% in the 3 years since July 2023, lower than the rate of inflation across these 3 years".

[1] https://madisonsreport.com/wp-content/uploads/2026/07/IndexG...

There can be surprisingly few critical components and processes in a water and sewerage network due to gravity-fed designs (far more cost efficient), large buffers (water reservoirs, sewage sumps, etc) allowing intermittent operation of otherwise critical components, retained ability for humans to manually operate equipment, and also the fields of availability and safety engineering which typically prefer elimination of software failure modes by designing equipment to not rely upon software.

The aim of a water network is to:

1. Take water from a water source (elevated dam -- strongly preferred, river, ocean) and as much as possible, gravity feed it to a treatment plant.

2. Treat the water using processes that are simplified/fail-safe as much as possible and could be operated manually by humans if necessary. This is where availability and safety engineers would design equipment to not be dependent on software and instead use mechanical or analogue electronics control.

3. Pre-position treated water as much as possible at ~50-90m hydraulic head (~500-900kPA) above the water faucets where people want to use the treated water and provide a buffer for X days of usage. Any pumps between the treatment plant and elevated storage therefore only need to operate intermittently to refill the buffer.

Sewerage networks have similar aims:

1. Let sewage flow as much as possible downhill to the treatment plant via gravity. Where a rising main (elevation gain) is required, place a large enough sump for X hours/days of usage and pump up to higher elevation from the sump.

2. Treat the sewage using processes that are simplified/fail-safe as much as possible and could be operated manually by humans if necessary. For example, a compressor used for aeration can be manually switched on/off with a mechanical switch and plugged into a diesel generator, and not require someone logging in with multi-factor authentication to a laptop to issue a command to a PLC to turn on the compressor.

3. Design overflows into the system for emergency release of partially or untreated sewage, and practice this process as part of disaster recovery exercises. This is generally an aim arising due to risk assessment process that says building a $1bn sump with 8 independent pumps is cost prohibitive versus the 1-in-200 year chance of untreated sewage messing up a downstream river for a few weeks.

Ultimately a lot of the cybersecurity risk comes down to government appetite to accept 1-in-1000 (or whatever) year failure modes. Is it worth investing now in triple modular redundant automated control systems (mostly used in safety-critical sectors such as aviation and space), or installing a just-in-case diesel generator at every one of 500 pumping stations across a region, or building $10bn of sewage sumps to hold sewage for up to a month, or building 2 treatment plants instead of 1 and using different technology for each, or hiring and training more humans to regularly exercise manual control and operation of a network, etc? Or just accept that once every 1000 years, some water rationing may be required, or a downstream river will be polluted for a few weeks?

OSM probably has the best data on golf courses because for many courses, people have mapped each 'golf=hole' as a way, and mapped other golf course features such as 'golf=bunker', 'golf=green', etc.

OSM knows of almost 40k golf courses around the world.[2] This compares to 38k golf courses known to the R&A Golf Around the World Fourth Edition (2021) report and 37.6k courses listed in the NGF course database as of July 2024. It's likely OSM knows of 99.99..% of all active golf courses and also still retains tags for closed/unused golf courses too. So if OSM were to be inaccurate, it'd likely be inaccurate for whether a golf course is open or closed, rather than OSM not knowing about a golf course existing.

I wonder whether an OSM tile server / custom style sheet for golfers would be easiest and most useful/comprehensive way to keep track of golf courses?

[1] https://wiki.openstreetmap.org/wiki/Tag:golf%3Dhole

[2] https://taginfo.openstreetmap.org/tags/leisure=golf_course#o...

[3] https://assets.randa.org/c42c7bf4-dca7-00ea-4f2e-373223f80f7...

[4] https://thegolfwire.com/worldwide-golf-course-development-re...

Update 2:

Upon checking Sentinel-2 imagery for BAH55 from 2026-03-29 to 2026-04-13 (and all later imagery) there is also visible blast damage to the roof of BAH55, which would correspond in timing to media reports about damage caused about 2026-04-01. Sentinel-2 imagery appears to clarify AWS' claim of "while in Bahrain, a drone strike in close proximity to one of our facilities" to mean a direct impact to the building. However it seems likely from high resolution satellite imagery of BAH55 that the machinery rooms of the building perhaps took most of the damage, perhaps leaving data halls in a better shape elsewhere in the building (but possibly still unusable due to water/smoke damage).

[1] https://browser.dataspace.copernicus.eu/?zoom=17&lat=26.156&...

[2] https://browser.dataspace.copernicus.eu/?zoom=17&lat=26.156&...

Update: IRGC published satellite imagery a few hours ago showing an impact to BAH54, apparently impacted on 2026-07-24, alongside another undated image before the impact. From a quick comparison of both images with reliable satellite imagery sources (e.g. WV02 image dated 2025-02-21 on ESRI World Imagery Wayback) there are no obvious signs of image manipulation, with roof features and surrounding buildings/other features lining up as expected. Additionally the claimed post-strike image adds a significant number of vehicles to the site (when there are usually close to none present), which may correspond to fire fighting vehicles expected to be monitoring the site afterwards. Further, Sentinel-2 imagery from 2026-07-24 shows a dark patch (blast damage) on the roof of BAH54 per https://browser.dataspace.copernicus.eu/?zoom=18&lat=26.0509...

To add:

The request has not yet been published by GitHub to https://github.com/github/gov-takedowns/tree/master/India/20...

Also not mentioned in the project's GitHub repository yet per https://github.com/search?q=repo%3Apermissionlesstech%2Fbitc...

AWS's 3 data centres in me-south-1 are:

BAH53 (Manama): https://www.openstreetmap.org/way/1492345589

  An adjoining substation to BAH53 had one of it's two main buildings damaged/destroyed about 2026-07-16 per https://soaratlas.com/maps/asia-damage-to-data-center-power-substation-bahrain-jul-16th-2026-142024

  Then about 2026-07-22 BAH53 itself was damaged/destroyed per https://soaratlas.com/maps/asia-damage-to-amazon-web-services-bahrain-jul-22nd-2026-142112

  Possibly the least defended of the three sites as there is no air/missile defence battery in between this site and Iran.

BAH54 (Zallaq): https://www.openstreetmap.org/way/1359931661

  No media reports about this data centre being attacked previously. Possibly the safest of the three as there are at least two (probably three) air/missile defence batteries in between this site and Iran.

BAH55 (Hamala): https://www.openstreetmap.org/way/956069872

  Apparently the Batelco DC.1 data centre adjoining (and apparently critical to) BAH55 was damaged/destroyed about 2026-04-01 per https://www.bbc.com/news/articles/cgk28nj0lrjo _or_ the adjoining substation to these two facilities was damaged/destroyed -- news articles are hard to follow as to what exactly might have been damaged and the extent of damage caused.

  Middle ground for defence with one or two (maybe three) air/missile defence batteries between this site and Iran, depending on where drones/missiles are launched from.

If these data centres are rebuilt, you'd maybe expect them to be rebuilt in new locations behind existing _permanent_ (and seemingly quite expensive) air/missile defence batteries in Bahrain (https://www.openstreetmap.org/way/1492281507 and https://www.openstreetmap.org/way/1492953902). Based on the permanency of those air/missile defence batteries it doesn't look like the government of Bahrain are expecting things to get safer for data centre hosting in Bahrain any time soon.

See [1] for April 2024 Clickhouse Github activity analysis of the xz backdoor.

I haven't seen anyone write up a proper analysis that includes consideration of:

- GitHub activity (e.g. all API actions on GitHub side including replying to comments) _and_ mailing list activity _and_ other public facing activity all considered together.

- Complexity of public actions e.g. was there a queue of code changes that would have taken 20 hours effort to put together that were all committed at once? Were there any long streaks of high activity where it might reveal how many people were involved?

- Latency of public actions e.g. if an issue was raised by some random person, how long did it take for the attacker to respond, and later resolve/commit a patch? Similar to the complexity of public actions, it might reveal how many people were involved by estimation of the time needed for an experienced developer to fix an issue vs. actual time taken, both in terms of level of effort and duration.

- International dispersement of a team in different timezones with some core hours for collaboration, review and public facing activity.

- Public holidays, country/region-specific work habits, etc--e.g. consideration of "summer holiday" periods or similar common holiday periods, consideration of unusual days of no/low activity versus snow days, power outages, etc which might have been experienced by the attacker.

Distribution of actions from Github indicates the attacker used a 6 day work week excluding Sunday, and almost all activity conducted between UTC 12:00-16:00. Within these 6 days, activity was uneven at 0.5, 1, 1, 1, 1, 0.5 effort per day. There are low activity periods too that line up with summer solstice (southern hemisphere) or winter solstice (northern hemisphere).

There are interesting patterns in the data not yet publicly analysed (I think?) that seemingly would reveal the true location of attackers, particularly because attacker actions are anchored to uncontrollable events such as a known-good contributor (such as Linux distro maintainer) raising a Github issue against a repository and the attacker replying an hour later. For such events with low latency of reply, it'd be well worth considering when a reply was made quickly, and when it wasn't, across a few years of data points.

[1] https://news.ycombinator.com/item?id=39905375

Title is not correct. Microsoft didn't patch a lot of this, they're reporting patches for dependencies that other people patched and Microsoft are inheriting.

For example, Mariner (now branded Azure Linux) is a Microsoft-supported Linux distribution. So in this list of 570 vulnerabilities, Microsoft have reported 100 vulnerabilities inherited from all sorts of open source software projects included in their Azure Linux distribution. The OpenSSH vulnerabilities are described in better detail at https://www.openssh.org/releasenotes.html where it implies 2 vulnerabilities were detected with Swival Security Scanner (using LLMs) and another 6 by other researchers/companies (using undisclosed methods).

As an example of one of the OpenSSH vulnerabilites CVE-2026-59996 which is attributed to Swival Security Scanner, Swival have published the output of their automated vulnerability detection report at https://github.com/Swival/security-audits/blob/main/openssh/...

If demographics are a problem for chipmaking in China, then it's good to compare against key chipmaking countries.

To compare, 2024 (UN) fertility rates (highest-lowest):[1]

  US:     1.62
  Japan:  1.23
  China:  1.02
  ROC:    0.86
  ROK:    0.75 (where an increase to 0.8 in 2025 was cause for celebration, as is a predicted increase to 0.85 by mid 2026)[2]

Alternatively (and perhaps accounting for migration etc), UN 2024 forecasts population differences in these countries between 2024-2050 as:[3]

  US:    +10%
  Japan: -16%
  China:  -8%
  ROC:    -6%
  ROK:   -12%

[1] https://en.wikipedia.org/wiki/List_of_countries_by_total_fer...

[2] https://www.chosun.com/english/national-en/2026/01/24/IVHGRT...

[3] https://en.wikipedia.org/wiki/List_of_countries_by_past_and_...

For some recent data, see the diagram "Semiconductor foundry capacity 8" & 12" - by foundry location (in %)" at [1] for a rough idea of kWpm (thousand 300mm equivalent wafer starts per month) for key countries/regions for 2024, 2025 and prediction for 2031. China and ROK are predicted in this report to have the largest overall market share increases to 2031.

For some more detailed data (hard to find it publicly available), also see the OECD report at [2], particularly pages 18 and 20 (as numbered). This report provides a breakdown of ~2024-2025 per-country/per-region capacity by chip type (power, analog, speciality memory, commodity memory, advanced logic, mature logic) and a prediction for pre-country/per-region upcoming capacity increases by chip type.

There are markets within markets of course. China dominates in power electronics which makes senses when you consider even just their domestic demand for electric vehicles and renewable generators. Taiwan dominates in advanced logic and exports pretty much all of it. ROK dominates in commodity memory and also exports pretty much all of it. When you compare populations of China vs. USA, the USA are/will be punching above their weight for analog and advanced logic chips, which is also where the focus of their investment is.

In categories such as power electronics and mature logic which China dominates, labour cost is much more important than categories such as advanced logic where equipment is the overwhelming cost. For this reason you'll find China (and maybe even India if they bother to get into the market) dominate these categories due to lower costs of labour. Traditional competitors in these categories such as Onsemi and STMicroelectronics have been hurting.[3]

It's hard to predict which announced/planned investments will go ahead and be impactful, for various reasons such as utilisation rates of fabs once built. But it'll be particularly and increasingly difficult to predict the future of semiconductor fabrication due to what is happening in China. China has expanded their domestic chip making equipment industry enough to mandate Chinese fabs use at least 50% Chinese equipment.[4] Over 2024 and 2025 the investment from China into chip making equipment was estimated to be 37-42% of global spend, so we're talking about 20% (or maybe higher up to 40%) of global chip making equipment spending not being readily observable.[5]

[1] https://www.yolegroup.com/product/report/status-of-the-semic...

[2] https://www.oecd.org/content/dam/oecd/en/publications/report...

[3] https://www.trendforce.com/news/2025/02/26/news-power-chipma...

[4] https://www.reuters.com/world/china/china-mandates-50-domest...

[5] https://www.semi.org/en/SEMI-Reports-Global-Semiconductor-Eq...

My key point you are avoiding with personal attacks is:

If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)?

--

The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203.

The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448.

[1] https://www.iana.org/assignments/tls-parameters/tls-paramete...

[2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2

[3] https://www.rfc-editor.org/info/rfc7748/#section-5

It looks like recent Tenda hardware/firmware is encrypted per below examples, making it harder to audit.

binwalk US_AC10V6.0si_V16.03.62.09_multi_TDE01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x436999A39FECA649

binwalk US_BE12ProV1.0mt_V16.03.66.23_TD01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x81235B7D4130B6AB

The third attempt I tried was unencrypted, and possibly reveals the problem exists on another model this CVE doesn't list as affected:

binwalk US_W18EV2_kf_V16.01.0.20\(4766\)_HighPower\ \(1\).bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  64            0x40            uImage header, header size: 64 bytes, header CRC: 0x95335734, created: 2026-06-16 09:09:35, image size: 2159135 bytes, Data Address: 0x80100000, Entry Point: 0x805F41C0, data CRC: 0x5ABEDB00, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Tenda Linux-4.14.90"
  128           0x80            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6947248 bytes
  2159263       0x20F29F        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 8971644 bytes, 847 inodes, blocksize: 1048576 bytes, created: 2026-06-16 08:53:20

Inside is /squashfs-root/webroot_ro/default_ac.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)
  sys.guest.username=guest
  sys.guest.password=Z3Vlc3Q=  (ed: base64 decoded: guest)

And /squashfs-root/webroot_ro/default_router.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)

From what I can see quickly (I haven't looked hard), "sys.rzadmin.password" is only referenced from the login() function of /bin/httpd in the context of retrieving a value. This value is retrieved and compared before the error message "login err: password is wrong." is emitted. I can't find any other reference to code in any part of the firmware that may allow a user to change the default value of "sys.rzadmin.password".

Also for fun there is a function imsd_upload_log_v1 in /bin/imsd that collects SSIDs, MACs, IP addresses, sys.admin.username, sys.rzadmin.username, timezone, and another function imsd_remote_pwd_get in /bin/imsd that retrieves sys.admin.password. Related library /lib/lubucapi.so also looks like a fun binary to inspect more closely as it contains a command set that seemingly allows either cloud management of Tenda routers and/or remote debugging, and possibly is why imsd_remote_pwd_get exists in /bin/imsd

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1]

But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance.

The draft MLKEM IKEv2 RFC[2] has the same problem.

Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive:

Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret."

To include side channel resistance, for example:

Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values."

Some further examples of RFCs which do care about specifying side channel resistance:

RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3]

RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4]

(this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance)

[1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4

[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...

[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3

[4] https://www.rfc-editor.org/info/rfc9941/#section-4

The draft considers FIPS 203 to be normative. Therefore FIPS 203 forms part of this draft. You can't implement this draft without first implementing FIPS 203.

FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.

[1] https://news.ycombinator.com/item?id=48811887

To point out some positive examples of what RFCs should include:

RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1]

RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2]

By contrast, this proposed RFC for MLKEM provides a single encouragement:

"[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3]

It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC.

When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself:

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4]

The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation.

The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon?

The key missing section of this RFC is perhaps a restriction on its application similar to:

"This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol."

Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls.

[1] https://datatracker.ietf.org/doc/html/rfc5288#section-3

[2] https://datatracker.ietf.org/doc/html/rfc7748#section-5

[3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.

For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.

For example:

FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]

NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]

RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]

A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].

A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...