You have to feel for the developer here, they knew they were taking a risk in using an unauthorized API, but they went for it anyway and now they are facing the music.

I understand Apple's position here, especially with APIs that control vehicles. It's just a sad fact that Tesla hasn't provided a safe public API to control their cars.

> to control their cars.

This sentence scars the bejeebus out of me to think this could even be a thing. If you mean to control things like entertainment system, then maybe i'm okay with that. But I would not consider that controlling the car

IIRC, GMC was hacked using an exploit in their Bluetooth stack in the entertainment system through which they got access to OBD controller. All parts of the car are more interconnected than what people generally think. From a security standpoint, remote opens up a wide attack surface.

Allowing the API to exist but not allowing people to use it does not close that attack surface.

It's not driving it. It's controlling the entertainment system, which includes things like AC/heater, charging or not (you have to be plugged in), closing or cracking the sunroof, looking at the state of charge. You can also unlock the doors. You have to get an otp token based on your name and password. People reverse engineered the tesla api from looking at what the app does. There are two concerns I have with the tesla system.

1. They only allow for tokens that take a very long time to expire, it's something like 3 months.

2. Although a few of these apps allow you to get the token on your own and send it to them (thus not exposing your password), that's too technically demanding for most users and so most of the apps have you get a token by giving your email/password, thus you expose it to them.

For those that don't know, Tesla pays people for security vulnerabilities, welcomes hacker attempts, they disclose things after they fix them, there's a list of the things and people who found them at their website, etc. There is a separate computer system for the drive train that is not accessible through this system.

Imagine some malware infecting the fleet that decides to take them all out for a joy ride on the same day.

Yeah, imagine

What exactly is unsafe about their API now? It's not like you can drive the car with it.

I think you are underestimating what the electronics on the car control. The speed, the breaks and how they behave. when you crash, the airbags, the cooling system, how the steering wheel moves, etc...

It might not be able to drive itself, but it can definitely control how fast and its direction, which would be super scary for some random dev to have any impact on.

I use the api and there’s none of that in the api which is why I ask. It sounds like you’re just guessing it’s something it can do. The only thing that allows the car to be driven with is summon mode but that requires you to be within a set range and as far as I know hasn’t been reverse engineered.

That's correct, the drivetrain is completely separate from what you can access from the outside.

Tesla did not create, nor "owns" the API. And if the API is open such that anyone can use, it seems the developer does have permissions to use the API. If we require that every single entity between a mesh of APIs and all of the data or systems they control must give permission, this is simply unworkable. It's APIs all the way down.

Frankly, this is Apple arbitrarily choosing apps they don't like and findng a loophole to block it.

What would motivate Apple to interfere in a third-party relationship business between the Developer and Tesla (as if that is not a trade violation)? Aren’t Apple Developers requires to indemnify Apple against all claims related to their apps?

>What would motivate Apple to interfere in a third-party relationship business between the Developer and Tesla

Who guarantees there even is a "third-party relationship business between the Developer and Tesla"?

Should Apple let any app that claims to have one or be officially sanctioned or whatever dupe customers?

In contract law, “third party” is a term of art meaning a party which is not a party to the contract. So the fact that Tesla is not a party to the developer’s agreement with Apple makes it a third party.

>In contract law, “third party” is a term of art

Next thing you'll tell me there's a Sanity Clause, with little elves helping him, etc.

Yeah, I know. My question is: "who guaranteers that the app maker has any agreement with Tesla"?

One could release an app claiming so, without Tesla approval, and do shady stuff -- where Apple gets part of the blame from customers.

Legal security? Theoretically Tesla can go after Apple for permitting 3rd parties access to Tesla’s APIs. AFAIK, API access to Tesla’s cars has been reverse-engineered and isn’t something Tesla publishes themselves so there could me DMCA issues, too. Not trying to state what is actually legal or not but rather Maybe Apple is trying to play it real safe.

I guess on top of that Tesla could stop supporting the API any day, creating a bad user experience.

That literally applies to something like 90% of apps.

This isn’t really new.

Historically Apple has always required consent for using such APIs and in many cases that’s a result of the API owner complaining.

I came across a remote control app getting rejected months ago for using an unofficial TV API.

A workaround would be to implement your own backend that forward requests to the unofficial 3rd party API.

Or would Apple also block such a thing?

I think that's the case already? He's communicating with some unauthorized API that's hosted on a third party.

Apple's argument is that they know that there's no official API so his can't be legal.

Hmm, I doubt that is the case. It’s almost certain they are using TeslaSwift, an open source swift implementation that communicates directly with Tesla’s own private APIs.

It’s quite common for you to instead do such a thing, since the cost of hosting such a service is nothing for you. The APIs are also extremely stable, so it’s not like Tesla is going to pull the rug from under you.

The only benefit of layering your own API on top of Tesla’s would be some sort of data collection.

"I'm accessing API of RealSweetSolutions GMBH as far as I know. It is impossible for me to know their relationship with Apple".

Sure, that's what I thought too, but at the end of the day it is a judgement call from Apple, if they think you're hiding your use of unofficial APIs, I guess they will also deny your updates...

So much power in a company is really scary IMHO.

Oh, I see, then I misunderstood their situation. Thanks for clarifying.

Would there be any way for them to know whether you're doing it, apart from noticing that certain responses your backend seem similar to those from another API?

They could take a guess that myapp.com shouldn’t have control over a Tesla. It’s publicly verifiable that Tesla doesn’t provide official API documentation or access to 3rd-party developers.

Since the app in question here allows users to send commands to their Tesla vehicles, it seems like Apple’s decision could be connected to their deeper integration with vehicles through Car Key (https://support.apple.com/en-us/HT211234).

After reading, this seems_very common_ and it seems like an odd app you single out... After reading about commenter about Apple having a competing technology (Car Key), this makes a lot more sense why Apple is singling this person out.

Doesn't seem legal in France, where there is the right to reverse engineer APIs for interoperability.

The title should be updated with "written consent for usage of unofficial third-party APIs"

I’d like to see what happens if someone like IFTTT is forced to do this...

IFTTT uses officially supported APIs though. They had to remove some Facebook integration functionality when Facebook deprecated the APIs that they were using.

Is there room here for an official intermediary? e.g. a device with a public API that your watch could connect to, and that could interface with other open APIs?

Isn't this similar to the Oracle-Google API dispute that has gone to the US Supreme Court?

EU has already ruled that APIs are not subject to copyright, https://econsultancy.com/will-the-oracle-google-lawsuit-kill...

But in that case nobody was accessing a service. If I use Tesla’s servers/service without permission in my app, then they could legally terminate my access (or, perhaps try to get it taken off the App Store). If I simply reimplement the Tesla service myself (even though that’d be useless with a production car unless you rewrote the telemetry stuff), they can’t sue me under the Oracle-Google decision, as I understand it.

I don't think this is the same issue. From what I understand, the Tesla api is accessed through Tesla's servers via a remote api service run by Tesla, and not by directly interacting with the car itself.

_Technically_ it is a crime to access a remote computer without permission -- Computer Fraud and Abuse Act [1].

[1]: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

No. In this case it's about permission to use a network-accessible service, not about copying a header file / interface definition or other code.

In the wiki article, this deals with the "Remote APIs" definition, not the "Libraries and frameworks" definition. https://en.wikipedia.org/wiki/API#Usage