There aren't enough details in the somewhat hyperbolic narrative format to really say, but if I were going to create a temporary archive of files on an embedded system for diagnostic upload, I would also delete it, because that's the nature of temporary files and nobody likes ENOSPACE. If their system had deleted the inputs of the archive that would seem nefarious, but this doesn't, at first scan.
The main reasons to store data are for safety and legal purposes first, diagnostics second. Collision data are all three. They need to be prioritized above virtually everything else on the system and if your vehicle has had so many collisions that the filesystem is filled up, that's a justifiable reason to have a service visit to delete the old ones.
If I were implementing such a system (and I have), I could see myself deleting the temporary without much thought. I would still have built a way to recreate the contents of the tarball after the fact (it's been a requirement from legal every time I've scoped such a system). Tesla not only failed to do that, but avoided disclosing that any such file was transferred in the first place so that the plaintiffs wouldn't know to request it.
The tar file is a convenient transport mechanism for files that presumably exist in original form elsewhere within the system. (All bets off if sources for the tar were changed afterward.)
Given storage is a finite resource, removing the tar after it was confirmed in the bucket is pure waste.
I'm not sure whether you're saying that the tar should or shouldn't be deleted. Regardless, my point isn't that it was intentionally deleted. I can easily imagine someone writing a function to upload the data using something like std::tmpfile (which silently deletes the file when it's closed) without thinking about the full implications of that for the broader context the code exists in.
Even in that case though, you would still have a way to produce the data because it would have been specced in the requirements when you were thinking about the broader organizational context.
When a vehicle crash occurs, that embedded system should no longer be treating data as "temporary", but as what it now is, civil and potentially criminal evidence, and it should be preserved. To go to the effort of creating that data, uploading it to a corporate server, and then having programming that explicitly deletes that data from the source (the embedded system), certainly reads as nefarious without easily verifiable evidence to the contrary. The actions of a company that has acted this way in no fashion lends any credibility to being treated as anything other than a hostile party in court. Any investigators in the future involving a company with such a history need to act swiftly and with the immediate and heavy hand of the court behind them if they expect any degree of success.
"Their system" is a car, sold as a consumer product, which has just experienced a collision removing it indefinitely from normal operation. Reconsider your analysis.
Yes? But the article doesn't say that Tesla deleted the EDR, it says they uploaded the EDR file in an archive format, then deleted the uploaded entity. Which strikes me as totally normal.
Totally normal for a completely different domain. Very abnormal for what's functionally the car's black box.
No, the car's "black box" is the EDR, the behavior of which is regulated by federal agencies. This article is discussing ephemeral telemetry which accessed the EDR.
No, the EDR forms part of the car's "black box" – just like the FDR forms part of an aeroplane's black box. Per the article, the erased* telemetry ("collision snapshot") contained quite a bit more data than just from the EDR.
*: I can't work out from the article whether this file was erased, or just unlinked from the filesystem: they quote someone as saying the latter, but it looks like it was actually the former.
So? Tesla needs to bear the responsibilities of having deleted its own potentially exculpatory evidence. Not granted an inference that it did so and therefore Tesla is innocent.
I would love to see what you need so much disk space for after the car is crashed and airbags are deployed. If that event fires the car is going in to the shop to have its airbags replaced at a minimum. Adding a service step to clear up /tmp after a crash is fairly straitforward.
You're assuming that it's a separate routine. It could very well be simply a routine that uploads any incident.
Tesla was having issues with log file writes destroying their chips. They can argue they have precedent for deleting data, but not hiding it.
I would be fascinated to entertain arguments for how the future write life of a flash memory chip, meant for storing drive-time telemetry in a wrecked car, merits care for preservation.
Many parts, especially non-moving parts, hold value after a wreck. It does not make sense to keep the file on the disk for the lifetime of the part. The part is most likely going to be resold as used. The part will have a shorter life if the big crash data file is left on disk.
I didn't know Tesla authorized any resale of parts from any of their vehicles, used, crashed, or otherwise! Certainly I had no idea they built support for it into the system software. Was that a recent change?
https://Service.tesla.com has been online for I think 2 years
Oh, I'm sure it has. Owners tell a different story about what the site is worth. Of course, Apple actually "innovated" that one. But do you seriously mean to suggest Tesla engineer their cars to discard potentially dispositive crash analysis, in order to support their own resale of junkyard pulls?
What's the alternative? Keep it on there for the next owner to view?
Okay, let's recap.
Your implicit claim is that there exists a resale market for wrecked Teslas, meriting such product and engineering interest from the company that the car's data storage, in the immediate wake of a disabling collision, preemptively and correctly destroys information of use to crash investigators, so that the company can cannibalize the wrecked hulk for items which Tesla then goes on to sell as new OEM repair parts.
Isn't it embarrassing to go to all this? It certainly seems like it should feel that way, for as degrading as it looks from the outside. If you can explain it, I would like to understand what makes it seem worth your while.
The data was not preemptively destroyed. It was uploaded and then deleted. The implications for deleting are obvious. The part can be sold and reused after the crash data is erased. The part should not be sold and reused until that information is erased because it contains a large file and this file will likely contain death footage.
> The data was not preemptively destroyed. It was uploaded and then deleted. The implications for deleting are obvious. The part can be sold and reused after the crash data is erased. The part should not be sold and reused until that information is erased because it contains a large file and this file will likely contain death footage.
Okay, then your contention appears that Tesla is content with not bothering at all to refurbish the junkyard pulls it sells through OEM channels as OEM repair parts, thus denying themselves any opportunity to manually wipe sensitive data - potentially to include video of the prior owner's violent death! - as part of any remanufacturing or even basic QC process. But - as has now been made a matter of public record, in consequence of their fighting and losing this wrongful death case - Tesla do make sure to keep a copy for themselves, one of an apparently large collection of same which they went far out of their way for years to keep anyone else from discovering even exists.
Is there anything you care to add to that? Feel free to take your time. You've said quite a lot already.
This counterargument does not hold. The vast majority of crashed vehicles are not sent back and resold by Tesla. They are resold at auto auctions, junkyards, ebay, etc. Deleting the crash data protects Tesla from lawsuits on both ends of the chain: the victims and the new owners, while also preserving the part's lifetime.
> Deleting the crash data protects Tesla from lawsuits...
Oh, obviously.
Wouldn't creating an archive on the filesystem and then deleting the archive cause more writes than just creating it without a delete?
Not in the big picture.
Fundamentally, flash memory is a bunch of pages. Each page can be read an infinite number of times but there are quite relevant limits on how many times you can write it.
In the simplistic system lets say you have 1000 pages, 999 hold static data and the last one keeps getting a temporary file that is then erased. All wear occurs on page 1000 and it doesn't last very long.
In the better system it notes that page 1000 is accumulating a lot of writes and picks whatever page has the least writes, copies the data from that page to page 1000 and now uses the new page for all those writes. Repeat until everything's worn down. Note the extra write incurred copying the page over.
In the real world a drive with more space on it is less likely to have to resort to copying pages.
Wear increases when free space is low as there's less overall space to put the data. If you only have 500MB of free space, those blocks take the majority of write hammering until the chip fails. If there's 5000MB free, you can spread the wear.
I think the goal is to save as much as you can in the interim. Holding onto X bytes of archives is more time worth of data than X bytes of uncompressed. We do that stuff all the time in finance. Stuff gets spewed off to external places and local copies get kept but archived and we simply rotate the oldest stuff out as we go. If the cleanup process is configured separately from the archiving process you can absolutely archive things just to remove them shortly thereafter.
What about not handing the tar ball to the police looking for data. Do you see that as a problem?
It seems they waited for a subpoena. Would you prefer automakers send the police a notification anytime the car records a traffic infraction, or maybe they should just set up direct billing for municipalities?
The police reached out to Tesla legal within days and asked if they needed a subpoena. The Tesla lawyer said no, but then directed the police to make their request in a specific way that hid relevant data from police and the victims. It took 5 years to get the data, and only then after a forensic engineer proved Tesla uploaded it by finding logs on the cars black box and after the court was leveling sanctions.
Should companies be intentionally misleading to law enforcement about what data they have on fatal accidents like Tesla?
I hadn’t listened to the below video in a while but I did again today and the above comment’s assumptions of fact perfectly illustrate the point of the video.
This comment takes as fact a claim made by the police, which might be wrong, either by error or purpose.
One thing is for certain though, the police’s initial investigation was criminal. That is to say it was to establish the fact of who was the driver, etc. It was totally separate from the civil litigation that later established Tesla to be at 30% fault for the wreck using computer records establishing that ADAS was engaged.
Leaving Tesla out of it, suppose there was some other automaker with some other problem. A cop comes to them and says “what do I need to ask you to establish the facts about an accident?” Since when do police just accept “oh, the potentially adversarial lawyer gave me advice on what they can tell me without getting a subpoena. Guess that’s all I can do?” That’s absurd.
Don’t talk to the police: https://youtu.be/d-7o9xYp7eE
I would prefer automakers to not pretend that they don't have telemetry that they actually do.
It isn't clear that Tesla pretended anything aside from a claim in the article. The article: 1) does not directly cite an original source; 2) walks back the claim to "acted as if". The police had access to everything in vehicle the entire time. The civil lawsuit plaintiffs also had access to everything as evidenced by their forensic expert's access. That Tesla also received a copy of the vehicle's data is not relevant.
Don't Talk to the Police: https://www.youtube.com/watch?v=d-7o9xYp7eE
That's obviously problematic. I am only commenting on the belief in a conspiracy of programmers here. The overwhelmingly most likely reason that a temporary file would be unlinked after use is that is what any experienced systems programmer always does as a matter of course.
What "belief in a conspiracy of programmers?"
I've made no contention, but if I had, it would be that whoever signed off on this design had better not have a PE license that they would like to keep, and we as an industry would be wise not to keep counting on our grandfather-clause "fun harmless dorks" cultural exemption now that we manufacture machines which obviously kill people. If that by you is conspiracy theory, you're welcome.
There are not PEs signing software changes for ancillary equipment in consumer vehicles.
ETA: Restate your conspiracy theory in the hypothetical case that they had used `tar | curl` instead of the intermediate archive file. Does it still seem problematic?
"Ancillary" is quite a term for crash reporting after a crash. That is, for a system responding as designed to a collision which disabled the vehicle.
I'm not going to argue with someone who throws gratuitous insults. Rejoin me outside the gutter and we'll continue, if you like. But the answer to your question is trivially yes, that is as professionally indictable, as might by now have been clarified had you sought conversation rather than - well, I suppose, rather than whatever this slander by you was meant to be. One hopes we'll see no more of it.
And deleting the file would have been perfectly fine, if Tesla had given out the file when asked for it. Instead of what they did.
Maybe, if this were a toaster or fridge.
For enospace, I’d put telemetry data on an entirely different partition or even device, as to isolate the rest of the filesystem.