@HankLloydRight & @supratachophobia , you have some bright minds. I like the idea, a lot. You could refactor all direct Tesla service communications to a custom, 3rd party service that you have more control over that is always-on, allowing you to schedule services independent of the platform, and even allow you to turn your device completely off or not have internet connection and still trust they'll function. This would, as you've said, make the Android or iOS app interface with the 3rd party service instead of the Tesla service directly. There would be no noticeable change to the end-user, just better functionality. You could then provide a web-app as well and visit it from within the car to turn on/off camper mode, for example.
I could update Dashboard for Tesla to use this new service relatively quickly, migrating the background services over would be the most difficult.
Essentially it's the holy grail, and I see immense value there worth looking into further, especially considering iOS's limitations moving forward.
However, there are some downsides immediately apparent to me. All your commands, credentials, network activity is being ran thru a 3rd-party service, meaning you need to have complete trust in that 3rd-party with your information because you have no visibility into what they're doing with it, or how they're storing it. This goes a step beyond this 3rd-party app I've developed here that simply interfaces with Tesla's servers better than the official app because at least then your private information does not touch my private servers where you have zero visibility.
Trust, but verify. You can trust Dashboard for Tesla, then verify it by sniffing the network traffic of the app and ensure I'm communicating all data in-and-out of the app in accordance with my privacy policy, but in any case you SHOULD be concerned if I'm posting your private details to a non-Tesla server (I'm not!). With the 3rd party service always-on approach, you can't verify, all you can do is trust. At some point though, with enough respect, transparency, time and happy customers, the trust is earned.
This would be a serious undertaking, but with serious perks. I'll likely pick it back up once I'm satisfied with the state of Dashboard for Tesla and am looking into the iOS expansion. In the meantime, Smart charging is almost complete and I'll have that out here in a few days.
I could update Dashboard for Tesla to use this new service relatively quickly, migrating the background services over would be the most difficult.
Essentially it's the holy grail, and I see immense value there worth looking into further, especially considering iOS's limitations moving forward.
However, there are some downsides immediately apparent to me. All your commands, credentials, network activity is being ran thru a 3rd-party service, meaning you need to have complete trust in that 3rd-party with your information because you have no visibility into what they're doing with it, or how they're storing it. This goes a step beyond this 3rd-party app I've developed here that simply interfaces with Tesla's servers better than the official app because at least then your private information does not touch my private servers where you have zero visibility.
Trust, but verify. You can trust Dashboard for Tesla, then verify it by sniffing the network traffic of the app and ensure I'm communicating all data in-and-out of the app in accordance with my privacy policy, but in any case you SHOULD be concerned if I'm posting your private details to a non-Tesla server (I'm not!). With the 3rd party service always-on approach, you can't verify, all you can do is trust. At some point though, with enough respect, transparency, time and happy customers, the trust is earned.
This would be a serious undertaking, but with serious perks. I'll likely pick it back up once I'm satisfied with the state of Dashboard for Tesla and am looking into the iOS expansion. In the meantime, Smart charging is almost complete and I'll have that out here in a few days.
@1101011 , interesting read, but yes by the very nature of the functionalities exposed by Tesla, it cannot be helped that if someone were to gain access to your My Tesla account that they could very well locate your car, unlock it, then enable keyless driving. Shoot even have the HVAC turned on so it's nice and toasty for them.
This is just puts more weight on your cyber security, and how you should or shouldn't conduct yourself online. In that particular case, somebody downloaded a modified Tesla app that would send their private data to a 3rd party service. Tesla's official app takes steps to prevent network traffic sniffing of their app using certificate pinning, but they can't do anything about somebody distributing a modified version of their app through 3rd party channels.
Steps I recommend to ensure safety going forward for everyone - only download and install apps (APKs) through trusted distribution channels (Play Store, Amazon, etc), this prevents hackers masquerading as Tesla Motors from tricking you into thinking you're getting the genuine Tesla Motors app.
If you want complete security, you'd have to disable Mobile Access in the car.
This is just puts more weight on your cyber security, and how you should or shouldn't conduct yourself online. In that particular case, somebody downloaded a modified Tesla app that would send their private data to a 3rd party service. Tesla's official app takes steps to prevent network traffic sniffing of their app using certificate pinning, but they can't do anything about somebody distributing a modified version of their app through 3rd party channels.
Steps I recommend to ensure safety going forward for everyone - only download and install apps (APKs) through trusted distribution channels (Play Store, Amazon, etc), this prevents hackers masquerading as Tesla Motors from tricking you into thinking you're getting the genuine Tesla Motors app.
If you want complete security, you'd have to disable Mobile Access in the car.
Last edited:
Ahh, I see. You are wondering why he can't setup server side scripts to control the car, regardless of app platform. I would imagine he doesn't want the infrastructure or the credential liability (more so than he has already).
@SG57 , in light of the recent Android malware, how would moving to a strictly token system with a per device restriction work? In other words, we somehow provide the token that's good for however long, but it's only authorized from that device. That way, a different device or phone can't use the same token? Just thinking out loud here. And regarding fingerprints to start the car, who has my mytesla password? The app, my android device, or some server side variable? Thanks.
From the article: "But at bottom, the flaw highlighted by Promon was in an outdated version of Android, not in the Tesla app itself."
Mostly I think an awareness of how this app functions allows users a great level of comfort. The openness with which @SG57 discusses his process is most admirable.
Looking forward to enhanced features. And isn't that what Tesla ownership is all about?
Not to sound like a dick, but I will anyway. iOS has Remote S for now, plus all the love Tesla gave you for the stock app for the first couple years. It's time to let Android have some space in the limelight.
We'll both be getting some bells and whistles with 8.1, and I'm sure this app will come to iOS eventually. For now, let him figure out the full extent of what can be done on Android. @SG57 sounds like he has enough knowledge of app development to port over what he can when the time comes.
@supratachophobia , I can verify Close and Vent are the only valid states to move the pano roof to now using the official APIs as of right now.
Originally, you could send the command to move the pano roof to either closed, vent, comfort, open or a custom percentage state. All have been removed except the first 2 in that list as of right now.
I'll be releasing a tweak to the sun roof control when Smart charging is released to address this sad change.
Originally, you could send the command to move the pano roof to either closed, vent, comfort, open or a custom percentage state. All have been removed except the first 2 in that list as of right now.
I'll be releasing a tweak to the sun roof control when Smart charging is released to address this sad change.
SomeJoe7777
Marginally-Known Member
I'm a 1-person programmer who has released freeware and shareware myself, and I've designed one that had functionality that needed to run on a server, away from the user's device/platform. As soon as your application requires that, you start to run into ongoing costs, scalability concerns, uptime and availability concerns, and if user data is involved, then backup and security concerns.
That's a lot of burden for a 1-person programmer, especially in this day and age where software's retail pricing has a very low ceiling, above which no one will buy it no matter how good it is.
To keep costs low and the other concerns out of the picture, pushing as much (or all) functionality to the user's device/platform is generally the way you have to design apps these days.
Clearly, the iOS version of this app can realize the same functionality as the Android app, but a back-end server to run the background tasks would be needed. If SG57 was willing to do that, he'd be well within his right to price the iOS version higher or price it on a subscription basis to compensate for the increased ongoing costs. Security is a big one here, because at a minimum, the server has to keep user's Tesla login tokens available to communicate with their vehicles. Compromise of the server would result in compromise of all user's vehicles. You begin to see now not only the increasing costs and complexity, but increasing responsibility that a 1-person programmer may not want to accept. Seriously, one all-too-human error in his code could result in multiple vehicle thefts.
HankLloydRight
No Roads
I'm also a one-person programmer, and I run three different online businesses using this model (soon to be four), and yes, on a subscription basis. And that includes running my own co-lo datacenter, with backup, security, and full redundancy.
No, it's not easy, but I've been doing it for more than 15 years now. But it's certainly doable if you know what you're doing.
Also, IMHO "pushing it to the device platform" has it's own massive suite of problems supporting thousands of different configurations, OS updates, app store and device policy changes, etc, etc, etc.... with a server based solution, you only have to worry about one platform which you have complete control over.
HankLloydRight
No Roads
But that's also true of Teslalog, TeslaFi, EVMote (now defunct), and even my own site EV-FW.com which stores tokens to track firmware updates. So lots of "one man-programmers" are already taking on those tasks and responsibilities. Maybe it makes sense for Dashboard to work with one of these existing server-based apps to implement the necessary scheduling processes.
SomeJoe7777
Marginally-Known Member
It's true, there are certain advantages to putting functionality at the server level vice at the device -- like you mentioned: different phones, OS versions, policies, etc. means that the less code at the device, the easier it is to deal with all of that.
The right solution for any 1-person programmer is dependent on the resources he has available. When I have released shareware and freeware stuff, it was things I did in my spare time. I have my own business that uses most of my time, so anything that starts to consume ongoing time with the shareware/freeware doesn't work for me.
My Tesla Winds site is a good example: I coded it intermittently over a couple weeks and it runs on an Amazon EC2 free instance. No ongoing costs, no personal data, reasonably secure, and no ongoing maintenance except when I want to add features. Those are the types of projects I'm able to work on. I could build other things that are a lot more involved with a lot more features, but I just don't have that kind of time anymore.
The right solution for any 1-person programmer is dependent on the resources he has available. When I have released shareware and freeware stuff, it was things I did in my spare time. I have my own business that uses most of my time, so anything that starts to consume ongoing time with the shareware/freeware doesn't work for me.
My Tesla Winds site is a good example: I coded it intermittently over a couple weeks and it runs on an Amazon EC2 free instance. No ongoing costs, no personal data, reasonably secure, and no ongoing maintenance except when I want to add features. Those are the types of projects I'm able to work on. I could build other things that are a lot more involved with a lot more features, but I just don't have that kind of time anymore.
SomeJoe7777
Marginally-Known Member
@HankLloydRight,
By the way, my post above wasn't really specifically replying to you. I know you run the ev-fw.com site as well as several others, so you're very aware of all these issues. My post was meant to comment to others in the thread who may not be programmers of how involved some of these small projects can get and how they can quickly grow beyond the resources of the 1-person programmer.
By the way, my post above wasn't really specifically replying to you. I know you run the ev-fw.com site as well as several others, so you're very aware of all these issues. My post was meant to comment to others in the thread who may not be programmers of how involved some of these small projects can get and how they can quickly grow beyond the resources of the 1-person programmer.
HankLloydRight
No Roads
I like seeing so many developers on these forums, so much talent in one place.
I had no idea you had so much going on, managing multiple successful operations of any magnitude is taxing. Thanks for your service
I had no idea you had so much going on, managing multiple successful operations of any magnitude is taxing. Thanks for your service
Similar threads
