Dr. Lance Eliot, AI Insider
API’s have become the darling of the high-tech software world. There are conferences devoted to the topic of API’s. Non-tech business-oriented magazines and journals gush about the importance of API’s. Anyone that makes a software package nowadays is nearly forced into providing API’s.
It’s the rise of the Application Programming Interface (API).
Rather than being something magical, it’s actually just the providing of a portal into a software system that otherwise might be difficult to communicate with. One major advantage of a portal is that it can allow various extensions that can add-on to the software system and go beyond what the original software system itself can accomplish.
You can also interface to the original software system and allow it to become interconnected with other software.
And, you can avoid potentially having to redevelop the wheel, so to speak, by leveraging whatever capabilities the original software system has.
Some would say it also allows the software to be at a higher level of abstraction.
I’ve written extensively about API’s for AI systems, which you can read about in Chapter 3 and Chapter 4 of my book “AI Guardian Angel Bots for Deep AI Trustworthiness: Practical Advances in Artificial Intelligence (AI) and Machine Learning” (available on Amazon at https://www.amazon.com/Guardian-Angel-Bots-Deep-Trustworthiness/dp/0692800611)
By providing a healthy set of API’s, the developers of the original software system are able to encourage the emergence of a third-party add-on ecosystem. This in turn will help make the original software system more popular as others connect to it and rely upon it.
With great promise often comes great peril.
In the case of API’s, there is a chance that the use of the API’s can boomerang on a company that made the original software system. These portals can be used as intended and yet cause undesirable results, along with them being used for unintended nefarious reasons and also causing undesirable results.
Hackers Love API’s
As you might guess, hackers love it when there are API’s.
It gives them hope that there might be a means to sneakily “break into” a system.
How could that happen?
Wouldn’t the API’s get as much scrutiny as the rest of the system in terms of becoming secure?
The answer is that no, the API’s often don’t get as much scrutiny. The perception of the company making the software is that the API’s are some kind of techie detail and there’s no need to make sure those are tight.
API’s are often classified into these three groupings:
API’s that are considered private are usually intended to be used solely by the firm making the software.
API’s that are oriented toward partners are intended to be used by allied firms that the firm making the software decides to cut some kind of deal with.
API’s of a public nature are intended to be used by anyone that wants to access the software. These are often very limited in their access capabilities and are considered potential threats to the system.
What sometimes happens is that a firm provides say public API’s, and secretly has partner API’s and private API’s. Those developers that opt to use the public API’s become curious about the partner API’s, and either figure them out on their own, or convince a partner to leak details about what they are. If the partner API’s can be used, the next step is to go after the private API’s. It can become a stepwise progression to figuring out the whole set of API’s.
The API’s are often classified into whether they do this:
- Perform an action
- Provide object access
Let’s consider first the performing an action type of API.
This allows an app invoking the API to request that the original software perform an action that has been made available via the API.
How does this apply to AI self-driving driverless autonomous cars?
At the Cybernetic AI Self-Driving Car Institute, we are developing AI software for self-driving cars. This includes providing API’s, and also involves making use of API’s provided by other allied software systems and components.
If you’ve ever played with the API for the Tesla, you likely know that you can get access to vehicle information, vehicle settings, and the like. You can also invoke actions such as honking the horn, waking up the car, starting the charging of the car, setting the car climate controls, open the trunk, and so on. It’s fun and exciting to create your own mobile app to do these things. That being said, there is already a mobile app provided by Tesla that does these things, so it really doesn’t payoff to create them yourself, other than the personal satisfaction involved and also to explore the nature of API’s on cars, or if you are trying to develop your own third-party app and want to avoid or circumvent the official one.
One of the crucial aspects about API’s for cars is that a car is a life-or-death matter.
It’s one thing to provide API’s to an on-board entertainment center, allowing you to write an app that can connect to it and play your favorite songs. Not much of a life or death matter there. On the other hand, if the car provides API’s that allow for actual car controls aspects, it could be something much more dangerous and of concern.
Now that I’ve dragged you through the fundamentals of API’s, it gets us to some important points:
- What kind of API’s, if any, should an AI self-driving car provide?
- If the API’s are provided for an AI self-driving car, how will they be protected from misuse?
- If the API’s are provided for an AI self-driving car, how will they be tested to ensure their veracity?
Some auto makers and tech firms are indicating they will not provide any API’s regarding their AI self-driving cars. That’s their prerogative and we’ll have to see if that’s a good strategy.
Some are making private API’s and trying to be secretive about it. The question always arises, how can you keep it secret and what happens if the secret gets discovered.
Some are making partner API’s and letting their various business partners know about it. This can be handy, though as mentioned earlier it might start other third-parties down the path of figuring out the partner API’s and then next aiming at the private API’s.
Overall, it’s a mixed bag as to the various AI self-driving car firms are opting to deal with API’s.
There can be API’s for the on-board systems of the self-driving car, and there can be other API’s for the cloud-based system of the self-driving car. Most AI self-driving cars are going to have OTA (Over The Air) capabilities to interact with a cloud-based system established by the auto maker or tech firm. From a third-party perspective, it would be handy to be able to communicate with the software that’s in the cloud over OTA, in addition to the software that’s on-board the self-driving car.
Some AI developers think it is crazy talk to allow API’s for the self-driving car on-board systems. They believe that the on-board systems are sacrosanct and that nobody but nobody should be poking around in them.
There are some auto makers and tech firms that want to provide API’s, which they do so in hopes that their AI self-driving car will become more popular than their competition.
Innocent API’s Promise Not to Endanger
It is believed by some that the API’s can be provided for aspects that don’t endanger the self-driving car and its occupants, these are so-called innocent API’s.
Suppose for example that the API’s only allow for retrieval of information from the AI and the self-driving car. This presumably would prevent someone from getting the AI self-driving car to perform an undue action.
Another viewpoint is that it is Okay to allow for action performing API’s, but those API’s would be constrained to only narrow and presumably safe actions. Suppose you have an API that allows for honking the horn or for flashing the lights of the car? Those seem innocuous.
If there was an API for the retrieval of information from the sensors data collection and interpretation, this would seem to be innocuous. Indeed, it might allow a clever third-party to develop add-on’s that could do some impressive augmentation to the sensor analysis. You could potentially also grab the data and push it through other machine learning models to try and find better ways to interpret the data. As mentioned before, this could though have privacy and other complications.
The API’s are often setup with authentication that requires any connecting system to have proper authority to access the API. This is a handy and important security feature. That being said, it is not necessarily an impenetrable barrier to still use the API.
Will AI self-driving car makers provide API’s?
Will they provide SDK’s (Software Development Kits)?
Will they discourage or encourage so-called “hot wiring” of AI self-driving cars?
Without such API’s, presumably the AI self-driving car might be safer, but will it also lose out on the possible bonanza of all sorts of third-party add-ons that will make your AI self-driving car superior to others and become the defacto standard AI self-driving car that everyone wants.
We’ll have to wait and see how the API wars plays out.
For free podcast of this story, visit: http://ai-selfdriving-cars.libsyn.com/website
The podcasts are also available on Spotify, iTunes, iHeartRadio, etc.
More info about AI self-driving cars, see: www.ai-selfdriving-cars.guru
To follow Lance Eliot on Twitter: https://twitter.com/@LanceEliot
For his Forbes.com blog, see: https://forbes.com/sites/lanceeliot/
For his Medium blog, see: https://firstname.lastname@example.org
For Dr. Eliot’s books, see: https://www.amazon.com/author/lanceeliot
Copyright © 2019 Dr. Lance B. Eliot