Office 2016 for Mac – A plea for add-ins functionality!

Office for Mac Website
With the release today of the first preview of Office 2016 for Mac (which has been a LONG LONG time coming as you will all know), I want to put forward the following plea to Microsoft. Thus far, on brief inspection, I have not seen any indications that add-ins will be supported in the new version of Outlook, or the rest of Office.

As many of you will know this has been something that is sorely lacking from the Mac version and therefore when vendor’s offer Outlook plugins (the ones that I personally would like to use the most), we Mac users get left high and dry.

Therefore I ask that everyone click the little smiley in the preview version of Office for Mac (top right hand corner) and echo this plea for Microsoft to include such functionality in the new release.

The feedback I left was along the following lines (I will admit this is a cleaner version as I lost the copy-paste version I took to post here):

Hi Team,
One thing that I have not seen thus far in the preview, on initial inspection, is the lack of any add-ins functionality like the Windows version of Office has had for many years. When I think of useful add-ins I think of those from vendors such as Evernote, Bananatag, Any of the anti-spam software companies all the way up to enterprise level add-ins for interacting with email archiving appliances and enterprise anti-spam solutions.

With the complete overhaul that is being worked on so diligently by Microsoft, I feel it is essential that focus is given to allowing vendors to extend the functionality of Outlook (as the highest priority) and the remaining Office applications as a secondary component.

While we are many months away from release I think this is the best time to raise this and I hope Microsoft will hear our pleas to provide a feature comparable version to that of Microsoft Windows users.

Kind Regards,
Stuart

Let me know what your thoughts are, and if you send Microsoft some feedback, please leave a comment here and let me know.

Cheers,
Stuart

 

 

CVE-2014-4451 – Apple iOS bug allowing unlimited incorrect pin attempts

A bug that would allow unlimited incorrect pin attempts on any iOS device is enough to make a lot of people’s toes curl. Unfortunately that is what I found when I recently stumbled upon an iPhone lockscreen bug allowing me to do just that.

On the 28th September 2014 I raised a bug with Apple which later was assigned the ID CVE-2014-4451. Now that this has been patched in the latest iOS 8.1.1 I am able to release the details of how the bug was exploited. At this stage I do not have any devices running any iOS earlier than 8.0 therefore am unable to test if this affects earlier releases of the operating system.

The steps to reproduce are demonstrated in the following video I placed on YouTube:

 

I have yet to discover if this affects devices running iOS 7 or earlier, therefore if you have one of these devices and are able to demonstrate that the issue occurs on that release of iOS also please leave a comment here and let me know.

I hope that this information helps users become aware that they should stay up to date with the latest release of software wherever possible to protect themselves against such bugs.

I thank Apple for working diligently to resolve the bug as quickly as possible.

Stuart

[[Update]]

Thanks to @DarthNull on twitter, we now know this goes back at least as far as iOS 6

Could bugs like Heartbleed pose issues for biometric authentication?

Heartbleed and Biometric SecurityCould a future bug, with similar implications to that of Heartbleed cause major concern to the future use of biometric security? Following the critical Heartbleed vulnerability in OpenSSL, and reading countless articles online (see below for a few) an interesting conundrum came to my mind.

As we now know, there are three requirements to overcome the effects of the Heartbleed bug on any one server or service:

  1. Patch the affected software on the affected server
  2. Revoke and re-issue the SSL certificates (essentially the private keys used to encrypt traffic between two points such as the end user’s browser and a bank’s web server for example)
  3. Change your password for the affected service/application in case it had been compromised

 

The conundrum focuses on a problem with step 3 and the use of biometric security measures such as fingerprints, retina scans and potentially new vein-scanning technologies. While these technologies are not heavily in use by consumers today they are becoming more commonplace, many users of the new Apple iPhone 5s (myself included) use a fingerprint to speed up unlocking the lock screen and the potential uses are already on the rise as this technology becomes more mainstream.

Taking a high level look at this, from a pure sequence of events (as opposed to analysing how or where the biometric data is stored and/or transferred and how it may or may not be encrypted), I provide the following hypothetical scenario to consider. In 12 months time lets say you can use your fingerprint or a retina scan to get cash out at an ATM, or to identify yourself to your bank and other providers using your smart phone. The technology is in use for a period of time and after a while a bug with similar consequences as Heartbleed happens to be discovered. At that time there may be no clear evidence of whether the bug has been exploited or not, however this actually becomes irrelevant. Taking a worst case scenario, lets say despite the best efforts of the companies, the multiple layers of encryption and all the other security measures that one of the many supporting components of the authentication process has a bug which has, or could potentially cause your biometric details to be exposed, copied or intercepted.

As our primary form of authenticating ourselves today is using a password, we can simply change our passwords which invalidates the potentially compromised user credentials. As I am sure you can now surmise if we were using biometric authentication, we could not simply change our retinas or fingerprints, these stay with us for life. I will admit this is taking the extreme end of a worst case scenario, with any high level security solution, you would expect several layers of protection, but it definitely poses an interesting question of what can be done to invalidate and then re-issue a biometric credential.

Unfortunately I don’t have an answer, I do hope that this might promote some discussion or at least get the idea in the back of a few peoples minds. If anyone has any thoughts or ideas please let me know as I am genuinely curious as to the answer to the riddle. In the mean time, perhaps it is best for us to all strongly consider who we want to hand over our biometric “prints” to… if they are ever compromised you can’t simply change them.

 

Articles that prompted my thinking:

Privacy Preference Center

    Necessary

    Advertising

    Utilised to provide advertising

    _gat,_gid
    IDE

    Analytics

    Utilised to enable Google Analytics

    _ga

    Other