[HN Gopher] Disaster awaits if we don't secure IoT now
___________________________________________________________________
Disaster awaits if we don't secure IoT now
Author : mdp2021
Score : 63 points
Date : 2025-06-02 17:44 UTC (5 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| HideousKojima wrote:
| Not going to happen any time soon because there is no concern
| about this from the consumer side, no financial incentive from
| the manufacturing side, and no regulatory pressure from the
| government (and I have low hopes that any regulatory solutions
| would actually fix the problem).
| Havoc wrote:
| >no regulatory pressure from the government
|
| No much, but there is some. Getting rid of default admin/1234
| passwords was 100% a regulatory push
|
| Small but important win
| thawawaycold wrote:
| What about EU's CRA?
| HideousKojima wrote:
| Doesn't really do anything to ensure the end-user truly has
| ownership over the device and the ability to control what
| software runs on it. 10 years of security updates is nice
| (assuming the company making the device doesn't go out of
| business in that time) but doesn't stop those devices
| becoming vulnerable after that (and a truly useful device
| will likely have more than 10 years of useful life). I don't
| know the specifics of the CRA, but most proposed regulatory
| solutions I've seen intentionally take control away from the
| end-user.
| spencerflem wrote:
| I used to be more concerned with this but the longer ive thought
| about it the more convinced I get that none of this matters.
|
| Most tech gadgets are a distraction and are about as useful off
| as on.
|
| Industrial stuff sure, but if someone's internet fridge or smart
| TV goes haywire, so what.
| arcticbull wrote:
| I think the risk isn't that your fridge is unable to suddenly
| to phone home about your butter consumption but that it gets
| turned into a giant botnet or joins some crypto mining pool.
| Sensors don't have much horsepower but some of those smart
| appliances have decent application processors.
| eadmund wrote:
| The issue is that one's fridge or light bulb becomes a lodgment
| from which an adversary can launch LAN attacks (e.g. via
| Ethernet) on one's more-sensitive devices, such as one's
| personal computer (which contains more-or-less one's entire
| life: banking details, correspondence and so forth).
|
| I don't really care if the IoT device is compromised; I _do_
| care if it is used to compromise my trusted devices.
| raylad wrote:
| This article is specifically discussing industrial Internet of
| things. And I think it's a good and instructive article
| actually.
|
| Please read before commenting.
| spencerflem wrote:
| I did read the article. It was not very good about separating
| the two cases (for example by saying the total # of IoT
| devices to sound dramatic while also only listing examples of
| industrial ones to sound more worrying).
|
| I love and care pretty deeply about security, I run Graphene
| OS & am trying to switch to Genode / Sculpt sometime this
| year. _I care._ But I 'm coming to realize that for the
| 'personal computing' use-case it doesn't matter much for
| people who aren't nerds.
|
| In any case, the sort of "hardware root of trust" reccomended
| is an insidious way of going about it.
| graemep wrote:
| > Industrial stuff sure, but if someone's internet fridge or
| smart TV goes haywire, so what
|
| If large numbers of fridges or cars fail to work properly or go
| haywire at the same time, it matters.
|
| The article also mentions enabling DDOS.
|
| The same with things like routers, any type of infrastructure.
|
| We have increasing amounts of electricity generation and
| storage moving to consumer devices. Its a good idea and could
| make the system more resilient if done right, but if it relies
| on insecure devices it would be a huge systemic vulnerability.
| Reubachi wrote:
| Encryption and non-repudiation to-from any deployed field
| device back home is analogous to putting a lock and your ID on
| your front door. It would deter the average "front door
| unlocked" criminal of opportunity.
|
| When does a device not authenticating itself and all it's comms
| matter?
|
| Mossad was able to (at great cost, and with an inept enemy)
| hijack a telecom supply chain to embedd explosives in internet
| radios.
|
| Were there _any_ operational oversight to simply have these
| devices call home with signed key challenge, the literal virus
| OS /code execution/explosive would have at least been caught.
|
| I only bring up THAT example to show that supply chains are as
| exposed as a bad actor wants them to be.
| Ekaros wrote:
| Fridge could have interesting attack vectors. Say allow
| temperature peak during evening and night and then lower it
| before morning. Keep repeating this. You get lot of spoiled
| food and worst case even dead people.
| netsharc wrote:
| How about home thermostats? Turn off the heating during a
| snowmageddon, freeze some people to death. Opposite thing
| during a heatwave.
|
| Or a distributed attack, turn on all ACs of a city, and
| overload the power grid...
| hooverd wrote:
| Secure from whom? I can envision a future where the real IoT
| security risk is insider threat. Buried in your smart lightbulb
| EULA there could be consent to be used as a residential proxy.
| mystraline wrote:
| > Secure from whom?
|
| From the person who thought the sale was ownership. More often,
| "sale" is 'trade green paper for a license of this physical
| good, that they retain to do whatever with later at their
| leisure'.
|
| Look at the scam Nintendo is doing with the Switch 2:
|
| Games no longer have any data other than a serial number to
| download a game.
|
| Hi tendon claims they can remotely destroy consoles they deem
| 'modified'. Not 'removed from online play', actually full
| digital destruction of device.
|
| I support ownership, not this 'we may revoke at any time'
| licensure.
| rbanffy wrote:
| > Hi tendon claims they can remotely destroy consoles they
| deem 'modified'. Not 'removed from online play', actually
| full digital destruction of device.
|
| This is illegal in many jurisdictions.
| mystraline wrote:
| I would believe you, but we've seen PlayStation 3 OtherOS
| play out. In that case, Sony sold it with 'install Linux'
| as a feature. Later on, they poison-pilled an update and
| killed that.
|
| There was a lawsuit, in which class action plaintiffs got
| between 9$, or $55 if you said you used OtherOS.
|
| But if this was any of us, hacking Sony, we would be
| rotting in prison. But Sony can hack millions of peoples
| supposed property, and "here's your latte money, too bad,
| so sad!"
|
| This should have been a criminal trial, in which the
| executives would go to prison, firmware should be rolled
| out to reenable it, and make people actually whole.
|
| So yeah, I fully expect Nintendo to remotely destroy
| hardware, and get away with it. The concept of "you don't
| own, but you license" is the toxic shit that allows this,
| alongside DMCA 1201.
| rbanffy wrote:
| It doesn't need to be mentioned in the EULA.
| NoboruWataya wrote:
| For industrial devices, absolutely. For consumer devices, I think
| it can be a double edged sword. The more "secure" IoT devices
| are, the more locked down and difficult to jailbreak they are,
| which is bad for consumers and just leads to e-waste when a
| product gets abandoned by its manufacturer.
| gjsman-1000 wrote:
| Sometimes I wonder what would happen, as a beginning step, if
| we mandated the ability to purchase unlocked bare hardware. The
| law doesn't need to require (in the first phase) that iOS or
| something be compatible with it, but you could at least walk
| into an Apple Store or Nintendo Store and buy the bare
| hardware, for your own purposes. Then we could claim it as
| being only about choice, and allowing software competition,
| without any plausible security risk.
| rbanffy wrote:
| In this case, you would be liable by any damage your
| compromised devices might cause. Let's say you find updates in
| your house battery/inverter are annoying and, then, someone
| takes over it and cause a power surge in the neighborhood.
| That'd not be on the hardware manufacturer, who did their best
| to avoid such incidents, but on you, who clearly didn't.
|
| If you knowingly use obsolete and insecure devices, you might
| end up being liable for their actions.
| OsrsNeedsf2P wrote:
| Are there such examples of this happening? Or are there only
| examples of corporations doing this and suffering no
| repercussions?
| dandanua wrote:
| There are two types of security: one where a user is secure
| against hackers and the other one where manufacturer has
| "secured" its devices against users. The second type is
| strictly stronger, and it seems companies will not be
| interested in giving any real freedom to users, apart from
| running a predefined and restricted set of functions. In other
| words, you won't own a device, only the services it produces.
| calmbonsai wrote:
| This is pure academic theory-crafting. Who is going to pay for
| this and how will it be financed?
|
| Even in the industrial space, it's simply not going to happen
| given the costs of securing wrt the business value and relative
| risk aside from projects that have some sort of
| community/municipal/national "critical infrastructure" domain
| (think power generation) where a legitimate business case (think
| in terms of MARR
| https://en.wikipedia.org/wiki/Minimum_acceptable_rate_of_ret... )
| can be made for safety and/or regulatory compliance future-
| proofing and a source of cheap 3rd party (usually government)
| capital is made available.
|
| There are also huge legacy IoT investments in capital inefficient
| low-margin businesses (think mining and ship-building) where this
| sort of "maintenance" and retroactively applying "defense in
| depth" makes little sense compared to wholesale generational
| migration.
|
| Nobody is going to do it until there's some sort of abrupt forced
| exigent existential externality applied to the entire industry
| (e.g. ozone layer depletion and refrigerants) and then they'll be
| a single mass-migration.
| ceejayoz wrote:
| > Who is going to pay for this and how will it be financed?
|
| As with climate change, "we all will" and "with great
| difficulty, far too late".
| hx8 wrote:
| There's two very established routes for setting cyber security
| standards.
|
| * Government regulation.
|
| * Insurance requirements. Mostly applies to businesses.
| mystraline wrote:
| > Guy Fedorkow is a Connection Science Fellow at MIT, a
| Distinguished Engineer at Juniper Networks, and a contributor to
| the Trusted Computing Group.
|
| Talk about the worst corporate doublespeak - 'trusted computing'.
|
| It also goes by DRM, or rental hardware, or you never actually
| own it cause someone else retains permanent digital control.
|
| There is NO trust here, only control and power in never actually
| selling anything.
|
| And since we're talking of IoT, this goes hand in hand with
| proprietary corporate clouds, anti-FLOSS like Home Assistant,
| rental in the form of sales, forced firmware upgrades that remove
| previous features to gatekeep and resell what you promised.
|
| I don't even need to read further. Anybody, and I do mean
| anybody, who uses the moniker 'Trusted Computing', should be
| ignored, blackballed, and relegated to the bin of computing.
| kwk1 wrote:
| > anti-FLOSS like Home Assistant
|
| Could you expand on this?
| mystraline wrote:
| Not hard to. Go look at the wide variety of hardware that
| does NOT work with Home Assistant, or works tenuously through
| some heavily rate limited public web api.
|
| There is a reason why for my IoT setup so far, its been
| primarily OpenGarage, IKEA IoT (ZigBee), and existing compute
| services I locally host.
|
| Remote servers come and go. Companies come and go. If I am at
| the forced behest of some company to 'bless' my hardware, its
| not mine. And I think its fraud to even claim it a sale. Its
| a 'rental as long as the company wishes'.
| Stefan-H wrote:
| Are you familiar with the academic field of security and the
| notion of trust in trusted computing? The IoT devices that is
| being discussed in the article are for industrial control
| systems, not necessarily your home lightbulb. The threat model
| is different. Do you want every municipal power company to be
| trusted to properly vet the code they are putting on these
| devices, or do you want to trust the device manufacturer to be
| the one who can put code on the devices?
| mystraline wrote:
| Owner is still owner, be it someone who lives in a single
| family residence, or that of a municipality.
|
| In my area, tornado sirens are unencrypted aand a simple
| recordable and replayable frequency. The cost to add an
| encrypted radio connection is $100k for the base station, and
| $25k per siren. There are 80+ sirens.
|
| If this were open source, then a simple computer could he
| retrofitted to do this. But because they are highly
| proprietary, the county would be on the hook for $2.1M just
| to defend against an asshole with a HackRF.
|
| FLOSS and open principles should matter to governments as
| well as individuals. Trading temporary easiness for no long
| term usability is utterly ridiculous. And you end up with a
| doorstop in the end either way.
| GuB-42 wrote:
| Please read the article before commenting, because I find the
| proposed solution a bit worrisome.
|
| Of course we should secure IoT, but the article is about one very
| particular kind of security: roots of trust. The idea is that
| devices shouldn't run unsigned software, so forget about custom
| firmwares, and generally owning the hardware.
|
| There is a workaround, sometimes called "user override", where
| the owners can set their own root-of-trust so that they can
| install custom software. It may involves some physical action,
| like pushing a switch, so that it cannot be done remotely by a
| hacker. But the article doesn't mention that, in fact, it
| especially mentions that the manufacturer (not the user) is to be
| trusted and an appropriate response is to reset the device,
| making it completely unusable for the user. Note that such
| behavior is considered unacceptable by GPLv3.
|
| There are some cases where it is appropriate, GPLv3 makes a
| distinction between hardware sold to businesses and "User
| Products", and I think that's fair. You probably don't want
| people to tinker with things like credit card terminals. But the
| article makes no such distinction, even implying that consumer
| goods are to be included.
| AnthonyMouse wrote:
| Not only that, "roots of trust" and locking users out of their
| devices is the thing that _causes_ the IoS omnishambles. The
| foundational problem is that some company makes millions of
| devices and then goes out of business or otherwise stops
| supporting them, but because the users are locked out of the
| device, nobody else can do it either. Meanwhile people continue
| to use them because the device is still functional modulo the
| unpatched security vulnerabilities.
|
| If anyone could straightforwardly install the latest DD-WRT or
| similar then it's solved, because then you don't have to
| replace the hardware to replace the software, and the
| manufacturer could even push a community firmware to the thing
| as their last act before discontinuing support.
| myself248 wrote:
| > and the manufacturer could even push a community firmware
| to the thing as their last act before discontinuing support.
|
| This should be held in escrow before the device can be sold.
| And the entity doing the escrow service should periodically
| build the software and install it onto newly-purchased test
| devices to make sure it's still valid.
|
| If the company drops support, either by going out of business
| or by simply allowing issues to go unaddressed for too long,
| then the escrowed BSP/firmware is released and the people now
| own their own hardware.
| AnthonyMouse wrote:
| That seems like a lot of complicated when the better
| solution is to have the people own their hardware from day
| one.
|
| You also need the community around the device to already
| exist on the day support is discontinued instead of needing
| to build one _then_ around a device which is by that point
| years old and unavailable for new purchase.
| specialist wrote:
| I really thought escrow for software would've been SOP by
| now.
|
| We made EMRs in the 2000s. Our customers required
| everything to be placed in escrow. It seemed abundantly
| prudent to me.
|
| Maybe even prescient; our startup was bought, then murdered
| in its crib, leaving our customers SOoL. But at least they
| got the source.
| oezi wrote:
| The issue is as much companies going out of business as
| consumers buying devices from shit companies.
|
| We need schemes which enforce security and which make long
| term economic sense. I would require software escrow for all
| companies to ensure a bankruptcy doesn't mean all software is
| lost.
| freedomben wrote:
| I completely agree, and it disappoints me greatly to see
| articles like this because it advocates doing what the
| manufacturers already want to do so they can increase their
| control. It's the exact type of article that people who want to
| lock things down will use to discredit or disagree with someone
| advocating a more ethical approach.
| wmf wrote:
| I would add that root of trust secures against rare, advanced
| attacks like the "evil maid" or supply chain attacks. You
| should worry about that _after_ you 've already secured against
| basic vulnerabilities which 90% of IoT devices have not done.
| Stefan-H wrote:
| How user antagonistic changing code on IoT devices should be is
| highly dependent on the threat model for the devices. I'm happy
| to trust home users to flash their lightbulbs and door locks
| (though the company might not see that as acceptable to their
| brand reputation if their lock is compromised nonetheless), but
| I would prefer not to trust the hundreds of IT departments and
| engineering teams to properly vet the code they are flashing
| onto industrial control systems when lives are at stake -
| centralized authority and accountability with high visibility
| on the code base that is flashed to the devices is what is
| needed there.
| jerf wrote:
| You'll know full-on no-engineer-required AI is here when you can
| point an AI at an IoT device and say "hack it", walk away for 30
| minutes, and come back to a hacked device.
|
| I'm not even being sarcastic. Most of them aren't that hard to
| hack now as it is; I know a guy who broke at least two devices in
| under an hour each because that's how bad they are. A piece of
| junk that goes out today that maybe still flies under the radar
| and nobody bothers to hack it isn't going to fly under the radar
| in a world where there's 10, 20, 50 times more "software
| engineering" power in the world, in the hands of a lot more
| people. In 5 years those things are going to be a nightmare for
| their owners, for their manufacturers, for all kinds of people.
| AnthonyMouse wrote:
| Finding a novel exploit against a device is kind of a reach
| right now, but if you give it a device with public unpatched
| vulnerabilities that were present in the AI's training data,
| emitting code to exploit them given arbitrarily many attempts
| is the sort of thing it can already do.
| jandrewrogers wrote:
| A challenge with IIoT is that the standards processes are
| consistently driven to the lowest common denominator. It is
| partly driven by cost sensitivity but also by the reality that
| many of these hardware companies are unsophisticated at software
| development and have no realistic way of becoming sophisticated.
|
| Adding to this that the scale requirements for implementing these
| standards varies by about 10 orders of magnitude between the
| smallest and largest companies, which is such a large scale
| difference that it becomes qualitative with respect to standards.
|
| This creates divergent incentives. Many companies want to
| optimize standards for the cheapest thing that will check a box,
| even if the implementation is ineffective in practice. The
| minority of companies that actually care about robust and
| efficient implementation often find this isn't feasible (and in
| some cases impossible) within the constraints of what ends up in
| many of these standards, so they ignore the standards since they
| are strictly worse than whatever non-standard thing they end up
| doing.
|
| Wash, rinse, repeat. I have participated in IIoT standardization
| efforts for almost two decades and it is the same vicious cycle
| irreconcilable requirements every time.
| fidotron wrote:
| This would be out of the frying pan and into the fire.
|
| The only long term viable approach for IoT security is to not
| allow these devices on the Internet in the first place. Have the
| WiFi Access Point, or some other gateway, act as the broker for
| all information, and the default is each device sees nothing
| until given permission. *
|
| Whenever this comes up people raise the point that this won't
| work because it disincentivizes making devices to slurp data, but
| it's not like that ecosystem actually exists at all, with the
| exception of smart TV which hardly counts as IoT. Consumer IoT
| hasn't taken off because consumers are rightly paranoid about
| bait-and-switch and being left with useless devices in the walls
| of their homes.
|
| * This is roughly what https://github.com/atomirex/umbrella is
| trying to head towards, hence seeing if a $50 AP can act as a
| media SFU, and learning it totally can.
| jamesgeck0 wrote:
| Apple had a decent start on this. An always-on Apple TV can
| connect to a Zigbee hub and provide remote access to devices
| through HomeKit. But it seems like Zigbee isn't winning out as
| the dominant standard. Most of the recent HomeKit improvements
| have been related to the wifi-based Matter.
| fidotron wrote:
| Industrially there is a decent amount of LoRa (and relatedly
| lorawan) about too, and that fills a similar role to Zigbee
| in the comparison.
| CalRobert wrote:
| It's definitely an issue - I was at a heat pump company working
| on data, and as much as the work was interesting (and I liked
| doing something related to sustainability), there was a core
| question of "wait, _why_ do we need to gather data from
| everyone's thermostats again?"
|
| Though as we move towards things like virtual power plants and
| more integrated systems with home batteries, etc. the use case
| is clearer.
| rightbyte wrote:
| > The only long term viable approach for IoT security is to not
| allow these devices on the Internet in the first place.
|
| Ye it is about that simple. IoT don't need the I. Given how low
| my trust is for vendors I wouldn't even be happy with a
| separate no internet wifi since the devices can hook up to some
| other wifi.
| fidotron wrote:
| Exactly. The wifi these devices should be on should have no
| access to anything except the broker in the gateway device.
|
| Certainly no multicast or anything like that.
| heraldgeezer wrote:
| >Have the WiFi Access Point, or some other gateway, act as the
| broker for all information, and the default is each device sees
| nothing until given permission. *
|
| Not everywhere is going to have WiFi. A SIM can use a private
| APN that selects the PGW/IP/Network range and from the ISP
| usually has a VPN to your network. Does not go "over the
| internet" at all.
|
| This is (usually) how industrial IoT, connected cars etc work.
| Shipping containers cant rely on WiFi.
| brookst wrote:
| I was positive this should have had a (2012) but sure enough it's
| a new article.
|
| "Security is the 's' in IoT" was an old joke back then. Still a
| problem but hardly a new one.
| nobodyandproud wrote:
| This is a technical "solution" which ignores a market and legal
| problem: There's no incentive to keep things secure, because the
| accountability falls on the rank-and-file, but rarely if ever on
| the actual leaders that all but require insecure incentives.
|
| We have Boeing-level incidents daily, except that it can be swept
| under.
| jmclnx wrote:
| >How to secure IoT devices
|
| Do not buy them and avoid built in ones at all costs.
|
| Maybe at some point newer ones can be secured, but I doubt it.
|
| Nevermind thousands have already be installed. People cannot be
| bothered to update their phones or computers, those updates are
| rather easy. Who will be bothered to update their IOTs ? Plus
| 2038 is coming quickly, good luck to people who have 32bit IOTs.
| Do 64bit IOTs even exist ?
|
| >it's up to system integrators, who are responsible for the
| security of an overall service interconnecting IoT devices, to
| require the features from their suppliers, and to coordinate
| features inside the device with external resilience and
| monitoring mechanisms
|
| So we give integrators access to our devices ? How is that
| security ? Also what if these integrator's company is purchased
| or goes out of business ?
| pixl97 wrote:
| Yea, it's not security and it's not how this shit works in
| practice either.
|
| "You by device that does a, b, and c"
|
| Device updates.
|
| "You now have device that does a, b, and d"
|
| You ask what happened to c?
|
| "You need to buy a new device to get feature c"
| leptons wrote:
| I can't take any article about IoT security seriously if it
| doesn't mention the inability to secure the internet connection
| with SSL. We're practically forced to use HTTP on some devices
| instead of HTTPS, because you can't issue an SSL cert to a local
| IP address.
| foobiekr wrote:
| The correct answer here is an attestation server and an 802.1AR
| device certificate; this should be used to attest to a remote
| server returned via DHCP or at a well known address (this
| sounds evil but a well known address and specific VLAN is the
| most widely deployed untrusted environment solution that
| actually works) which uses a long lived certificate for which
| the fingerprint is TOFU'd by the device. The device can use
| this attestation and mutual challenge to obtain a certificate
| (if it needs one) from an authority that other entities trust
| (which is necessarily not the 802.1AR CA).
| gigel82 wrote:
| It's so disappointing from IEEE to be arguing against user's
| freedom to own their devices.
|
| Supply chain attacks concerns are infinitesimally smaller than
| manufacturers writing buggy, unmaintained software / firmware.
|
| We should instead argue for open software / firmware, or at least
| local control only (if desired). Also solves the problem of
| billions of e-waste devices whenever manufacturers go under or
| shutdown their servers, or moves them behind new paywalls /
| adwalls.
| chickensong wrote:
| They aren't arguing that, they're promoting defense in depth.
| foobiekr wrote:
| Industrial IOT is mostly secured through network segmentation.
| There is a lot to hate about this fact.
|
| However, by career I deal with a lot of embedded devices.
| Embedded is where the hell begins. Embedded plus standards is
| pretty bad. SCADA and others. Embedded plus standards plus
| vendors .. now you are doomed. The half-assedness of embedded
| systems security is worse than any normal coder can imagine.
|
| Basically the IIOT domain is the one place that remains where
| network segmentation and encirclement and so on are the only
| things we have that work. The worst best option.
| raminf wrote:
| Any post about IoT security that doesn't mention or link to
| Shodan (https://www.shodan.io) is missing a lot of context. It's
| way worse than you think.
|
| Also, with tools like Chip Whisperer
| (https://www.newae.com/chipwhisperer) the physical security of
| the hardware root of trust needs to be reevaluated.
| mikewarot wrote:
| Imagine if electrical devices were locked down in this manner.
| You'd only be able to use appliances that the outlet
| manufacturers approved. If they went out of business, you'd have
| to have your house wiring stripped and replaced. The local
| utility would also get a vote.
|
| It's obvious to me that this model is unacceptable.
|
| A better choice is to ensure that internet stacks are secure in
| hardware, not software. This is how power is distributed.
| Internet connectivity could be secured the same way.
|
| Then you could use anything you want without worrying about
| confused software or hackers, in the same way you can plug in
| anything to any outlet without worrying about burning the house
| down.
| sublinear wrote:
| > ... does anyone really want their refrigerator to automatically
| place orders for groceries?
|
| Yes, actually. I also want the groceries delivered to my door
| using the services and stores of my choice depending on the items
| and prices, and for it to integrate seamlessly with my Home
| Assistant instance without any funny business regarding the API
| or needing to install yet another bullshit app I didn't ask for.
|
| This is the real reason we don't have nice things. The
| implementation is always botched by businesses who don't do a
| thorough job and finish their product. There's clearly a huge
| chasm between what the customer and the IoT business would
| consider an MVP. Do it right or don't do it at all.
___________________________________________________________________
(page generated 2025-06-02 23:02 UTC)