The Car Privacy Problem Does Not Stop at the Dashboard

A connected car can protect a network connection and still expose its owner to an unwanted data relationship. That is the uncomfortable distinction in new research from Northeastern University and Consumer Reports. The question is not just whether someone can break into the vehicle. It is what the vehicle and its companion app are designed to send out, and whether the driver has a meaningful way to understand that exchange.

The researchers' project summary reports tests of 21 vehicles and 30 companion apps. Nineteen vehicles contacted at least one third party over Wi-Fi. Seven apps transmitted sensitive identifiers to companies associated with advertising, tracking or analytics. Those findings are related but not interchangeable: a connection to an outside service does not, by itself, reveal the personal information inside it.

The work, titled Automatic Transmission, examines a vehicle and its phone app as parts of one connected product. The project identifies testing between October 2024 and August 2025, and explicitly cautions against generalizing beyond its sample. This is newly reported research about a historical observation window, not a September 2026 audit of every current app version or every car on sale.

The methods explain why that caution matters. Vehicle traffic was largely encrypted, and the researchers could observe destinations without reading its contents. Attempts to substitute certificates were rejected. Their phone setup exposed more app traffic, although some certificate-pinned connections remained outside inspection. They also tested 11 electric vehicles inside a Faraday tent to examine behavior when cellular service was blocked. That intervention did not guarantee complete visibility into every vehicle's communications.

The paper identifies additional blind spots: most cellular traffic was not directly observed, and transfers between manufacturers' servers and other companies were outside the researchers' vantage point. App tests accepted requested permissions. These are not measurements proving that every available opt-out fails. Nor does an absence of observed traffic establish that a vehicle has no other data-sharing route. The experiment is informative precisely when its boundary stays visible.

That boundary should shape how a buyer reads the headline. A list of contacted domains is a starting point for questions, not a complete privacy score. A service that needs an outside map provider and an app that sends an identifier into an unrelated analytics workflow may both generate third-party traffic. A useful assessment must ask what was sent, for which function, to which recipient, under which restrictions.

For a product team, simply counting vendors would be an equally weak response. Removing a necessary navigation service to improve a domain count could make the product worse without addressing an unnecessary disclosure elsewhere. The more useful engineering objective is to reduce information that has no justified purpose in a particular interaction, then prove that the intended function still works. That is a different target from making a dashboard look quieter.

TechCrunch's independent coverage highlights the linkage risk when vehicle identifiers travel alongside contact details or precise location. Its account also reports that adding companion apps substantially expanded the set of advertising and tracking companies encountered. This is independent reporting on the research, not a separate replication of the experiment. It strengthens the public source trail without creating a second set of laboratory results.

The linkage issue deserves attention beyond the raw sensitivity of a single field. In an illustrative case, a maintenance service might need to know which vehicle needs a part. That does not automatically explain why a separate service needs the owner's email and a location alongside it. The design question is whether the recipient needs the combination. Evaluating each field in isolation can miss the consequence of joining them.

Consumer Reports, which provided the vehicles and testing facility, sought responses from automakers. Its account says several companies cited restrictions on vendors' independent use or sale of information. Others pointed to outside webpages opened from their apps. These responses matter: the observation of a transmission does not establish that a recipient sold the information, breached a contract or used it to change an insurance premium.

There was also a concrete response from Honda. Consumer Reports reports that Honda stopped sending location data to Amplitude and instructed the vendor to delete what it had received. That is a narrower and more useful outcome than a general reassurance about privacy. It identifies a data type, a recipient and a change. The reviewed reporting does not independently establish that every downstream copy was deleted.

The contract defense raises a practical distinction between authorized processing and unnecessary processing. A supplier can be contractually limited and still receive more information than the feature needs. Conversely, an outside service can have a legitimate role without being free to reuse everything it receives. A responsible review should examine both the purpose of the transfer and the controls after receipt, rather than declaring every external connection either harmless or malicious.

The embedded-web explanation also points to an ownership problem. Imagine a service appointment page opened from a vehicle app. The driver experiences one workflow, even if different teams maintain its native screen, web page and measurement tools. A product review that stops at the native app boundary would be incomplete. The relevant acceptance test should follow the user through the whole task, including pages opened along the way.

Consent needs similarly concrete treatment. The useful question is not whether a company can produce an accepted agreement. It is whether the explanation makes the actual choice intelligible: which optional function uses which information, whether another recipient receives it, and what stops working if the driver declines. Those are proposed product-design tests, not a legal conclusion that every agreement in this study is invalid.

There is already a separate regulatory precedent for treating connected-vehicle data as consequential. In January 2026, the Federal Trade Commission finalized its GM and OnStar order settling allegations of collecting and selling location and driving-behavior information without adequately informed consent. The order includes a five-year prohibition on disclosing covered driver information to consumer reporting agencies. That completed enforcement action should not be confused with a new finding against every manufacturer in this study.

The FTC also describes longer-running obligations around affirmative consent, data access and deletion, and controls over collection, with stated exceptions. Its example of emergency responders illustrates why indiscriminately switching off every data flow is not the only possible privacy design. The task is to separate purposes and choices. The order applies to its named respondents; it is not evidence that every vehicle owner already has identical controls.

NIST's guidance on using its Privacy Framework offers a practical organizational approach. It connects desired privacy outcomes to planning, design, deployment and ongoing operation. It also describes communicating requirements to suppliers and verifying that those requirements are met. A written policy is therefore only part of the work. The framework's current and target profiles give an organization a way to identify gaps without claiming that a document itself removes them.

Applied to a vehicle app, an actionable inventory would connect each outbound field to the feature that needs it, the recipient that receives it and the person accountable for approving it. A remote-unlock function, a service booking and a marketing measurement should not disappear into one undifferentiated category called connected services. That proposed inventory would make a disputed transfer easier to investigate and a supplier change easier to assess.

A release review could then exercise the same feature under different permission choices and compare the actual transmissions with the expected ones. It should record the app version, vehicle configuration and account state, so the next reviewer knows what was tested. These are engineering recommendations, not results the researchers measured for every manufacturer. Their value would depend on whether they expose and prevent an unwanted transfer in the real product.

Independent follow-up has a specific job as well. Where a manufacturer says a disclosure has stopped, a later test should identify the updated version and reproduce the relevant interaction. Where the remaining dispute concerns a vendor's use of received data, another phone capture will not settle it. That question needs evidence about the recipient's controls and handling. The next investigation should match the kind of claim being challenged.

Owners can obtain a smaller window into the phone side today. Apple's App Privacy Report shows recent sensor access and contacted domains, including activity from web content inside apps. It starts collecting only after it is enabled, covers the preceding seven days of activity and keeps the report encrypted on the device. Apple also explains that accessing a sensor is not necessarily the same as the developer collecting its output.

That tool can help an owner ask a better question about an unexpected contact or permission. It cannot substitute for the research setup, identify every transmitted field or show the car's separate cellular traffic. Nor should a user treat a recognizable technology-company domain as proof of a data sale. The appropriate follow-up is a specific explanation from the app provider, tied to the feature and activity observed.

For builders, the most important lesson is that privacy acceptance criteria need to survive an organizational handoff. A supplier agreement, a working encrypted connection and a successfully completed user action can each be correct while the overall data choice remains poor. Someone needs responsibility for the complete interaction, including deciding when a field should never leave the product in the first place.

The study does not justify declaring every connected feature unsafe. It does justify demanding better evidence about what those features cost in data. The next meaningful improvement is a documented, testable reduction in unnecessary disclosure, with useful functions preserved and current versions identified. That is a standard an automaker can build toward and an independent researcher can check. Another broad promise to take privacy seriously is not the same deliverable.

LaunchPad positionEvaluate the whole vehicle-and-app workflow, distinguish observed transfers from downstream-use claims, and require specific evidence that a reported privacy fix changed the data flow.