Basically the article is talking about vulnerabilities for man-in-the-middle attacks for apps using Sparkle framework. This framework is used by many developers to manage the update process of an app.
HTTP to HTTPS global trend
First of all, the group of developers behind the current Sparkle framework, pornel and the others, are very commited developers. Always trying to maximize the security of the product. This can be witnessed by the discussion on Github. This is why few months back they started to push for HTTPS a lot, to almost today deprecate the HTTP connection in their framework.
And they are not the only ones. Last autumn 2015, Apple with their last OS X release, El Capitan, implemented what is known to the developers as App Transport Security (ATS).
What is this? Basically an app compiled recently, by default cannot connect through HTTP to a server with El Capitan. This protection is not related to the sandbox. It is an extra protection. So today for a developer to release an app with HTTP connection, the developer must authorize it. Host by host or fully, which obviously increase the security risk.
Now let’s talk about seense apps? Are they impacted?
All my apps are stored on seense servers, the same server as my website.
Last October 2015, I have announced that I moved seense.com to HTTPS. One of the main point was more secure app upgrade.
Since last October 2015, all the apps from seense connect with seense server through HTTPS. And I leverage the ATS new security system to reinforce this on El Capitan.
On top of this all the apps are signed with my Apple certificates.
All the apps simultaneously sold on the Mac App Store and seense Store are sandboxed.
So, the short answer is, seense apps are not impacted by this issue!.
Why this post?
I did this post, because I started receiving emails from concern customers following the Ars Technica article.
I guess, more of you may be concerned too. So, I want to say that seense apps are not impacted by this issue!. I take very seriously the security issues. And as explained previously, it was already anticipated last year.
Added 20/02/2016: You can test yourself if your apps are vulnerable to the Sparkle framework by using the following script, proposed by the Sparkle developers.