2018 Tech IPOs: Is Enterprise a Game-Changer?

Jon Swartz’s recent piece in Barrons asks “Is This the Year Tech IPOs Stage a Comeback?” Prior year IPOs did not meet expectations, with consumer companies like Snap and Blue Apron the poster children for a miserable performance.

But the speculation among the smart money is that 2018 tech IPOs will surge, and they’ll be driven by enterprise companies.

So, is enterprise the game changer for tech IPOs in 2018?

My answer: “Yes” and “No”. Does that help?

Enterprise companies differ from consumer companies in that one can validate revenue streams. It’s a no-brainer, really. So that is comforting to investors looking for solid growth.

But the downsides to enterprise companies is that the very revenue streams that make them look juicy are also very vulnerable to disruption from upstarts offering a better deal.

The reason the 2017 consumer tech IPO market was a miserable failure from an investment perspective is that everyone fixated on hyping a big name, Snap or Blue Apron. The more they repeated it, the more they assumed consumers would flock to use it, justifying the IPO.

That didn’t happen, because, unlike FaceBook which did an extensive global lockup of the market, companies like Snap didn’t bother to do that hard footwork. But it was necessary to continued success after the spinup to IPO. They got lazy.

Now we’re in 2018, and extreme views change extremely. Consumer plays are anathema. Enterprise is the ticket. Getting some traction for revenue in an enterprise company is possible and desirable.

But the problem for enterprise companies is understanding the quality, consistency, and dependability of revenue as new guys offer better deals.

In particular, I wonder about Dropbox post-IPO. Is their enterprise story really that deep? Honestly, I can think of several different ways one can do a Dropbox one better, and I’m not even trying hard. Imagine if some investors got serious about this area, instead of playing low dog on the deal flow. Would it be an easy one for newbies to crowd in and offer enterprise customers a better deal? We shall see.

The Security Frustrations of Apple’s “Personal” Personal Computer: Device Access, Two Factor ID, and 386BSD Role-Based Security

Recently, a FaceBook friend lamented that he could not access his icloud mail from a device bound to his wife’s icloud access. He also expressed frustration with the security mechanism Apple uses to control access to devices – in particular, two-factor authentication. His annoyance was honest and palpable, but the path to redemption unclear.

Tech people are often blind to the blockers that non-technical people face because we’re used to getting around the problem. Some of these blockers are poorly architected solutions. Others are poorly communicated solutions. All in all, the security frustrations of Apple’s “personal” personal computer are compelling, real and significant. And do merit discussion.

One way tech folks get around Apple restrictions on email, for example, is to use multiple accounts. On an IOS device one can use multiple services and setup accounts for these services. For example, most don’t know that “notes” is actually a hidden email client via an imap fetch. Apple does use the appropriate protocols behind the curtain.

In my case, I don’t even use icloud mail. I use dedicated email accounts. I have access mediated by a mail server in our datacenter cloud which we personally administrate.  So all this frustration doesn’t impact me. I don’t see it in my daily life. I’m blind to the impact on others.

But what if I, like most people using Apple devices, want to access icloud mail from any Apple device? Icloud isn’t an ordinary heterogenous service. It is actually bonded to a set of devices. This is the philosophy behind Apple’s “personal” personal computer. The assumption is the customer has many devices tightly held and only used by that single customer. If that’s so, it naturally follows that those device will not easily permit access to a different icloud mail, because there is no need. The security won’t allow it. They expect you to setup another imap account, like Gmail, directly. They expect you to be a “techie”.

As an experiment in trying to understand this issue, I went to a mac that is not bound to an iphone I had in hand. By using “find my iphone”, I logged in as the apple ID and password. It then showed the location of that iphone sitting next to me. I then changed to the mail app within the browser, and it showed me the icloud mail. All this on a mac bonded to a different user. So I did get around the problem.

But it was non-intuitive. It was somewhat absurd. And it did reveal a security issue. Security by obscurity is a bug, not a feature.

I was unable to test this on other devices, such as an ipad, as I was pressed for time. But I’m pretty sure there are ways to get around this even on small devices. But really, seriously, is this sensible?

This entire conversation then segued into a discussion of two-factor identification. In theory, two factor identification is quite straightforward: Since everybody has a phone and some other device, if someone tries to access your account because they cracked your password and it’s not on one of your bonded devices, they send an email or a text to another device known as yours to confirm it’s OK. Simple, right?

Well, theory and practice are called that because thinking and living are really two different things. People live messy lives. Their phone may have been lost or forgotten or not charged up. They don’t know what device is the “mother may I” device.

The fundamental problem is that the nature of the security constraints of the Apple iphone concept requires it to be hermetically sealed. (In contrast, Android is a leaky sieve, and it is quite vulnerable.) This is why the battles between Apple and the government on access to personal iphones is so fraught, because it really is all or nothing.

This is not the only use of two factor identification. Two factor identification is required for a lot of services, such as FaceBook, and is not bound to a particular device walled garden. But the issue of making sure you have access to the primary device and “mother may I” device is still there. You must have all your devices, old and new, standing ready for the occasional incursion. And you must check and update all two-factor identification access points when you update devices. And this, my friends, is absurd.

I actually did a little work on security way back in the 1990’s, where William and I came up with the concept of role-based security as an adjunct to the usual password mechanisms. We even wrote up an article in Dr. Dobbs Journal about it, plus implemented it in 386BSD Release 1.0.

What were the gotchas? Security people didn’t like it because they were obsessed with crypto as a savior – which of course it wasn’t. The IT guys weren’t enamored because they liked administrating passwords and didn’t think it was a problem to change the password all the time, even though people don’t do that because they forget it, or they put it on a post-it on their monitor or write it in their wallet, and use “password” and “12345” as their password.

Two factor authentication is just doing a “mother may I” to a separate device because we have lots more devices, but fails if the device being asked might not be available, hence blocking the user from work. It may not be great, but at this point, it’s really all we have.

Apple Store “Bait and Switch” IPhone Battery Gambit: Apple Giveth and Taketh Away

Beware the Apple Store “bait and switch” iPhone battery gambit. We faced this yesterday in Los Gatos, CA where they tried to claim a working iPhone 6s with a good screen / original owner was not eligible for their $29 battery replacement at the appointment because it had a slight bow in the frame.

Now, by this point everyone likely has some flaw in their old iPhone, whether it is a slightly dinged frame from being dropped to a minute crack or scratch under the frame. It’s normal wear and tear. And they likely didn’t have a problem replacing the battery before the discount was announced and replacements were more costly and infrequent. But now, it’s an issue.

They did offer to sell an iPhone 6s for close to $300! This is a terrible price. Don’t go for it. This is what they mean by bait and switch.

There’s a good reason why Apple doesn’t want to replace old batteries after their bungled attempt to intentionally slow down older iPhones with an OS update was discovered, but they don’t mind selling old inventory at a premium. Money.

According to Barclays’ analyst Mark Moskowitz, extending the life of old iPhones will impact Apple’s bottom line and stock price severely: “In our base case scenario, 10% of those 519M users take the $29 offer, and around 30% of them decide not to buy a new iPhone this year. This means around 16M iPhone sales could be at risk, creating ~4% downside to our current revenue estimate for C2018.”

I suppose we’re back to the maxim, “If it seems to good to be true, it is too good too be true“.

Consider your options carefully when they refuse to honor their agreement.

Intel’s X86 Decades-Old Referential Integrity Processor Flaw Fix will be “like kicking a dead whale down the beach”

Brian, Brian, Brian. Really, do you have to lie to cover your ass? Variations on this “exploit” have been known since Intel derived the X86 architecture from Honeywell and didn’t bother to do the elaborate MMU fix that Multics used to elide it.

We are talking decades, sir. Decades. And it was covered by Intel patents as a feature. We all knew about it. Intel was proud of it.

Heck, we even saw this flaw manifest in 386BSD testing, so we wrote our own virtual-to-physical memory mapping mechanism in software and wrote about it in Dr. Dobbs Journal in 1991.

You could have dealt with this a long time ago. But it was a hard problem, and you probably thought “Why bother? Nobody’s gonna care about referential integrity“. And it didn’t matter – until now.

Now a fix is going to be expensive. Why? Because all the OS patches in the world can’t compensate for a slow software path. We’re looking at 30% speed penalties, sir.

Now, we can probably and properly blame the OS side with their obsession with bloated kernels.

But you promised them if they trust your processors, you’ll compensate for their software bottlenecks and half-assed architectures. And they believed you.

So now you’ve got to fix it, Brian. Not deny it. Fix it. Google didn’t invent the problem. It’s been there in one form or another since the 8086 was a glimmer in Gordon Moore’s eye.

And now it’s going to cost Intel. How much is up to you.