deonb
Active Member
So, the API in the original iPhone SDK was public? The one hacked together by the community by jail breaking the first iPhone 2Gs, then reverse-compiling header files from the objects and resources?
I have a different definition of public. I call that an unauthorized API, or a private API, because I don't think the owner of the API should be held responsible for <B>flaws that only appear when the API is not used as intended</B>.
Would you hold Microsoft to that same standard? 90% of Windows security exploits are in private API's. So should we just disregard those and say Windows is perfect because hackers aren't using the API as intended so no flaws actually exist in Windows? No? So why hold Tesla to a different standard?
Whether the API was initially intended as private or not, it doesn't matter now. Tesla knows the API is out there. They've not done anything to close it down. They've promoted apps based on it. If they change it now, users will get upset if Tesla breaks their apps. And trying to then blame the users for using those app in the first place isn't going to win Tesla any popularity contests either, especially with Elon going on and on about how he's a fan of open source and against proprietary patents. It may not have been public initially, but it sure has to be treated like that now.
The whole principle of designing an API for private use is anyway flawed. Inevitably the shortcuts you take by thinking it is private comes back and bite you in the butt. Somebody out there is going to reverse engineer it and now you're stuck with a badly designed API that you now have to support in perpetuity. Not only that, but by keeping it private, you don't have a lot of eyes looking at it, which means you're going to make mistakes. You should just design every API in the first place as if you're going to publish it on google.com's homepage.
So I wholeheartedly agree with nspollution. The Tesla REST API is flawed. Badly.
Do you realize how little work it will be for a hacker to exploit this? All they need to do is create a really compelling app or site that gives users a few cool features (track battery life over time, historical location, whatever), spend a little money promoting it, and they'll easily get a few 100 users signing up. But why would a hacker go through that trouble and expense? Oh, let's say for a few thousand 50% out of the money puts that will become in the money the moment you have a 100s of cars misbehaving in unison from an exploit that will be so well published it will make the current "Short Tesla" movement look like something created by Sal Demir. At that point all the blame in the world for users being so "stupid" as to give their usernames and passwords to a 3rd party site doesn't help you with TSLA trading at $70.
There shouldn't be an API that takes a username/password in the first place that will enable this.
Usernames/passwords lead people into a false sense of security. They think by providing credentials, it somehow protects them - especially if they can see a visible side effect. (Logical fallacy: 'Site X' takes my username & password and displays my account balance. Only my bank would know my account balance. Hence 'Site X' is my bank.).
Case and point - there are WiFi hotspots out there that use a pre-shared WEP or WPA key. You go to the front desk, you get a key that you can use for some time. The purpose of the key is to protect the hotspot from users that don't pay for the service. HOWEVER, that's not what users think - they assume the key will mean the network they connect to is legit. Except that it so doesn't mean that. Try the following experiment the next time you're in such a hotspot: Bring up an open WiFi hotspot, and see if anybody connects to you - chances are nobody will. Now enable authentication and use the same pre-shared key from the front desk and route traffic to their real network. Your hotspot will become very popular very quickly. It's the easiest MiTM attack in the world, all because users think that because they entered a password they must be safe. And a MiTM attack on a hotel hotspot trivially gives you a credit card number.
I know it's mindboggling to us, but there are users out there who bought a Model S, but doesn't know you can change the % of charge (was in another thread posted earlier this month. I forget which.). That same user isn't going to think twice about entering his credentials into some mytesla.com site and use a cool map to see where he's been in the last few months and how much electricity he used to get there.
The way out for Tesla is to provide a different mechanism as soon as they can, publish it as wide as they can, and retire the existing one.
My background: I've created and shipped 100s of API's that are used by thousands of developers and hundreds of millions of end-users daily. The most well known (by end-users) are the Wireless API's that has shipped inside Windows since XP SP2 until today. If you've used a wireless network on a PC, you've used something that was built on an API that I designed. And yes, I've also gone through the whole cycle of patching a security exploit that I caused (in a private API nonetheless) - it's not a good feeling, but it's something I've learned from. Tesla still has a LOT to learn.