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

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

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.

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

There appears to be no obvious plausible link between the SANs other than very obvious lack of plausibility to each website. They're mostly pretend (or knock-off) business websites in random countries (everywhere from Trinidad and Tobago, Germany, mainland USA, Hawaii...) in various languages and all the ones I checked have no verifiable substance to them. For example, one domain is a supposed USA shipping/logistics company whose website states they have 1949 customers and have only delivered 7126 packages, and claims a head office as a house in Renton WA, an office at a different house in Stockbridge GA and a supposed warehouse at a third house in Portland OR. Most domains don't include any valid contact or business information, even a supposed restaurant where you'd want people to find your location easily!

There does appear to be heavy use of Google Firebase, and many of the sites share the same IP address(es) for hosting. A reverse IP lookup of domains hosted at those IP addresses reveals more random suspicious domains beyond just those just listed at https://crt.sh/?q=andrewjdillon.com

Ideally ATP's "located_in" and "located_in:wikidata" fields would be populated for these wildberries pickup locations, making it clear the pickup location is part of a parent feature (e.g. fuel station, supermarket). These fields are specific to ATP and are not OSM fields. OSM would expect features to be merged and a hypothetical field such as "pickup_brands:wikidata=Q1;Q2;Q3" be used instead on the parent feature.

ATP has a much more inclusive set of features it can extract than what Overture Maps, TomTom et al care about. As Overture Maps is more opinionated on what they aggregate they will filter out ATP extracted features such as individual power poles, park bench seats, local government managed street and park trees, stormwater drain manholes, cemetery plots, weather stations, tsunami buoys, etc. I think there might be some exceptions if it helps TomTom et al with their products such as speed camera locations, national postal provider drop-off/pick-up locations within other branded retail shops, etc.

Seemingly once you've installed Windows and given the Microsoft your BitLocker keys in escrow, you could then use Remove-BitLockerKeyProtector to delete the VMK which is protected with mode 3 "Numerical password" (recovery key).[4] It appears that the escrow process (possibly the same as used by BackupToAAD-BitLockerKeyProtector) might only send the numerical key, rather than the VMK itself.[5][6] I couldn't find from a quick Internet search someone who has reverse engineered fveskybackup.dll to confirm this is the case though. If Microsoft are sending the VMK _and_ the numerical key, then they have everything needed to decrypt a disk. If Microsoft are only sending the numerical key, and all numerical key protected VMKs are later securely erased from the disk, the numerical key they hold in escrow wouldn't be useful later on.

Someone did however ask the same question I first had. What if I had, for example, a billion BitLocker recovery keys I wanted to ensure were backed up for my protection, safety and peace of mind? This curious person did however already know the limit was 200 recovery keys per device, and found out re-encryption would fail if this limit had been reached, then realised Microsoft had fixed this bug by adding a mechanism to automatically delete stale recovery keys in escrow, then reverse engineered fveskybackup.dll and an undocumented Microsoft Graph API call used to delete (or "delete") escrowed BitLocker recovery keys in batches of 16.[7]

It also appears you might only be able to encrypt 10000 disks per day or change your mind on your disk's BitLocker recovery keys 10000 times per day.[8] That might sound like a lot for particularly an individual, but the API also perhaps applies a limit of 150 disks being encrypted every 15 minutes for an entire organisation/tenancy. It doesn't look like anyone has written up an investigation into the limits that might apply for personal Microsoft accounts, or if limits differ if the MS-Organization-Access certificate is presented, or what happens to a Windows installation if a limit is encountered (does it skip BitLocker and continue the installation with it disabled?).

[1] https://learn.microsoft.com/en-us/purview/office-365-bitlock...

[2] https://itm4n.github.io/tpm-based-bitlocker/

[3] https://learn.microsoft.com/en-us/windows/win32/secprov/getk...

[4] https://learn.microsoft.com/en-us/powershell/module/bitlocke...

[5] https://learn.microsoft.com/en-us/graph/api/bitlockerrecover...

[6] https://learn.microsoft.com/en-us/powershell/module/bitlocke...

[7] https://patchmypc.com/blog/bitlocker-recovery-key-cleanup/

[8] https://learn.microsoft.com/en-us/graph/throttling-limits#in...

- They're easy to setup and maintain immutable and reproducible builds.

- You only install the software you need, and even within each software item, you only build/install the specific features you need. For example, if you are building a server that will sit in a datacentre, you don't need to build software with Bluetooth support, and by extension, you won't need to install Bluetooth utilities and libraries.

- Both have a monolithic Git repository for packages, which is advantageous because you gain the benefit of a giant distributed Merkle tree for verifying you have the same packages everyone else has. As observed with xz-utils, you want a supply chain attacker to be forced to infect as many people as possible so more people are likely to detect it.

- Sandboxing is used to minimise the lines of code during build/install which need to have any sort of privileges. Most packages are built and configured as "nobody" in an isolated sandbox, then a privileged process outside of the sandbox peeks inside to copy out whatever the package ended up installing. Obviously the outside process also performs checks such as preventing cool-new-free-game from overwriting /usr/bin/sudo.

- The time between a patch hitting an upstream repository and that patch being part of a package installed in these distributions is fast. This is important at the moment because there are many efforts underway to replace and rewrite old insecure software with modern secure equivalents, so you want to be using software with a modern design, not just 5 year old long-term-support software. E.g. glycin is a relatively new library used by GNOME applications for loading of untrusted images. You don't want to be waiting 3 years for a new long-support-support release of your distribution for this software.

No matter which distribution you use, you'll get some common benefits such as:

- Ability to deploy user applications using something like Flatpak which ensures they are used within a sandbox.

- Ability to deploy system applications using something like systemd which ensures they are used within a sandbox.

Microsoft have long underinvested in Windows (particularly the kernel), and have made numerous poor and failed attempts to introduce secure application packaging/sandboxing over the years. Windows is now akin to the horse and buggy when compared to the flying cars of open source Linux, iOS, Android and HarmonyOS (v5+ in particular which uses the HongMeng kernel that is even EAL6+, ASIL D and SIL 3 rated).

[1] Transpower pylons: https://alltheplaces-data.openaddresses.io/map.html?show=htt...

[2] Transpower substations: https://alltheplaces-data.openaddresses.io/map.html?show=htt...

The public source of this data (ArcGIS Feature Server account of Transpower) shows data last modified by Transpower in October 2025 for pylons and February 2025 for substations. At the rate of development of NZ, you wouldn't expect major changes to any of this data unless it's a major transmission upgrade project identified years in advance in hundreds of public announcements and documents.

For distribution, the largest distributor in NZ (Vector) provides "Line" geometry at https://www.arcgis.com/apps/mapviewer/index.html?url=https:/... (note: not included in AllThePlaces due to ATP not currently collecting geometry other than points)

The ACT government provides ~10cm aerial imagery of Canberra and surrounds a few times a year and from this imagery, unless a minor power pole is obscured by trees or a building, it is generally easy to identify most poles. Evoenergy (distribution operator for the ACT) also publicly provide detailed maps of poles and lines no matter how minor they are. The reason this detail won't be mapped in OSM is lack of interest and availability of mappers to micro-map every minor power pole from aerial imagery, and OSM's very conservative approach to importing datasets, particularly from a licensing perspective (e.g. attempting to apply European database directive concerns in countries like Australia which don't have equivalent laws, and even have opposing case law precedents).

Australia is one of the most open countries when it comes to supplying electrical grid data. Even underground conduit locations are available publicly for most distributors, as well as designed summer/winter constraints for each transmission line (e.g. maximum kA per line). See [1] for some links to maps and other data that is made publicly available.

[1] https://query.wikidata.org/#SELECT%20%3Foperator%20%3Foperat...

Unfortunately he doesn't show in the top 100. Also unfortunately, there is no blogger described in the top 100 as having a geospatial interest/focus.

Vantor Legion-2 image of the BYD plant in Zhengzhou as captured on 18 January 2025: https://livingatlas.arcgis.com/wayback/#mapCenter=113.9361%2...

Vantor WorldView-3 image of the Tesla plant in Austin as captured on 31 January 2024: https://livingatlas.arcgis.com/wayback/#mapCenter=-97.6189%2...

It didn't take long for people to link a growing mound of spoil on a nearby golf course (East Potomac Golf Links) to excavations occurring at the White House.[1] A few simple volume calculations, and/or truck movement counts, is all one would seemingly need to estimate the size of the new bunker.

USD$300m also doesn't buy much of anything underground, especially at top secret military bunker pricing. Look at the cost of typical rail tunneling projects (much simpler and more efficient construction) for rough comparison.

[1] https://golf.com/news/white-house-carting-dirt-golf-course-p...

[1] https://www.youtube.com/watch?v=_otJbx-PVOw

A more useful addition would be a contributions calendar similar to GitHub's [2] but focused on which time zones the user is active within, and importantly, the latency of the user's replies. It's trivial to fake geographic location observed through source IP addresses (or even RTT multilateration) but much harder to fake time zones a user is active within, particularly if monitoring latency of replies.

edit: To further clarify, I don't think a contributions calendar would be beneficial to HN either. I've never cared to think about the country a commenter resides in, and don't care about username/real name either unless the commenter is appealing to their own authority (e.g. "I am the author of this software"). Even then, the usefulness of an appeal to own authority is often limited to the ability to reverse lookup the user's personal website (which itself is proven to be notable from other sources) for a link back to their HN profile.

[1] https://impliedchaos.github.io/ip-alloc/

[2] https://docs.github.com/en/account-and-profile/concepts/cont...

The question is generally, could a standard in 2025 build upon decades of research and implementation failures to specify side channel resistant algorithms to address conditional jumps, processor optimisations for math functions, etc which might leak secret state via timing, power or EM signals. See for example section VI of [1] which proposed a new side channel countermeasure that ended up being implemented in MbedTLS to mitigate the conditional swap instruction leak. Could such countermeasures be added to the standard in the first instance, rather than left to implementers to figure out based on their review of IACR papers?

One could argue that standards are simply following interests of standards proposers and organisations who might not care about cryptography implementations on smart cards, TPMs, etc, or side channel attacks between different containers on the same host. Instead, perhaps standards proposers and organisations only care about side channel resistance across remote networks with high noise floors for timing signals, where attacks such as [2] (300ns timing signal) are not considered feasible. If this is the case, I would argue that the standards should still state their security model more clearly, for example:

* Is the standard assuming the implementation has a noise floor of 300ns for timing signals, 1ms, etc? Are there any particular cryptographic primitives that implementers must use to avoid particular types of side channel attack (particularly timing)?

* Implementation fingerprinting resistance/avoidance: how many choices can an implementation make that may allow a cryptosystem party to be deanonymised by the specific version of a crypto library in use?[3] Does the standard provide any guarantee for fingerprinting resistance/avoidance?

[1] Template Attacks against ECC: practical implementation against Curve25519, https://cea.hal.science/cea-03157323/document

[2] CVE-2024-13176 openssl Timing side-channel in ECDSA signature computation, https://openssl-library.org/news/vulnerabilities/index.html#...

[3] Table 2, pyecsca: Reverse engineering black-box ellipticcurve cryptography via side-channel analysis, https://tches.iacr.org/index.php/TCHES/article/view/11796/11...

djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor implementation mistake specific to timing of specific instructions on specific CPU architectures, or specific compiler optimisations, etc doesn't break the implementation. See for example the many problems of NIST P-224/P-256/P-384 ECC curves which djb has been instrumental in fixing through widespread deployment of X25519.[3][4][5]

[1] https://cryspen.com/post/ml-kem-implementation/

[2] https://kyberslash.cr.yp.to/faq.html / https://kyberslash.cr.yp.to/libraries.html

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

[4] https://safecurves.cr.yp.to/ladder.html

[5] https://cr.yp.to/newelliptic/nistecc-20160106.pdf

What is more interesting for meteorological forecasting is the time-sensitive details such as:

1. We know severe storms will impact city X at approximately Ypm tomorrow. Will it include large hailstones? Severe and destructive downdraft / tornado? What path will the most damage occur and how much notice can we provide those in the path, even if it's just 30min before the storm arrives?

2. Large wildfire breaks out near city X and is starting to form its own weather patterns.[3] What's the possible scenarios for fire tornadoes, lightning, etc to be formed and when/where? Will the wind direction change more likely happen at Ypm or Y+2pm?

I'm skeptical that AI models would excel in these areas because of the time sensitivity of input data as well as the general lack of accurate input data (impacting human analysis too).

Maybe AI models would be better than humans at making longer term climate predictions such as "If [particular type of ENSO/IOD/etc event] is occurring, the number of cloudy days in [city] is expected to be [quantity]/month in [month] versus [quantity2]/month if the event was not occurring." It's not that humans would be unable to arrive at these type of results -- just that it would be tedious and resource intensive to do so.

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

[2] https://imagehunter.apollomapping.com/search/90e4893eeeaa48a...

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