2015-02-19

Regarding Lenovo preinstalling SSL-breaking MITM on their machines

One of my fears day-to-day is that my own employer will make a similar mistake. This could have so easily been my employer, instead of Lenovo. And I have no standing or ability in my employer to prevent it, especially not pro-actively. Nobody does, in any of the Windows OEMs.

The OEM gets paid for every instance that gets shipped, and for every instance that gets run, and for every demo preload that gets upgraded to a paying user.

And when something like this happens, the tech and infosec savvy people in an OEM company will run headlong into the people who have bonuses and promotions riding on "cultivating" the "relationships" with the "partners" that wrote the shit. Ripping the software out, backing out the damage, and apologizing will negatively impact their salary, so they will go to the mat and break out all the corporate political long knives to stonewall the issue.

I hate everything about OEM preloads. I tell people that when they do buy a retail Windows machine, they should immediately take it to a Microsoft Store and purchase a "Signature Editions" Windows reload. The staff there will take the new machine, scrub off the OEM install, install a fresh clean lean un-crapified Windows, and then put the old valid license key back on the machine. (Since they are Microsoft, they can generate and load valid license keys at will.)

Or if you can't stomach paying Microsoft $99 to give you the machine you thought you had already bought, at least download a copy of "PC Decrapifier" and immediately run it on your new machine the very first time you turn it on.

2015-01-02

Mark's Stories: Talking to tech press reporters in China

I've waited over a year to tell this story. And I'm going to leave out some details that are in my notes, for obvious reasons.

In November 2013, the OpenStack Summit was held in Hong Kong. My employer worked with their publicity and media relations groups and companies to arrange some interviews with the Chinese technical press with some "thought leaders" in my company, and I was tapped as one of people to participate. What was arranged was a panel interview, were all of the reporters and all of the interviewees all met all at once all at the same time in a meeting room at the conference center.

I showed up early to review the briefs and messaging, much to the relief of the marketing and publicity people.

At the stroke of the minute, one reporter showed up. I will not name them, or their employer. Their manner pinged all my rapid impressions that they were very capable. They were impeccably attired. Their questions were insightful, and each one lead logically from our answers and the earlier, and revealed that they had read the briefs as well, and was pretty familiar with OpenStack, with how the summit works, with my employer, and what my employer had publically said in the past about working with OpenStack and with open source. Their English was very good, though accented, and they took copious rapid notes while listening.

About 10 minutes later, all the other reporters showed up, late, about a dozen of them, with a female translater in tow. They were all male. Several of them were obviously hung over. I'm pretty sure several of them were still intoxicated. A couple were significantly overweight, which was odd for me to see on a Chinese man. They all arranged themselves in a phalenx behind one guy, who asked all the questions, from a notebook, via the translator. His questions were much less insightful, most of them were already answered by our advanced brief doc, and they were much more "fluffy", and much more about "why should China care?" He took no notes, and some of the men arranged behind him did take some.

The reporter we had been working with earlier sat silently in the corner, head down, eyes down.

I asked later, and had my suspicions confirmed. The excellent reporter we had been speaking to first, represented the *only* mostly independent tech press outlet represented. All the other quote reporters unquote represented state controlled media companies, or represented media outlets that were owned by state or army owned enterprises.

For obvious reasons, I am not naming anybody here, not even my own employer.

But, that was an interesting and illuminating experience, and is apparently just part of the facts of life when dealing with China.


2014-12-30

Why podcasts don't work for me

Why podcasts don't work for me:

I don't have a driving commute, so when it is the case that I am driving, it's either a short trip, or I have passengers, or I'm going to an unfamiliar place so I have to pay attention to navigation. Plus my car time is irregularly scheduled. And to top it off, my car's audio doesn't have an aux input of any sort.

When I'm not driving a car, I'm usually reading, writing, doing work with my hands, exercising, meditating, thinking deeply about something, sleeping, or talking with someone. None of these activities are compatible with listening to a podcast.

And finally, podcasts are too slow and too linear. I can read well formatted text an order of magnitude faster than someone can speak clearly.

Plus my reading style is to constantly jump backwards while reading ahead, constructing lists and building up the "idea structures" that the text is presenting, and then if the text was interesting and useful enough, jump back an entire section or chapter or the whole work and reread it again, filling in the structure that I built the first time. There are probably people out there that can do the same thing in one pass, memorizing the text in one flat read or as it's dictated to them, but I am not that smart.

In other words, if a podcast is that awesome, please also translate it into an essay, or even just a cleaned transcript, and I will read that instead.


2014-12-12

How Microsoft could save their mobile business

I feel bad for the winphone product team at Microsoft. On a purely technical basis, in many ways, the current MSFT phone OS is superior to both iOS and Android. However, none of the ISV's trust MSFT not to pull the rug out from under them, again. How many times has Microsoft abandoned their mobile OS ISVs this way, developing, marketing, pushing, and then suddenly EOLing a mobile OS with no sane forward path? At least seven. Sometimes very abruptly. Microsoft could still possibly get a win in this space, but they will have to keep their mobile phones and mobile phone OS in the market for at least 2 more years, before any ISVs start trusting them again.

If it was me tasked to save the winphone, I would do the following things, all at once:

  1. make the developer experience for developing for their phone seamless
  2. give the all the developer tooling and training away for free
  3. hire several parallel teams of app developers, and put them to work grinding out useful apps.
  4. Focus the security model and app priority list on the actual needs of business and users and IT departments. (Which means a lot more than just "port Office to it".)
  5. And then, the big one: open source all those apps, and the dev tools, and the mobile OS itself.

In fact, Microsoft could do something both amazing and good for themselves, and GPL the winphone OS, and GPL the HALs for all their Nokia hardware. Since they would be the copyright holder, the GPLs stickiness works *for* them, instead of something they would be terrified of and fight against.

They are not going to do any of this, of course. Instead they are going to do something stupid, like try to "converge" their cloud server OS, cloud guest OS, data center server OS, desktop OSs, tablet OS, and phone OS all to the same code base. Which is one of those things that seems like a great idea at first, until thinking through it more deeply.


2014-10-23

Rant: account setup and reset flows for banks are all terrible

Why is the account setup and password recovery flows for the sites of financial companies so utterly terrible?  And so insecure?   "Please fill in the following badly structured form with your personally identifying information that is easy to research from public records" and then emailing a new password in the clear, instead of a reset link, seems to be standard practice.

Account setup for financial, insurance, employment, medical, legal, regulated utilities, and government services should go through registered postal mail, and/or in person.   And if I were king, that would be black letter law, with no wiggle room, and draconian penalties, plus private rights of action with statutory damages.

2014-09-22

On telco admin access to your DSL or DOCSIS modem (rejected by the Cryptography mailing list)

(The following post was rejected by the moderation of the Cryptography mailing list as "inappropriate", so I am posting it here, instead.)


Bill Stewart writes:
probably the telco has their own [administration interface] for the DSL [modem].

I respond:

Having had jobs where I had access to the management and configuration UIs for various brands of head end units for DOCSIS [cable modem] and for DSL systems, and for various brands of remote management tools for customer side equipment control for DOCSIS and for DSL, all in lab settings: I flat guarantee that the telco has their own management access to your DSL modem, and that that management control can see both the CSE and CPE sides of your modem.

When we were lucky, the modem lets the telco change the credentials to the telco admin interface. All too often, it was fixed to a hard default by the modem manufacturer.

IMO, one of the deeply fundamental problems with both DOCSIS and with DSL is that the telco has to trust the equipment installed at the customer's site, and thus cannot allow the customer to randomly play with what it can be configured to do. (For example, at least in 2004, DOCSIS 1.1 and DOCSIS 2.0 did bandwidth caps in part on the terminal side, instead of at the head end.) This is the kind of deeply stupid design error that only someone breathing the telco / bellhead koolaid can make.

2014-08-14

Regarding systemd

After reading this rant by Christopher Barry about systemd, I feel the need to weigh in myself about systemd

After learning more about systemd at the LinuxConUS last year in New Orleans, I took half a day to audit the source code. It's a nasty complex hairball, full of internal boundary violations, leaky abstractions, undocumented implied state, no DRY (don't repeat yourself), and poor code style.

It is, in short, a pile of shit, worse than most, and is not to be trusted, especially NOT as process id #1.