Ford, Mazda, Toyota, Subaru, PSA (Peugeot, etc.), and Suzuki are now part of an automotive alliance concerning your dashboard. The SmartDeviceLink Consortium, as they’re styling it, is apparently all about muscling around Google and Apple’s forays into the automobile, and is based on Ford’s existing “AppLink” software project, which has been around for several years.
I’ve written about smart dashboards before for TTAC. Particularly, in 2013 after Apple’s original announcement, I was amazed automakers were willing to cede so much control over the precious dashboard real estate. I later noted people are likely to be more loyal to their phones than cars and to make buying decisions around what cars support their phones “properly,” especially because Apple and Google fundamentally know a lot more about you and can do a much better job of knowing what you want to listen to and where you want to go.
But what exactly is the SmartDeviceLink Consortium all about? You might think it sounds like it’s a rejection of your smartphone driving the screen in your car, as with Android Auto and Apple CarPlay. Curious as to what was really going on, I then dug into the giant pile of software and specifications they’ve posted on Github. What’s really going on here isn’t as much in opposition to what Google and Apple are up to as it’s an attempt to standardize it and refactor it.
Consider the following diagram:
HMI, on the left, is the big touchscreen in your dashboard. SmartDeviceLink (SDL) is a computer somewhere behind that screen running many different software components, which then interacts with your device, pictured on the right.
Hey, can you zoom into that SDL diagram? Sure, happy to oblige:
What I hope is plainly visible to any TTAC reader, whether or not they’ve ever written a line of code, is that there’s a whole lot of stuff going on here, replicating many of the features and services already present inside your phone.
So how is all of this different from what Apple and Google are doing?
Primarily, Apple and Google’s designs are all about keeping it simple. The car provides access to the screen and maybe a few other handy things like wheel telemetry or a compass, and then the phone does all the rest of the work, saying “here are a bunch of pixels, draw them.” Dumb car, smart phone. Apple and Google’s designs are conceptually similar to a long-established class of remote desktop software applications (think: Microsoft Remote Desktop Services, Citrix, VNC, and other such things).
What’s the ostensible benefit of SDL having all of this functionality refactored into the car rather than resident solely in the phone? Let me give an example and zoom in on one proposal (dated August 2016, written by a Ford employee) for handling “turn by turn mobile managers”:
The idea is to provide an API in the mobile libraries to app developers to navigate to a desired destination. On the other side suppliers of navigation SDKs can develop against APIs and create a [turn by turn] proxy to accept requests to navigate to a destination. Furthermore these navigation SDKs can provide notifications for instructions, a maneuver icon and a map view to be shown inside the lock screen. In between SDL can receive the information from the navigation SDKs and send them to the HMI of the head unit. Implementing the HMI related work inside the mobile libraries would unify the behavior of different navigation SDKs and make it very easy for app developers to integrate a navigation feature into their apps.
In a nutshell, SDL is all about having the car collaborate with the phone rather than being a dumb display terminal for it. This gives the automaker an opportunity to customize how things work, to add their own layers, to mix-and-match native and remote applications, and so forth. Sounds great, right?
Computer security and keeping it simple. A legendary computer scientist, Sir Tony Hoare, once said: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Apple and Google’s approaches are all about keeping the car side relatively simple with the heavy lifting happening inside the phone. Conversely, SDL is trying to do more of the work inside the car itself. Not only does this imply many more problems with software bugs, integration issues, and long-term maintenance, it’s also going to be a nightmare for computer security.
Yes, computer security. In the modern era, when cheap Chinese webcams have been used to mount massive denial of service attacks, it’s legitimate to consider how our cars should be resistant to external exploitation.
Consider the last time you rented a car; you had no idea where it’s been. The prior driver’s poor taste in music or incomprehensible seating position is only the start of your problems when we’re talking about the car’s computers. Would you connect your phone with that car?
The magic of having a standardized connection between your phone and the car, if it’s done right, is that you have a narrow interface between the evil, sharp, dangerous world of smartphones and the safe, fluffy, every-component-is-a-special-snowflake world of the automotive CAN bus, wherein any component can issue nasty commands to any other; see for example this lovely security analysis of J1939 communications used in big trucks and other heavy equipment. The car-side support for Android Auto and Apple CarPlay can be small and carefully engineered. It can shield the car from evil phone behaviors. At the same time, the car/phone communication protocol can be sufficiently full-featured to pass along screen touches, wheel telemetry, and other goodies to make your smartphone nav work better than it could do alone. Likewise, the security-sensitive software on the phone can and will be updated all the time. Software in the car, at least for most cars, is rarely updated.
Computer security is a process. No software is ever perfect out of the gate, and carmakers don’t generally have the processes or mindset to deal with this. After all, it took GM five years to fix the security vulnerabilities reported to them by a joint UCSD / U. Washington team. (Check out our TTAC coverage from 2011.)
In short, everything about SDL seems to fly against Hoare’s keep it simple maxim. Inside the car, SDL places a full-blown web browser supporting the HMI. SDL includes a giant pile of C++ implementing the SDL Core. And how aggressive will the automakers be at rolling out monthly security patches for decade-old cars? How well do you trust them to debug and test their internal software against all the external phone apps that will be communicating with it now and in the future?
In computer security lingo, SDL has a massive attack surface. In military lingo, SDL is a target-rich environment. Keep it simple! It’s the only way.
Dan Wallach is a Professor in the Department of Computer Science and a Rice Scholar at the Baker Institute for Public Policy at Rice University in Houston, Texas. His research concerns computer systems security, he harangues Rice CS sophomores to “write beautiful code,” and he’s really bothered the new Honda Civic Hatchback doesn’t let you get a manual transmission and Android Auto at the same time.