Hacker News Reader

Comment by jacquesm | Hacker News Reader

Remote unlock is the least of the problems here, the real issue is that cars have no business being connected to the vendors servers at all. This could have been entirely solved locally by pairing the car to one or more phones using BT/WiFi. How remote does it have to be, you don't really want to be able to start your car if you're not in WiFi range.

View on HN

> How remote does it have to be

My SO absolutely loves being able to enter a heated (winter) or cooled (summer) car for the drive home from a cafe, restaurant or similar.

Parking for these activities is seldom within direct phone range (BT/WiFi), so would have to be something else.

Yeah, I also like the ability of third parties like Teslabout to provide dashboards of your car usage. Personally, I want "personal telemetry" in all my devices: if protocols like Solid ( https://solidproject.org ) were more well-established, they'd be a great way to have this sort of functionality without relying on the vendor to store/process all the data.

Solid still requires data to be stored somewhere thought, someone needs to host the pod -- and the chances are, it'd still be one huge vendor-owned pod.

You could say: "but I want to configure my car to upload data to a different pod" -- but this is possible today. If there were an interest, the car could ask for WebDAV / sftp / webhook address + credentials, and put telemetry there. But manufactures don't do that because there is not enough interest for this feature to justify development + support costs.

The problem is UX: if data privacy laws forced the issue, I think we could come up with a nice way to specify the pod that is accessible to non-techies.

Agreed, those are reasonable additional features. And critically, they aren't necessary for the car to function (so they could, and should, be optional).

It could be something you self host on your own server.

True. However my SO also loves not having to set up her own server in order for her to enjoy her comfortable car.

That was an extreme example. My point was more that it's technically possible to enjoy your car and have privacy. There's just no incentive for car manufacturers to not control your data. If there was user friendly was to have control of the data by running on either your own computer or have it hosted somewhere without having to think about it that would be ideal.

This could be done via ZigBee, you'd plug in a transceiver to your home local home network your phone could connect to you or access via BT. Or maybe the keyfob itself can act as a ZigBee transceiver?

I dont think zigbee covers the usecase highlighted. Consider your are at a cafe and your vehicle is parked on the street maybe 700m away.

Or alternatively that you live in an apartment complex where your vehicle does not reach your personal router.

I love technology. I think it's great. I think it's the bee's knees.

My house thermostat is failing. Many segments on the display don't work, the programmable bits no longer work, I woke up to a frigid house last week.

I went on amazon.com and looked at thermostats. Internet connectivity galore, fancy phone apps, full color LCD displays, dashboards and logging, the works.

I bought an $18 model that has a weekend/weekday programmable schedule. I know I can't trust these vendors. They care entirely too little about my security.

Some day I may sit down and build myself arduino-based thermostat, but that day is not today.

> Remote unlock is the least of the problems here, the real issue is that cars have no business being connected to the vendors servers at all.

Why do you think that? It provides valuable functionality that I use, such as journey logging, fuel status, access from an app, and so on. You need an intermediate server run by the vendor. I can't give it my phone's IP address, can I!

Maybe something simpler like a stun/turn server would be enough. Or something with no infrastructure (or recurring fees) at all, only working in my local network (like my printer).

I can understand that's attractive to a techie, but approximately nobody else wants to manage that kind of setup.

What is there to manage? Plenty of devices work just fine on local networks without the need of a mothership to act as a bridge. Just look at almost any Apple P2P service, such as AirDrop, Wifi Password sharing, Handoff, AirPlay etc

Zero management need by the customer.

I'm not sure you understand the use-case here - Apple P2P services are about working on a local network. But that doesn't apply here, does it? My car and my phone obviously aren't on a local network, are they? How do you propose to establish a local network remotely? Some kind of VPN? You'd need to establish a connection via some kind of centralised server... run by a vendor.

As the previous poster mentioned, that can be achieved with much simpler STUN/TURN servers provided by the vendor, that don’t take active part in sending commands etc, they just provide a basic pipe to route traffic through. Frequently they can even provide that pipe by just providing some help to link two devices so they can do direct P2P.

In this environment the vendors doesn’t get to watch and inspect the content of what’s transmitted, their devices don’t phone home, and the service is trivial to restore because they’re pretty much stateless.

Sounds like you've accepted the vendors do really need to run a service, and it can't be local, and now you're just debating how big that service needs to be.

There is a mothership -- it is just built into an Apple device, and Apple spent a lot of effort getting this all to work, and they can only get it to work because they control all sides.

Try setting up a generic wlan-compatible printer and a macOS laptop on a local network. I have such setup, and it is just fails every once in a while for no reason.

I would not recommend this to anyone over well-run centralized server.

> You need an intermediate server run by the vendor. I can't give it my phone's IP address, can I!

1. Why couldn't you give it your phone's IP?

2. You could just as easily use USB, Bluetooth, or local wifi, none of which require anything other than your phone and your car.

> Why couldn't you give it your phone's IP?

Because my phone frequently changes IP as I connect to different networks. It's dynamic, not static.

> You could just as easily use USB, Bluetooth, or local wifi, none of which require anything other than your phone and your car.

USB is wired.

Bluetooth requires me to by physical standing by my car.

My car and phone may not be on the same WiFi.

Well, yes, if you refuse to connect your phone to your car then you will need an intermediary to connect your phone to your car. The vast majority of people would be fine with a setup that syncs their phone and car when they're in the car, though; I assume I'm not that rare in that I always plug in my phone when I get in the car in order to use it with the dashboard anyways (Apple CarPlay / Android Auto), at which point it might as well sync any info I want.

I can't understand you.

If you want to remotely start your car to warm it up from a mile away, then by definition you're not going to be sitting in your car connected with a physical wire, are you?

And whatever your IP was the last time you plugged in may have changed by now. Do phone networks even let you accept incoming connections from non-approved services?

Does not compute.

> The vast majority of people would be fine with a setup that syncs their phone and car when they're in the car, though

I think demand for wireless car functionality in practice in the market (it's often an optional extra - people pay real money for it) shows you you're wrong.

> If you want to remotely start your car to warm it up from a mile away, then by definition you're not going to be sitting in your car connected with a physical wire, are you?

Oh, yes, in that case we're totally talking past each other and you have a completely valid point. I was originally responding to:

> journey logging, fuel status, access from an app

which should be perfectly doable locally, but agreed that [very] remote start is likely to need some sort of intermediary.

> I think demand for wireless car functionality in practice in the market (it's often an optional extra - people pay real money for it) shows you you're wrong.

Possible; it certainly wouldn't be the first time that I had very different preferences from 99% of the population without noticing...

> people pay real money for it

I'm not sure that's clear. Almost nobody custom orders options on cars anymore. They take what's in stock or readily available at the dealer, and those are mostly the fully-loaded models.

Yes, they are buying it and paying for it, but do they really have a choice?

> Almost nobody custom orders options on cars anymore. They take what's in stock or readily available at the dealer

I think this is a uniquely American thing. In Europe, Asia, etc, most people custom order a configuration on a website that’s then built at the factory and delivered to the dealer where they pick it up.

Reply on news.ycombinator.com