5 ms·

Assuming no malice, I'd guess it's for space saving on the car's internal memory. If the data was uploaded off of the car, there’s no point keeping it in the ca

Assuming no malice, I'd guess it's for space saving on the car's internal memory. If the data was uploaded off of the car, there’s no point keeping it in the car.

wat10000 1y ago
Sounds like a pretty standard telemetry upload. You transmit it, keep your copy until you get acknowledgement that it was received so you can retry if it went wrong, then delete it when it succeeds. It’s just worded to make this sound sketchy. I bet ten bucks “unlinked” just refers to the standard POSIX call for deleting a file.
- tobias3 1y ago
  Sketchy is that then someone takes “affirmative action to delete” the data on the server as well. Also this is not like some process crash dump where the computer keeps running after one process crashed. This would be like an plane black box uploading its data to the manufacturer, then deleting itself after a plane crash.
  - wat10000 1y ago
    I’ll bet another ten bucks that this is a generic implementation for all of their telemetry, not something special cased for crashes. Deleting the data on the server is totally sketchy, but that’s not what the quoted section is about.
    - dylan604 1y ago
      How handling an automobile crash not as a special case is the weird part. Even in the <$50 dashcams from Amazon there is a feature to mark a recording as locked so the auto delete logic does not touch the locked file. Some of them even have automatic collision detection which locks the file for you. How Tesla could say that detecting a collision and not locking all/any of the data is normal is just insane.
      - immibis 1y ago
        That one's easy: nobody at Tesla cares about having this feature
    - pjob 1y ago
      That might not be a good bet. https://news.ycombinator.com/item?id=45063380 https://news.ycombinator.com/item?id=45063380
      - wat10000 1y ago
        I don't see anything in that comment that would apply to what I said.
- buran77 1y ago
  The process of collecting and uploading the data probably confuses a lot of non-technical readers even if it worked as per standard industry practices. The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. There's no technical reason to dispose of data related to a crash when you hold so much data on all of the cars in general. Crash data in particular should be considered sacred, especially given the severity in this case. Ideally it should be kept both on the local black box and on the servers. But anything that leads to it being treated as instantly disposable everywhere, or even just claiming it was deleted, can only be malice.
  - wat10000 1y ago
    > The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. Exactly. The issue is deleting the data on the servers, not a completely mundane upload-then-delete procedure for phoning home. This should have been one sentence, but instead they make it read like a heist.
  - giancarlostoro 1y ago
    > The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. There's no technical reason to dispose of data related to a crash when you hold so much data on all of the cars in general. My money is on nobody built a tool to look up the data, so they have it, they just can't easily find it.
    - deleted 1y ago
      [deleted]
- alistairSH 1y ago
  That might be the case but the article seems to indicate the system knew the data was generated from an accident. So, removing to save space on the car should now be a secondary concern.
- joshcryer 1y ago
  The problem with this is that it destroys any chain of evidence. Tesla "lost" this data, in fact. You would never want your "black box" in your car delete itself after uploading to some service because the service could go down, be hacked, or the provider could decide to withhold it, forcing you into a lengthy discovery / custody battle. This data is yours. You were going the speed limit when the accident happened and everyone else claims you were speeding. It would take forever to clear your name or worse you could be convicted if the data was lost. This is more of "you will own nothing" crap. And mainly so Tesla can cover its ass.
- aredox 1y ago
  It is a car. A vehicule which can be involved in a fatal accident. It is not a website. There is no "oversight", nor is it "pretty standard" to do it like that: when you don't think about what your system is actually doing (and that is the most charitable explanation), YOU ARE STILL RESPONSIBLE AS IF YOU HAD DONE IT ON PURPOSE.
  - wat10000 1y ago
    One of Tesla’s things is that their software is built by software people rather than by car people. This has advantages and disadvantages. Maybe this is not appropriate for a car, but that doesn’t excuse the ridiculous breathless tone in the quoted text. It’s the worst purple prose making a boring system sound exciting and nefarious. They could have made your point without trying to make the unlink() call sound suspicious.
    - buran77 1y ago
      > their software is built by software people rather than by car people The rogue engineer defense worked so well for VW and Dieselgate. The issue of missing crash data was raised repeatedly. Deleting or even just claiming it was deleted can only be a mistake the first time.
      - wat10000 1y ago
        I really should know better than to think that I can criticize a small part of an article without a bunch of people thinking that I'm defending everything the article discusses.
    - const_cast 1y ago
      There are software people who know what they're doing - some write flight software or medical equipment software. They know how to critically think about the processes of their systems in detail. So either the problem is Tesla engineers are fucking stupid (doubtful) or this is a poor business/product design. My money is on the latter.
    - 1y ago
OutOfHere 1y ago
That's 100% wrong. In standard practice, collision files are to be "locked", prevented from local deletion.
- phkahler 1y ago
  >> That's 100% wrong. In standard practice, collision files are to be "locked", prevented from local deletion. I worked a year in airbag control, and they recorded a bit of information if the bags were deployed - seatbelt buckle status was one thing. But I was under the impression there was no legal requirement for that. I'm sure it helps in court when someone tries to sue because they were injured by an airbag. The argument becomes not just "the bags comply with the law" but also "you weren't wearing your seatbelt". Regardless, I'm sure Tesla has a lot more data than that and there is likely no legal requirement to keep it - especially if it's been transferred reliably to the server.
- giancarlostoro 1y ago
  I don't think its wrong, have you ever pushed code that was technically correct, only to find months later that you, your PM, their manager, their boss' boss, etc all missed one edge case? You're telling me no software developer has ever done this?
  - buran77 1y ago
    You discover it the day you a person dies and your relevant data is not there. Next time it's no longer a "missed edge case".
    - giancarlostoro 1y ago
      In a perfect world where developers are omnipresent and all knowing sure? This isn't a perfect world. Heck, how do you account for the developer who coded it leaving the company, and now that code has been untouched for half a decade if not more, because nothing is seemingly wrong with the code, what then? Who realizes it needs to be changed? Nobody. The number of obscure bugs I find in legacy code that stump even the most experienced maintainers never ends.
giancarlostoro 1y ago
I think your answer is the most logical to me as a developer, we often miss simple things, the PM overlooks it, and so it goes into production this way. I don't think its malicious. Sometimes bugs just don't become obvious until things break. We have all found an unintended consequence of our code that had nothing wrong with it technically sooner or later.
const_cast 1y ago
Dude we're at the point where cars are practically gathering data on the size of your big toe. The performance ship sailed, like, 15 years ago. We're already storing about 10000000 more data than we need. And that's not even an exaggeration.
ajross 1y ago
In point of fact eMMC wear failure was an actual bug in early Tesla MCUs. They were logging too much, so when the car reached (via routine use) a certain fill level the logging started running over the same storage again and again and the chips started failing. It's very easy to imagine a response to this being (beyond "don't log so much") an audit layer to start automatically removing redundant data. The externalities of the company are such that people want to ascribe malice, but this is a very routine kind of thing.
- A4ET8a8uTh0_v2 1y ago
  This, I think, was the argument that seems most plausible to me ( without ascribing malice ). It brings its own set of issues, but even those issues make it more believable despite being problematic in their own right.

Assuming no malice, I'd guess it's for space saving on the car's internal memory. If the data was uploaded off of the car, there’s no point keeping it in the car.

wat10000 1y ago

Sounds like a pretty standard telemetry upload. You transmit it, keep your copy until you get acknowledgement that it was received so you can retry if it went wrong, then delete it when it succeeds. It’s just worded to make this sound sketchy. I bet ten bucks “unlinked” just refers to the standard POSIX call for deleting a file.

tobias3 1y ago
Sketchy is that then someone takes “affirmative action to delete” the data on the server as well. Also this is not like some process crash dump where the computer keeps running after one process crashed. This would be like an plane black box uploading its data to the manufacturer, then deleting itself after a plane crash.
- wat10000 1y ago
  I’ll bet another ten bucks that this is a generic implementation for all of their telemetry, not something special cased for crashes. Deleting the data on the server is totally sketchy, but that’s not what the quoted section is about.
  - dylan604 1y ago
    How handling an automobile crash not as a special case is the weird part. Even in the <$50 dashcams from Amazon there is a feature to mark a recording as locked so the auto delete logic does not touch the locked file. Some of them even have automatic collision detection which locks the file for you. How Tesla could say that detecting a collision and not locking all/any of the data is normal is just insane.
    - immibis 1y ago
      That one's easy: nobody at Tesla cares about having this feature
  - pjob 1y ago
    That might not be a good bet. https://news.ycombinator.com/item?id=45063380 https://news.ycombinator.com/item?id=45063380
    - wat10000 1y ago
      I don't see anything in that comment that would apply to what I said.
buran77 1y ago
The process of collecting and uploading the data probably confuses a lot of non-technical readers even if it worked as per standard industry practices. The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. There's no technical reason to dispose of data related to a crash when you hold so much data on all of the cars in general. Crash data in particular should be considered sacred, especially given the severity in this case. Ideally it should be kept both on the local black box and on the servers. But anything that leads to it being treated as instantly disposable everywhere, or even just claiming it was deleted, can only be malice.
- wat10000 1y ago
  > The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. Exactly. The issue is deleting the data on the servers, not a completely mundane upload-then-delete procedure for phoning home. This should have been one sentence, but instead they make it read like a heist.
- giancarlostoro 1y ago
  > The real issue is that Tesla claimed the company doesn't have the data after every copy was deleted. There's no technical reason to dispose of data related to a crash when you hold so much data on all of the cars in general. My money is on nobody built a tool to look up the data, so they have it, they just can't easily find it.
  - deleted 1y ago
    [deleted]
alistairSH 1y ago
That might be the case but the article seems to indicate the system knew the data was generated from an accident. So, removing to save space on the car should now be a secondary concern.
joshcryer 1y ago
The problem with this is that it destroys any chain of evidence. Tesla "lost" this data, in fact. You would never want your "black box" in your car delete itself after uploading to some service because the service could go down, be hacked, or the provider could decide to withhold it, forcing you into a lengthy discovery / custody battle. This data is yours. You were going the speed limit when the accident happened and everyone else claims you were speeding. It would take forever to clear your name or worse you could be convicted if the data was lost. This is more of "you will own nothing" crap. And mainly so Tesla can cover its ass.
aredox 1y ago
It is a car. A vehicule which can be involved in a fatal accident. It is not a website. There is no "oversight", nor is it "pretty standard" to do it like that: when you don't think about what your system is actually doing (and that is the most charitable explanation), YOU ARE STILL RESPONSIBLE AS IF YOU HAD DONE IT ON PURPOSE.
- wat10000 1y ago
  One of Tesla’s things is that their software is built by software people rather than by car people. This has advantages and disadvantages. Maybe this is not appropriate for a car, but that doesn’t excuse the ridiculous breathless tone in the quoted text. It’s the worst purple prose making a boring system sound exciting and nefarious. They could have made your point without trying to make the unlink() call sound suspicious.
  - buran77 1y ago
    > their software is built by software people rather than by car people The rogue engineer defense worked so well for VW and Dieselgate. The issue of missing crash data was raised repeatedly. Deleting or even just claiming it was deleted can only be a mistake the first time.
    - wat10000 1y ago
      I really should know better than to think that I can criticize a small part of an article without a bunch of people thinking that I'm defending everything the article discusses.
  - const_cast 1y ago
    There are software people who know what they're doing - some write flight software or medical equipment software. They know how to critically think about the processes of their systems in detail. So either the problem is Tesla engineers are fucking stupid (doubtful) or this is a poor business/product design. My money is on the latter.
  - 1y ago

OutOfHere 1y ago

That's 100% wrong. In standard practice, collision files are to be "locked", prevented from local deletion.

phkahler 1y ago
>> That's 100% wrong. In standard practice, collision files are to be "locked", prevented from local deletion. I worked a year in airbag control, and they recorded a bit of information if the bags were deployed - seatbelt buckle status was one thing. But I was under the impression there was no legal requirement for that. I'm sure it helps in court when someone tries to sue because they were injured by an airbag. The argument becomes not just "the bags comply with the law" but also "you weren't wearing your seatbelt". Regardless, I'm sure Tesla has a lot more data than that and there is likely no legal requirement to keep it - especially if it's been transferred reliably to the server.
giancarlostoro 1y ago
I don't think its wrong, have you ever pushed code that was technically correct, only to find months later that you, your PM, their manager, their boss' boss, etc all missed one edge case? You're telling me no software developer has ever done this?
- buran77 1y ago
  You discover it the day you a person dies and your relevant data is not there. Next time it's no longer a "missed edge case".
  - giancarlostoro 1y ago
    In a perfect world where developers are omnipresent and all knowing sure? This isn't a perfect world. Heck, how do you account for the developer who coded it leaving the company, and now that code has been untouched for half a decade if not more, because nothing is seemingly wrong with the code, what then? Who realizes it needs to be changed? Nobody. The number of obscure bugs I find in legacy code that stump even the most experienced maintainers never ends.

giancarlostoro 1y ago

I think your answer is the most logical to me as a developer, we often miss simple things, the PM overlooks it, and so it goes into production this way. I don't think its malicious. Sometimes bugs just don't become obvious until things break. We have all found an unintended consequence of our code that had nothing wrong with it technically sooner or later.

const_cast 1y ago

Dude we're at the point where cars are practically gathering data on the size of your big toe. The performance ship sailed, like, 15 years ago. We're already storing about 10000000 more data than we need. And that's not even an exaggeration.

ajross 1y ago

In point of fact eMMC wear failure was an actual bug in early Tesla MCUs. They were logging too much, so when the car reached (via routine use) a certain fill level the logging started running over the same storage again and again and the chips started failing. It's very easy to imagine a response to this being (beyond "don't log so much") an audit layer to start automatically removing redundant data. The externalities of the company are such that people want to ascribe malice, but this is a very routine kind of thing.

A4ET8a8uTh0_v2 1y ago
This, I think, was the argument that seems most plausible to me ( without ascribing malice ). It brings its own set of issues, but even those issues make it more believable despite being problematic in their own right.