I was probably thinking of a future where future devices from education institutions would have these preloaded with a non modifiable version of agents guardrails tuned for learning...
That very much could be the case, in which case deleting the (now useless, because your car is not connected) app would resolve that - no bluetooth restriction needed.
It does produce a local Wi-Fi network but there's no evidence that it supports internet communication. That would be considered a hotspot, which not all carriers even support.
I've never understood how this can be limited in practice: surely as far as the carrier is concerned, all traffic from the mobile device is the same (unless there are identifiers on the traffic coming from hotspotted devices via the mobile device). Here in Australia we've never had any form of hotspot detection/segmentation - if you have a data plan, all data features work (across all carriers). I do recall lots of online chatter from the US though, especially years back when mobile data was more of a precious resource.
Specifically it decrements the TTL of routed packets, so hotspot traffic will tend to have a TTL of 63 instead of 64. You could theoretically disable this at the risk of creating infinite routing loops, although android probably makes it inaccessible if the kernel has a setting for it at all, so you might have to rewrite packets in user space.
It has been a long time since I've done this, but:
If your Android is rooted, it's pretty easy to get tethering working. There's magisk modules that can fix the TTL problem and/or disable the hidden carrier-installed software that Android will ask for permission before enabling tethering.
Different applications on a single device can't apply different TTL's? I thought TTL was a pretty basic knob exposed to applications. e.g. A sensor that transmits fresh data every 20 seconds doesn't need stale packets bounding around clogging up the pipes, while a file transfer over an intermittently delayed link might benefit from a higher TTL.
> surely as far as the carrier is concerned, all traffic from the mobile device is the same
Going on a bit of a tangent, but deep packet inspection can identify packets routed using NAT, so if the phone is operating as a typical hotspot it would be identifiable by your carrier. Carriers in the USA used to block / denylist / charge extra for tethering using this exact approach.
DPI can refer to inspecting beyond just the headers, but since it's more of a marketing term than a technical one, you could also say you're "deeply inspecting" the IP headers of a packet and no-one would show up to arrest you for bad terminology.
Anyway, one way to detect NAT is to observe different TTLs originating from one device. Is that deep inspection? Probably depends on who you ask. The fact that you have to track information across multiple packets counts for something, though.
Off the top of my head I wouldn't really expect there to be much value in a MITM inspection of the contents of HTTP traffic for the purposes of NAT detection. You could probably come up with some scenarios in which it might be possible, but I'd content those scenarios aren't very practical. Easier to compare TTLs between packets, say, or track connections to known OS "phone home" destinations. While these just use information from the IP layer, they're stateful observations requiring comparisons across multiple packets, and that might count for something.
One way to detect a shitty carrier service, though, is that they're inspecting your traffic for "good" or "bad" uses of their service, because that is a good indicator that they're not just a carrier. I call it Dickish Practices Identification, or DPI.
DPI is distinct from TLS MITM (though many enterprise devices offer both).
The delineation here is between "shallow" packet inspection (which basically nobody refers to because it's just a normal part of networking), where network devices look at just the bits of the packets they need to route / NAT / etc them appropriately.
DPI can tell a ton of things without needing to MITM encrypted layer 7 traffic.
A boring example is that you can tell TLS from OpenSSH traffic just by seeing the initial handshake. sslh ( https://github.com/yrutschle/sslh ) takes advantage of this on the server side to let you run both on the same port.
A less boring example is identifying OpenVPN, Wireguard, etc traffic regardless of what port they're run on, to enable blocking VPN traffic on a network.
At one point it was definitely not so deep... carriers were literally looking at the IP TTL and seeing whether it was a recognised value from the phone or a few hops less than one of the common defaults, in which case it was considered tethering traffic.
You could spoof it by finding out your mobile's TTL, overriding the TTL in the connecting device to be one higher than the mobile.
I recently switched to a carrier (Fido/Rogers in Canada). My plan limits hotspot by disabling the hotspot settings on ios. However, I was able to enable it again by changing the access point name.
On android, there is an OS-level feature that checks the cell tower to verify if you're allowed to create a hotspot. It runs whenever you try to enable the hotspot feature. On rooted systems, you can disable this check. There are also apps that let you run a hotspot without using the OS feature, bypassing the check.
I believe there’s some stuff like that for commercial things. One project I worked on used an ‘IoT portal’ for cloud based telemetry (at the customer’s request) and we had to get a special SIM card for it (although I don’t know if this is still needed.)
Plus it seems unlikely that the telematics module is even really related to the display screen stuff, let alone being configured to use alternate network connections to transmit data.
Mostly by looking at packets TTL. It gets decreased by 1 by the hotspot’s NAT so if the value is something like 63 or 127 (instead of 64 or 128 which are the defaults for most platforms) then it’s almost certain the packet originated from a device behind the phone and not from the phone itself.
Just a note about Toyota specifically - There are many blog posts and articles out there alleging that Toyota shares your data with insurance companies.
As I own two Toyota's I have read through these carefully and consistently the theme is that the owner was opted into this program without knowing it (likely by the sales person clicking through setup steps to enable every feature). If you are not opted in, I have seen no evidence they share driving data.
When I set up my Toyotas, the app clearly walks through the programs they have and you must click either "yes/opt in" or "no/opt out" for each program. It is not opted in by default.
I've bought multiple Toyotas from the same dealer, and each time the sales person has been overly aggressive about setting up the app and connecting to the car. The first time I let them do it to a point as I had not seen what it did, but had to prevent them from syncing contacts. After that, I had to be very stern about not needing help to set up an app I was never going to use. I don't know if they are used to neophytes being unable to handle this and think they are doing a service or if it's a push to get people to connect/sync as much as possible.
> I don't know if they are used to neophytes being unable to handle this and think they are doing a service or if it's a push to get people to connect/sync as much as possible.
Likely doing it to remove any frustrations from the brand new buyer being unable to figure out how to set it all up. The last thing you need is someone changing their mind about the car they just bought, because well if setting up the app is a PITA, what else is terrible about the car?
The main problem I had with it is the fact it requires an app in the first place. Once they have an app on your phone, they have access to so much data. The app by nature of the functions it performs will need GPS, Bluetooth, and Contacts at a minimum. Once they have that access, there's nothing stopping them from using it for whatever they want. That's just absolutely not something I'm willing to give a car app. Do we really think their map/routing app will be better than something else I could use instead? I don't even like using map apps because of their power to snoop and report.
if it doesn't have bluetooth, how is it going to communicate with the device? if it doesn't have location, how's it going to operate the map? if it doesn't have contacts, how is it going to display the caller info on screen? what in the world are you talking about? after denying the app all of that information, there's not point in using the app which is precisely why i didn't use their app.
I asked the Subaru dealer to not set up an account for me. They did anyway with an email that wasn't mine. So they gave someone else control of my car over the Internet after I asked them not to even bother.
I only found out because Subaru sent me mail that had the email address on it.
That's some shady ass shit right there. Did you reset it after finding out? I would have driven up there and become a Karen demanding to speak to a manager at the dealership. I wonder if any kind of identity theft laws or anything along the those lines could be used.
I assume any dealer who's comfortable signing a contract (terms of service) on your behalf is comfortable with you signing a contract on their behalf. Time to write yourself a new car.
A lot of engineers view the touchscreen head unit to be the central nerve system of the car, when in reality it's just a peripheral. It's an accessory. It's like those gimmick CPU coolers with a watch sized display. They use different models of that screen for different trims of same cars. This article in fact discuss removal of the DCM unit, not removal of the touchscreen; the touchscreen is still 100% functional. Because the entire screen is just an accessory.
What that means is, those data collections don't necessarily go through that display thing, therefore collections consent/disable screen just might not be there. Maybe it's in the paper contracts or maybe they think cars aren't people, but my point is, a car is not built around the display, and there is no guarantee that the tracking code is on that part of the car.
Before 2018-2019, the opt-in process for data sharing was hidden on a website somewhere. Around that time, the form became part of the vehicle purchasing process.
When I bought my 2024 Lexus, there was a sticker on the headlamp saying to push the support call button to talk to a rep if I don’t want any vehicle data collected . So I did and the rep told me they can disable it but it will also disable the SOS/911 calls and crash report if I do that. Choosing my own battles, I begrudgingly told them to leave it enabled.
On the 23 4Runner, telemetry is enabled by default. You get warning stickers but other than that, it's just on. No app, no other indicator. Had the dealer removed that one sticker, there would be no obvious indicator
> Even after the modem is removed, if you connect your phone to the car via Bluetooth then the car will use your phone as an internet connection and send all the same telemetry data back to Toyota
What is the basis for this claim? I've never heard of this capability.
> One caveat, if you use bluetooth to connect your phone to the car DCM will use your phone to connect to the mother ship and presumably send your data. I only use my iPhone cable to connect to the car which does not have this effect.
A random post on a forum is not evidence that Toyota has found a magic way to exfiltrate data over a bluetooth connection without turning on hotspot/etc.
It's not evidence against it either. Presumably CarPlay and Android Auto could implement a network interface through the application layer, or even activate Bluetooth tethering at the system level as they are privileged apps.
But they could also do this over USB, so something doesn't add up.
RNDIS was a mechanism for tethering over USB, and you could certainly pair "Bluetooth Network Adapters" for years and there's a profile for it. So there's at least precedent for it. That makes it pretty plausible to me.
A crypto miner needs consent because it burns your battery and CPU power with no benefit to you. This AI model would only be used when you invoke it so the only problem is disk space, which the comment you're replying to acknowledges as a point of issue.
> This AI model would only be used when you invoke it
You sure about that? How explicit is the invocation? assuming it’s only run when the user does something (big assumption), does the user know clicking that summarize button is going to bog their system down and crank up their electricity use?
Indeed. Trusting that it will only be processing the user's queries - as opposed to, say, becoming part of a distributed grid of AI processing nodes - isn't a bet I'd be willing to place much money on.
reply