Apple, Competitive Advantage, and the Fall of RIM

This is part of Techno Bits Vol. 71. If you’d like to read more like it in your email every week, sign up

There’s been a lot of talk lately about Apple’s competitive advantage, and how we’re standing at some sort of mobile precipice that might find Apple on the receiving end of the same treatment Apple gave to RIM a while back. It’s good to stop and think about these kinds of things, and that’s important.

But in this case, I don’t see the case being adequately made.

I think we are at a technological inflection point, but in a lot of cases, it’s Apple pushing the marketplace forward, not sitting still. The first of these cases is Apple Pay. The state of payment structures in the US is antiquated and terrible. We pay with plastic cards with magnetic stripes that are easily duplicated, a technology that has been subject to fraud since before I left college more than 15 years ago.

Europe banded together years ago with Visa and Mastercard to create the EMV Chip-and-PIN system to build better cards. I’ve had one in my American Express since 2001 or so. But only within the last year have I ever used it to make a payment. Why? Because no one’s incentivized a movement away from the stripe payment system. This past year, a change in liability for fraud started to push more contactless and chip reader terminals to the forefront.

I’ve spent the past three months on a project replacing all of the old stripe readers with new chip and contactless systems for a client with a large venue. We’re now four big events in, and I can tell you more about the problems in the payment space than I thought I’d ever be able to. The biggest problem with chip card transactions? Time and User Awareness. If you get a user that’s never used their chip card before, even with the best terminals on the market today, you’re adding 30 to 60 seconds of frustration and delay to the transaction. And that’s with the best terminals on the market today!

What about the mom and pop shop on the corner that has no control over that experience?

It’s pretty bad.

Even with the shiniest new terminals, they’re still not the bulletproof credit card swipers that we’re used to, the ones that rarely if ever malfunction, because their software was treated like the software to keep astronauts alive: it can only fail safe, it can only be changed rarely. It was ossified technology for good reason: it worked, and it worked well, and it worked for people who didn’t want or need to understand every moving part behind it. The credit card industry had made it simple by taking on the technical requirements and adhering to them in an act of ironclad religious devotion that you might find admirable in a cargo cult.

Sure, contactless is a better experience, thanks to Apple Pay, because they put a lot of thought into the user experience, but it’s still a vanishingly small percentage of commerce. Apple can do better here by evangelizing the ease of use to both commercial institutions and users alike. This needs to be better if we’re going to complete that changeover. In addition, these transaction times need to get better and not worse.

But, if you want to see what the future looks like for payments, read what happened when a Buzzfeed writer lived only off contactless and bitcoin for a period of time.

Let’s slide onwards here to another advantage that Apple has: research and engagement with the scientific community. Last year, they released ResearchKit, designed to provide the research community with necessary and almost futuristic backends for collecting complex data from layman users. It was a huge project, to the point it was released in a keynote by now-COO Jeff Williams last year.

Better still, Apple both open-sourced ResearchKit, and then released CareKit to help medical environments make apps that can persist outside of the care environment.

Apple has an unquestionable commitment to medical research with iOS devices as tools to help gather data.

Meanwhile, Android has ScienceJournal which looks like a tinker toy.

So, I don’t think that Apple is nearly as poised to fall as quickly as RIM fell, especially not with their massive cash reserves and revenues. But it’s important to stay agile, and I expect Apple won’t disappoint. Even if I don’t want a Siri bridge for home, it would make sense to build it elsewhere if only to help mollify concern they’re missing a crucial interface.

So, it’s not all bad. Even if the markets make it seem that way. Apple is best when they have to compete for their lives. I look forward to seeing them hungry and behind. It’s when we get the best work from them.

Links to Read

New Podcast: MacAdmins Episode 1

While I was in London for MacADUK, Charles Edge and I started talking about adding a Podcast to the MacAdmins community, and as it happened, we weren’t the only ones who wanted to start something new. Adam Codega from Upserve, Dr. Emily Kausalik, Jason Miller from Thumbtack, Marcus Ransom from RMIT, Pepijn Bruienne from University of Michigan, and John Kitzmiller from Fastly all wanted to chip in, and we’re going to rotate through hosts on the show as we go.

First episode is now posted, and it’s Adam, Dr. Emily, Charles and myself, talking a bit about iOS 9.3, Apple’s Ethernet Drivers, and Google SSO, before we sat down for an interview with the Organizing Committee of the Penn State University Mac Admins conference.

Come on out and listen!

Eero – More Than Meets the Eye

I’ve been fascinated by the Eero for some time, mostly because I love the idea of dirt-simple wireless mesh access points. That’s a challenging space to operate in, and if it’s done well, it has the potential to do a lot of good in putting crappy wireless repeaters out of the marketplace before they convince someone to do impossible things with Wi-Fi.

Recently, though, I’d read some odd things about them, and I wanted to see if I understood the whole situation. First up was something specifically I’d read: they use 40 MHz channel widths in the 2.4 GHz spectrum. My primary experience with devices that work like that has been finding them in use at various corporate sites where they’re just blotting out entire swaths of a very crowded spectrum. It lead to this slide’s existence:

40MHz Channel Widths in 2.4?! Weehawken, Dawn. Guns, Drawn.

It’s safe to say that I feel strongly about this.

Weirder, though, the Eero doesn’t move from its channel position at channel 1 no matter the situation. While 2.4GHz does only have three channels in 2.4 that are unencumbered by adjacent channel interference, it seems odd to pick one and lock right down to it. I asked the CEO of Eero about this on Twitter, and he came back with evidence: “Across now thousands of networks, the best channel has been 1.” In addition, while it will default to 40 MHz widths in 2.4 GHz, if things are crowded, it will dial it back to a standard 20 MHz width.

Fascinating, right? Wait ’til you see what else they’re doing.

802.11ac in the 2.4GHz band?!
802.11ac in the 2.4GHz band?!

Yes, that graphic is right. They are using 802.11ac in the 2.4GHz range! HOW?!

Well, for one, Eero is not Wi-Fi Alliance certified, which means their gear isn’t necessarily adhering to every part of the 802.11 set of standards as designed and approved by the IEEE. That means that they can choose to do more innovative things with their units, at the cost of a pretty and recognizable badge on their box.

Now, why’s this all matter at all? The culmination of our Wi-Fi deck at Cascadia was the definition of transmit speeds, which depend on the guard interval, the encoding and modulation scheme, the channel width, and the number of spatial streams available. Like a mathematical equation, these group together to give us a decent result. Wi-Fi works by encoding signals through amplitude modulation and phase-shift keying, which combine to put the wave in a specific position in a given polar chart, like so:

64QAM Chart
64QAM Chart

Depending on how the amplitude and phase are shifted together, you can line up each symbol in one of 64 positions, which a fourier transform can quickly calculate. That’s how Wi-Fi works. But until 802.11ac – which is a 5GHz technology by specification – 64-position Quadrature Amplitude Modulation was the limit. With 802.11ac, when conditions are right, everything upshifts to 256-position QAM, and the chart gets a whole lot denser:


Sure enough: 2 spatial streams, with a short guard interval, in a 40MHz channel in the 2.4 GHz band, at 256QAM 5/6, gets you a 400Mbps Tx Rate, and that’s what Wi-Fi Explorer sees in this test provided by a friend-of-a-friend.

It’s a pretty neat trick to make 802.11ac work in the 2.4 band, especially when you think they’re flouting the standards to prove a point. I’m interested to see a little more about how these handle the backhaul between units, but I’m not sure I want to spend $500 to find out more.

Techno Bits vol. 63: The Transmission Problem

This week’s edition of Techno Bits is now out in the wild, and this week I’ve written about the ransomware trojan that was embedded in Transmission 2.90 by an unknown party who both had an Apple code-signing certificate and access to Transmission’s web server. That’s a huge threat vector, so it might be time to start thinking about using Extinguish on a full-time basis.

Also included are the latest update to Munki-in-a-Box, and some thoughts about the nature of web security, and the state of my iPad Pro fascination.

Munki-in-a-Box Adds HTTP Authentication and SSL

Tonight I’ve released a test branch of Munki-in-a-Box that adds a significant feature: Out of the box HTTP Authentication over SSL for a higher level of security.

Previous versions of Munki-in-a-Box have leveraged transport layer security to make sure that the packages and manifests sent from the server to the client were not captured in transit. TLS is helpful for making sure that you’re talking with the right server, provided that you haven’t accepted a false certificate. This new version seeds the authentication credentials to the client through the ClientInstaller.pkg file created by the script, and then provides HTTP Basic Authentication setup files for your Server.

This does make a pretty stark change: The Software Repo now has to be in the Server’s path, and by default, it will be a folder marked munki_repo in /Library/Server/Web/Data/Sites/Default. Server cannot apply .htaccess and .htpasswd files outside of /Library/Server, so the repository has to live there directly instead of in /Users/Shared.

You can set the password for HTTP Basic Authentication in the initial declaration of variables.

Next up? Figuring out how to automate the setup of a CA for device certificate signing.

Apple Accidentally Blacklists Own Ethernet Kernel Extension

This afternoon, Apple released a background update that accidentally blacklisted their own Ethernet kernel extension. These background updates are generally not user-facing. The system will perform a daily check for these updates and apply them without notification. Users whose systems installed the update, marked as or Incompatible Kernel Extension Configuration Data 3.28.1, on reboot lost their Ethernet adapter’s functionality.

This is a result of Apple’s security processes working to disable kernel extensions Apple deems harmful. Also included in this update was the banishment of spyresoft’s Dockmod which somehow managed to get a kernel extension signed by Apple into production, in conflict with the security guidelines for OS X. This is a concern for a number of reasons, but that’s a matter for another day.

Fortunately, Apple realized their error in a short period of time, and pushed another Incompatible Kernel Extension Configuration Data update which removed the entry for the Ethernet Kernel Extension.

Are you concerned that you might be missing your Ethernet adapter? You can check. From a terminal, run
pkgutil --pkgs=".*compat.*"
This will then reveal all the Incompatible Kernel Extension updates. Look for:
If you see both 14U2129 and 14U2130, you are up to date. If you only see 14U2129, you should run the following to get the update from Apple (likely over your Wi-Fi connection):
sudo softwareupdate --background-critical
This will update the background updates and apply them. You may need to reboot to enable the missing kernel extension.

Thanks as always to my fine colleagues Pepijn Bruienne, Rich Trouton, Allister Banks, Mike Lynn, and Ben Toms for contributing advice and code.

Update: Via Patrick Fergus comes an important update: another way to check is to use System Profiler. Look in Software > Installations, “Incompatible Kernel Extension Configuration Data”, 3.28.1 = 14U2129 = bad, 3.28.2 = 14U2130 = good, sudo softwareupdate --background-critical to update to the new version.

Update Two: Via Rich Trouton, a longer, more detailed examination of the issue. Still not sure how this one made it out of QA.

Update Three: Via many sources, Apple has provided a technote for those who were affected. In addition, Rosyna Keller has posited a reasonable theorem for why this happened: this was supposed to be released after the upcoming release of 10.11.4, which could contain a security patch for the Apple Ethernet Kernel Extensions that were blocked yesterday. Kernel Extensions are blocked based on name and version identifier. If the Kernel Extensions were revised upward – say, for a security release – then it’s very possible that this is the reason things were done.

What remains to be seen is why they released this change now as opposed to after 10.11.4 shipped and had been in the field for some time. Given the catastrophic affect on systems, though, it’s possible this was just an intern with a faulty commit button that wasn’t caught. Neither make me feel warm and fuzzy about the state of software coming from Apple.

Techno Bits Special: Apple, Encryption, the iPhone 5C, and what it all means

A special edition of Techno Bits due to yesterday’s court events surrounding the iPhone and Encryption:

Late yesterday, Apple released a letter to their customers, signed by CEO Tim Cook, concerning device encryption. Earlier in the day, a Federal Court, at the request of the Department of Justice, issued a technical assistance order to Apple to get them to comply. The phone belongs to a deceased person accused of shooting a number of people in an attack on a county facility in San Bernardino, California, and the iPhone 5C is locked. The FBI would like access to the locked device, presumably to determine whether the deceased was part of a terrorist cell, acting alone, or something even far more nefarious. Given the FBI’s mandate, it is not a surprise that they want access to the phone.

While this particular request is grantable (and attacks against A7 phones and later is not), it shouldn’t be granted, because we should not be giving anyone the ability to crack a locked iPhone, because developing those tools is admitting that they should be given to any government, not just ours.

Techno Bits vol. 60: Packaging Isn’t (Quite) Dead

This week in Techno Bits vol. 60: Packaging Isn’t (Quite) Dead yet, some feedback on last week’s issue that sparked a lot of commentary. There are updates to the idea of a future without packages and why we might not be there just yet that you should catch up on. I’ve also got a download of my favorite talks from MacADUK, as well as some commentary on the nature of getting ahead vs. doing good.

Techno Bits vol. 59: What if Packages Went Away Tomorrow?

This week’s newsletter contains highlights from the MacADUK conference, put on by Amsys in London, England this week. It was an incredible show where I got to talk with a lot of really great admins, kick around good ideas, ponder appropriate security changes necessary for our production environments, and plan for a better tomorrow. One particular discussion at the pub on Tuesday night lead to the longest section of this week’s newsletter: what if the end of the .pkg as we know it is upon us? What if the tool we use for deployment every day was suddenly curtailed by a change at Apple?

Read up and see why it might not be as awful as you think.