dhx

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]

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

[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

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

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

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

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

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...

To extend on this good point--

DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.

For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?

See [1] and [2] for answers. Summary: Technology is not ready.

[1] https://dl.acm.org/doi/10.1145/3569420

[2] https://dl.acm.org/doi/10.1145/3779208.3785290

At least in my experience for large retail chains or restaurant chains, hours on their websites are very accurate. I think where Google might benefit from calling to verify hours is, for example, where they've scraped https://schema.org/openingHours from the web page for an independent store, but the website has used an invalid/incorrect format, and some manual human check or clean-up is necessary, but this work would be too time consuming for each of 100,000's of independent stores which exist.

There are cases where a brand might have broken opening hours information such as "Mo- Tu - We 09 00 -4 p m". For alltheplaces.xyz scrapers, a human is often able to make sense of the situation and fix the problem through a few lines of extra code. Contacting the business to get the hours confirmed would only be necessary in very rare cases.

Where it would perhaps make the _most_ sense to contact a business to confirm opening hours is:

1. Ahead of public holidays to confirm planned temporary changes to opening hours. Many brands don't bother to update hours on their websites for such temporary changes, or at least don't list those hours until the week prior, which is usually too late for OSM, ATP, offline maps, etc which would ideally want to know these changes to hours up to a year in advance.

2. To confirm actual dates of permanent store/restaurant closures. Many brands in liquidation tend to fire the website developers (or can't pay them to work) and leave an outdated website online until the final shop or restaurant is closed. Commonly it's only some "CLOSING DOWN SALE LAST DAYS EXTENDED TO FRIDAY" post on social media that informs visitors accurately.

See alltheplaces.xyz for continuously updated straight-from-the-primary-source opening hours of chains of shops and restaurants, public facilities such as libraries, etc. This is probably as accurate as it gets AND you have the confidence of knowing exactly where the data came from (down to the URL) and when it was last checked.

Some OSM contributors go brand-by-brand/operator-by-operator in making sure OSM features have the most up-to-date opening hours added to them from matched ATP features. As such, OSM may be fairly accurate for chains too.

For a standalone shop or restaurant the opening hours situation is usually still better with Google Maps rather than OSM. There aren't enough OSM contributors who care enough to check and maintain opening hours for every shop, restaurant, fuel station, etc.

1. This is largely country-dependent with some governments being quite adamant that address data should be in the public domain, and some governments doing the opposite and selling address databases to private companies for some quick cash, where private companies then sell address lookups for some absurd per-lookup price for the next few decades. Most of the world though is probably just not rich enough to compile, publish and accurately maintain a national address database.

OpenAddresses is perhaps the gold standard for open source address data compilation from government datasets. Note for the future that alltheplaces.xyz (project I contribute to) is looking like it may eventually perform the automatic address data download/extraction/compilation that OpenAddresses currently performs. This has the benefit that in backwards countries, alltheplaces.xyz also obtains some addresses through other means--such as advertised location of international restaurant chains. And quite often, being within +/- 100 address numbers on a road is good enough for navigation. Google Maps obviously crawls addresses from all over the Internet AND has quite a high tolerance for errors, hence will perhaps always seem more complete than OSM.

2. Some further ideas for open source mapping applications trying to determine real time traffic situations:

2a. Use GTFS/GTFS-RT feeds for bus networks to detect real time delays but also to compare planned bus route schedules for different times of the day (different traffic conditions) where buses share the road with the public. There's already a few maps out there that overlay nearby GTFS-RT feeds for the city of interest and usefully provide a visual indication of how well public transport vehicles are currently moving.

2b. alltheplaces.xyz extracts public traffic camera feeds which could be presented to users when they plan/commence a journey as an indication of what lies ahead on the route.

I change that slightly to "Good luck getting an explosive payload."

The difficulty for an attacker is the explosive payload, not the delivery mechanism. If it were easy for an attacker to get an explosive payload there would be car bombs going off every day as an easier delivery mechanism than use of quadcopters.

Thankfully it seems to be relatively easy to prevent people from making explosives, at least outside of warzones in countries with strict border control, because random people don't have a valid reason to buy industrial chemicals or equipment, and especially not chemicals identified as precursors for making explosive compounds. And for plants where such industrial chemicals are legitimately necessary to use, inputs and outputs can be measured, and detection taggants[1] used, and many other security measures, to prevent accidental or deliberate loss of control over such chemicals.

[1] https://en.wikipedia.org/wiki/Taggant#Explosive_taggants

"Fix this code" should ideally solve entire vulnerability classes, not just spot fix buffer overflows one by one. Thus it may be possible to design an LLM which can solve entire vulnerability classes and remain useful to users, but refuses to reason about specific buffer overflow vulnerabilities or specific race conditions, etc.

For example, "fix this code" on an ageing monolithic C codebase that accepts media files as input and outputs them visually to a display server could:

1. Recreate the software using a modular and loosely coupled architecture rather than monolithic and tightly coupled software architecture. For example, command line argument parser is a separate process, file format parser is a separate process and display server output is a separate process. If new features are added in the future (such as filters for manipulating output) then the architecture supports such additions with ease.

2. Use operating system sandboxing features to restrict what each modular component of the software architecture is permitted to do. Now that the parsers are separate processes, it's easy to pass an open file handle to the file format parser and only permit the process to read the file handle (not write to the file, not open any other file, not read the system clock, not open a new network socket, etc). The worst case impact of a parser bug is now significantly reduced.

3. Convert at least critical components to "safe" programming languages (Rust, Ada, SPARK, etc) which can be used to remove entire classes of bugs--read/write out of bounds, division by zero, numeric overflows, etc. For cryptography code--use a formal mathematical proof language. With a modular and loosely coupled architecture, different programming languages can be used depending on the use case--for example, assembly for video decoding where performance matters most and sandboxing can provide the security guarantee, Rust for implementing multi-threaded servers where race conditions must be avoided and Python for low-criticality user-adjustable code/plugins where ease of use and maintainability is most important.

4. Ensure software components are reproducible during their build.

5. ...etc

However, a prompt of "Are there any buffer overflow bugs in this codebase?" or "Fix the integer overflow vulnerability in add_numbers(x, y)" would be rejected. In the later case, telling the LLM to fix some specific bug in each of function1 through function9999 would force an LLM to reveal whether it thinks a bug exists or not. Responses of "Silly human, that bug doesn't exist in function596" or "Good find human, I've fixed that bug in function596 for you" allows a human to quickly narrow down where the LLM thinks a bug worthy of manual human detection can be found.

I like that it's non-serious and contains jokes throughout the user interfaces. Reminds me a little of Airline Tycoon's non-serious/joking nature, and Theme Hospital if going further back in time. It makes the game fun rather than a boring simulator some city planner would use for work.

Contributor for an open source scraper -- https://alltheplaces.xyz/ -- which currently has about 4700 scrapers extracting 40-someting million points of interest.

The project aims to scrape location data and other general information about shops (main use case), postal addresses, restaurants, schools, weather stations, marine buoys, traffic cameras, street trees, whatever someone may decide is worthwhile to add to OpenStreetMap, or use as location data in other projects.

There's a decent community of contributors keeping the scrapers maintained and further expanding the number of points of interest which are extracted.

The opportunity I'd like to work more on (time permitting) is the data scraped by this project I feel is heavily underutilised in other open source/community projects. For example, there's a great opportunity to generate a location map once a week of current locations of international restaurant chains, and upload to Wikimedia Commons where every language Wikipedia would gain a high quality infographic of current locations of a chain's restaurants, etc. As an additional example, time-series data from ATP could be used to update a graph hosted on Wikimedia Commons each week where the graph plots the rise and fall of retail or restaurant chains.

There's an example at [1] of a prompt for a HTML mockup operating system where 3 applications are requested to be "white hat tools" that show diagnostic system information. Claude Fable 5 is shown and said in the video to switch back to Opus 4.8 as a "safety" feature.

What an utterly useless model if it refuses to work on something as benign as basic system diagnostic utilities (nmap or whatever).

[1] https://youtu.be/9GLYsrMpprs?t=305

Also have a look at Inform 7[1] (domain specific language for interactive fiction), specifically the "Stone" example section[2] which explains edible food and the effects different foods may have on the adventurer.

It's similar concept to OPM with some modelling basics already built on top for player movement throughout a world, player interaction with objects (looking at, lifting, moving), and many other primitives needed to write interactive fiction. And relevant to this thread, Inform 7 of course has modelling basics for a player eating food, drinking potions, etc.

[1] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la...

[2] https://ganelson.github.io/inform-website/book/RB_9_1.html

Agreed. My comment was to highlight that if a recipe for a soup just says "1kg squash", that could mean anything from "Cucurbita maxima subsp. maxima var. Jarrahdale"[1] through to "Cucurbita pepo subsp. pepo var. recticollis"[2], with vastly different outcomes for the soup.

The model under the hood should probably have ingredients as parts of a taxon, then have common names mapped (many:many) to these parts of taxons. Then it's necessary to have abstract classifications such as "pumpkin seed" which could be defined as the seed of multiple different taxons, which for some recipes, may not matter which one of 5 Cucurbita subspecies is used. That way if someone types "squash" or "pumpkin seed" they get asked to clarify what they mean, which will change quite a bit depending on locality of the person being asked.

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

[2] https://en.wikipedia.org/wiki/Straightneck_squash

This will perhaps be overkill for what you're trying to achieve, but there is Object Process Methodology (OPM)[1] which may be inspiration for modelling recipes. It looks similar to the methodology you're using, and as an example, expects the following type of modelling:

"peeling carrot" (process) consumes "washed carrot" (object)

"peeling carrot" (process) yields "peeled carrot" (object)

"peeling carrot" (process) yields "carrot peel" (object)

"finely dicing carrot" (process) consumes "peeled carrot" (object)

"finely dicing carrot" (process) yields "finely diced carrot" (object)

"prepare mirepoix" (process) consumes "finely diced carrot" (object)

"prepare mirepoix" (process) consumes "finely diced celery" (object)

"prepare mirepoix" (process) consumes "finely diced onion" (object)

"prepare mirepoix" (process) consumes "butter" (object)

"prepare mirepoix" (process) yields "mirepoix" (object)

The advantage of OPM is alignment of graphical and textual representations.

The downside of such approach is you soon discover how many millions of objects may exist in recipes--unwashed carrot, washed carrot, orange carrot, purple carrot, yellow carrot, white carrot, peeled carrot, coarsely diced carrot, finely diced carrot, julienned carrot... and purple julienned carrot vs. yellow julienned carrot. And that's just basic preparation complexity well before any contemplation of cooking or plating up elements. To go further you then discover a lack of useful labels such as "mirepoix" or "soffrito", if for example, you wanted to substitute sweet potato in place of carrot in the recipe.

Then there is SysML 2[2] which is kind of like OPM if you ever wanted to write a recipe in 35,000 lines of code, including possibly all the complexity of mathematical modelling of the Maillard reaction for purple carrots vs. yellow carrots using either extra virgin olive oil or butter. Probably best suited for the largest food processing companies such as Nestle, Unilever, Modelez, etc and even then, inherent complexity of their food products rarely would reach the level of a fine dining dish prepared by a chef.

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

[2] https://www.omg.org/spec/SysML/2.0/Language/PDF

See [1] for a demo, seemingly of an older iteration of what this paper describes. I was curious what ingredients the demo had selected (1032 available vs 1790 this paper selects) so I tried some obscure ingredients from "Organum: Nature, Texture, Intensity, Purity" by Peter Gilmore[2] (known for Quay restaurant in Sydney, Australia).

It's got some adventurous ingredients such as juniper berry, macadamia nut, nigella seed, orange blossom water and lemon verbena. It even separates sesame oil and toasted sesame oil. Even though the ingredients list only has "rice", "black rice", "brown rice" and "glutinous rice", when you select "rice" as an ingredient, the recipes it generates are smart enough to advise of chilling cooked jasmine rice before using in a fried rice, and smart enough to soak and rinse Basmati rice before using in a pilaf. If selecting "lamb" as an ingredient, the recipes it generates will choose the cut as shoulder or shank if you select vegetables normally associated with braising.

It doesn't know of grapeseed oil, orzo, mangosteen, lemon myrtle, and of course anything that only Peter Gilmore might use in a recipe and most chefs would have never heard of (karkalla as an example). I don't see this being too much of a limitation because such ingredients are quite localised or speciality. It knows of "pumpkin seeds" but not "pumpkin"--that is "squash", so there are some localisation improvements which could be made to improve British and American English use. I tried pairing "lamb" and "avocado" together in the hope it'd generate a recipe with a salad, but this failed. I then realised the ingredients list doesn't include lettuce or rocket, but has "salad greens" instead (American English) and no matter what I tried (other salad ingredients, chicken or no protein), it would not give me a salad. It kept generating wannabe-fancy dishes of a chunk of protein surrounded by tomato gel (agar agar) and a smear of avocado, or similar.

[1] https://epicure.kaikaku.ai/

[2] https://en.wikipedia.org/wiki/Peter_Gilmore_(chef)

I dug into how software such as LS-DYNA could have been modified. Take for example the EOS_JWL equation at [1] (vendor website, public manual) which is implemented by LS-DYNA. This equation seemingly could be used, alongside other equations implemented within LS-DYNA, to answer questions such as how long it'd take for a detonator in a missile warhead to detonate a primary explosive substance to cause a particular pressure wave at 20m distance. Working backwards from this result may provide a required fuze timing. Equations and parameters used with LS-DYNA are derived from scientific research, such as [2], which is US government research from the 1980's providing experimental results for high explosive substances. One such example from [2] is experimentation to determine the friction an explosive substance has against different materials which may enclose it. Given the software has equations purposely designed for explosives modelling, it'd be fairly easy to just target those equations in ways which will just slightly frustrate a scientist/engineer into thinking they've got a problem with the manufacturing quality of steel, rather than suspect the software is deliberately adding +/-20% noise to a friction coefficient.

The modern equivalent may be something like {insert adversarial country name here} downloading a pirated version of Ansys Autodyn 2026 R1 shortly after official release from a Chinese cracking group on a Chinese bulletin board forum, where just a handful of seeders sit behind Russian ISPs. And then {insert adversarial country name here} later notice during experimentation that the software calculations never quite match experimental results, and maybe then suspecting the pirated copy was deliberately tampered with and distributed. However, this situation may be fairly easily solved by {insert adversarial country name here} by just grabbing a copy of the software they want off a hacked network of a random university or engineering consulting firm in the aerospace and defence sector. Plus it may be naive to assume {insert adversarial country name here} in 2026 couldn't develop their own software from scratch (and/or perform calculations manually), or just rely on experiments, to achieve whatever outcome some other nation state group of hackers is trying to avoid. {insert adversarial country name here} would have to have experimentation equipment and skills regardless to verify manufacturing quality. Simulation software mostly reduces costs and timeframes by reducing the number of mockups and physical experiments needed. For example, it's cheap to run 1000 simulations of an artillery shell hitting vehicle armor plates as shown in [3], and more expensive and time consuming to do the same repetitive thing in the real world.

[1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...

[2] https://www.osti.gov/servlets/purl/6530310

[3] https://www.youtube.com/watch?v=_dv2PecKUBM

For more, there is also Umbra SAR open data at [1]. Most of this imagery is also copied to Wikimedia Commons where if someone has got around to doing so, much better metadata may have been added, and smaller images of key features within a larger scene extracted.

[1] https://registry.opendata.aws/umbra-open-data/

https://web.archive.org/web/20260303144625/https://changelog...

Nothing ready-to-go that I'm aware of. ATP will just observe in the next weekly crawl that a shop is no longer returned by the storefinder API call or sitemap crawl, and that shop will simply not be present in the next weekly dataset generated.

To set up archives of shop-specific pages (e.g. record of opening hours, address, etc at a point in time), one could monitor the latest builds of https://alltheplaces.xyz/builds.html and when a new build completes, take the new build and 2nd oldest build to compare differences. Then for any feature whose attributes have changed (address, phone number, opening hours, etc) archive the `website` and/or `source_uri` attribute pages again to ensure the latest snapshot is captured. Any new feature would get the same treatment so the page for the newly observed shop/feature is archived for the first time.

I'm also aware ArchiveTeam projects tend to commence once the impending collapse of a retail chain is known and someone realises there is a website not archived which would be useful to preserve. Monitoring of ATP feature counts for brands across time may give some hint of how a brand is performing and whether it is growing or shrinking without having to find press releases and financial statements of the brand. Even if a brand suddenly announces bankruptcy (it happens all the time), generally the website will remain online for at least a few months whilst a new buyer is sought or whilst each retail location has a fire sale to get rid of remaining merchandise. It's also worthwhile to be aware of acquisitions of retail chains as this often results in the new parent company changing websites soon after acquisition closes, possibly removing useful content that once existed. Websites also change "just because" and this could be observed after-the-fact by seeing when ATP spiders break and get replaced/fixed.

The situation with retail chains is improving thanks to projects such as https://alltheplaces.xyz/ (disclaimer: I'm a contributor) and efforts of some OSM contributors to focus their contributions towards comparing OSM and ATP features to add missing shops, remove closed shops, update opening hours, etc. For one such example, see https://matkoniecz.codeberg.page/improving_openstreetmap_usi... for a tool (created by https://news.ycombinator.com/user?id=matkoniecz) which is used to match and compare OSM and ATP features.

This work has been slow to take off though as the OSM community has traditionally been stuck on time wasting debates about whether opening hours displayed on the wall of a shop are copyrighted (just the raw data, not a photo of their presentation), and debating the merits and pitfalls of armchair mapping vs. on-the-ground mapping. At least these historical roadblocks seem to now be mostly resolved.

For OsmAnd, you might be able to use the OBF import feature (see https://www.osmand.net/docs/user/personal/import-export/) to add the raw ATP dataset, or potentially other open data such as Overture Maps if that is more to your liking. Data is mostly sourced direct from brand websites, APIs, etc (as if you were using a storefinder map on their website).

Last account activity was 2024-07-08 to push changes to the personal website andrewjdillon.com.[1][2]

Last account activity to contribute to any to any repository was 2021-11-28 to comment on the hopding/pdf-lib repository.[2]

It's clearly now an unmaintained repository with 4+ years of inactivity, and likely now also a mostly unused GitHub account in general.

[1] https://github.com/Hopding/andrewjdillon.com/commit/0657c690...

[2] https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...