Some details emerging from a new horrifying crash are different than most Tesla crashes, and yet sadly overall it is the same story.

Driving his Dodge Challenger ScatPack, which he certainly loved as much as he loved working with patients at Newman Family Dental, Dr. Clifford was on the road. However, on this ill-fated day, tragedy struck as his car was involved in a collision with a Tesla Model S.

Here’s what’s different: Every report I’ve seen makes very special mention of the model of the victim’s car. That ScatPack seems to be revered in Detroit news reports almost as much as human life.

The term ScatPack is what Dodge brands its cars that can run the quarter mile under 14 seconds. More importantly, it’s a nod to some specific Motor City history. ScatPack established a club for Dodge-enthusiasts to come together and honor hard-working, hard-charging dreamers. It meant paying a couple bucks to become a card-carrying member, with regular magazine and newsletter updates, a bumper sticker and colorful patch.

ScatCity epitomized 1970s pride in American muscle car community. This car probably meant the world to its owner, his family, their neighbors….

The crash scene suggests the Tesla flew at extreme speed southbound through an intersection, like a cruise missile straight into the rear of the ScatPack.

The ScatPack owner worked in a nearby office on northbound US-24 and was returning home. It will be interesting to find out if he made a left turn onto west-bound Carlysle and then onto south-bound US-24. In other words he may have pulled out and then turned in front of an oncoming Tesla that blew a red light and blindly slammed into him.

That would help explain why the Tesla traveling south-bound at extreme speed struck it from behind… related to the well-known “Autopilot” design flaw that fails to calculate for cross traffic.

Here’s what’s the same: the Tesla “Autopilot” keeps fatally slamming into vehicles slowly pulling out onto a highway. Impact with such high speed difference is a known long-standing design flaw — unfixed since 2016 — that begs why Tesla is still allowed to operate on public roads.

Authorities say that despite emergency response the ScatPack owner died soon after due to a “medical episode”. I wonder if he had a heart attack when he realized the loss to ScatCity.

In January of this year I mentioned how Tesla crashes were being reported as suicides.

You may remember also in January a doctor was accused of intentionally using a Tesla to try and kill himself and his family by driving off Devil’s Slide cliff.

Now a medical examiner says a 41 year old psychiatrist from California used a Tesla to kill himself with blunt force on a remote and empty rural road in Spokane County, Washington.

Goodwin crashed his Tesla at the intersection of East Truax Road and East Old Truax Road. His cause of death was listed as blunt force injuries.

Other than old utility poles and the above small grove of trees, the poorly marked rural road runs through open fields with nothing to crash into.

Blunt force trauma suggests he accelerated off the road into a tree the same as other recent veered Tesla crashes in Michigan, and North Carolina. What is the probability he was asleep (drugged) while speeding on back roads and the known faulty “Autopilot” decided to veer suddenly?

Did the examiner assume lack of brakes applied meant suicide, failing to account for the common and long-standing symptoms of critical Tesla design failures?

Or perhaps that’s the point, and this examiner is suggesting to us everyone in a “blaze your glory” Tesla at this point has to be assumed to be suicidal.

Goodwin had been investigated over several months for accusations of sexually assaulting drugged patients, losing his license more than a year ago. At least he harmed only himself in this latest assault, unlike the suicidal Tesla in Oregon whose “blaze of glory” just killed an innocent woman driving another car.

The new cranky privacy report from Mozilla on car data is a useful point in time analysis… unmoored from the past and lacking suggestions for what to do in the future. Give it a read and ask yourself when things will change and why.

I am reminded of my 2019 blog post about 2012 research:

I’d say the problem is so old we’re already at the solutions phase, long past the identification and criticism.

Has it been 10 years already? You’d think I’d be excited for Mozilla to be pounding their drum so OEMs would rush into my welcoming arms. Alas, I am not sure it helps.

Earlier this year I was talking with data scientists inside a huge OEM and they said things like “wish I knew earlier about the solutions available, because the project just finished with some bad privacy compromises and will be released in a couple years”.

They know privacy is broken, because they have known for a decade, yet they still don’t know what they can do instead. That’s why the Mozilla report to them is ineffective, like a drop of rain in a hailstorm.

…according to our research, they are all bad! On top of all that, researching cars and privacy was one of the hardest undertakings we as privacy researchers have ever had.

.

^^^ That’s the world’s smallest violin playing for Mozilla researchers showing up suddenly and saying they had a very hard time researching car data.

*shakes fist

You kids, back in my day we walked uphill in snowstorms both ways to assess car data safety!

Here’s a fun fact: in 1999 it took me 30 seconds to install RedHat on an IBM 8-CPU Server with fiber NAS designed for Detroit OEM data analysis. I found some security flaws of course (it fell over if more than five virtual machines pushed via X to remote terminals, and it leaked metadata)… but I digress.

Let’s be honest here. The Mozilla narrative of “they are all bad” is lazy, the easiest form of research. It reinforces a deeper problem of coming up with no incentives for change. Mozilla is doing the opposite of “nudge” theory. Do they not have any economists on staff?

The report team even readily admits to using a counter-productive binary analysis for their entirely unsympathetic bashing of manufacturing. It’s easier to call everything bad for smash and grab headlines than do deeper nuanced analysis and open pathways to change.

Blurry, complex and messy things actually are hard and worth doing, so if some “news” interloper shows up to say it’s all bad… easy for OEMs to sit back and say they can do nothing. “We’re bad, impossible to be good, oh well”.

Mozilla says cars capturing customer “sexual activity” data is bad, for example, with absolutely no thought about why anyone designing seat recliners and center consoles would want to look into that ever.

Good/bad, leaves no venue for the process of getting better and even encourages cheats to just flip a score. I am reminded of the Tesla CEO yelling “fix this now so I won’t have to care” for everything without any real understanding of why complex interconnected things become so broken. His binary thinking led to coverups (bad flipped artificially to good) and has been getting hundreds of people killed unnecessarily.

To me there’s a huge missed opportunity for Mozilla to engage with data security experts, architects of information safety, and discuss what’s really possible for car privacy and therefore what’s next for OEMs. Let’s talk about goals for privacy change 12 months from now, 36 months…

Solutions exist.

The technology is ready.

Here’s one answer that an OEM just told me they liked, to drive out of the senseless “car data privacy sucks” headline loop while delivering data-driven consoles: solidproject.org

Try it. It’s not all bad.