End of free API access?

[rileymd88]

Today Tesla launched their official API and also mentioned that they have plans to deprecate the owners API. I am a bit worried as it seems like they want to charge for API access in the future. You can read more about it here:

https://developer.tesla.com/docs/fleet-api
https://developer.tesla.com/docs/fleet-api#membership-tiers

What does everyone here think?

[cwanja]

#3364 has some on going comments. The Fleet API seems separate than the owners API, at least the URLs are - from my quick glance, not a developer. The posts references 'commands' and not streaming data.

TeslaScope X feed seems to go the other route.

[pradeeppattamatta]

From what I see, The approach would be the same as outlined in fleet-api. The Readme from this new Vehicle Command SDK is pointing to fleet-api docs about process to get the OAuth tokens.

[kimmilde]

2023-10-09: Rest API vehicle commands endpoint - deprecation warning

Following the release of Tesla Vehicle Command SDK support for REST API vehicle command endpoints is now reaching end of life. Starting 2024 most vehicles will require sending commands via Tesla Vehicle Command SDK.

[chiflux]

Well, as long as there is a Tesla App for owners, there must be an API that offers the same functions as the Tesla App. It must somehow work with your normal Tesla Account Credentials but it could require some additional device-specific encryption for authorization. The latter could make it (depending on the implementation) complicated or practically impossible to use the API outside the App.

[eiannone]

If TM will continue to impersonate Tesla app, maybe we just need to find the client_id and client_secret strings, which will be probably stored somewhere inside the app, and use them to access the Fleet API, like it was some years ago with old app versions.
Looking at the Fleet API documentation, I don't see any particular encryption tied to the device.

[brianmay]

I believe the fleet API is also deprecated. The new API is a protobuf based protocol, very different from the owner API or fleet API, which are both based on json.

Which means that docs people are pointing to regarding the fleet API, and membership tiers for fleet API, may be misleading.

[brianmay]

Just noticed, that I cannot find the original *.proto files for the new API, only the translations in go: https://github.com/teslamotors/vehicle-command/tree/e1ca5088e3c55f85c7c3f251dd306181520e4afc/pkg/protocol/protobuf

I do see some *.proto files here, but suspect this is not what we want: https://github.com/teslamotors/fleet-telemetry/tree/main/protos

These proto files are required to support other languages. While it might be possible to reverse engineer the go files, not something I want to do.

No idea how good protobuf support is in Elixir, but see https://github.com/elixir-protobuf/protobuf

[brianmay]

End-to-end command authentication

I can understand the desire for "end-to-end command authentication". Which I think means commands are signed by the user and then sent all the way and checked by the car. I think the API without end-to-end command authentication means if somebody broke into https://owner-api.teslamotors.com and/or https://owner-api.vn.cloud.tesla.cn then they could send commands to any car in the world. Which makes this hosts are prime attack point. And bad publicity. "You knew about this but did nothing?" I imagine this change would mean attackers now would have to break into the auth servers too[1], which presumably is a very separate and distinct system security wise.

The change in itself isn't what was got me upset here. Rather the lack of information. And the timing - is Tesla going to try to make this a paid API? Are they going to try to rate limit free users that just want to do things with their own cars? And the fact they don't appear to have published the *.proto files (wonder if this was accidental or deliberate). Or any information on how to use the new protocol, apart from the open source code in go.

This signature checking is in addition to the existing oauth server side checks. So having just the private key by itself is not sufficient. If you did break into the server (e.g. proxy server), you could gain immediate access to the private key, and then wait for somebody to send you a valid token. The server holding the private key really needs to be secure as possible, especially if there are a number of cars that have the associated public key. Because typically, unlike tokens, the private key will last longer. Actually I don't see any information on if/when they expire, might be the case the only expire if you replace/delete the public key in the car, which requires you know about the breach.

Teslamate

My growing, unproven, suspicion is we can change Teslamate to point to a local instance of the HTTP proxy server. This will be required for all /api/1/vehicles/* endpoints. Which excludes auth and streaming endpoints, which I think are not changing.

My feeling is we should conduct some tests against the HTTP proxy, see if it works or not.

I think there is some confusion regarding owners API vs fleet API, but for the APIs we use I think they are the same thing. Except the endpoint is different (irrelevant for proxy). So the fact the proxy supports the fleet API presumably means it supports the API calls we need (most notably /api/1/vehicles/:id/vehicle_data), and it should work.

And looking at the proxy code, I believe it will transparently forward requests to the old API if the car doesn't support the new API.

Public/private key management

The immediate painful part may be the management of the private/public keys. As Teslamate is open source, distributed software, we cannot generate a Teslamate private key and distribute that[2], each user would need their own private/public key, and somehow supply to their cars. But it looks like each public key distributed needs its own DNS domain. You need to put the key at https://<your domain>/.well-known/appspecific/com.tesla.3p.public-key.pem. This could be a big stumbling point for Teslamate users.

I think so far, Tesla hasn't really considered the open source community. Which is not surprising really. You should be able to load your own public keys on to your own car without involving "the cloud". If that is possible, it is not documented.

Notes:

[1] While this solves one problem, I don't think it solves the other problem that Tesla have a huge amount of stored data about the cars. So the above hosts would still be a prime attack target.
[2] In theory we could set up a Teslamate, http proxy server that has the private key, but no, I think keeping this system up and running, trusted by all Teslamate users, and secure (think of legal liability issues if server security is breached and cars get stolen) is beyond the scope of what we can do.

[havekes]

You suggest changing Teslamate to point to the local http proxy server and I'd like to test that. I should be able to setup Tesla's http proxy on my own but I have no idea where to start when it comes to TM. I suppose it is something that could be added as a configuration?

[brianmay]

Basically read the instructions here: https://github.com/teslamotors/vehicle-command/

Currently the Tesla API endpoint is hard-coded: I think you would need to change the references in this file https://github.com/teslamate-org/teslamate/blob/master/lib/tesla_api/vehicle.ex

(assuming you do not need to update the auth or streaming API endpoints, which is my current understanding)

[havekes]

Thanks for pointing me to the correct file for changing the endpoint (I know nothing about Elixir unfortunately).
I'll let you know how my testing goes

[brianmay]

The documented device data limits do concern me: https://developer.tesla.com/docs/fleet-api#membership-tiers - even if they don't affect as right now.

Not even clear what counts as an API request. Failed attempts? Attempts that return cached data without going to the car?

Teslamate I think relies heavily on polling (because the streaming API is very restricted), and as a result I think it could easily exceed the 1 request every 5 minutes. Particularly if/when the vehicle is asleep - I think we poll every 30 seconds (but maybe these requests don't count?).

[eiannone]

Yes, those limits are very restricting.
I wonder if they will also be applied to the official app. If it's not the case, maybe we could try to use its credentials.