DAVEY WINDER
Davey explores the effectiveness of Gmail’s security enhancements, and wonders how chicken bits helped Red Hat fight the CPU Meltdown crisis.
Fetch the bunting! Google has at last updated the Gmail web interface, although you may need to hit the settings cog to opt into using it. Until now, there have been two versions of Gmail: the standard interface that hasn’t changed much since it launched in beta in April 2004; and the radically different “Inbox” interface, launched by Google as an invitation-only beta in 2014.
I never got on with Inbox, as I found its insistence on sorting my email into predefined “smart” folders quite dumb. With the classic interface I could see all my email in a list, with the important – by way of sender and subject – and unread stuff at the top. It isn’t perfect; I’ve used the excellent Gmelius extension since 2013 to add the features I thought were missing. Things like being able to snooze my emails for attention later, disabling tracking that allows a sender to see when I’ve read their email, and the option to print direct from Gmail with a cleaner outcome.
With the new Gmail update you get the best of all three worlds, where features from the old, new and third-party interfaces integrate to become what Gmail has promised but never quite delivered: a powerhouse of an email client. The new privacy features are front and centre when it comes to floating my own boat, so no surprises there!
As you might expect, my Gmail accounts all come with two-factor authentication activated, complex and random passwords, up-to-date recovery details, and the bare minimum of third-party app permissions enabled. In addition to the already-noted Gmelius function to detect and block trackers, the new Gmail comes with another weapon to wield in the ever-evolving battle for better email security and privacy.
It can be found in the form of the new Confidential Mode, which adds several welcome tweaks to the security and privacy of your emails. And, yes, I appreciate there are readers already rolling on the floor laughing at a Gmail user talking about privacy of message content. However, it’s been about a year now since users of the free consumer service joined commercial G Suite customers in not having email analysed by bots to target advertising. Instead, Google uses data mined from across its portfolio of other services to do this.
Of course, there’s still a degree of scanning required to analyse messages to remove spam, feed the AI that provides “smart reply” functionality and so on. As I’ve stated before, there are options to easily encrypt Gmail messages with OpenPGP plugins such as Mailvelope.
Anyway, the new Confidential Mode brings Mission Impossible- style self-destructing messages into play. By which I mean that you can set an expiry date for the email sent, after which it can’t be opened or read by the recipient. The options aren’t as flexible as I’d like, however: you can choose from a day, a week, a month, three months and, rather inexplicably, five years. Currently, it doesn’t support attachments, which I’m assuming is a storage issue.
So it isn’t fool-proof by any means – a simple screenshot would derail it – but it’s a welcome nod towards message access control. As is the ability to require that a code be entered before the recipient can open the email. This code is generated by Google and delivered by SMS, so requires you to know the mobile number of the recipient, but it’s another layer of security to make the opening of emails by anyone other than the intended reader that bit harder. Confidential Mode can disable the option for the recipient to forward, download, copy or print the message as well.
This all works by sending the person a link to the message rather than the message itself, falling short of what encrypted-up-the-wazoo and privacy-focused email clients can deliver. If the recipient is another Gmail user then everything looks pretty standard, but the link thing is very apparent to non-Gmail users.
Given the sheer number of Gmail users out there, anything that can help users act more securely and provide easy-to-use additional privacy protection when required is a good thing. Sort of. I have some concerns over the way Google has implemented Confidential Mode, with the emailing of a link for a user to click, the message being stored in the cloud, and the requirement to sign into a Google account, if not already logged in. Doesn’t that sound just like a phishing attempt of the type I’m always warning folk not to fall for?
I’m sure it won’t be too long before social engineers are exploiting this similarity to steal user credentials. I’m also not too keen on the fact that messages are stored on Google servers, with access via that link sent in an unencrypted message. Then
there’s the issue of the phone numbers you need to provide to send codes via SMS. I’ve been unable to find any mention of how, where, and for how long they’re stored. I’d like to think they expire with the message itself, but I doubt that will be the case. Google needs to amend privacy policy to make this clear. GDPR, anyone?
Will I be using it? Certainly not for my business communications, and probably not for personal mail, where I want to keep the conversation truly private. There are far better secure-messaging solutions out there.
New-look Gmail does have some other interesting functionality worthy of a mention. Intelligent nudging – although it looks like dumb nagging to me – will alert you to things that need to be prioritised within your inbox. For example, highlighted tags have started appearing next to messages saying things such as, “Received 3 days ago. Reply?”, which might be useful for the chronically unorganised.
The smart-reply function is a feature I’ve actually been using on my mobile Gmail client for some time. It suggests relevant responses that can be sent with a click of the finger, and as a time-saver for responding to messages that don’t require anything more personal than a “no thanks” or “sorry I can’t make it”, it does the job.
Then there’s the addition of inline quick task buttons as you hover over a message in your inbox, making deletion, archival and replying a one-click action. I mentioned that Gmelius provides a snooze function, and this is now an integral part of Gmail, accessed via those quick task buttons. You can remove non-urgent stuff from your inbox by “snoozing” them to reappear at a later date. This is made even better by using Gmelius: it has reactivated the “smart snooze” feature to work alongside the Gmail functionality. So, for example, you can snooze an email only if nobody replies to it, so active conversation threads aren’t overlooked, and it adds greater flexibility to custom times for waking up messages.
One of my favourite additions to Gmail is the new sidebar, which can display your Google calendar among other things. If you’re a Gmelius user, this includes the ability to attach custom and shareable notes to individual messages.
Secure is the new default
Sticking with Google for a moment, it looks like the “security indicators” in Chrome are changing. This comes off the back of Google’s decision to actively promote secure pages by hitting insecure ones, in terms of Hypertext Transfer Protocol at least, with SEO penalties and warnings within the browser itself.
We already knew that plain vanilla HTTP pages would be marked as “not secure”, and now the situation is evolving naturally so that HTTPS ones won’t be marked as secure. While this might sound daft, it makes perfect sense: if all HTTP pages aren’t secure then the default unmarked state should be secure. Expect to see this rolling out from September this year in Chrome 69, and the red “not secure” warning for HTTP pages (with user input) from October. HTTP pages without user input will get a grey “not secure” warning.
Did chicken bits help Red Hat to mitigate against Meltdown?
I was recently in San Francisco for the Red Hat Summit, celebrating 25 years of the commercial open-source outfit that now powers large swathes of the internet and cloud. While hybrid cloud was the focus of the event, the topic of security was there – if you knew where to look.
For example, there was a workshop that looked to demystify the dark art that is SELinux management in the form of “Security-Enhanced Linux for Mere Mortals”, and an in-depth look at how MITRE and Red Hat Consulting collaborated with the US Air Force Program Management Office to develop a mission-critical, containerised DevSecOps platform.
In case you’re wondering, it was through the use of an Infrastructureas-Code model to produce a selfcontained, bootable DVD that automated the installation process. All the while meeting a whole host of military requirements: being a dev-replicable and consistent runtime across multiple sites to support development through production via air-gapped and secure environs; being SEC-secured out of the box using hardening tools, compliant with US government security baselines; and providing a fully autonomous installation of OpenShift, CloudForms, Cluster Storage and Enterprise Linux into a bare-metal environment.
However, the most interesting presentation was a panel discussion covering the Meltdown and Spectre processor vulnerability. The excellent John Masters, Red Hat’s chief ARM architect and processor nerd, took centre stage alongside Chris Robinson, an incident handler from the product security team.
John was candid about the necessity for mitigations to work, while at the same time minimising the performance hit. As a security geek
“I’m sure it won’t be too long before social engineers are exploiting this similarity to steal user credentials”
I’m always wanting things secured, no matter what it takes. At the large enterprise coal face things aren’t so black and white; performance issues can’t be ignored. When you understand that the speculative execution process within the CPUs at the heart of these vulnerabilities exists to improve performance, you also understand that mitigating it was always going to do the opposite.
It took John and his team around two months to come up with a ready-to-roll patch, all before the public disclosure took place. Red Hat was among the first to get patches out to customers, and although initially this resulted in performance hits of 20% or more, ongoing tweaks quickly reduced that to 10%. One of the fascinating revelations for someone who isn’t a CPU nerd, was how chicken bits helped resolve the issue.
Note that no actual chickens were harmed. The chicken bits in question being configuration bits incorporated into the design of a chip. They’re introduced to enable the disabling of workarounds to issues that come to the fore in the development process. Sometimes, these workarounds have side effects that can impact performance or security. By disabling the correct chicken bit, you can disable an entire workaround without impacting the essential configuration bits locked into place. It’s my understanding that chicken bits helped John and his team to get to the bottom of producing a mitigating patch. If you’re still scratching your head about Spectre and Meltdown, head on over to pcpro.link/287melt for an explanation of how speculative execution vulnerabilities work.
And finally…
Anyone who has ever cursed as they repeatedly input the wrong code in a Captcha box should head over to the Crapcha site ( crapcha.com). I’m not advocating that anyone installs the code to create a Crapcha code for their site; heaven knows that winning the security versus usability argument is difficult enough. However, you can have a laugh at some of the Crapcha codes, which are about as difficult as many of the real thing...