
Fiat Chrysler recalls 1.4M cars after Jeep hack - vvanders
http://www.bbc.com/news/technology-33650491
======
tinco
This is a terrible decision. On such a short timescale, they'll only be able
to fix the particular bug in their infotainment system. The real problem as
everyone has pointed out is that the car control and infotainment should not
share channels. There should be a physical gap between them and if really
necessary a very tightly controlled message bridge.

The real fix will require much more intervention than just a firmware flash at
the garage.

We'll see at Def Con how much Chrysler really screwed up.

~~~
Xorlev
> This is a terrible decision.

It's the only one available to them. They can't just refit all existing cars
with a new design on a short timeline. Hardware has permanence.

With that in mind, how would you fix the issue for existing vehicles?

~~~
SEJeff
The infotainment system should never have access to the CAN[1] network in the
first place... ever. At most, they could have a very simple listener on the
can network that could send data (one way only) to the infotainment device via
a different channel of sorts. Mixing the two is asking for issues such as just
this to happen.

[1]
[https://en.wikipedia.org/wiki/CAN_bus](https://en.wikipedia.org/wiki/CAN_bus)

~~~
wvenable
> The infotainment system should never have access to the CAN[1] network in
> the first place... ever.

The problem is access to the CAN bus is necessary to change various vehicle
settings from the infotainment system. I know for a fact that changing the
door lock settings in my car requires the infotainment system to access the
CAN bus to apply settings to that system.

This is not an unsolvable problem; this is basic software engineering.
Processes should be isolated from each other. I imagine everything in the
infotainment system effectively runs as "root" because they consider the whole
thing a singular black box.

~~~
UnoriginalGuy
I agree with both you and the person above. I think the missing word we're
looking for is: "unrestricted" (as in unrestricted access should not be
permitted).

Yes, the info system needs SOME access to the CAN network. But it shouldn't be
unrestricted access. Instead the info system should be treated as "untrusted"
and only specific things should be permissible over a well documented set of
APIs.

I'd almost be tempted to say that while the car is moving, ALL access to the
CAN network should be disabled. Since let's name some things the info system
needs on the CAN network:

\- Reconfigure car (e.g. daylight running lights, auto-locking door, etc).

\- Start car remotely.

\- Set AC remotely.

\- Diagnostics.

The only one on that list which MIGHT be useful to have while the car is in
motion is diagnostics. And that could be delivered via a read only interface.

~~~
mzs
Steering wheel audio controls are common and useful in motion.

It's not really about RO v RW, CAN is about sending commands. The head unit
could say, it's the brakes, so that has to be protected against.

When there is not a physical layer doing that protection (separate bus, a
filter, and so on) there are two other layers. One is the thing sending can
reject it from going out, but that takes resources that might not be there.
The other the receiver does some sanity checking on it, like "you want me to
go in P but I'm going at 65, yeah I don't think so" to even it's gotten common
place for messages involving the brakes include a shared code back and forth.

Really I think this boils down to there are untrusted channels (wifi,
cellular, DAB) that should be locked down better. I mean the DAB thing, likely
it's a buffer over flow in the head unit. Even if that has a cpu that is
running FW that is making sure the CAN messages it is sending are sane, the
exploit just makes it stop doing that. There's such a pressure to save cost
and so many OEMs involved that ease of integration motivates the rest.

Yeah it sucks, but it is what it is.

~~~
gherkin0
> Steering wheel audio controls are common and useful in motion.

But wouldn't those likely be one-way commands TO the infotainment system? They
would still work even if it was receive only.

~~~
mzs
My goodness this is really not going well for me.

Basically there is no notion of to or from really. When you push the vol+
button on the steering wheel there is a controller that sends a message trying
over and over again until there is no collision. That message has an ID in it
early on. In this case it will be like I dunno $412 okay. That means audio
controls or something. A bit later is some length and then the data, say the
data is $C.

The infotainment unit is listening to everything just as the controller for
the steering wheel controls is and everything else on the bus (it has to,
because of how collision detection works). When the controller in the steering
wheel sees that $412 ... $C it goes, well isn't that nice, me or someone else
sent the vol+ message out finally, cool, I'll stop sending that now. When the
radio sees that message with an ID of $412 it goes, oh that's an audio control
message command, I should pay attention to that. Then it looks at the length
and data and sees $C. It goes oh that means someone pressed vol+, I'll make it
louder.

But here's the thing, there might be a knob too for volume and there really is
just one board doing the infotainment. It's not like the old days where it's a
potentiometer, it's not even wired directly into the board that handles
infotainment. All the IO pins that board has are already used-up handling the
screen, CAN bus, and other things. When you twist it, it also sends the same
$412 ... $C over CAN from it's controller! The radio did not know what sent
it, and that's by design in CAN bus.

There might be mobile phone integration, it can do CAN too, say also a $412
with with a different payload (and possibly length) that might mute on call.
Also there may be a touch screen, but that will not do a thing over CAN if you
press the vol+ there, just do it's normal IO from screen to SoC on the board.

Am I doing a better job of explaining? The take away is lots of things can
send the same message and lots of things might be interested in that message
and that is how it is intended. To some extent you can mitigate this in
hardware. You can make long runs or some shorter star shaped topologies as
long as you get the termination right. For the star shaped topologies you can
stick gateways in there. The controllers can be setup to filter on certain
conditions and the bus is the limit for filtering if you are using a
programmable part. What I mean by bus is the limit is things like there is no
notion of to and from.

That's what you get in CAN bus cause that's how it works. You can thank Bosch
for that.

~~~
userbinator
That looks like an absurd amount of complexity/overengineering just to save
some wire. I suppose "put everything on one bus" could be turning into some
sort of anti-pattern.

~~~
nitrogen
Consider how much wire would be required to route every button directly. There
would be tens of pounds of extra metal, plus impossible bundles of hundreds of
wires to route around the car.

CAN is great for its purpose, but handling untrusted actors is not part of
that purpose.

What _should_ happen is a non-CAN hardware gateway that only passes valid
commands to CAN buses.

------
jacquesm
> The company added that hacking its vehicles was a "criminal action".

I don't think that's the case, but I still commend them for doing a recall
this quick.

Shooting the messenger seems to still be quite a strong reflex for
corporations faced with bad news. The way to look at it should be that these
guys did Fiat-Chrysler a service. After all, it's not only security
researchers that have the ability to write code and that have prolonged access
to a vehicle to test.

They seem to be mistaken about the time to write the code, after all, you can
write the code and test it on a different vehicle than the one you intend to
crash.

Law enforcement typically won't analyze the firmware of all the computers in a
car after a single vehicle accident (and it would probably be quite possible
to erase the evidence once the car has been given a command sufficient to kill
the occupants).

~~~
TallGuyShort
I would add that shipping cars with such vulnerabilities should be a criminal
action, if it isn't. It's certainly negligent (however unintentionally) and
unsafe for consumers.

~~~
jacquesm
Given the complexity of the software components in a modern car I think it
would be a safe assumption that all of them are shipping with such
vulnerabilities. If there is one area where we could benefit from some
openness it is the embedded world, these are life critical systems in every
sense of the world and what I've seen of such code bases does not inspire
confidence at all (rather the opposite).

~~~
fineman
The issue isn't vulnerabilities, it's connecting those vulnerabilities to the
net. This isn't about software quality in general.

~~~
jacquesm
But that's exactly how these things happen. People program insecure stuff
thinking 'well, at least this isn't connected to the internet', then one day
someone else takes the blackbox the original guy (long departed) put together,
hacks up a TCP/IP interface or does something else without looking through the
codebase and _boom_ you're wide open.

You can replay this story 10's of times over the next couple of years and lets
hope it's only the nice guys finding them.

~~~
TallGuyShort
See also: SCADA

~~~
jacquesm
Don't get me started on that one, yes, it's probably even worse than
automotive because these are 100's of thousands of legacy systems quite often
without any security at all connected to the net. Obscurity is the only thing
that keeps these systems working.

------
jameshart
I see a lot of people thoughtlessly applying computer-security mindset here to
vehicle-safety. They're really not the same thing, because they are handling
very different risk models. Vehicle safety is about "how will this system
perform under typical conditions when something goes wrong?". Computer
security is about "how will this system perform if a smart asshole tries to
abuse it?". Vehicle safety _generally_ doesn't concern itself with deliberate
sabotage. You won't see a product recall for a car because "under some
circumstances, a criminal might cut the brake cables". What Chrysler are doing
here is, though, effectively that, and _why_ they have to do that for a
computer security issue is interesting.

We're all used to the idea that if you put a computer on the internet, it will
come under attack. People will try to snoop on the data it handles, or subvert
it to use it for their own purposes. So why do we then move on to assume that,
if such a system is attached to something safety critical, that those same
people who will attack the computer to get at its data or processing power
will now move on to attacking the brakes, or the engine, and try to kill
people?

Most vehicular crime isn't homicide, it's acquisitive - people will attack
vehicle security systems to steal the car, or get access to valuable contents.
Sabotaging the vehicle to kill the driver is way down the list.

As a society we tend to assume that physical security is not the only thing
that stops random strangers from trying to kill us. We do not all drive around
in armored cars in case someone decides to shoot at us from an overpass. We
don't all sweep under our car with a mirror for bombs before we get in and
start the engine.

And it's certainly not a failing of Chrysler's engineers to adequately
consider customer safety that they sell Jeeps which are not bulletproof and
which have exposed frameworks on the underside where bombs can be attached.

So why is it that we're so quick to assume that because a safety-critical
computer system is exposed to the internet, that this is the _worst thing
ever_?

Is it that as far as physical security of your Jeep goes you only have to
trust the people in your neighborhood, but for internet security we have to
trust the whole world?

~~~
munificent
> So why is it that we're so quick to assume that because a safety-critical
> computer system is exposed to the internet, that this is the worst thing
> ever?

Because of the Greater Internet Fuckwad Theory (or, more nicely put, the
"online disinhibition effect"[1]).

We don't worry as much about random strangers harming us in person because
most people are generally well-behaved when they are face to face with someone
in real physical space.

On the Internet, where all you see is a screen and all you do is click your
mouse, "reality" gets a lot more tenuous. In that environment, people act
worse.

If you were walking over an overpass and saw someone left a cinder block up
there with a note attached saying "Throw me!" how likely would you be to
lumber it up off the ground, carry it to the edge, and heave it over onto to a
car you can see passing below, whose occupants are visible to you?

Now imagine you stumble onto a random web page with a button labeled "Click to
drop cinder block off overpass". Tempting?

The way our behavior differs in these two circumstances is a big part of why
Internet security is so different from physical security. (The other big
difference is how data can be replicated for free. It takes 50x as much effort
to steal 50 cars. It often takes no more effort to apply the same have 50, or
a million times.)

[1]:
[https://en.wikipedia.org/wiki/Online_disinhibition_effect](https://en.wikipedia.org/wiki/Online_disinhibition_effect)

~~~
imh
In addition to this, there are differing scales at work. In real life, by your
analogy, you might find a cinder block with a "throw me" note. With the
internet, you might find a button that says "throw 1.4M cinder blocks." One
maniac can cause much more trouble that way.

------
skimmas
One got to love bright minds who ever thought connecting any relevant part of
a cars control mechanisms to the internet was a good idea.

~~~
netrus
Doesn't Tesla send over-the-air updates for critical systems to its cars? From
my understanding, that means there is a way for a similar attack with a fake-
firmware. Am I wrong?

~~~
tinco
Yes, but I don't think skimmas is fully right. Updating firmware over the
internet is not a terrible idea. Public key decryption is well established
technology and simple enough for even big corporations to get right.

Of course.. there's some room for them to screw up, but I would argue that
that's set off by the risk of having buggy vehicle control firmware killing
people. Especially with a new vehicle like the Tesla.

~~~
higherpurpose
There's also such thing as "key stealing". I imagine it would be quite a
valuable target.

~~~
UnoriginalGuy
When you're signing a binary blob, protecting the private key is actually
pretty easy since it can be air-gapped/offline. Or heck you can buy appliances
where they'll perform specific functions using the private key but won't
expose it themselves without physical intervention.

------
dsfyu404ed
Just an FYI for everyone on the "segregated systems" bandwagon:

If a compromised device can talk on the CAN bus it's game over since (pretty
much) everything listens on that bus so you can't (without a lot of time and
effort, implement a way to) pick and choose systems to segregate while
maintaining wireless connectivity to those critical system.

Vehicle manufactures get a huge data set sent back to them by vehicles. They
use this for stuff like correlating part failures to operational conditions,
determining which intermittent wiper setting people use as well as improving
the logic for the operation of critical systems (e.g. if my last inputs were
$stuff then don't upshift). I wouldn't be surprised if they sold the data as
well. McDonalds would love to know where and when people start looking for
food. insurance companies would love to have more variables to correlate to
risk trivial (e.g. $color cars with $trivial_feature get in accident that cost
$really_small_percent $more_or_less than $other_color

To segregate systems you need to be able to pitch to the bean-counters that
the cost/benefit of whatever degree of segregation you're proposing beats the
cost/benefit of whatever plan the next guy is proposing. These data sets are
incredibly valuable to many different parts of the company. The people doing
marketing and customer facing stuff would be at a severe competitive
disadvantage if they had to wait months (first oil change) o get real world
data on feature usage after a re-design.

Sure you could download it at service time..."but we already have a system
that does it in near real time, can't we just secure that?"...

TL;DR: Segregating systems involves more than having the engineers wait a few
months to figure out if their new tune solved the problem.

~~~
krapp
Which costs less in the long run, a potential class action lawsuit and loss of
consumer confidence, or better system security?

If necessary, consider that security is a feature you can sell, when your
competitors are following the path of least resistance and paying out their
settlements.

~~~
dsfyu404ed
Depends on the lawsuit. How much effort would you go through to secure
software that runs on a decade old vehicle with a very particular set of
options if the exploit requires a very particular set of conditions?

You might fix it just to have a similarly obscure zero day be discovered
(unknown to you) and exploited in a different place. Then not only were all
those resources spent in vain, but you've got to deal with the opportunity
cost of not having thrown those resources behind current of future safety and
security tech.

People accept the risk of driving vehicles with legacy safety equipment, why
should software be any different from hardware or legacy software in non-
embedded applications. At some point you have to let stuff go. Just ask
Microsoft.

~~~
krapp
Depends on how much effort it would have taken to get it right the first time,
which is what I'm suggesting be done.

And in this case, these vehicles were manufactured pretty recently, so even
conceding your point, I don't think we've passed the 'let stuff go' point in
this case.

------
gandalfu
From the press release:
[http://www.media.chrysler.com/newsrelease.do?id=16849&mid=1](http://www.media.chrysler.com/newsrelease.do?id=16849&mid=1)

"No defect has been found. FCA US is conducting this campaign out of an
abundance of caution."

What the hell?

~~~
maxerickson
Defect appears to have a particular meaning in relation to vehicle safety. I'm
just basing that on the way it is used here:

[http://www-odi.nhtsa.dot.gov/recalls/recallprocess.cfm](http://www-
odi.nhtsa.dot.gov/recalls/recallprocess.cfm)

I guess it isn't that big a stretch to use such defensive language, there are
a lot of things that can be tampered with on a vehicle that arise out of
engineering trade offs.

I don't mean to dismiss the problem at hand, but it is only an issue if
someone makes an effort to tamper with a vehicle, which is different than a
critical part failing prematurely or whatever.

~~~
gandalfu
Unfortunately your argument makes sense.

------
bradgessler
The good that comes out if this is that somewhere in the management chain
people will feel justified to increase security investment by saying,
"remember the Fiat Chrysler recall?"

------
tantalor
_The recall aligns with an ongoing software distribution that insulates
connected vehicles from remote manipulation, which, if unauthorized,
constitutes criminal action._

The WIRED story's hackers presumably _were_ authorized by the vehicle's owner
or operator, so the demo did not "constitute criminal action."

~~~
privong
> The WIRED story's hackers presumably were authorized by the vehicle's owner
> or operator, so the demo did not "constitute criminal action."

They were probably authorized by the driver, but car companies have argued
that the driver does not "own" the software in the car, so I assume their
claim of unauthorized access is predicated on the assumption that the car
company still owns the software and that the car company did not authorize the
access.

I do not agree with the car company's stance on ownership, but that may be the
origin of their claim.

~~~
tantalor
WIRED has another story about this question,

[http://www.wired.com/2015/04/dmca-ownership-john-
deere/](http://www.wired.com/2015/04/dmca-ownership-john-deere/)

Supposedly the US Copyright Office will decide this month.

------
jasimq
If you missed it, this is related: [http://www.wired.com/2015/07/hackers-
remotely-kill-jeep-high...](http://www.wired.com/2015/07/hackers-remotely-
kill-jeep-highway/)

~~~
maxerickson
Discussed here:

[https://news.ycombinator.com/item?id=9921557](https://news.ycombinator.com/item?id=9921557)

Also related:

[https://news.ycombinator.com/item?id=9929177](https://news.ycombinator.com/item?id=9929177)

------
discardorama
If researchers _really_ want to underscore a point: hang out outside the IIHS
testing facility, and when they're testing the vehicle in question, _then_
mess with the systems.

Maybe IIHS needs to include "remote hackability" as a criterion in their
testing?

~~~
dsfyu404ed
IIHS uses cars that aren't running and don't have fluids in them. They don't
want to clean up that mess (or have the car destroyed by fire). They do test
fuel system integrity though. I'm not sure if they use some other fluid (water
+ dye) or something like pressurized air or leakdown test after the fact.

I guess you could engage in other antics but none of them would be all that
effective since the car is towed by a cable until it's a few feet from
whatever it's hitting.

~~~
discardorama
Actually, you are right. I was thinking of NHTSA, which does braking tests on
an actual track.

------
blahblah3
Wow connecting cars to the internet? Sounds insanely dangerous. Not everything
should be connected to the internet or "smart".

------
ryandrake
Auto companies' lax attitudes towards systems security will change when
insurance companies start considering such security vulnerabilities as safety
issues and adjust their existing safety ratings appropriately.

~~~
brudgers
Insurance companies already do. Insurance rates are actuarily based on actual
accident frequency. Outlier risks are covered by reinsurance. Not only are
insurance companies well funded, they employ smart people and work in an
information network with a lot of depth.

~~~
aianus
Yeah, right. The only way insurance companies are competitive and pricing risk
correctly is if there's a magic responsibility fairy that bestows wisdom and
driving ability upon all at midnight on their 25th birthday.

~~~
brudgers
If the band is 20-25, they charge everyone based on age 20, otherwise they
would be subsidizing high risk drivers instead of generating more profit on
21-24 year olds. Actuaries are applied mathematicians, and typically of above
average intelligence compared to the general populace.

~~~
aianus
Why would the band have to be 20-25 for every insurance company in the
country? Why not be innovative and create an accurately priced 24-25 band and
undercut your competition?

I'll tell you why: because insurance companies are a rent-seeking oligopoly
with an enormous barrier to entry. They just sit there and make a fortune
doing jack shit.

------
pasbesoin
Based upon my own experience (in another industry), I have no doubt that there
were knowledgeable people internally who warned them of this -- if they were
not fully cowed by the bureaucracy.

I have zero sympathy for the manufacturers. I only hope that, if they decide
to go on a witch hunt, they actually seek and punish the morons in power who,
most likely for self-serving purposes, let this slide.

This also should raise a ringing cry to rein in DMCA et al. uses that seek to
outlaw such research. In this case, the manufacturer has obviated their
authority in the matter.

------
LoSboccacc
> The company added that hacking its vehicles was a "criminal action".

screw that attitude.

I hope government will make the equivalent of whistleblower protection for
security researchers that report exploitable flaws, because it's the only way
to increase security over time.

i.e. I'm scared as hell that planes are allegedly hackable but researchers
aren't really talking about it nor testing it properly because fear of
lawsuits.

------
rasz_pl
In other news Apple just hired Doug Betts, former FCA 'quality' boss

[http://blog.caranddriver.com/fiat-chrysler-quality-chief-
res...](http://blog.caranddriver.com/fiat-chrysler-quality-chief-resigns-one-
day-after-terrible-consumer-reports-rankings/)

[http://www.autonews.com/article/20141028/OEM02/141029851/bet...](http://www.autonews.com/article/20141028/OEM02/141029851/betts-
leaves-chrysler-after-another-poor-quality-showing)

[http://www.techtimes.com/articles/70582/20150721/apple-
hires...](http://www.techtimes.com/articles/70582/20150721/apple-hires-fiat-
chrysler-executive-doug-betts-beep-beep-beep-icar-coming.htm)

because nothing screams quality like a 'decided to leave one day after yet
another drop in Consumer Report rankings' and 1.4m car recall!

------
bborud
I've been spending a bit of time over the last couple of months reading up on
CAN, OBD2, system architectures for automotive systems, attack vectors,
various forms of CAN-attacks, building stuff that interfaces with CAN buses,
writing software, figuring out how things work etc. And I have to say that
many of the comments in this thread are frighteningly uninformed.

I know this is supposed to be The Magic Kingdom where people are only supposed
to say positive things and eat happy pills all day, but would it kill people
to at least try to read up about the things they so willingly share their
"insights" on before posting here?

At the very least, try to understand how CAN works before spouting nonsense
grounded in uninformed assumption. Uninformed opinions are not helpful. They
just pollute the discussion.

------
cmurf
At RSA I was at a car hacking session, and the big take away I got is how some
of these systems have none upgradable firmware, and today's designs sent for
manufacturing now aren't due for 2017-2018 model year cars. So some of these
vulns could be baked in, in a way that have expensive work arounds because the
car manufacturers have been so feature driven rather than security conscious.
It's the car equivalent of bloat/crap ware on phones. Features that drive up
selling the customer. The cars that have OTA firmware updates (BMW was one
example) are able to push out fixes faster, and with more complete coverage
than recalls so it seems sane to me to make it mandatory such "smart cars" can
be OTA updated.

------
JustSomeNobody
Do we really need our vehicles to have so much technology?

I know I'll get down voted, but it has to be asked.

~~~
csours
Short answer, no.

But, consumers expect a infotainment user experience at least as good as
hanging an iPad in the car, and if your car doesn't provide that, they will
rate it poorly in surveys.

Source / Disclaimer - I work for GM.

------
mizzao
So despite the huge uproar at
[https://news.ycombinator.com/item?id=9921557](https://news.ycombinator.com/item?id=9921557),
it turns out the end did justify the means.

~~~
JeremyBanks
That only holds if there were no better means that could have achieved the
same ends.

~~~
mizzao
It's possible, but can you cite another example of when a news article caused
a recall to be issued a couple days later? It seems unlikely - usually takes
months if anything happens at all.

~~~
rhino369
Do you really think this article would be less successful if the driver was on
a test track?

~~~
jessaustin
Yes I think that. This was on local news early in the morning, just to cite
one source from which I rarely get hacking stories. Normally they just talk
about weather and how the elderly are getting scammed. This test occurring on
a public road created an effective visual, that pushed the story into many
more media channels.

~~~
MBCook
I think 'hackers turned off the breaks on a car with a reporter in it at
70mph' would have made headlines even if it took place on a test track. It's a
juicy story with plenty of 'it could happen to you' scare factor built in.

------
fauigerzigerk
Auto makers will have to make sure that they can update their software
remotely or this going to become really expensive very soon.

~~~
mzs
What's to say this wasn't precisely that? Maybe at the talk we will learn that
accidentally uconnect was listening to the update FW messages from the sprint
network.

Often the board that handles the radio acts like a bridge in modern cars. It
tends to be the beefiest computer hardware in the vehicle. So it is on the
high speed CAN bus and a node on the more star shaped low speed bus.

When they updated the FW, they removed the bit of code that prevented
dangerous messages IDs from leaving the controllers on the radio board and
possibly added code that could put arbitrary CAN bus messages on the buses as
relay from the sprint network.

I am very eagerly awaiting the talk.

------
nissehulth
They claim that only US cars are affected. Is this because liability costs are
much higher in the US or is there really a different software used in the rest
of the world?

~~~
maxerickson
It could also be related to the cell network used.

~~~
nissehulth
Good point. I guess there could also be some other service involved that's US
only, something like OnStar.

------
bithead
> _" I wonder what is cheaper, designing secure cars or doing recalls?"_

Ever the enduring question

------
satyajeet23
If you have to update software in person, you shouldn't be in the software
business.

------
curiousjorge
Why does Jeep in particular have so much issue with quality assurance? The
most memorable is the SUV rolling over in a simple test a couple years ago
which have been fixed but it's quite worrying.

[https://www.youtube.com/watch?v=zaYFLb8WMGM](https://www.youtube.com/watch?v=zaYFLb8WMGM)

~~~
dsfyu404ed
First off that test is somewhat of a joke for SUVs since it basically rewards
car-ish handling which is at odds with the truck-ish performance that is
demanded of larger SUVs

In terms of comparing two different vehicles...

If the $year base model $carA has a suspension system closer in performance to
the sport model of $year $carB but for $year+1 they put a much softer
suspension in the base model of $carA in response to customer feedback then
the results go out the window. Alternatively, if the OE tires are particularly
expensive then you can bet that most owners will replace them with cheaper
one. Additionally, particular trims are often incredibly rare or almost always
have a particular option added. So testing a $trim without $package will be of
little meaning when the vast majority of $trim that make it to dealer lots
will have $package. In either case the results go out the window because
there's a handful of large variables that are uncontrolled for. It's little
better than the comparisons you see in car commercials.

If you actually want to grill Jeep over something I suggest you read up on 90s
XJ gas tank fires.

