
Volkswagen’s Diesel Fraud Makes Critic of Secret Code a Prophet - nkurz
http://www.nytimes.com/2015/09/23/nyregion/volkswagens-diesel-fraud-makes-critic-of-secret-code-a-prophet.html?_r=0
======
silverpikezero
This would be a good time to point out that a similar auto software story
found its way to HN recently:
[https://news.ycombinator.com/item?id=9643204](https://news.ycombinator.com/item?id=9643204)
Once Toyota's ECU code was reviewed by domain experts, they found
extraordinary lapses in basic software quality practices. This and the VW
fiasco clearly show that hiding ECU code is the wrong way to go. We can
directly measure the negative consequences, and these are only _2_ such
incidents discovered recently. Who knows how many more issues are still
hiding. We won't really know how at risk we are unless there is some kind of
3rd party review process, required by law. Clearly, the auto industry will
prioritize profits and liability over actual quality, in much the same way
that banks will never voluntarily limit their risk at the sacrifice of
profits. Self-regulation is not working.

~~~
InclinedPlane
I agree completely, but on the other hand I'm not convinced that tighter
government regulation of ECU code would be better. Can a bunch of government
bureaucrats come up with a set of standards and regulations that would
actually be beneficial? Given the track record with similar projects, it looks
doubtful.

Really I'd say that part of the problem here is that academia has been letting
us down. CS programs are universally of fairly low quality, in my opinion, and
proper software engineering programs are very rare. There has been
insufficient pure research into software development practices, software
design patterns and features, and so on in regards to what is required and
what is beneficial when it comes to creating control software and firmware.
Industry too has been letting us down with their lack of pure research in
general, but that's been obvious for a while.

We're starting to reap what we've been sowing for the last several decades in
software engineering. We got out of the first "software crisis" where many
software projects didn't even deliver anything worthwhile or functional, but
now we are in another perhaps even more severe software crisis. One where
shipping software that "works" isn't a problem, but where making sure that it
does the "right thing" and is sufficiently secure, robust, etc. for the
intended use is becoming a huge issue. And not just a financial one, but one
that can (and will, and has) result in injury, death, and destruction. We very
much need to wake up to the seriousness of this problem, it's not going to get
better without concerted efforts to fix it.

~~~
adrianN
I develop safety critical software for railway applications. We have to follow
some ISO norms that contain some sensible rules. For example, code reviews are
mandatory, we need to have 100% test coverage, the person who writes the tests
must be different from the person who writes the code etc. This leads to
reasonably good code.

It also makes some things a lot more difficult. For example the compiler must
be certified by a government authority. This means we're stuck with a compiler
nobody ever heard of that contains known (and unknown) bugs that can't be
fixed because that would mean losing the certification.

I assume the car industry has a similar set of rules and the problem is not a
lack of rules, but a lack of enforcement.

~~~
RealityVoid
> We have to follow some ISO norms that contain some sensible rules. For
> example, code reviews are mandatory, we need to have 100% test coverage, the
> person who writes the tests must be different from the person who writes the
> code etc.

The exact same thing happens in the car industry.

> I assume the car industry has a similar set of rules and the problem is not
> a lack of rules, but a lack of enforcement.

Bingo! Right now I'm staring at some ECU code(not safety relevant, thankfully)
that looks like it's been written by a monkey, but I'm a new addition to the
team, have no authority here yet and we have to ship it like yesterday.

Guess what will happen.

Truth be told, for safety relevant applications, I've seen the code and it's
quite good. And the issue in this case is not that the software was badly
built, it's that it was built with deceit on their mind.

~~~
pbhjpbhj
>some ECU code(not safety relevant, thankfully) //

What parts of the running of an automobile engine aren't safety relevant?

Sounds like "oh we made the stock for that shotgun from cheap, brittle plastic
as the stock isn't safety relevant; how were we to know that it would crack
and embed itself in someones shoulder?".

You're right that the primary issue here is deceit but the issue of closed
source code in such systems is how that deceit was possible [edit, should
probably say "facilitated that deceit" as the deceit would still be possible,
just harder and move discoverable with open source]; and that leads to
questions of safety as if companies will screw over the environment against
the democratic legislation then they're unlikely to be mindful of other
morally negative consequences.

~~~
Too
Infotainment, air conditioning, etc. There are many many more ECUs in a car
than just the one in the engine.

------
credo
I think the Volkswagen episode shows that we need better emission testing
mechanisms.

Demanding that all code be open-source unfairly targets the software industry
(companies that sell software products for money). Why not ask Google to make
their search engine code public ? If all software code must be publicly
available, why not demand that Coca Cola also make their formula and their
entire manufacturing process public ? Why not insist that no product must have
any proprietary/secret information about how the product was created ?

Ultimately, the proof is in the pudding. I think we need a better emission
testing system for testing emissions, not a government review of software
code.

IMO asking for free software code is an ideological demand that is better
promoted through the free market. Free software ideologues should refuse to
buy products that have proprietary components, but all of us should only ask
that the government fix its emission testing process.

~~~
lemming
_Why not ask Google to make their search engine code public?_

That's a great question - why not? For many consumers, Google essentially _is_
the internet, and by meddling with search results (which they already do to
try to personalise my results) they could make or break companies or
politicians by presenting one-sided or even false material. That's a lot of
power - why shouldn't we know how it works to make sure they're not abusing
it?

~~~
danso
Why do you need to see Google's source code when you already know that Google
is personalizing the search results for you? Hypothetically, what kind of
parameters discernible in Google's search code would make the difference
between "OK meddling" versus "Evil meddling"?

The bigger question is: why do you think that there is some kind of pure,
objective ranking of websites that Google is now tampering with? Do you think
that someone whose IP is located in Utah should get the same result for "good
hamburgers late night" as someone in New York? If someone from Vietnam
searches for "Vietnam War"...should they be sent to the entry at
vi.wikipedia.org because it's in Vietnamese and perhaps more relevant to the
Vietnam user? Or to en.wikipedia.org's version, because besides having a
shitton more inbound links, it's likely to have also many, many more eyes and
editors on it? These are complicated things that we don't need a review of
source code to debate. But your suspicions toward them seems to be based off
of a worldview in which there is One True Web for everyone, which seems as
problematic as the mindset that surely Google can do no evil.

Given that Google uses personal data to shape the web its users see...isn't it
even more relevant to see the data they collect? AFAIK, Google still allows us
to download virtually every bit of data we've explicitly generated on its
services, including all the emails and search requests we've conducted.

~~~
thaumasiotes
> If someone from Vietnam searches for "Vietnam War"...should they be sent to
> the entry at vi.wikipedia.org because it's in Vietnamese and perhaps more
> relevant to the Vietnam user? Or to en.wikipedia.org's version, because
> besides having a shitton more inbound links, it's likely to have also many,
> many more eyes and editors on it? These are complicated things

I don't find this one so complicated; they're better sent to en.wikipedia.org,
because that page, like their query, is written in english.

~~~
danso
Sorry if this is already evident to you...but the differences between
Wikipedia sites is not just about the language. vi.wikipedia.org is
independently edited and maintained from en.wikipedia.org. The Vietnamese
wikipedia page [1] is not as lengthy as the English one. And I'm not as good
as reading Vietnamese as I should be, but the Vietnamese page doesn't seem to
have the same content for "Media and censorship" that the English one
does...among other differences. So I don't think it's as simple as "Send them
to whatever language they used" (though I guess this is one case where seeing
Google's source code would be enlightening, so...touché?)

[1]
[https://vi.wikipedia.org/wiki/Việt_Nam](https://vi.wikipedia.org/wiki/Việt_Nam)

~~~
thaumasiotes
I have no doubt that the English page is higher quality than the Vietnamese
one. That won't matter at all unless the person searching can read English.
When looking for information, there are no concerns greater than "even if I
find it, can I understand it?"

Even if the Vietnamese page were better, there's no excuse for replying to an
English query with a Vietnamese result.

------
Angostura
Hopefully, the Volkswagen events may make people think rather more about what
is going on in their voting machines.

~~~
logfromblammo
I am up-voting you _so hard_ right now. I really, really want it to be true.

But I doubt that anyone even remotely likely to connect those two dots will be
allowed anywhere near the camera lenses of any company that broadcasts
television.

The source code to one of Diebold Elections Systems (now dba Premier Elections
Systems) voting machines was leaked in 2003, which summoned blackboxvoting.org
into existence.

As far as I know, every voting machine system that has been examined since
then has been found to have potential attack vectors large enough to fly an
intercontinental airliner through. When the public records are examined, the
audit trail is often nonexistent, destroyed, or falsified.

In the 12 years since then, the only meaningful result has been to end the
practice of exit polling in the U.S. Yep, rather than explain the
discrepancies between statistical sampling methods and the official results,
we chose to stop sampling and trust the results.

So some academics apply statistical methods to the official results, to show
convincing evidence that one major party or the other, or both, are blatantly
cheating using specific voting machine systems.

You can hear those crickets chirping over the din of the absolute silence.

~But hey, let's all get worked up over homosexual marriage and Syrian
refugees, mmkay? The 2016 national elections will be _perfectly fair and
honest_ , and not cracked and defrauded at the central tabulators _at all_.
And since there's no cheating going on there, there certainly wouldn't be any
at the primary level, with lower levels of scrutiny.~

Open source is democratic, but democracy certainly isn't open source.

~~~
webXL
Why did we end exit polling? Seems like an obvious counter-measure/check.

I don't trust for-profit media to conduct them. This is something that we all
need to chip in to accomplish, if we care about democracy. If we can't trust
election results, we really can't trust anything connected to government, and
as the state continues to grow, that's very little.

~~~
logfromblammo
There are two reasons.

Firstly, they were diverging from official results. There are two possible
reasons. Reason one would be that the exit polls were not accurately
reflecting the will of the people. Reason two would be that the official
results were not accurately reflecting the will of the people. It could be
both.

Since reason two would have been too uncomfortable to consider, reason one was
chosen. And the exit polls dried up.

It is not even widely known that prior to ending the polling completely, the
pollsters were already applying statistically-calculated adjustment factors
before reporting the poll results on air, in order to force the polling
numbers to predict the official results more accurately.

I don't even need to put my foil hat on to say that I trust a statistical
prediction made by blindly sampling from a random pool of volunteer
respondents over a secret-source black box that pretends to be counting votes,
where there is significant incentive to cheat.

The great thing about exit polling is that _anyone_ could do them, and publish
the results along with their margin of error. And some people still do. They
just don't get reported on television during elections night coverage any
more.

The second reason is that news programs are now reporting official results, as
they are tallied and reported by those black box computer systems. The
computers can count electronic ballots quickly enough to report initial
results shortly after voting booths close. Exit polls lost the advantage of
speed. The television news programs like to be able to project the likely
winners as soon as possible, and preferably before any competitors. By the
time the hand-counted paper ballot areas finish reporting, the winners have
already been known for hours, if not days.

~~~
webXL
Seems like this trust issue could be solved with a bit of cryptography. A
search for "blockchain elections" turned up some interesting proposals.
[http://www.bitcongress.org/](http://www.bitcongress.org/) seems like it's
being served over 28k modem though.

------
seibelj
My company, like most companies, relies on an enormous amount of open source
code in order to construct a closed source product.

We have also contributed to open source, and have plans to contribute more.
There are certain things that help everyone without jeopardizing our business,
and other things that are too valuable to share.

We cannot force a company to open source code without an extraordinarily good
reason. I believe in open source and support it, but at the application level
it is a trickier issue.

~~~
throwaway7767
> We cannot force a company to open source code without an extraordinarily
> good reason. I believe in open source and support it, but at the application
> level it is a trickier issue.

The fact that human lives depend on the correct functioning of the code is an
extraordinarily good reason. IMO, any code that can affect driving safety
should be required to be released (note: this does not mean that the companies
must relenquish any copyright claims, just that the code has to be publicly
available for inspection).

Right now this is hard to do because all the auto manufacturers like to have
everything connected, so the result of this would be that everything including
the in-vehicle entertainment system would have to be open-sourced. But that's
the point - such a requirement would overnight force the manufacturers to
implement a proper seperation between critical software and non-critical, so
that they could keep the non-critical stuff closed.

------
s0rce
I'm curious how other companies did not know about this. Did engineers at
GM/Chevy not inspect the VW product and figure out that it was cheating or
even suspect that their competitor couldn't have some sort of magic
engineering snake oil to pass emissions.

~~~
etep
Great question. I've seen companies with entire teams dedicated to dissecting
the performance claims of the competition, and then running their own tests to
verify and/or debunk the same. Keeps everyone honest, and it prods along the
in-house engineering effort. Why didn't the other automakers see this?

~~~
cpeterso
Maybe other car companies don't want to know because VW is not the only guilty
company? What are the odds that only one car company cheated on only one car
model?

------
LVB
I understand and sympathize with this point of view, but I have no idea how it
would work out practically. Software patents are rightly criticized and I
don't think they should be the avenue to recapture investment. But if you also
remove trade secrets, the dynamics behind expensive R&D would certainly be a
lot different.

I used to work for a company that produced diesel engine. Trying to pass ever
stringent emissions meant massive capital investment and millions of dollars
in research and testing. The "secret sauce" ends up being a few thousand lines
of code and lots of constants. It is literally the make-or-break factor in
whether a manufacturer can sell a product or not. If all results had to be
immediately shared, what happens to the competitive zeal?

My most optimistic perspective is that critical pieces of software just become
common, with everyone latching onto the best option available. There is still
plenty of room to differentiate, especially in something like a car, and that
the sharing would be just generally beneficial.

But will the real breakthroughs still occur if there isn't the potential to be
substantially better (and substantially rewarded) at some fundamental factor,
like fuel efficiency?

~~~
alkonaut
Hopefully any system of "code inspection" could be done by authorities, and
not require the code to be public.

As an example: I'm not sure, but I believe the Nevada Gaming Control Board
inspects the source code of gambling machines in Las Vegas casinos. This
doesn't mean the casinos can't have secrets in the source code, it just means
that the authority sees all the secrets.

I do think however that "code inspection" for engine control units is a dead
end. Writing underhanded code that appears to do X but instead does Y is so
easy. (See
e.g.[http://www.underhanded-c.org/](http://www.underhanded-c.org/)).
Inspecting a 100k C-program for illegal behaviour won't be doable until the
next years model is out, at which point it's time to start again.

The solution is to treat the code as a black box, and just test it as a black
by casting a wide net. The problem is the reliance on simple lab tests that
are easily fooled.

------
vetler
Somewhere, this software sits in a source code repository. Someone planned it,
wrote it, reviewed it and approved it. Where are these people, and why are
they not speaking up? Why have there not been any whistleblowing on this, it's
huge?!

~~~
pt3530
What I have seen missing from most reports is that VW does not make the ECUs.
Consumer reports has reported[1] that Bosch was the company that produced
these ECU. So Bosch should have the repository and should have a request from
VW to implement this particular code. I wonder if Bosch will be forced to
throw VW under the bus.

[[http://www.consumerreports.org/cro/cars/volkswagen-
emissions...](http://www.consumerreports.org/cro/cars/volkswagen-emissions-
cheat-exploited-test-mode.htm)]

~~~
seren
If this is provided by a third-parties, there is a requirement written
somewhere for the supplier to have two different modes of operation, one for
test and one for road. This is likely redacted to be innocent sounding, but
there is definitely a DOORS history that would give the date and the name of
the people who have written the requirements.

However there might be some good reason to have a test mode, for engineering
tests, for example. The culprit would be the one who have decided to ship it
and activate in production.

~~~
cakes
This is definitely a question I have especially since in my experience
sometimes you had trade-offs due to other restrictions so every functional
item needed to have value and new functionality may require
removing/changing/disabling other functionality.

------
bmaupin
"A group of automobile manufacturers said that opening the code to scrutiny
could create 'serious threats to safety and security.' And two months ago, the
E.P.A. said it, too, opposed such a move because people might try to reprogram
their cars to beat emission rules."

Oh, the irony.

------
snowwrestler
I think that the code that operates dangerous machines should be publicly
available. I think that applying the DMCA to keep it hidden is a bad
application of that law.

The DMCA was intended to protect creative works like movies or songs, where
the whole value is in the encoded file.

Code that runs a car is the opposite: it is worthless by itself. Keeping it
hidden from the public just enables bad behavior, like Toyota's terrible code
or VW's deception.

~~~
x5n1
Yes but it gives it to competitors as well, which is a problem.

~~~
phire
But your competitors can't really steal it, because they are subject to the
same rules and have to make their code available too. So any theft of code
will be apparent.

Manufactures will probably check each others code to make sure none of their
own code has been stolen and file lawsuits if it has.

~~~
ernsheong
There's still China you know. They don't play by the rules and copy everything
relentlessly.

------
ekianjo
No mention of RMS as an earlier prophet ?

~~~
oska
Eben Moglen has had a long history with the Free Software Foundation. He co-
drafted version 3 of the GPL and still serves as their legal counsel. It's not
necessary to mention RMS every time other leaders of the Free Software
movement make a comment on something, unless it's something specific RMS has
said on the subject.

------
d_theorist
VW could have given the EPA the complete source code for its system, and it
would likely have made no difference.

The main thing preventing inspect-ability isn't lack of access to the code.
It's the incredible complexity of the software. Even barring deliberate
attempts at code obfuscation, it would be prohibitively time-consuming and
expensive for the EPA to gain any sort of understanding of a codebase of this
size.

Comparing a complex software system to an elevator is absurd.

~~~
krupan
"The main thing preventing inspect-ability isn't lack of access to the code."

No, I'm pretty sure you can't inspect code that you don't have access too.

I get what you are saying about complexity, but I don't think that's an
argument for prohibiting inspection altogether. This story directly
illustrates that there was at least for this particular car a group of people
will and able to inspect at least a particular part of the code, if they had
access to it.

~~~
d_theorist
>This story directly illustrates that there was at least for this particular
car a group of people will and able to inspect at least a particular part of
the code, if they had access to it.

How does it illustrate that?

They discovered the scam by doing _better emissions testing_ not by reverse
engineering the code.

~~~
breischl
That's true, but then there followed a long time (18 months?) in which VW
denied any wrongdoing, and nobody could really prove them wrong. If the source
code were available, the investigators could have quickly gone from "this
looks wrong" to "hey, check out this really sketchy source code!" It might
also prove that it was deliberate, rather than a complicated accident.

Also, I have a hunch that they wouldn't have done it in the first place. If
you know your code is going to be public that's an incentive not to do bad
things, even if there's a chance nobody will ever read it.

~~~
d_theorist
>Also, I have a hunch that they wouldn't have done it in the first place.

That's a good point. But, I see no practical way to enforce that the source
code that has been published is actually the same as that running on the car.
Not without prohibitively slowing the pace of development.

> the investigators could have quickly gone from "this looks wrong" to "hey,
> check out this really sketchy source code!"

I really don't think this is true. Not quickly. The investigators would have
be a big team of expensive code audit experts to achieve this. And, even then,
if the authors wanted to, they could easily obfuscate the code to the point of
making it effectively unfindable.

Apple can't even guarantee that the apps it's auditing for inclusion on the
app store are malware free. And that's _Apple_. And apps are relatively simple
compared with the codebase for a modern automobile.

The real way to fix this is just to have better and harder-to-defeat testing
procedures.

~~~
breischl
>>I see no practical way to enforce that the source code that has been
published is actually the same as that running on the car.

I was going to say that you could dump the code from a random vehicle and
compare the hashes. But I suppose that would require having the entire
toolchain to go from source to shipped code.

>>Not quickly.

Perhaps I should've said "more quickly." You've got a point that it's
difficult to verify that code doesn't do anything bad. However, it's
_relatively_ easy to start from the notion that it's doing one particular bad
thing and then find the code that does it, which would've been the case here.

------
ChuckMcM
And here I thought it was going to be an article about Richard Stallman. :-) I
like the approach that proprietary software is an 'unsafe building material'
(or component). I think that is something non-technical folks can understand a
bit more easily than "software rights". I hope Stallman adds this approach to
his arsenal.

------
bcg1
Recording of Eben Moglen's speech, if you'd like to listen instead of reading
the transcript:

[http://www.softwarefreedom.org/podcast/2010/jul/20/episode-0...](http://www.softwarefreedom.org/podcast/2010/jul/20/episode-0x2c-eben-
software-liability/)

------
tomphoolery
The amount of logic that went into this program just so Volkswagen wouldn't
have to lessen their emissions seems...illogical. Did it really cost less to
build, QA and deploy this software (and keep it under wraps for this long)
than it would have to just fix the damn engines?!

~~~
function_seven
Just like "good, fast, cheap: pick two" there's a similar rule in automotive
tuning: "Fast, efficient, clean: pick two"

VW decided to go for all three.

~~~
chao-
That's an interesting comparison. What would it mean, from a mechanical or
chemical perspective, for an engine (or the whole car?) to be both very fast
and very clean, but not efficient? Does not the inefficiency also lead to a
lessening of cleanliness?

I know that would probably require defining "clean" as distinct from
"efficient", I simply know very little about cars and so the fast+clean idea
feels a little off, and I'd like to know where I'm wrong.

~~~
function_seven
> Does not the inefficiency also lead to a lessening of cleanliness?

All depends on what we're measuring. In the case of VW, it's the NOx limits
that they were cheating on. In order to reduce NOx, you can run a richer
air/fuel mixture, which consumes more fuel and is thus inefficient.

If you're instead talking about C02, then you're generally right. Efficiency
and cleanliness are aligned.

And my original comment could probably be rephrased as, "fast, clean,
efficient, reliable, cheap: pick any three". But that doesn't have zing to it
:-)

------
dragony4
You really believe it was only VW doing this and not other companies? And it
was miraculously discovered and not part of automotive war?

~~~
JanneVee
The Swedish transport agency found that Volvo, BMW and VW had ten times as
much nitrous oxide in roadtest than labtests. So it might be automotive war.

------
gaius
I certainly hope Google will open-source their self-driving car code before it
is let loose on the public roads.

~~~
wodenokoto
That wouldn't matter. We don't know how to inspect a trained deep neural net.
No one knows how the car drives.

~~~
davmre
A trained network should be considered compiled code. It's almost literally a
circuit wiring diagram, the lowest level of all code representations.

Arguably the "source" in this case is the dataset used to train the model,
along with the learning algorithm. If the data are released, so that you can
inspect them and replicate the network weights yourself with an off-the-shelf
learner, that's a reasonably good sign that nothing nefarious is going on
inside the system. (though not strictly a guarantee: you could imagine someone
searching very hard to find an innocuous-looking training set that somehow
encodes malicious behavior)

------
alansmitheebk
This would be a great time to point out that the diesel engine was originally
intended to be run on peanut oil. Any diesel automobile can run on "bio-
diesel" with no additional modifications. You may be (un)surprised to learn
that the inventor of the diesel engine died a rather mysterious death on a
trans-Atlantic cruise.

------
Pamar
Haven't read all the comments yet, so maybe others have commented on this
already, but I find the premise (critic of secret code validated by VW
scandal) weak.

According to the article:

“Proprietary software is an unsafe building material,” Mr. Moglen had said.
“You can’t inspect it.”

Except that in this specific case, it was the _builder_ who designed and
implemented something "faulty" precisely because they needed that. There is a
difference between installing a third-party set of windows and finding out
that it soon falls apart because the frame is defective, and installing
windows after you have secretly bored small holes in the frame (because you
have an interest in your tenants going overquota with their heating expenses).

------
cmurf
Making it possible to download the firmware as a binary blob, even if it's
encrypted, so that it can be hashed and compared to the published hash for the
version of the software that's supposed to be in the car; while also
publishing the source code of that version, doesn't in any way mean the user
has a way to modify the code, compile it, and install it into the car.

Now maybe the people talking about this to the reporter don't know this; but I
suspect people at the car manufactures know they could do this, they simply
don't want to, so they cherry pick b.s. arguments why disaster will strike if
code is published.

------
tefo-mohapi
I hear all this talk about how this software scandal by VW is pointing to the
end of diesel cars but this raises concerns about electric cars as they rely
heavily on software. We actually discuss this in this podcast
[http://www.africantechroundup.com/volkswagen-up-in-smoke-
as-...](http://www.africantechroundup.com/volkswagen-up-in-smoke-as-the-south-
african-government-is-set-to-investigate/) and even more concerning is when it
comes to self driving electric cars. Mmm...

------
clamprecht
I can't believe it - not a single comment about Richard Stallman (in the
article or this thread). When I read the title, I thought the article would be
_about_ Richard Stallman.

~~~
krupan
Richard Stallman's lawyer isn't close enough for you? :-)

------
acd
I want open firmware in my next laptop so its inspectable.

If you mix open source with closed firmwares you are half doing it. Half doing
it means there are potential malware lurking around hidden in some corner
where no one looks.

Richard Stallman has been right the whole time.

Also if the software is open there is possibility to maintain the code long
after the manufacturer makes the next model and loses interest in the old
device.

------
wedesoft
I think it's a really weird situation where everybody has painted themselves
into a corner:

* the emission tests are extremely tight

* the car industry is very competitive

* loosening emission standards would be a politial issue

As far as I know things started badly with emission tests not being
representative and car manufacturers doing cheap fixes to pass them. Now would
be a good time to fix this mess.

------
marcosscriven
In the article, they say the software detected the 'speed' of the vehicle
among other things. I always thought the speed was simply calculated as a
function of the wheel turning rate - unless the article really means
'acceleration', and there's such sensors in the car?

~~~
tajen
When the trajectory assistance detects that the front wheel spins at 60mph
whereas the back wheels are fixed, of course the code puts itself in a special
condition. Same goes if the wheel meets no resistance to acceleration. It's
either surfing on butter or in a garage.

~~~
marcosscriven
Interesting - didn't know a) that cars measured torque, or b) speed of the
unpowered wheels.

~~~
fianno
For the likes of ABS to work the car needs to know the speed of all wheels.

------
matthewaveryusa
>A group of automobile manufacturers said that opening the code to scrutiny
could create “serious threats to safety and security.”

I think it is tremendously difficult for the layman to understand that
obscurity is not security. In fact it's counter-intuitive at first.

~~~
gress
Obscurity is not security. True.

Transparency is not security. Also true.

~~~
davexunit
But transparency is a _prerequisite_ for security. Free software isn't
necessarily secure, but only if its free software can we check and verify or
fix it and distribute modified versions.

~~~
gress
That was true when the incentive was for vulnerabilities to be disclosed and
fixed for the good of all, but sadly today, vulnerabilities are extremely
valuable and so the incentive is for them to be sold to the powerful.

------
digitalneal
As a car guy, I fear this fraud is the symbolic fallen domino that will lead
to the end of my hobby of tweaking the tunes on the ECU of my Subaru WRX STi.

~~~
sounds
How will Volkswagen's cheating, or Eben Moglen for that matter, make it more
difficult to tinker with your car?

The Magnussen-Moss Act aside, auto makers seem to have failed to notice that
DMCA-ing their software has not stopped tweakers and modders.

It's so bad that John Deere doesn't want you to own your own tractor, just
"license" it from them [1] (ostensibly so that they can refuse to let you look
at the ECU). Would they take this step if they were confident in the DMCA's
protections?

Hollywood was the bellweather and tip-of-the-iceberg with DVD-CSS many years
ago.

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

------
venomsnake
Really? Can't I hack into the build chain and inject code while building. The
code will pure and clean like a ice block for sculpting.

------
jaybuff
"Reflections on Trusting Trust To what extent should one trust a statement
that a program is free of Trojan horses? Perhaps it is more important to trust
the people who wrote the software. "

[https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...](https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)

------
tibbon
If it was standard for the software on vehicles to be FOSS, this type of
problem wouldn't exist.

------
jd3
Stallman must be happy now that someone is actually listening (albeit; not to
him)

------
on_
Does external code review even matter? Leaving aside the difficulties of
fighting with lobbyists, entrenched companies, unions, IP risk and financial
obligations, (among many other points of friction) what is the upside?

OTA and continuous integration will only improve, and likely at a logarithmic
pace typical to other technological advancements. What if you during your
project you needed every line of code reviewed before it was deployed (you
probably do), but then a thrid party has to review it before you can ship it?
This would KILL turn around time.

Entire teams are devoted to writing and reviewing this software at every
company, and each continuous update. These updates can be rolled out daily,
weekly or monthly. It probably takes internal testing and internal reviewing
to push code. This is non-trivial and scales with the complexity of the
design. Further, as difficult as internal reviews and testing may be, it can
still be incorrect; even when the reviewers have intimate knowledge of the
entire codebase and the granular changes, source-code diffs, and commented
commit messages.

How many people do you reckon it would take to independently review every line
of code in production? At what level of inspection would you be able to
achieve a confidence level >90% that the code did what the developers allege
in a safe and sane manner? Open source works because people can contribute
code, fork-code and use the code they write and fork. Without these incentives
a decentralized community would be unlikely to contribute, review and maintain
proprietary code as they would be disincentivised from doing so as the IP
would be protected. The government or the auto-companies would do the reviews,
which outside of the massive cost (passed on to consumers) I will leave you to
work out the issues there.

Oh thanks for this grim view, it is fairly accurate, I disagree with X but on
balance maybe it is more true than false, what is the solution?

We open source the testing and make that public, and we don't need the actual
code to do this. Simple heuristics are developed for whatever we need to
optimize for.

* Safety works this way and is done really well, we smash some cars up, run some stress tests and qualify them.

* Manufacturers are required to publicly announce when they have pushed an update and the specific systems changed like a longer commit message with details of the system and changes.

* Third party tests are continuously upgraded for whatever the battery demanded by the market is.

This will create a market opportunity for someone to create value. They will
provide data and can sell it, distribute it or publish it. People will be
incentivised to write tests because they use vehicles and companies will want
to be auto-trends verified car of the year. If we accept that it will be
almost impossible to convince automakers to give up their IP and that the code
will regulalrly change making review prohibitivle expensive, this seems like
the only option.

Create in depth testing for emissions, safety, cruise control, privacy, data
transmission ETC and have that be governed as open source projects. Open up
bug bounties (either auto-trader/magazines/interested companies sponsor this
or automakers are incentivized to foot this bill). By bug bounty, I mean more
of audting the car and requirements, or if the companies allowed specific
features to have code reviewed like the Jeep hacking experiment.

This will happen anyway because people don't like their credit card data to be
stolen, and they don't like getting caught cheating on ashley madison, but
what they really don't like? Having their car remotely turned off, remotely
piloted using self-driving technology to the criminals dark layer or have
their car otherwise destroyed or used for crimes.

Review is coming, maybe even endorsed by automakers with some of their code
provided, but we can't expect the government to do a great job reviewing the
code, so let's just have an open-source testing model and develop better tests
for things we care about.

------
danso
I have mixed feelings about this. I mean, yeah, open source would definitely
alleviate this issue. I don't know enough about the state of car industry
software (if Honda is par for course...I'm guessing, based on my new car...not
that great?) but I imagine there would be unintended consequences that make
OSS a difficult pill to swallow for carmakers. But sure, if it's feasible,
make them do it.

...But my objection is that there seems to be many other ways that this
problem could be solved...For example, perhaps the certification process
should be slightly more rigorous than "self certification"? Obviously, testing
is cumbersome if the EPA can only test "10 to 15 percent" of new cars...on the
other hand, it sounds like WVU engineers were able to discover it
_accidentally_ without touching the software...which is how a lot of effective
engineering testing manages to be done despite black box systems.

Yeah, making software transparent is almost always a good thing...but if the
test has the kind of predictable characteristics such that programmers can
seemingly hard code the parameters...Is it really easier to move an entire
industry to the open source paradigm than to design a more robust test?

And not to throw too much pity on the regulators...but they were dealing with
an exceptionally committed adversary. It's horrible how GM's culture allowed
the ignition switch defect [1] to go unrecalled until a dozen people died in
such senseless ways...but the ignition switch defect was a result of well-
intended, if ultimately incorrect tradeoffs in the engineering process. And
the deaths were far enough apart, and their cause not certain enough, for
good-hearted engineers to have a "well, someone above my pay grade is dealing
with this" mentality.

But VW's situation...it's hard to imagine how the bad code came about
_without_ active intent by everyone who touched and tested that code. It's one
thing for a huge company to have the kind of bureaucratic stagnancy that leads
to tragic inaction...it's something else for them to commit to breaking the
law in such an obvious way.

[1] [http://www.npr.org/2014/03/31/297312252/the-long-road-to-
gms...](http://www.npr.org/2014/03/31/297312252/the-long-road-to-gms-ignition-
switch-recall)

edit: It really just seems the OP is throwing a bunch of assertions together,
with software being the most mysterious and therefore the most obvious
scapegoat. The advocate/technologist most prominently featured doesn't make
cogent arguments (though maybe he was misquoted?).

The following quote from Mr. Moglen is so nonsensical that it could only make
sense to people whose understanding of computers seems very limited:

> _“Software is in everything,” he said, citing airplanes, medical devices and
> cars, much of it proprietary and thus invisible. “We shouldn’t use it for
> purposes that could conceivably cause harm, like running personal computers,
> let alone should we use it for things like anti-lock brakes or throttle
> control in automobiles.”_

Huh? If software shouldn't be allowed to run personal computers, because PCs
can cause harm...then...huh?

~~~
etherealmachine
I've seen a lot of comments on this topic discussing the issues manufacturers
might have with releasing their code as "open source". I say odd because it's
orthogonal to the issue here. No one (not even the EFF) seems to want to force
auto makers to open source their code - not even if you use a bastardized
meaning of open source like Microsoft's "Shared Source". What most articles
I've seen propose is instead that it not be a felony to copy, reverse engineer
and then inspect the code. Some articles have mentioned letting regulators
inspect code, but most stick to a simple request - remove the DMCA Anti-
Circumvention protection for automobile software. It's disconcerting to see a
relatively simple request be pushed into straw-man territory of requiring all
code be open sourced.

~~~
danso
Of the DMCA issue, I definitely agree. If that's the main obstacle preventing
a more transparent way to scrutinize automakers' software (among the many
other kinds of software the DMCA negatively impacts)...it's hard to see the
downside of fixing the law.

