Category: Technology

If you’re like most people, when you decide to check the weather, you look at a forecast, likely supplied by your mobile device.  If you’re more inquisitive and want a visual aid, you visit a website and check the radar.  That probably satisfies your curiosity and you quickly move on to significantly more important aspects of your life.

But if you’re like me, you become irrationally irritated because, well, there seems to be no good way to view the radar.  Chances are, if you go to your local news’ website, they have a poor quality, buggy, slow to load page with the current national or regional radar.  Why this is so difficult to pull off baffles me.  It’s probably due to the extraneous features that no one will ever use, like the option to view the last 24 hours.  Who the hell cares what the weather was like 24 hours ago?  Also there’s probably a plethora of scripts that have to load on the page, adding to the already script-laden overhead from 3rd party served advertisements.  Often do I miss the days when websites contained text, images, hyperlinks, and nothing else.

But nostalgia aside, I considered what I wanted such a radar page to do.  My list was short: I wanted it to show the current radar as of the last update and not the interactive history, not the last 30 minutes that always cycles through on infinite loop with no way to disable.  I wanted nothing else on the page, and I wanted it to take up the full page.  Finally, I wanted it to update as the new radar become available.

But first things first–and a question that always bothered me: where do news stations get their national radar, because surely that has to be a shared network?  Fortunately, it didn’t take long to figure out.  If it was a nationally-shared network of data, then it had to be government-owned.  It had been around too long and was too big for it not to be government-controlled (look at where national internet access is headed).  I didn’t even have to Google this, for I already knew of this governmental entity: the National Oceanic and Atmospheric Administration:

http://www.noaa.gov/

Digging through this site, I discovered that the national Doppler radar was indeed freely available for public access, and updated automatically:

https://radar.weather.gov/

As I write this post I notice that it’s even https now, go figure.

I found the image I was after, the national real-time Doppler image:

https://radar.weather.gov/ridge/Conus/full.php

But, problems still remained.  For one, the image is too large for a normal browser window.  Also it contains the NOAA logo that uses up space.  And, the image is static and doesn’t update unless the page is refreshed.

Fortunately, with a little bit of web-development know-how, it is quite possible to link to the image externally, as the gracious NOAA has not disabled image-linking.  Looking at the page’s source code, I saw that the radar image was delivered from this URL:

https://radar.weather.gov/Conus/RadarImg/latest.gif

Easy-peasy.  I simply just inserted that image with one line of code into my own page’s body:

<p align=”center”><img src=”https://radar.weather.gov/Conus/RadarImg/latest.gif” height=”650″ width=”1157″ align=”center”></p>

I also centered and resized it to my liking.  Then it occurred to me that I really don’t need to see the national radar.  I was more interested in the regional radar.  This became slightly more involved, but still doable with a little CSS, so I inserted this little bit of styling information into my page’s head, forgoing adding the image to the body:

<style type=”text/css”>
body
{
background: url(“https://radar.weather.gov/Conus/RadarImg/latest.gif”) no-repeat left center white;
background-size: 4500px 2400px;
background-position: -2500px -550px;
}
</style>

I set the image to be the page’s background, then through trial and error resized it to zoom, then offset it so as to center approximately upon the Midwest.

One last problem remained, and that was the automatic updates.  This was solved with a simple meta refresh:

<meta http-equiv=”refresh” content=”60″>

Now the page refreshes every minute, which automatically pulls the latest radar image at that time.

Now, at long last, I can have real-time Doppler radar imagery delivered without fluff, and automatically updated.  Plus, if I put the window in kiosk mode, it covers the entire monitor so I can feel like a meteorologist!  Or…old man, depending on who sees me doing this.

Here are the sites if you wish to use mine and forego any coding:

https://moorheadfamily.net/weather.html

https://moorheadfamily.net/weatherohio_kiosk.html

Now place a wireless thermometer next to your monitor and you won’t even have to open the curtain to determine the weather is not to your liking!

–Simon

As long as I’m shouting into the void, I’ll mention a recent tutorial I summarized on implementing S/MIME email encryption, specifically within iOS.

I am very cognizant of the fact that people as a whole, when faced with the decision of mildly inconveniencing themselves for security vs. not using security at all, will inevitably choose the latter.  It is a predictable constant which infuriates me immensely.

There, I voiced my opinion on the matter.  With that preface, I will avoid the more lengthy soapbox speech.  You’re welcome.

I categorize various technologies into one of three overly-simplified classifications: “Not Secure”, “Probably Secure”, and “Secure Beyond Reasonable Doubt”.  The email protocol as a whole falls under “Not Secure”, however, circumstances may allow it a “Probably Secure” status.  For example, when the sender’s email provider’s server sends the email to the recipient’s email provider’s server, it has the option to negotiate encryption.  This encryption is not enforced, so if either server opts to not support it, then there is no encryption.  Also, there is no way to verify this level of encryption as the user doesn’t see this process.  Now, certain email providers can be assumed to use encryption as the default, based upon their established reputation.  Google, for instance, does default to encryption with their Gmail service.  Therefore, if both the sender and the recipient are using Gmail accounts, then it can be safely assumed that the email remained encrypted in transit, therefore it is “Probably Secure”.  But this a very specific example, and cannot be assumed or confirmed by the end users.

Another example of “Probably Secure” is Apple’s iMessage.  This messaging service not only defaults to, but requires encryption.  The caveat is that Apple itself creates and maintains the encryption keys.  This is where a lesson in how public key infrastructure operates would add context, but any explanation I could offer would be far less robust than that of a crypto-analyst’s, so if curious, you know, LOOK IT UP!

The conclusion here is that while iMessages are indeed encrypted, we’re relying solely on a third party to keep them that way, and again the user has no way of verifying the process.  Therefore: “Probably Secure”.

The point being: in certain circumstances you are probably okay, but sometimes being probably okay isn’t good enough.  My wife and I often have the need to exchange sensitive information, as no doubt many married couples do.  Health information, other personal information about ourselves and our daughter, financial information, the need to exchange login credentials to sites that house this information–these are instances where “Probably Secure” doesn’t inspire much confidence, whereas coordinating dinner plans doesn’t need that level of security.

Which brings me to the solution and my ultimate point: a system exists that can provide “Secure Beyond Reasonable Doubt” communication, and as the title of this post would suggest, that is called “S/MIME Email”.  The base concept is that both users obtain encryption certificates and, using the public key exchange system on which all modern asymmetric encryption is based, encrypt and decrypt each others’ emails before they are sent and after they are received at the device level.  Nowhere in transit will the email be unencrypted (such as in webmail).

For a better understanding and background on the technology, some keywords to search for are: “S/MIME”, “Public Key Infrastructure”, and “Asymmetric Encryption”.

Moving on: the process is somewhat irritating to set up initially, plagued by the individual quirks of each device/computer and email client.  After trial and error, I have compiled a brief walkthrough of the process for iOS–of which, I note, I was unable to find in its entirety elsewhere on the internet (specifically uninstalling previously installed recipients’ certificates).  I have housed the walkthrough on my Wiki: https://moorheadfamily.net/MediaWiki/index.php?title=S/MIME .

Good luck, and keep your private information safe!

–Simon