Thursday, December 3, 2015

Android apps on Windows Phone is like Windows on OS/2

Steve Ballmer is paraphrased in this ZDNet article saying "the company needs to ensure Windows Phone handsets can run Android apps".  For a guy who spent more than 5 years writing system code for OS/2, the parallels to WinOS2 are pretty interesting.

Here's the lesson: The operating system must stand on its own, or your just postpone it's death.

"A better DOS than DOS and a better Windows than Windows"!  

With the 80836 supporting versions of OS/2 starting with 2.0 in 1992, the company did an absolutely excellent job running DOS applications in MVDM virtual machines.  This provided the required legacy support for DOS applications while the native side of the OS provided developers a platform to build rich applications that could fully exercise the systems 32-bit world.  OS/2 had an impressive multitasking kernel and a great TCP stack and could have been a great platform for application developers.  The applications never came; why?  A lot of reasons actually, but a big one was because IBM made the fantastic blunder to also build support for Windows 3.1 applications.

Once IBM built "adequate" system support for running Windows 3.1 applications on OS/2, ISVs now had zero motivation to write native applications and the native applications were not implemented, or were implemented poorly with customers instead opting to use the Windows applications on the OS/2 system and at the end, that operating environment just didn't make sense anymore.

Development team gets distracted

Meanwhile, the operating system development team were spending tremendous effort to make Windows applications run inside a virtual machine.  Yes, Windows 3.1 was just a 386 DOS extender application running with a DOS boot loader, and given a MVDM supporting system already, running this big app wasn''t impossible.  It still took work though, real work!.   Work that ultimately included dragging me away from OS/2 native system work and into a world of writing what we today call paravirtualized drivers to send Windows 3.1 audio operations across to the native OS/2 multimedia system for processing.  Time that I SHOULD have been building the greatest audio and video processing system in the world, or perhaps just getting more device support for the native system.

Bottom line, it's 20 years later.  Microsoft has become IBM and Google is playing the part of Microsoft.  If this "run Android on Windows" strategy actually proceeds, Android developers will have no motivation to write native applications for Windows phone handsets, and the operating system will ultimately die.

Everything that is old, is new again,

Joe Nord

Sunday, November 22, 2015

New Dell computer comes with a eDellRoot trusted root certificate

I recently purchased a Dell Inspiron 5000 series notebook (October 2015).  Setting things up, I was surprised to see a trusted root certificate pre-installed on the machine labeled "eDellRoot".  I'm having a tough time coming up with a good reason that Dell Computer Corporation needs to be a trusted root CA on my computer.

It has me thinking things similar to the Lenovo mistakes earlier this year with Superfish which I described at the time on twitter as "Lenovo commits corporate suicide".  With this eDellRoot presence causing curiosity, I posted again on twitter and this has resulted in some queries to more specifics on what I know.

I'll start with the MMC console certificates view of the installed cert.

Observe, the eDellRoot certificate is a trusted root that expires in 2039 and is intended for "All" purposes.  Notice that this is more powerful than the clearly legitimate DigiCert certificate just above it, which spikes more curiosity.

Drill in to see the certificate details and alarm bells start going off. 

"You have a private key that corresponds to this certificate".  This is getting very fishy!  As a user computer, I should NEVER have a private key that corresponds to a root CA.  Only the certificate issuing computer should have a private key and that computer should be ... very well protected!

Certificate details

Serial number starts with "6b c5 7b 95 18 93 aa 97 4b 62" and the keys are marked non-exportable.  Notice that this doesn't mean that the private key isn't accessible, it only means that it isn't exportable.  Anyone possessing the private key which is on my computer is capable of minting certificates for any site, for any purpose and the computer will programmatically and falsely conclude the issued certificate to be valid.

This is the same action that existed with Superfish and in that case, Lenovo made the tremendously awful action of using the SAME private key on every computer.  Has Dell done the same?  When I get a few minutes, I'll try this technique to dump the private key.

Is it Dell?

Consider, while I do know that this certificate came pre-installed on the computer and I do know that it is named "Dell", I do not actually know that this certificate came from Dell Computer Corporation.  Root certificates are always self-signed, so all I really know is that eDellRoot says eDellRoot is legit. Where it breaks down is that the private key IS PRESENT on my computer and that means ... bad.

I'll note that I do not see MITM website proxy as described in this Sophos blog and the sites visited check out clean using Steve Gibson's fingerprints service.  A spot checking of web browsing here and there also shows certificate chains checking out as I would expect.  What is the purpose of eDellRoot?

And request arrives, Joe, would you kindly share the eDellRoot certificate from your computer?  Okay, here you go, link

I look forward to reading comments,

Joe Nord