Not knowing what percentage of the active TMC membership already participates I don't know for sure if it would significantly increase or not but in my experience it should. In any case your right about passing this token outside of TMC's domain to your servers. I wouldn't allow it if I were them either, they would have to host it which is likely a resource problem.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Firmware 7.0
- Thread starter MarcG
- Start date
Not knowing what percentage of the active TMC membership already participates I don't know for sure if it would significantly increase or not but in my experience it should. In any case your right about passing this token outside of TMC's domain to your servers. I wouldn't allow it if I were them either, they would have to host it which is likely a resource problem.
Andyw2100
Well-Known Member
I think you're never going to be able to please 100% of the people. Trying to please a very small percentage of unreasonable people is probably just a waste of time. Better to just let them go.
Khatsalano
Member
Because it's simply one more step and life is too busy as is. Sorry. I sincerely appreciate the work though and obviously we all benefit.
Hank's insight sounds reasonable-- that without some authentication step, the data would soon be unreliable. No solution will encourage the entire user base to participate. For me, I guess I just fall on that side of the line because it requires one more step and a PIN.
- K
Cyclone
Cyclonic Member ((.oO))
Meanwhile, I just had my password general use a random pin that auto-fills when I go to the site.
HankLloydRight
No Roads
OK, after seeing too many posts on something so silly, I regret being the guy to bring it up in the first place. I understand site needs to be secured, and a PIN is the least intrusive security. Should not be an obstacle to anyone. Can we stop?
@Hank - Have you ever seen the 3rd party Chevy Volt stats site? Basically people login to their OnStar accounts on the site (originally with voltstats saving the password, and more recently with auth tokens with OnStar's blessing), and then a couple of times per day the site polls the API and gets stats about your car and saves them.
I was wanting to do something similar for the Model S a while back, but never got around to it. But, I realized that a side effect would be that such a site could track firmware updates automatically, along with vehicle configurations and such.
Given that the Tesla API supports keyless driving if you have the owner's password I wouldn't want to go that route, but if there were an easy and secure way for someone to give a 3rd party access to the API, that'd be pretty cool I think.
I was wanting to do something similar for the Model S a while back, but never got around to it. But, I realized that a side effect would be that such a site could track firmware updates automatically, along with vehicle configurations and such.
Given that the Tesla API supports keyless driving if you have the owner's password I wouldn't want to go that route, but if there were an easy and secure way for someone to give a 3rd party access to the API, that'd be pretty cool I think.
Cyclone
Cyclonic Member ((.oO))
The Remote S app for Apple devices uses the OAuth token from the vehicle login to interact with the car, thereby never needing to save the password. Should you want Remote S to stop having access, logging out and back in on the Tesla app revokes the old token. Such a process could be used.
Yeah, I'm thinking about for a 3rd party server that would poll Tesla's API for your car's data periodically, independent of your app or whatever. Since Tesla has no official 3rd party API, you'd have to trust my site to not do anything crazy with your password, even if it wasn't saved and just the OAuth token was saved. Just like you trust the author of Remote S not to transmit your password elsewhere before discarding it.
Cyclone
Cyclonic Member ((.oO))
Exactly. I don't have the app, but I remember reading about it before Rego had to sign off for his operation. But then, it's much easier to "meet the author" with you!
I'm a security guy and I don't know enough about OAuth or REST API other than it is my understanding that Tesla does not use the industry standard OAuth but rather their own implementation and I see that as a possible vulnerability. I also didn't know Remote S stored passwords. I thought, perhaps wrongly, that it was just an encrypted hash or pass thru token that they had. If they or anyone else other than Tesla did have my unencrypted remote access password at any point in the authentication process I would be concerned as I doubt a small developer would be able to protect it adequately. A hacker can do more damage than just honk your horn or flash your lights. Aside from security do we know if the API gives you access to the data you need for this project such as firmware version, model, battery pack, etc...? Does it mask the private data such as GPS position? Worth exploring.
Cyclone
Cyclonic Member ((.oO))
Hopefully this is the last bit of OT, but Rego said Remote S does not store passwords. It stored the returned token. I believe he said anyone could hook up a sniffer and watch the data and see that the login credentials were not going to him.
e-FTW
New electron smell
<attempts to get back on topic>
AP does seem to learn. It is dealing much better with left or right lane markings going away, and with exits. Anyone else notice it getting better at this? Less pinball-y?
AP does seem to learn. It is dealing much better with left or right lane markings going away, and with exits. Anyone else notice it getting better at this? Less pinball-y?
Regarding whether or not AP is learning, I have not been driving the same route with enough regularity to observe any difference. However, based on MobilEye's description of how their software works, there are two levels of "learning". One is the deep neural network that is used to evaluate every pixel in the camera image to assign it to categories like accessible road, back of vehicle, side of vehicle, road sign, road marking, barrier, etc. The second is the nano-GPS detailed data about road at a much higher level of detail than ordinary GPS, which at best says road orientation and number of lanes. MobilEye explicitly mentioned that this was being collected as cars drive and was a lower level of detail than what Google collects (megabytes per mile vs gigabytes per mile).
My guess is that any improvements that are being seen are due to improvements in the nano-GPS data as the result of information being collected as we drive. Presumably merged nano-GPS data is streamed back to the car as input to the MobilEye video analysis. Note that the details will likely depend on which lane you are in, so frequently used lanes will improve more than less used lanes, even for the same road. I also expect that this nano-GPS data currently is separate from the GPS data used for/by the NAV.
Modifying the training of the deep neural network run by the MobilEye processor is a more involved process and I expect that any updates there will come via the software update process. This is likely where the AP 1.01 updates mentioned by EM will be.
My guess is that any improvements that are being seen are due to improvements in the nano-GPS data as the result of information being collected as we drive. Presumably merged nano-GPS data is streamed back to the car as input to the MobilEye video analysis. Note that the details will likely depend on which lane you are in, so frequently used lanes will improve more than less used lanes, even for the same road. I also expect that this nano-GPS data currently is separate from the GPS data used for/by the NAV.
Modifying the training of the deep neural network run by the MobilEye processor is a more involved process and I expect that any updates there will come via the software update process. This is likely where the AP 1.01 updates mentioned by EM will be.
My S is doing better about passing freeway off ramps. Also better when cross streets intersect and the lines on the right abruptly end for the width of the crossing street.
But it's still having problems on secondary roads when the line on the right curves away to the right to form an exit lane. In that case the car usually starts to take the exit and then recognizes the "mistake" and very abruptly jerks back to the left and the ping-pongs a few times a few times before settling down.
In that latter case I'm just waiting to get stopped for suspicion of DUI.
(Have not been updated to .77 yet.)
Have you gotten the software update notification yet? I'm still waiting for mine... wondering why it's being rolled out so slowly. I'd like my temp and time back in the IC, please! :biggrin:
Andyw2100
Well-Known Member
I'm not sure there's any evidence Tesla is pushing this OTA to people in the US. I could be wrong, and it's not easy to tell from the tracker, but from what I recall reading, I think .77 has been pushed in other countries, and a few people in the US have received it at service centers. One poster who hadn't received any OTA updates in a very long time also received it OTA, in response to his query about why he had not been receiving OTA updates, but that would appear to be a one-off.
HankLloydRight
No Roads
Yeah, obviously something like that is possible, but I don't think I need to re-invent the wheel when Remote S and EVMote.com are already doing the Oauth (authentication) part. I'm already talking to the EVMOTE guy about integrating an API call to my LogMySc app to almost automate the process of logging SC stops and road trips, which would be really cool. It would only be a hop-skip-and-a-jump to include the firmware version in the API call to update EV-FW.com at the same time. I really don't want to get into the login credentials/Oauth game just to extract firmware tracker updates... but if we can make it work with EVMOTE, that might be the path of least resistance (assuming that firmware build number is available in the Tesla API).
Similar threads
