Examining, reporting, and eventually litigating the ins and outs of emissions control software is beside the point. This could have been, was, detected by measuring the junk coming out the tailpipe.
The thing to do is to allow researchers to test cars in realworld situations and then actually listen to them when they report anomalies.
I think you are dangerously wrong on that point. Of course the EFF has an agenda which colours their argument, but right now the DMCA is being used to prevent independent scrutiny of devices that are essential to people's lives.
"Testing cars in real-world situations" is only a small part of a vehicle testing procedure. Remember the Toyota uncontrolled acceleration thingy? That was tested in real-world situations multiple times, yet still people died because of it. Toyota had been succesfully dodging liability until they were forced to open up their source code.
"Listen to researchers" is moot if the researchers are forbidden from researching parts independently.
America's sheer size and influence dominates the world. Even in fields that are not of concern to the rest of the world, countries tow the line to keep this gorilla happy.
True - none of our politicians are going to take on the gorilla. It would only hurt them and us. So if it wants the gorilla gets to set the rules for everyone else - vote or no vote.
That is a self fulfilling prophecy. It is quite ironic that a European company has devolved to committing fraud to try to get around stricter emission rules in the US.
The big if here is that anyone would have bothered in the first place. There are far more enticing targets the DMCA puts out of reach, emission software doesn't ever seem to get mention but we can sure it will in the future.
What I want to see is that all current cars are put through the wringer to insure no other manufacturer is gaming the system.
That's still reactionary policy: "Ooh, we discovered it's possible to game the system doing X. Let's do more black-box testing and specifically look for X." I agree that's par for the course for the hamstrung Congress, but let's not taint ideological discourse with pessimistic realism.
It's also ignoring the larger picture, which I've seen echoed more across this thread: the software governing physical processes should not receive more protection than the physical process itself. Black-box testing is a very poor substitute for dismantling and testing each part in isolation, and if manufacturers are able to subvert regulation by encoding the more useful bits in software and then claim "IP" or "DMCA", expect to see more of these things in the future, not less.
So personally, I would go much further in my suggested response (but I'm not a politician): given the active subversion performed here, I would halt all sales and imports of VW products until they share all source code for their entire (US) range. That should serve as a better deterrent than fines IMHO.
> So personally, I would go much further in my suggested response (but I'm not a politician): given the active subversion performed here, I would halt all sales and imports of VW products until they share all source code for their entire (US) range. That should serve as a better deterrent than fines IMHO.
Why not just require that for all cars? It seems a completely sensible policy. Just doing it after a manufacturer has been caught cheating is a reactionary view too.
>> I think you are dangerously wrong on that point. Of course the EFF has an agenda which colours their argument, but right now the DMCA is being used to prevent independent scrutiny of devices that are essential to people's lives.
How so? I think the EFF is going a bit off track here. They seem to imply that source code is required for independent testing. If we assume that's true, who gets to see it? How do they get to use it?
Emissions tests are circumvented by knowing the test conditions and/or sequence and having software behave differently during the test. You can either try to understand the software, or you can just change your testing sequence. Which seems more reasonable?
Now what if China wants to see your code to verify compliance? And Germany, and France, and every country to sell cars in.
>They seem to imply that source code is required for independent testing.
That is most certainly NOT what the EFF is implying. They are asking for an exemption to the DMCA, not access to anyone's original source code. When they say "Automakers argue that it’s unlawful for independent researchers to look at the code that controls vehicles without the manufacturer’s permission," they're not talking about "you should have a legal obligation to give us your human-readable source code," they're talking about "You shouldn't be able to sue us for copyright infringement when we analyze the firmware on our cars." Car manufacturers argue that people don't really own cars, and that any attempt to look at the software that manages them is in violation of the DMCA.You can read more about it here:
The kind of thing the EFF is trying to legally access is already shipped in every vehicle that goes to China (or anywhere), where they don't have the DMCA and probably are already examining it - just not for our benefit.
> If we assume that's true, who gets to see it? How do they get to use it?
Everyone? What would be the harm?
> Now what if China wants to see your code to verify compliance? And Germany, and France, and every country to sell cars in.
Show them the code.
Before cars were run with software, it was possible to buy a car, take it apart, measure every single part, and construct a copy. You could learn everything about a car by examining a car. The fact that this was possible did not prevent the U.S. auto industry from succeeding financially. It did not hurt anyone.
I can't think of a reason that would be different today. The DMCA was enacted to protected creative works, in which the IP represents the entirety of the value. Software that runs hardware is not the same thing and should not be accorded the same protections.
As we learned from Toyota, these protections have enabled absolutely terrible software development practices. Third-party inspection would provide pressure to improve that. Imagine if Consumer Reports had electric engineers and software engineers on staff and their car reviews included scores for code quality and proper safety checks. I think that would be good for everyone, including car companies.
I don't think they're implying that, I think they're saying that searching through the source code could have identified this issue years earlier, which I think is 100% possible, but not guaranteed.
I mean, how do you know the source code for this "cheat" wasn't 100% obvious, such that looking at the code would have revealed itself right away? Obviously, no one can know that right now, since it's protected under DMCA, but what if.....
A random sample of each make and model of car should be periodically put through far more stringent testing than normal, in an effort to catch this kind of thing. Allowing this cheat to go undetected for so long speaks to the failure of the testing regime.
Let's not pretend that there aren't problems there too.
In reality, it is very helpful to have a carefully controlled, consistent test so that comparisons between vehicles are apples to apples. Variances in the real world will be argued as inevitable, and very quickly you'll find the industry converges on how likely it is that a give variance is "acceptable/plausible", and then you'll have engineers designing for that variance....
The "emissions cheat" in question altered the output of the car when it was being tested. So, they were testing the emissions that came out of the car.
"EPA regulators said that Volkswagen adopted a 'sophisticated' algorithm that turned on vehicles' full emissions controls when it detected they were being tested for emissions performance." - http://www.usatoday.com/story/money/cars/2015/09/18/epa-accu...
have you ever got software certified for the government or military? It's daunting at first, you know there are problems. As the process goes along though, it's just a financial process. You pay a government contractor to write some documentation and it's the documentation that is "tested". It just takes time and it's not cheap, it has little to do with security.
The epa tests are for beaurocrats, now maybe the world is changing but I suspect that if you could simply plug a usb stick in to your car and get better mileage and more power, at the cost of some nitrogen, a ton of people would do it, maybe most would. If it was really important, they'd require the cars to have real time sensors as standard equipment and put some of the responsibility on the driver too. VAG just played along and made the game more efficient. Not that I agree with it, it sucks, but the system was built to be gamed, it's broken
The testing was in place, but the software was designed to detect the testing process. A simple hack would be something like: (Hood open)or(doors open)+(Throttle>0)=I'm being tested. That would be enough to hide from standard testing procedures.
Systems designed to defeat specific test are nothing new. The biggest example I can think of are the Buell (Harley) bikes that use an exhaust bypass designed to keep the bike quite at RPMs used during the CA test.
The emissions test takes place on a dynamometer, which would result in a large number of weird things the car could test for.
Such as open doors/hood while the wheels are spinning, no acceleration or a stationary GPS signal.
The fact that cars have GPSs, make it next to impossible to design tests that can't be cheated, you would need a testing rig that could be mounted on a moving car, that didn't cause an increase of pressure on the exhaust system (cars could detect that) And then you would need to do testing on public roads, so the car didn't switch to a different mode when it's GPS showed it was on a known test track.
Volkswagen used a ECM that sensed if the vehicle was being tested based on various inputs including the position of the steering wheel, vehicle speed, the duration of the engine's operation, and barometric pressure.
(source EPA.gov)
In my state, PA, they use an inductive pickup on the spark plug wire for cylinder #1 to determine the RPMs and a probe that's inserted into the tailpipe. The probe is a small diameter (0.5" or less) tube and it shouldn't raise the back pressure by any appreciable amount.
Maybe an EE could tell us if it's possible for the ECM to detect the presence of the inductive pickup.
EE here. Technically it's possible to detect an inductive pickup. But they are pretty subtle. You would probably need a very specially designed coilpack.
You can't, but that doesn't really affect the cheat. I mean you could do: if gps not available default to clean mode. That would benefit you during testing or when you're in an underground garage or tunnel (Places where you would like to have as clean exhaust as possible anyway).
There is talk of emissions controls being linked to GPS location so that each country/state/city might enforce different emissions rules. Some high-end Japanese machines already use GPS to determine whether or not they are on a racetrack, opening up performance and speeds normally locked away while on public roads.
It is very practical - the whole Volkswagen scandal is caused by the fact that the compromise of low emissions vs better performance and mileage can be dynamically changed by software, and that a car that can conform to the tightest standard still would prefer use a mode with higher emissions whenever and wherever allowed.
It would enable your car to suddenly perform better as soon as you enter a state with less strict emission requirements, or vice-versa, your usually high emission car would be legal to operate when visiting stricter places because it can switch to a limited more when needed.
On a slightly related note, here's a story from back when the EEPROMs for cars were on DIP chips and slightly more hackable:
The old OBD I GM cars had a feature called "highway mode" which would lean out your fuel mixture when cruising to give you better gas mileage [1]. The downside was that your car had worse emissions. This feature was known to (or discovered by) the EPA, and they forced GM to turn off the feature. GM did so not by re-writing the fuel maps and cutting out all the highway mode code, they just created a disable bit that kept the ECU from ever entering highway mode-- the EPA was satisfied with that fix. People today with an EEPROM writer (can get a cheap one for under $100), a bit of soldering skill and access to the internet can remove the disable bit and give their car highway mode.
How can you get better mileage but produce more emissions? I would assume that emissions are proportional to the amount of gas used. If you're using less gas, wouldn't you produce less emissions?
The stoichiometric mixture of air and fuel burns exactly all the fuel. You can run richer than stoich (lower air-fuel ratio), which will produce more power and run cooler, at the expense of fuel economy. You can also run leaner than stoich (higher AFR), which will be more economical but combustion temperatures will be higher and more NOx will be produced.
Throw ignition timing in the mix and you have a complicated balancing act that engine designers perform in order to produce the ideal combination of power, fuel efficiency, and emissions.
Throw variable air intake, variable timings and injection patterns into the mix and you get powerful, clean and efficient engine. Which leads to a question whether this cheat by VW is intentional or a (possibly intelligently executed) side effect?
Given the number of moving parts and man-hours of research required to get everything right I am leaning in favour of the latter.
Diesels are complicated to sell in the US because of their emissions profile. Part of this is because they must run lean in order to completely burn fuel and prevent soot formation. This results in very high NOx emissions compared to contemporary gasoline engines.
Typically, passenger diesels employ a urea injection system to meet EPA standards, which reduces NOx as a catalyst. This system adds expense and maintenance duties. VW claimed their small diesels could meet emissions standards without such a system. What they have actually admitted to doing is writing a complicated algorithm that detects the conditions of a CARB emissions test and modifies running parameters in order to reduce NOx to acceptable levels during the test. This isn't in dispute by any party.
As emissions are not tested during typical driving scenarios, and given that CARB and the EPA has measured 40x the acceptable level of NOx, I speculate that VW is enriching the fuel-air mixture when their algorithm detects the conditions of an emissions test; this would dramatically reduce NOx emissions at a measurable cost to fuel economy.
As other automakers—such as Mazda with their perpetually delayed Mazda 6 diesel—are having trouble developing urea-free diesel engines for the US market, it is no wonder that someone noticed the discrepancy between USDM and EUDM emissions numbers for these vehicles.
Note that the EPA does not perform emissions testing of its own; automakers self-certify. CARB is the de-facto enforcer of EPA standards.
Well, I wanted to question whether they have found out their engines are rather polluting and have invested extensively into developing such a cheat or just found out (on two separate instances) that a) it is possible to detect emissions testing and b) some engine modes have drastically lower emissions; and simply put the dots on i and went along.
The complicated balancing act gets even cooler. Modern engines can play tricks like injecting fuel into the very center of the chamber, so that the flame front does not touch the chamber walls, insulated by air. Supposedly this reduces the development of hot spots on the chamber walls (reducing NOx formation)
Ah, I see, so if the fuel mix is lean, then there's some oxygen left over after all the fuel has burnt, and it goes looking for something else to oxidize, and it produces NOx.
[I am not an expert, but] first there are controllable emission control devices (e.g. EGR) and secondly burning conditions (thermodynamic cycle) highly influence power and emissions (emission mixture), i.e. how much power and emissions you get from burning 1 g of fuel.
An intuitive analogy: when you are camping (or just use firewood in a grill) and are just starting a fire there is a lot of smoke, although the fire is relatively small. When you get it hot and burning nicely there is barely any smoke left, although you burn much more fuel per time.
For an internal combustion engine the factors determining power/emissions are mainly fuel/air mix, ignition angle (gasoline), fuel injection pattern (for direct injection engines - all "modern" diesels, VW [T]FSI gasoline) and or air/mix injection angle (variable camshaft timing).
Fun fact: modern diesel cars have a DPF designed to limit emissions (fumes mainly). Engines have special DPF cleaning mode designed to kick in in highway modes by slightly increasing exhaust gas temperature. Driving only in urban cycles causes a DPF to get clogged, engine enters deep cleaning mode from time to time (power loss, dark fumes out of "chimney") which has a negative net effect on particle emissions, which are arguably most detrimental to respiratory tract.
It seems like Nitrogen Oxide output increases as the fuel combustion temperature increases. So when you're at a cruising speed that burns fuel more efficiently, it alters the balance of waste products. Somehow.
I'll defer to anyone who claims any real knowledge about this at all, I'm just doing some motivated googling.
Roughly, a higher combustion temperature increases combustion efficiency, but also increases NOx produced. Running lean increases the air:fuel ratio, which combusts more of the fuel at higher temperatures. On the flip side, EGR [1] is one of the primary techniques to reduce NOx at the expense of efficiency. Incidentally, it's actually somewhat common for diesel truck owners to do an EGR delete to increase fuel economy.
The "somehow" is pretty straightforward chemistry. As temperature increases, oxygen in the chamber begins to react with nitrogen, producing oxides of nitrogen (NOx). Both are present in the atmosphere, but do not react at normal atmospheric temperatures.
Total emissions aren't the issue here - it's the emissions of specific regulated compounds like NOx.
Most emissions from engines are in the form of CO2, which is indeed directly proportional to how much fuel is getting burnt. However, other compounds like NOx and unburnt hydrocarbons (HC) are a product of how combustion is happening, not how much is happening.
Basically, the car can choose to trade decreased efficiency (additional CO2 emissions) for reduced NOx and HC emissions.
Note to readers: 14.7 is the stoichiometric mixture for pure octane (C8H18). The stoichiometric AFR for pump gasoline is a bit lower, but the same principles apply.
I'm far from suggesting that companies should publish their code for everyone to see, but one thing seems a little bit absurd. We require companies to have their financials audited by independent auditors, but we don't require any independent audits of their software which has potential to affect people's lives.
Software will determine more and more aspects of our lives and we probably should shift our mindsets of what areas should be regulated or audited.
There's lot of audit requirements in several areas which are intended to keep customers and the environment safe. If you want to manufacture food, you need to comply with food safety regulations and you will be subject to audits in this area. If you want to manufacture pharmaceuticals, there's long list of requirements and checks which are required. Even if you want to manufacture a simple electronic device with some wireless communication, you need to have it cleared by FCC. The list goes on. But nobody cares for your software. You can be as malicious or as incompetent as possible and you're allowed to sell products with software features or bugs which could take people's lives. Nobody will care until there's something wrong.
The mindset here stayed in the 80s when software was considered spreadsheets and similar stuff and not that important for real life. We got our food, drugs, electronics and other safety regulations. In the age of software eating the world perhaps it is time to think about software audit regulations.
> I'm far from suggesting that companies should publish their code for everyone to see
This would actually be a good punishment. If you screw up, you could be forced to open source your code. If VW is serious, they could do such a thing. I guess that Mercedes wants to keep its Formula 1 code closed, but for it's normal cars it is a different case. The big car companies share so many of their technologies and even complete cars, what's keeping them?
1.) Pay a disgruntled competitor's employee to deliberately sabotage part of their product in an illegal way.
2.) Finger the company to the feds.
3.) Watch as the competitor's market position is hurt by bad thing X.
Works if X is fines, sanctions, stricter regulations, prison time for those involved, or even just a court case that costs a significant amount of money.
Thus we shouldn't punish a corporation no matter how bad it is.
As a side note, this same logic would let us conclude that punishing a person who commits a crime is a bad plan because it allows for their enemy/rival to frame them.
I agree your arguments are reductio ad absurdum. The difference between the government compelling groups to forced speech (release all of your source-code, trade secrets) and fines is that forced speech destroys value. From a societal standpoint, the punishment should scale to the crime. Being forced to open source a companies code is arbitrary and indiscriminate. Why should a company who spent $20 million on their code, who committed a transgression that would be equivalent to a fine of $100k have to open source their entire code base?
My guess is the motivation to force a company to disclose their source code as punishment is coming from a place of thinking that the more harsh the punishment, the more seriously actors will abide by the rules. As it's been proven to be the case in criminal law, the death penalty does nothing to dissuade homicide.
If a disgruntled employee can successfully sabotage part of their code base, their process is broken anyway, and uncovering this would actually be a good thing.
If you're looking to sabotage a competitor where you have a saboteur, why not just do (1), except at various other parts of their development/manufacturing process?
Pay them to break their factory automation. Pay them to write code that randomly increases fuel consumption. Pay them to write code that only allows you to play Rick Astley songs during March.
Because government is your force multiplier. If you have an embedded saboteur doing direct sabotage, you can only do as much damage as one person can do. If you have your saboteur conducting false flag crimes against the government, you can do as much damage as one government can do, at a time that you may be able to influence via quiet information leaks to the right people.
How would that sink a competitor? In the days before software ran cars, Ford could buy a Chevy, take it apart, and learn everything about it. This did not sink Chevy or prevent competition or a healthy auto industry in any way.
How is it different if Ford gets to see Chevy's throttle control software code today?
> We require companies to have their financials audited by independent auditors, but we don't require any independent audits of their software which has potential to affect people's lives.
It is done in high integrity software, e.g. MISRA C, but not to the level you are suggesting.
I support the EFF with regular donations and definitely don't care for DMCA but this feels like quite a stretch..
Most estimates put the number of lines of code in a new car at near 100 million, it'd be trivial for a company with intent to obfuscate the 'emissions mode' criteria in a manner that would be completely invisible to researchers.
I feel exactly the opposite. I think the poor quality of code in this industry across all manufacturers would benefit greatly from a little sunlight. Some of the researchers I know are clever people, they might get lucky. /s
I agree with your overall point that auto code should be open to review and the "could have uncovered" buys the EFF enough wiggle room in the headline -- but it just seems extremely unlikely that it would have been uncovered.
Part of my doubt comes from a financial incentive for random researchers to really spend time on bug review for Jetta wagons.. Though seeing the 20% stock plunge and following a few 'Fraud Cap' traders did provide an interesting view into a possible reward mechanism for researchers who find illegal or dangerous defects in embedded code..
There's a class of hedge funds and independent traders that specifically search out frauds to profit off of exposing their malfeasance. The most famous of this group at the moment is probably Muddy Waters Research[1].
They look for companies that are trading at suspiciously high prices relative to their peers and then try to figure out why. In many cases lately, their targets are Chinese companies that "reverse-merge" with companies that are already listed on US stock exchanges. These companies are often partly or mostly fradulent and the "Fraud Cap" traders take large short positions and then publish their research to make immense profits off of the cratering share prices.
Their methods usually start with pouring over financial records but often involve boots on the ground too.. In one case, they hired people to literally count every truck that came and went from a factory that was claiming much more business than it was actually doing.
It's a fascinating part of the market and I think a net 'good' in the scheme of things but I think it'd be interesting if hedge funds started deep dives on published code in an attempt to profit off of security holes or intentionally dishonest emissions controls..
Don't underestimate the simple effect that publishing the code will bring. If a car company knew that all the source code that went into the car would be published they would have to be comfortable with what might be in there because there would always be a risk of someone finding something. It's a bit like the asymmetry in security investment: the attackers (or emissions researchers in this case) only need to find a single issue to win, but the defenders (car companies) have to invest across a broad range of areas so there are no obvious weaknesses.
As a comparison, consider the difference in a developer's behaviour when writing code or a commit message in a completely private repository vs. one which will be published for anyone to see. Closed code only needs to reach the level that's considered 'normal' for the culture within the organisation. For many developers the quality threshold goes up for things that will be published more widely, even if the potential audience is small.
Cars are pretty much traveling entertainment systems these days, so I'm sure most of it isn't "mission critical" code, but here's a decent seeming source:
I doubt that the EEPROM is holding all the code these days. For the most part, it's probably holding small sub-routines, or even just LUT's for mapping the parameters of the control logic.
It's probably mostly real code, though cars certainly do use plenty of lookup tables, starting from one of the earlier uses of computers in cars, the engine control unit.
Modern cars have tons of things needing code:
Power seats with memory
Drive by wire gas pedal and cruise control
Keyless entry
Stereo system (auto volume by speed, etc.)
GPS/Navigation (perhaps third-party)
USB outlets for iPods, USB sticks for music
Reverse-gear proximity sensors
Emissions controls (oops!)
OnStar-type services
Cellular phone integration, e.g. mute on ring
Lighting (DRL, smart cabin dimming)
Traction control and ABS
Variable suspension
Dashboard diagnostics
OBD-II
Self-parking
Windshield wipers (auto speed, rain sensors)
Antitheft systems
I'm sure I've left out plenty, but even something "simple" like keyless entry has a lot of features (integration with OnStar, alarm system, reprogramming support for new remotes, ...). How many LOC do you think that entails? I imagine at least 100K LOC (keeping in mind it's likely written in C or similar).
Well the parent of the comment I first replied to said "Most estimates put the number of lines of code in a new car at near 100 million." I took that to mean total LOC in a car, not in an Engine Control Unit. But your comments to me suggest you are talking about an Engine Control Unit. Forgive me, but it is not obvious to me what you are on about.
I think the point is that if you're talking about finding malicious engine control activity, then talking about the number of lines of code for the entire car is irrelevant, because all that matters is the code for the engine control unit.
To be honest, that is pure populism by the EFF. I am a supporter of EFF and against the DMCA. But that saying is BS.
There are many different ECUs within a car (about 40 in a current Volkswagen Golf). Does EFF really thinks that someone would have found that issue, when everything is OpenSource?
Nobody would have examined such things, because nobody would have been interested in examining it, if it would be OpenSource. We have seen such things in lots of OpenSource software, just reminding of the now legendary Debian bug in the random number generator or Heartbleed and such things. How long where those bugs present?
To find this wrongdoing by VW you don't need access to the car. Put a measuring device to the pipe and drive around.
The question: why did the engineers implemented a detection of the test environment? Because you need to. You just have to apply a little bit of thinking your self. Such a car is equipped with lots of assistants like traction control, like crash detection, and so on. In a test environment you have your car running on a dynamometer or alike. That means the car detects, that 2 wheels run at 30 mph while 2 wheels are standing still and there is no acceleration. The car now has to classify that situation. The car has to decide if the front wheels are just spinning in the mud and traction control must be applied, or is it a valid situation. So there are lots of those things you have to consider during development and which are valid use cases. Of course this should not be misused.
> Nobody would have examined such things, because nobody would have been interested in examining it, if it would be OpenSource.
I would've been interested, and I don't even work in the field... Regardless, the EFF says "could", not "would". And they're right. This sort of code absolutely should have third party reviews.
> The question: why did the engineers implemented a detection of the test environment?
Yknow, maybe because they knew they didn't have to worry about people reviewing their code.
>> The question: why did the engineers implemented a detection of the test environment?
> Yknow, maybe because they knew they didn't have to worry about people reviewing their code.
You read the rest of the comment? You NEED to detect it to apply to correct algorithms for all those safety assistants.
Otherwise you could decide to just cool down when a door is open, when the front wheels are spinning, while there is no acceleration, when the distance sensors detect obstacles. But that would make testing impossible.
The problem is not that they detect the test - the problem is that they modify parameters so that exhaust is within acceptable limits as imposed by law. Hiding this in open source code would be quite a feat (but not impossible [0]).
A bug like heartbleed was not found because no got the idea of how to exploit it. Plenty of people and researches have read that code without seeing the bug. This case with VW, was to my knowledge not a bug, it was deliberately code to work that way. That is quite different from a subtle bug where you need to apply advanced statistical attacks to perform the exploit. Or a random generator bug that simply reduce the randomness.
I'm absolutely positive that there is some enthusiasts, that would read and dissect every single line. But even if that wasn't the case, I'm even more certain that multiple competitors would, and this would be reported as fast as you can set up a meeting with the relevant authority.
> Does EFF really thinks that someone would have found the issue, when everything is OpenSource?
Volkswagen stock dropped massively (20% so far) since this announcement. If you discovered the bug and took a leveraged short position you could make an incredible amount of money.
They didn't mention source code. And the Jeep Cherokee bug was found by analysing firmware, so it can happen. I agree in the case of emmissions it is easier just to measure them.
I guarantee it'd be examined by at least a few VW owners who are interested, not to mention researchers and the government regulators themselves. Especially after this fiasco.
Those tests should also be abolished. We all know cars are relatively economic if you're able to ride them at 50km/h constantly. This has nothing to do with real life.
Yes, it makes no sense to use them for real world.
No, they provide a comparable environment to compare different models and different OEMs.
It is the same difference like conformance testing and performance testing. A piece of software, a device, a system can be conform to a specification, but can have different performance in different situations.
They're not talking about access to source code here.
The issue is whether it should be possible to legally analyze and reversing engineer the compiled binary code on such devices, which is currently not permitted under the DMCA.
Source code for slot machine firmware is open for regulator scrutiny. Human lives aren't directly at stake, but apparently gambling rises to the level of importance that such scrutiny is accepted.
How is is acceptable that automotive firmware, an application in which human lives are directly at stake, doesn't rise to that level of importance?
Slot machine manufacturers don't have anything to hide, as there is nothing malicious about their software - it's programmed to mathematically make the players lose money most of the time, but everyone already knows that. Thus they have no incentive to fight against their firmware being open for regulator scrutiny.
Automotive manufacturers, on the other hand, have very good incentives for their firmware not being open for regulator scrutiny, as the recent events have shown...
Huh, what? The commenter is asking why one industry is open to regulator scrutiny and the other isn't.
My reply covers why lobbyists from one industry might have incentives for not being open to scrutiny, while lobbyists from the other industry might not.
I'm not answering literally the question "why is it acceptable..." because that's not the real issue at play here.
Seems much more important, so should be open for independent researcher and general public scrutiny. The exemptions the EFF wants should absolutely be granted, but seem a very indirect way of enabling greater scrutiny of automotive and other life critical software.
I'm surprised that the EFF would suggest going to the level of having companies publish their code. A huge number of manhours goes into developing the software that runs a car, and a significant amount of IP is tied up in it.
Forcing vendors to release software would allow competitors to steal it outright, and open up the entire industry to a massive set of lawsuits. I don't think that's a very beneficial outcome.
As someone who works in a technical safety auditing role, I strongly doubt that NDAs would preclude the widespread release of this software. I have a hard enough time convincing vendors that the lifecycle documentation they are already mandated by law to provide, should be provided. This is just unrealistic.
Force one, force all. The side effect being that if another manufacturer steals and reuses code under NDA, that'd show up as well.
Calling it "unrealistic" is unrealistic. These companies are not anybody's pet, to be loved and hugged and cared for. We should ask them to release their code, at least to regulation agencies under NDA, because otherwise they harm the health of millions of people for the sake of passing regulations, like in this very case. Don't know about you but I'm in no mood to give them a free pass on this and on top of that, worry about "oh but those poor SOBs, what would they do if their NDA'd code would get leaked"...
Sorry, this is a bit of a hostile answer and it's not meant to be - this entire ordeal is enraging... and I don't see why we should preemptively defend their rights to make money off our own health.
Don't worry, I'm just as furious as you are! I want realistic solutions though, and I don't think forcing vendors to open their source will fly.
For one, you will never force all vendors to comply, as some are completely outside of the jurisdiction, like China. Secondly, even if you did force vendors to comply, you've just given any new startup a massive leg-up on R&D, which the existing vendors discounted for them.
I don't think it's realistic, and there are already methods by which the code has to be reviewed externally, at least in principle. I want to improve the existing processes, not move to a new model.
Maybe I misread the article, but I don't think the EFF are actually calling for car manufacturers to _open_source_ their firmware. Instead, I think they're arguing for a DMCA exemption on reverse-engineering the firmware.
At the moment, (allegedly) it's illegal under the DMCA to reverse-engineer car firmware. This obviously stops the research that might have highlighted this. The EFF are suggesting that the DMCA should not apply here, so researchers would be free to work from the compiled firmware (not the source code) to look for issues.
> Secondly, even if you did force vendors to comply, you've just given any new startup a massive leg-up on R&D, which the existing vendors discounted for them.
Real talk here: Is that such a bad thing? Why should new companies have to deal with problems humanity has already solved?
Because this completely dis-incentivises companies to spend money developing features in the first place, and makes it impossible for them to recoup the sunk cost of development over car sales, since they're competing against companies who did not pay those costs.
It seems to me what's unsustainable is relying on a system built on trade secrets. Something we quickly moved away from in the software world, which has greatly accelerated development, been mutually beneficial to everybody, and certainly hasn't been "unsustainable".
I remember someone comparing, on HN, what "closed source" is to science to what ancient guild secrets were to alchemy. Are guild secrets any more sustainable than closed source?
It wouldn't be only a beneficial outcome, it would be the best and the only morally right outcome.
Consider that before the advent of software, people actually owned the things they bought. And you could argue that it isn't fair to impose such standards on markets that haven't existed before software and you might be right, after all people have to eat, but when it comes to automobiles people have historically owned the car they paid for. And in practice what this meant is that they can get it inspected and repaired by third-parties should they want to do that, which means longer lifecycles and cheaper service, among other side-effects that come as a natural consequence of actually owning things, a freedom that is essential for the proper functioning of capitalism itself.
But now with the advent of software in these computerized cars all of that is about to change. And lets place that in the context of the never ending copyright terms, with the excruciatingly low threshold for awarding patents, with the price of IP lawsuits going through the roof, along with the fact that software leads to natural monopolies. As that's the context we live in, a context in which innovation happens only because the giants whose shoulders we stand on haven't protected their "IP".
And I get it, we are software developers, we've got to sell our labor, but nothing makes the stealing argument any less bullshit. And we could start from stating the obvious, which is that copyright or patent infringement is not stealing.
Don't get me wrong, I'm the last person to defend the overuse of software patents. Where people are genuinely creating extremely complex functionality in software however, I think they deserve some protection for their outlay.
On your point about historically owning vehicles, as a software developer you will understand that there is a very wide gap in competence between being able to tune a standard motor, and being able to inspect and modify software that controls a car safely. Currently this is protected so that only the vendor can change it, precisely because that's how we wrote the standards - vendors are responsible for their code, and responsible for the safety outcomes on the road.
If we moved to an open model where anyone could modify the software in their car - what do you think would happen to the safety and reliability of that software? I don't think any of us could imagine that it would improve.
> you will understand that there is a very wide gap in competence between being able to tune a standard motor, and being able to inspect and modify software that controls a car safely
A big part of that is because cars have been around for over a century, and there has been a huge tinkering crowd to learn and teach newcomers to the scene. The software/robotics crowd is maybe only a decade old (ignoring the hacking scene). Why wouldn't we in a hundred years or so be able to write our own car control software? Or more importantly, why shouldn't we?
I also disagree on your stance that open-sourcing it wouldn't improve anything. If anything, open-source has been the driving force behind great procedural advancements in software design: source control, code quality measurements, unit testing, metaprogramming, have all been influenced or driven by large open-source projects. If anything, I think the first thing an open-source movement for car control software would produce is testable code, probably from a greater focus on compiler-enforced design-by-contract languages.
In my mind, the only reason we wouldn't be able to progress to that point is exactly because of these anti-reverse-engineering policies, because of IP protection and litigious manufacturers. I'm firmly with the EFF on their Freedom To Tinker cause, and I think it's perfectly acceptable for the EFF to take this case as an example of why current policies are wrong.
"If we moved to an open model where anyone could modify the software in their car - what do you think would happen to the safety and reliability of that software? I don't think any of us could imagine that it would improve."
1. 99.99 percent of the owners of these automobiles wouldn't have a clue to even where to access, or what to do with the code? Most can't find their AlDl, or OBD plug.
2. Most mechanics out there don't know much about car computers, and 99.9 % know nothing about programming. When something goes wrong with the computer; they just replace it. When I was in automotive school, the failure rate of car computers were 1 in a million. I think that's low though? Mechanics just replaced the computer--hopeing they got the right one. The one in the vechicle was usually fine, but was shorted out by fat fingers, and hangovers.
In real life, when a mechanic, usually erroneously blames the automobiles computer, as the fault of the problem, he/she just replaces it. Their biggest achievement is not shorting the new computer in by installing it. Of course when they short out the computer, they blame the computer as defective, and charge the customer.
Dealership mechanics(some) can reflash their particular brand of vechicle computer/computers, but they don't code anything. They push a GUI button, and answer yes, or no questions the enginneers at corporate programmed.
As to propriatiry software, it's not about safety, and reliability. It's about customers being held hostage to the dealership. You buy a fancy car, with a bunch of do-dads on it. You can't just bring your ailing car to any independent mechanic. They don't have access to the computer system. Most wouldn't have a clue to the actual code, but they need trouble codes. These trouble codes are being held hostage. The dealer will happily fix your car, but at dealer prices.
Even if people abused the open source software(affecting emmissions), it would be caught at the bi-annual smog check? As the safety, the automobile companies would love to blame tampered with software in order to lessen their liability? (It sounds like it would be pretty easy to test for altered code, on the manufactures end?) For years now, I can buy computers that improve a vechicles performance, but it's just not worth not passing an emmission test--in my view.
So, I don't think it's about safety, It's about greed.
And maybe other factors; like they don't want the Programmers peering into their horrid code. Code that defeats smog checks. Code that reuses other manufactures patents--without payment? Code that is just terribly written, and causes numerous accidents, and thefts?
Again, I don't want much. I just don't want to essentally lease my vehicle after buying it with cash? What? Yes, because no one other than the Dealership can work on it at $170 hr. The idependents will attempt to work on my new vechicles, but they never seem to solve the problem. Why should they, they don't have the information! These automobiles have gotten so complicated, even your dealership mechanic is usually figuring out your cluster of sensors on your dime. It's gotten to be quite a racket? I forsee acres, and acres of newer automobiles that are junked because they aren't worth fixing? Give out trouble codes? Give out a service manual with every new car sale. Tell the customer up front, "I will see you again sir, for many years--let me program all our dealerships into your GPS?" "I hope you never lose that high paying job?" "Your so good looking, why would you ever want to get your cute hands dirty working on that dirty automobile?"
Give me access to my computer on my car, at least the trouble codes, and access to a reasonably priced scan tool? I'll even sign a waver--if that's the problem?
> In real life, when a mechanic, usually erroneously blames the automobiles computer, as the fault of the problem, he/she just replaces it.
For one, it depends on the repair shop you're talking about. Personally I require proof that the problem has been solved.
But anyway, for one while it may be true that most mechanics will simply replace a component when broken, replacements can also be made by anybody and that will drive the cost down and encourage local businesses.
And really, many software developers are nothing else than glorified mechanics. Right now the supply and demand curves are favoring us, but give it some time and you'll see software developers working for car repair shops. After all, the trend is always commoditization and at some point investors will stop wanting to create frontends to a database that are automating an Excel spreadsheet communicated in an email exchange.
But is that what they are saying in this article? Obviously they would prefer a future where firmware like this is open source (for regulatory reasons or whatever other reason) but all they are saying in the article here is that it's wrong that you can't tinker or reverse engineer? "Unlawful to look at the code" that is a roundabout way of saying that it's unlawful to try to decompile, right?
I agree that peeking at code or decompiling it should never be illegal, nor publishing what you find. But requiring companies to publish code openly would be something completely different than allowing decompilation.
Where is the EFF suggesting that companies should publish their code? At least in the linked article, they are merely arguing that it should not be illegal to reverse engineer it.
I've read and reread the article, and I just don't see anywhere where the EFF are suggesting companies publish their code - can you provide a quote? Maybe it's in another article?
What I see the EFF asking for is a DMCA exemption so that researchers can legally reverse-engineer the firmware.
I think that if emissions tests are distinctive enough from normal driving that they can be detected, they're not representative of realistic driving conditions. It's like microbenchmarking.
"Only then did VW admit it had designed and installed a defeat device" that purposely lowered emissions while a vehicle was being inspected, the agency said. During regular driving, emissions would return to as much as 40 times the level of pollutants allowed under clean air rules.
The other sources I've seen specifically said ANY time a vehicle was tested, this did not show up.
Tests are typically done on a dynomometer. One easy solution would be trigger the clean mode when the front (driven) wheels are spinning but the rears are not.
The primary code needs to be published, and the publication kept current (versioning). I don't know what kind of open source license is well suited to this that also limited reuse and use modification since those things can open a liability can of worms potentially. But the idea that code applying to the primary control functions of an automobile cannot be known (is not published and cannot legally be reverse engineered) is just a bad idea. Consumers are injured, the environment is damaged, and arguably even a bunch of shareholders and national pride are damaged because none of the participants had a say in VW's decision. Well, they get a say if the code is published.
User apps and UI/UX code I'd say can probably be proprietary, closed, and not published.
> But the idea that code applying to the primary control functions of an automobile cannot be known (is not published and cannot legally be reverse engineered) is just a bad idea.
Why is it a bad idea? Do we know the code base of airplanes? Critical infrastructure, like power and water plants? How about military software that controls missile guidance?
The answer isn't to open source everything and let programmers sort it out. We have regulatory and safety boards specifically to counter the issues around public safety that software in critical applications causes. A huge amount of time and money is spent developing standards, and verifying and monitoring compliance with them.
Obviously these processes are not always perfect. In this case, it will be interesting to see how far the corruption necessary to include a pollution-defeat spreads. But throwing out the whole process and just publishing code in its place is not a reasonable solution. More stringent black box testing by experts could have caught this issue far sooner.
>Why is it a bad idea? Do we know the code base of airplanes? Critical infrastructure, like power and water plants? How about military software that controls missile guidance?
I OWN my car. I do not own nukes and powerplants yet. My evil genius lair is still under construction.
Ownership should come with reversal rights, rooting, reflashing, modifying etc for this one unit I bought.
By purchasing a car, you purchase an end product, which is designed to be suitable for your purposes. You don't purchase rights to a million manhours of software, free to do what you will with. If companies had to amortise the cost of code development over the cars they sold, you would end up paying a lot more for 'your' car.
Actually I do purchase it. I don't purchase the right to redistribute it. But I totally own the right to modify my car however I see fit as long as it is road legal. Part of it being mine.
Are you serious? Absolutely not. Unless you can show that you are competent to modify safety critical software, and have a certified process in place to do that, it would be illegal for you to modify the code, and you would be personally liable for any accidents caused by such a modification.
You would also require the full lifecycle documentation to allow you to understand the impact of any modifications you make, and be required to do a full impact analysis to prove that any modifications you make do not reduce the integrity of the existing safety functions.
That's completely ignoring the vendor's configuration management requirements (which you can't do).
This the whole point - devices run by software systems are too complex to be modified by a layman. There are very detailed, statutory processes and requirements around the development and modification of software in safety critical applications, and you absolutely cannot modify it just because you bought it.
>Unless you can show that you are competent to modify safety critical software, and have a certified process in place
> require the full lifecycle documentation to allow you to understand the impact of any modifications you make, and be required to do a full impact analysis to prove that any modifications you make do not reduce the integrity of the existing safety functions
Car manufacturers does not use formal verification, even though it exists, and would be able to give hard guarantees about safety and the like. And given recent history about analysis of code that resulted in run away bugs, I, as a professional developer, are completely confident that few if any manufacturers do the above. They have an extensive testing procedure, surely, but they're not trying to avoid the bugs earlier in development, nor try to enforce a coding style that reduce the risk of bugs.
But besides that point, many people are not arguing that they should be allowed to tinker with safety settings and drive on the road. That would be illegal, just as it is illegal to remove the lights and drive at night. But I as an owner of the car, should be able to see and change that code for auditing purposes, or use on a closed road. If the entire system of the car is open, it is also trivially easy to compare the running code with the version supplied from the manufacturer and see if any modifications have been made.
European car manufacturers are required to develop safety critical software under ISO 26262, which is a derivation of IEC 61508, which absolutely does require formal verification and validation activities.
If you change the code outside of the development process, you could unwittingly compromise the safety of the vehicle. The manufacturer is required to use access controls to prohibit people from changing the software for exactly this reason.
ISO 26262 does not to my knowledge require formal verification, and some googling around seems to support this. Without access to the actual specification I cannot find out exactly what it requires.
So you don't know what's in the standard, but you make assertions and continue to support them? That's a fairly disappointing level of discourse for HN. It requires a very similar software development process to all other functional safety standards, in which verification and validation are key steps.
Here is a paper from Mathworks describing verification and validation according to ISO 26262:
I know how ISO standards are implemented in two unrelated fields, that was really the basis for my comment. Besides, I am now certain that it does not require formal verification, as several companies sell products that support formal verification as a mean to pass the verification part of the ISO.
I'm not going to pay for access to the standard just for a comment on HN.
When you say European manufactures are required to follow this, what about non European manufactures?
Actually that's an interesting point you raise. The automaker provides you with a finished car containing finished machine code. It doesn't provide you with the CAD files needed to reproduce the car, the techniques used to built it, or the source needed to reproduce the machine code. And maybe they shouldn't be required to.
That said, I think it's reasonable to reverse engineer the code, just like you could physically take apart the car to figure out how it works. As long as you don't disseminate the results of that work, it shouldn't be illegal in my opinion. Even dissemination should be legal in some circumstances, like whistleblowing.
It's a bad idea because it's a departure from our historic common sense, as well as patents and copyrights. It's commonly accepted that when you buy a car you can learn how it works by poking it with a stick, and make modifications, and everyone expects that the things they modify they assume liability for and a warranty exemption. Code? Nope. You do not own that part of the car. You don't have the right to figure out how it work, or modify it, or even replace it. There's residual ownership in the form of IP, in perpetuity.
One of the major purposes of patent law was to make the entire details of an invention public so that it was possible to know exactly what monopoly was being granted, and also permit people to learn and invent something better. That doesn't happen when things are obscured like this.
And just because airplane code isn't published doesn't mean it's a good idea.
So you're basically arguing for an Android-esque project for cars, where Samsung or Ford basically fills the device with crapware and bloat over a simple base system? I'd be fine with that, as long as there were firmware signing mechanisms in place to prevent every 16 year old with a USB cable and a penchant for speed from modding the family car. Early Android ROMs were a lesson in how not to modify things; luckily there wasn't a lot of widespread damage done with the quantity of compiled binaries of unknown origin being distributed over typical filesharing sites like Mediafire.
If people are afraid of releasing the car's code, the agency doing the emission testing could make it a bit less obvious when the car is being tested. That would make it harder to cheat.
> If people are afraid of releasing the car's code, the agency doing the emission testing could make it a bit less obvious when the car is being tested. That would make it harder to cheat.
I'd say requiring the release of all source code involved in or connected to control circuitry in the car (i.e. anything other than in-vehicle dash systems that are completely isolated from CAN, etc.) would be reasonable. The safety concerns outweigh any proprietary benefit to the companies involved.
It would also create a lot of pressure for the manufacturers to actually isolate the non-critical value-add parts from the critical keep-the-car-driving parts, which would increase security.
I made some ignorant comments about the legitimacy of how much pollution is actually caused by these cars considering "tailpipe" emissions tests are a thing where the test is segregated from the car's computer system entirely, and we haven't heard much about these types of tests failing.
The real question I have is, if the vehicles are actually producing less emissions during the test, how come they can't use the same method to produce less emissions during normal operation? If the "defeat device" had some adverse effects on the car's operation, which I imagine it does, I would also think that it would be apparent when running the test. "Sounds like this car is running on 2 cylinders at 75 RPM..."
Edit: I'm just going to wait for the videos, someone will eventually detail what's going on.
More then few times I could smell some distinct smell that some diesel cars produce, which reminds me something.
When I was a kid I've traded with someone on IRC to get some HNO3 with plans to make... dynamite. Few weeks later, the lid of mason jar rusted thru and my room had this distinct smell. I doubt that is NO as I would probably be dead now, but coupled with all the experiments involving nitrates I probably do hold more nitrates than usual.
The thing to do is to allow researchers to test cars in realworld situations and then actually listen to them when they report anomalies.