For example, inject a dialog box that says "Our records indicate your taxes were not paid this year! Before you can view the weather you must click here and log in to resolve this issue!".
The reality is, it’s not complicated to add HTTPS, as a feature, so there’s no good reason as to why it’s not implemented - aside from incompetence, or trying to save money, on staff?!
Just like some sites insert adverts in web pages, "possibly opening up the user, to drive by browser exploits…"
See: why are free proxies free https://blog.haschek.at/2013/05/why-free-proxies-are-free-js...
I regularly visit: www.bom.gov.au/<mystate>/forecasts/<mytown>.shtml
It either shows me the forecast or it doesn't.
To date it's always worked - if one day it doesn't I might have to look out of a window.
You tell me why http is bad now.
What about when they wasted $220k [1] on rebranding but ended up scrapping it?
[0] - https://www.itnews.com.au/news/asd-reveals-how-the-bureau-of... [1] - https://www.abc.net.au/news/2022-10-19/bureau-meteorology-re...
[0] https://www.abc.net.au/news/2018-03-08/bureau-of-meteorology...
Their off hand comment around why BOM didn't have https was due to the amount of overhead and infrastructure changes needed to make that https change.
Fast forward to 2018ish they recently created a new API, and a new website. Https://Weather.bom.gov.au with https enabled! (which I now have integrated into a raspberry pi and an eink display for my morning weather).
For whatever (archaic) reason the new weather webui is now defunct but the api still exists, uses https, and as far as I know supports their mobile applications.
All it would take is for some ISPs here to mitm the traffic with ads / junk and maybe they would change it. The upside to this story is that it is currently a great site to visit for captive portal detection.
For over a decade the BOM themselves ran ads on their website:
https://www.governmentnews.com.au/online-ads-now-permanent-f...
https://web.archive.org/web/20230605202001/http://www.bom.go...
They appear to have stopped the practice in June 2023:
https://web.archive.org/web/20230515000000*/http://www.bom.g...
AFAIK the only way to programatically obtain bom data is the awful ftp endpoint.
If letsencrypt would offer wildcard certificates with their url based authentification as they offer for non-wildcard certificates, it would be ok.
But having to tinker with the DNS infrastructure for each project which wants to use domain wide HTTPS is so much hassle.
Do you care about if the data actually comes from your weather forecasting service and was not tampered with by a third party? Then you need https as well.
A different example: a podcasts website I've seen was served over http, and someone argued the same (data is public, no login). The page contained an IBAN for donations. That would be a valuable target to replace as an MitM.
The entire internet needs to be HTTPS to protect against stupid security decisions made long ago that we can’t undo now in the name of backwards compatibility.
We can undo it now, the powers that b just refuse to abandon the altar of backwards compatibility, damn the cost. (Even though the addition of a straightforward document browser with no JS and no dynamic content would seriously improve most of the internet....)
edit: and everyone is voluntarily mitming via cloudflare anyway..it's all such a farce
There might be some hypothetical scenario from faking weather data and injecting it to fool the casual user but that seemingly hasn't come up in practice and so they don't fuss about it.
On the flip side, for those interested in RAW downloads from MODIS and other sats relevant to the weather, to ground station raw data transfers, to modelled predictions under various assumptions for commercial | military | government use etc ... BOM has secure login and bulk data transfer protocols, and has had those for at least 30+ years (morphing with time).
