Friday, August 21, 2020

A Quick Followup on Thunderbird 78 and OpenPGP

 I had not tested OpenPGP capabilities in my last post for a new account and suggested a followup. I'm doing so here.

Actually it's fairly straightforward. I clicked on my second gmail account (without a key pair ). I went to the options menu, clicked on OpenPGP key manager and selected Generate on the popup window. It was easy to submit the new key request. Interestingly, I'm not prompted for a passphrase.  (I am if I want to store a backup copy of my key files.) And then I write a new email choosing Security/Require Encryption to one of my other email accounts, and it's a breeze to read at the other end with the lovely padlock in the upper right.

I do believe that you would have had to install OpenPGP for Windows/Kleopatra. And there are still questions, e.g., why my new key didn't appear in Kleopatra although I seemed to be able to import it into Kleopatra?


Tuesday, August 18, 2020

Thunderbird 78, Enigmail and Secure Emails

 I migrated to Thunderbird after Microsoft desupported Outlook Express around the mid-2000's. Dealing with large email folders in Windows Mail tested my patience. I also didn't want to upgrade to licensed Outlook. So Thunderbird has been my primary desktop email client during the life of this blog, and it's no accident that multiple posts have touched on Thunderbird.

This week I upgraded to Thunderbird 78; upgrades are always risky since some of your add-ons may not be compatible with the new release. So, for example, a plug-in I was using to access at least a half dozen Google calendars isn't currently available. Of course, I can easily check Google Calendar on my desktop or Android, but it's convenient in my email client if I see, say, a grandniece is celebrating her birthday.

One thing I've looked at doing is improving my email security through PKI technology. Basically there are public/private key pairs that you can use to encrypt and/or establish nonrepudiation of an email source. For example, I can use your public key to encrypt an email so only you can view its content, e.g., by providing a correct passcode/PIN. I can also apply my private key to the email which you could use my public key to verify that I sent said email. (For a related discussion, see here.)

Government (especially military) personnel often use smart tokens/smartcards known as CAC's. (I've discussed CAC's in recent posts.) Basically there are PKI certificates which are paired with your passcode/PIN to work with secure emails, network access and/or endpoint devices, etc.,It's a form of multi-factor authentication: something you have (a token), something you know (the passcode).

In legacy Thunderbird one add-on, Enigmail, has provided an implementation of PKI through integration with OpenPGP (pretty good privacy). I muddled through its implementation. All of this is freeware, no out-of-pocket costs including limited-term certificates, Now I have a large number of email accounts for various purposes, but there are 3 external providers I primarily use (an arbitrary order: hormail/outlook.com, gmail, and yahoo). And so I configured key-pairs for each of the accounts, and tested the functionality among the accounts.

The biggest problem I have with the technology is almost no personal contact or other (business) emails deploy PKI. I use it so infrequently (mostly to check functionality after various upgrades), I'll sometimes have to check one of my password stores to recall my different passphrases for the accounts.

One of the key new features of Thunderbird 78 is native support for OpenPGP, which basically means Enigmail is redundant.  It's fairly straightforward to create a new keypair through OpenPGP Kleopatra, but I haven't come across any tutorials on implementing them in Thunderbird. As time permits, I'll try to add a fourth keypair and perhaps document it in a future post.

One nice thing in Thunderbird for past Enigmail users is they provide a migration option I believe in the options menu. At least the initial steps of the migration were fairly obvious; in my case, in the order yahoo, gmail and outlook.com. What completely threw me off was the fourth prompt, which prompted me for the password for a long randomized alphanumeric string. What the hell? Is it prompting me for some password I forgot to capture in configuring Enigmail a while back?

I noticed there \were 3 such prompts\, so the obvious inference is I had to reenter the same passwords. In what order? I guessed in the earlier migration sequence. Good guess. I'm not sure why the interface was designed that way, but it wasn't obvious.

It's fairly easy to toggle on the signature and/or encryption options (I think through a security menu in the compose window), not to mention adding your public key to the email. And when I opened the email at the target I noticed a nice padlock symbol in the message window.




Tuesday, August 11, 2020

The New Blogger Interface: Some First Impressions

I don't like being forced into an upgrade, especially where it violates expectations of past experience, makes things less convenient, etc. Back in the 1980's, Coca-Cola decided to change the formula of its classic soft drink to a sweeter version and would not allow the customers to choose their preferred option. Consumers rebelled, hoarding supplies of the legacy formula. To its credit, the company quickly relented, relabeling and producing "Coca Cola Classic". New Coke never did catch on and was eventually  dropped; decades later, the company dropped "classic" on packaging of its legacy formula.

Since starting work on this post, I've discussed some of the issues I have with the new Blogger interface in a segment of my signature political blog here. Ironically, one of my chief complaints, which has to do with Blogger's New Coke approach, doesn't apply to this blog; I do have a link for reverting back to Blogger Classic, although only temporarily, for this blog. I don't know why the older blog doesn't have the link. Many of my issues deal with toggling the compose and html mode. In my daily political "miscellany" post, I'll often include a number of embedded objects, primarily video clips. So typically I'll copy and  paste bits of html code from other sources into html mode. Now the classic mode of html did a beautiful job of maintaining separation of html code and preserving text lines between modes, so, for example, I could effectively insert a couple of lines between a video and the next (existing) section header while inside html mode and those blank lines would carry over to compose mode. There were various functional reasons for inserting blank lines in html mode, including it is an easier way to avoid carryover formatting while in compose mode, e.g., from headline format to normal text format. I could more easily adjust the post format without fiddling with formats in compose mode.

It also makes it easier to find and replace html code. An example is that I've sometimes thought I had copied a video's embedded code into clipboard for insertion (replacing the prior video's code) but the copy failed, and I ended up duplicating the video in the post, which I discovered after publishing the post. Under the classic html mode, it was fairly easy to locate the duplicated video code and replace it for updating the post.

Under the new html format, html code becomes more spaghetti-like in a collapsed format and you need to parse the html ball to make your changes. Spacing in draft mode doesn't map to the compose mode. For instance, my miscellany posts usually include a quote for the day and a daily older music video "interlude" at the bottom. But if the first thing I do after adding a quote is to add my music video of the day, I can separate the quote and video segments by 50 lines in html mode, but if I flip back to display mode, the music video section appears immediately after quote and I have to fuss with compose mode settings to insert intervening post segments. It adds to the busy work of writing and publishing a mixed-mode post. (It isn't as much of an issue in drafting a primarily text post like this one.)

One related aspect I didn't discuss earlier is that Blogger Classic would also provide a way of displaying an embedded video (especially Youtube clips). Now you simply see a gray blob. The (earlier) WYSIWYG compose display didn't work for all but most of the clips I would embed. There is a preview post mode (under both versions) which works to the same desired end. Occasionally I'll run into a clip where I can't see if it works until the post is actually posted. But obviously it was easier for me to verify the clip in a WYSIWYG compose view than to preview or publish the post.

There are other minor points, probably idiosyncratic to my blogging activity. One is the fact that there used to be a checkbox in the blog stats page where you could set a blocking cookie so your own pageviews wouldn't inflate statistics. (Technically, I would prefer that to be true by default without having to constantly check if the cookie is still there.) I'll often tweak a published post for various issues like typos or wording, and maybe up to a half-dozen edits (rare, but it happens) would significantly bias my reader stats. (Some of my blogs have 100 or more pageview posts, but say I probably average less than a dozen on my daily blog;) I have an informal preference to see at least double-digits, but "real" double-digits. I have probably dozens that have capped at 9, but I don't want to cheat just by viewing each post in question. So the point is, if there is a block cookie option in the new Blogger I haven't found it yet. I recall recently I had a delayed browser launch of my published post, and the browser eventually responded with 3 or 4 windows; those all factored into the post statistics.

Finally, there are a number of feature inconsistencies, not that difficult but annoying and not necessarily obvious. An example to make the point: I'll often embed a political cartoon in my miscellany daily post and use the caption function to attribute the artist and the source. I normally had to resize the embedded image under the old format and actually like the initial size under new functionality; if I had to tweak the size, the controls are obvious, while the old controls were more of a toggle switch approach. However, somehow I didn't recognize the caption option at first and ended up manually inserting a caption line in a line following the image the first few times I inserted images and eventually discovered the caption option by playing around with the interface. Maybe the interface was more natural to other people.