[HN Gopher] NTSB report: Decryption of images from the Titan sub...
___________________________________________________________________
NTSB report: Decryption of images from the Titan submersible camera
[pdf] (2024)
Author : bmurray7jhu
Score : 178 points
Date : 2025-11-23 00:35 UTC (22 hours ago)
(HTM) web link (data.ntsb.gov)
(TXT) w3m dump (data.ntsb.gov)
| bmurray7jhu wrote:
| Report on unrecoverable SSDs:
|
| https://data.ntsb.gov/Docket/Document/docBLOB?ID=19169363&Fi...
|
| Full docket:
|
| https://data.ntsb.gov/Docket/?NTSBNumber=DCA23FM036
| dwohnitmok wrote:
| I'm confused. Why are decryption keys in NVRAM? That seems to
| negate the purpose of at-rest encryption if you can retrieve keys
| from the device even after shutdown.
| daemonologist wrote:
| Well they're encrypting an SD card, so this still defends
| against its being removed from the camera and stolen or left in
| a bar or something.
|
| But honestly from the rest of the story it sounds like the
| camera manufacturer was selling their pressure housing moreso
| than the off-the-shelf camera hardware inside, and was not
| particularly concerned with whether/how the storage was
| encrypted.
| tremon wrote:
| What would you say is the threat model that leads one to auto-
| encrypt sdcards?
|
| For a machine that needs to boot unattended, what would you do
| with disk decryption keys?
| dwohnitmok wrote:
| > What would you say is the threat model that leads one to
| auto-encrypt sdcards?
|
| Jumping off of daemonologist's point, the most convincing
| model I could think of is one where you are consistently
| removing the SD Card, likely because you are swapping
| multiple SD cards back and forth. But this still seems bad!
| In that case your multiple SD cards all share the same
| decryption key (or I guess less egregiously all at least
| share the same physical vulnerability of that device's
| nonvolatile memory).
|
| > For a machine that needs to boot unattended, what would you
| do with disk decryption keys?
|
| This depends entirely on what you mean by unattended. Here's
| some candidates:
|
| 1. The machine has a network connection and you would like to
| boot it over the network. In that case you have a small
| unencrypted bit that handles the boot sequence and then pass
| the decryption key over the wire, store in volatile memory,
| and wipe on shutdown or logout.
|
| 2. The machine is regularly serviced/booted by an in-person
| operator. You give the decryption key or passphrase to the
| operator to decrypt and boot the machine.
|
| 3. The machine is meant to autonomously reboot itself due to
| e.g. error conditions. In extreme cases when the machine
| detects that there is a large probability of physical
| compromise, it shuts down. In this case for the former I
| would imagine some power supply, e.g. a backup battery, that
| keeps the volatile memory up when rebooting and in case of
| large probability of physical compromise there is a forced
| shutdown and/or wipe of the volatile memory.
|
| 4. An operator needs to periodically boot up the machine, but
| the operator should not be able to access any previous data
| the machine has recorded (data from the moment operator
| arrives forward is assumed leaked to the operator because
| e.g. the operator can just position their own sensor in front
| of the machine and collect data). In that case asymmetric
| encryption should be used and the encryption keys should be
| stored on the machine, but the decryption keys should not,
| effectively turning the machine into a write-only device from
| the operator's perspective.
|
| The only case I could imagine where you want the machine to
| boot unattended and you'd keep the decryption keys in
| nonvolatile memory on the device is if you want an operator
| to be able to boot the device without knowledge of the
| decryption key and also to be able to view historical data
| previously recorded by the device. But in that case there is
| no functional difference between that and a device that is
| unencrypted! In both cases you boot up the device without a
| password and voila all the data is in front of you ready to
| be read! And indeed that's basically what happened here
| (modulo the difficulties associated with the device being
| damaged). And in that case encryption seems like pure
| overhead for no real security benefit.
| cbsks wrote:
| Wow. SubC's software engineering needs some work. They thought
| the camera's file system was unencrypted, when it was encrypted.
| They didn't know where the keys were to decrypt it. It turned out
| the key was written unencrypted to a UFS storage device. There
| was a file written to /mnt/nas/Stills, which indicates that the
| camera was to writing to a remote file system that wasn't
| mounted.
| userbinator wrote:
| _They thought the camera's file system was unencrypted, when it
| was encrypted._
|
| Unfortunately this situation is likely to get more common in
| the future as the "security" crowd keep pushing for encryption-
| by-default with no regard to whether the user wants or is even
| aware of it.
|
| Encryption is always a tradeoff; it trades the possibility of
| unauthorised access with the possibility of even the owner
| losing access permanently. IMHO this tradeoff needs careful
| consideration and not blind application.
| jiggawatts wrote:
| This is why I always shake my head when the Reddit armchair
| security experts say "The data wasn't even encrypted!?
| Amateur hour!" in response to some PII leak.
|
| Sure, sure buddy, I'll encrypt all of my PII data so nobody
| can access it... including the web application server.
|
| Okay, fine, I'll decrypt it on the fly with a key in some API
| server... now the web server had unencrypted access to it,
| which sounds bad, but that's literally the only way that it
| can _process_ and _serve_ the data to users in a meaningful
| way! Now if someone hacks the web app server -- the common
| scenario -- then the attacker has unencrypted access!
|
| I can encrypt the database, but at what layer? Storage? Cloud
| storage is already encrypted! Backups? Yeah, sure, but then
| what happens in a disaster? Who's got the keys? Are they
| contactable at 3am?
|
| Etc, etc...
|
| It's not only not as simple as ticking an "encrypted: yes"
| checkbox, it's maximally difficult, with a very direct
| tradeoff between accessibility and protection. The sole
| purpose of encrypting data is to _prevent access!_
| londons_explore wrote:
| I like the approach of mega.nz...
|
| Server stores encrypted blobs. Server doesn't have the
| keys. Entire application is on the client,
| and just downloads and decrypts what it needs.
|
| Obviously your entire application stack needs to be
| developed with that approach in mind, and some things like
| 'make a hyperlink to share this' get much more complex.
| Terr_ wrote:
| Nah bro, you just gotta use homomorphic encryption! /s
|
| That said, encryption at rest is still good in terms of
| theft or mis-disposal.
| dh2022 wrote:
| Re: encrypting data that would be served via web server:
| why would anyone bother to encrypt data meant to be shared
| externally worldwide? It makes no sense to begin with...
| UltraSane wrote:
| This has already happened to Windows users when BitLocker
| disk encryption is enabled by default and they do something
| that causes the encryption key to be lost.
|
| You can have the key saved in your Microsoft account.
| userbinator wrote:
| _You can have the key saved in your Microsoft account._
|
| I find it very hard to believe that those who _want_ their
| disk encrypted also want Microsoft to have the key.
| UltraSane wrote:
| Microsoft isn't going to release it without a warrant.
| But you have to trust their security not to leak it.
| londons_explore wrote:
| > They thought the camera's file system was unencrypted, when
| it was encrypted.
|
| Willing to bet plenty of hn readers are unaware of encryption
| going on at lower layers of the tech stack than they're aware
| of.
|
| For example most hard drives encrypt all data, even when not
| commanded to, as a way to do 'data whitening' (ie making sure
| there are even numbers of 0's and 1's in the data stream and
| not some pattern which might throw off tracking.)
|
| The encryption key is simply stored elsewhere in the drive - or
| nvram or in the firmware.
|
| But it means if you extract the physical magnetic surface and
| read it with the right microscope, you might well find the data
| encrypted with no available key.
| ryan-ca wrote:
| To my knowledge, encoding avoids runs to avoid
| desynchronization in a way that isn't encrypted.
| londons_explore wrote:
| This used to be done, but since ~2000, disks were expected
| to support on-device encryption, and by making encryption
| always-on no encoding is needed.
| rocqua wrote:
| This is line coding, often used on wired connections. But
| reading a hard drive trace isn't quite a wired connection,
| so the trade-offs are different.
|
| Most notably with line coding when using positive and
| negative voltages it is quite important for the average
| voltage to be zero to avoid building up a charge
| difference. Whitening can often be used if the downside to
| an imbalance or long runs is much lower. Notably in RF this
| is often about avoid harmonics with a little bit of symbol
| timing advantage thrown in.
|
| Whitening doesn't really require encryption though. Weak
| cypher streams xored into the data work fine. Even a
| repeated 256 bit string is quite alright.
|
| Whitening using any non trivial encryption key seems weird
| to me. AES with a key equal to the current offset in ECB
| mode already feels over-engineerd.
| londons_explore wrote:
| > Whitening using any non trivial encryption key seems
| weird to me.
|
| It's because there was an era when drives were expected
| to be able to do 'hardware' encryption with a user
| provided key, so reusing that hardware to also do
| whitening even if the user didn't provide a key was very
| convenient.
|
| Plus you get all the other benefits - ie. a single scsi
| command can 'secure erase' the whole disk in milliseconds
| by simply changing the stored key.
| themafia wrote:
| Scrambling and encryption are two different things.
| Scrambling is very easy to do at line rates. Encryption not
| so much.
|
| Ethernet is a good example. It has the same problem where
| long strings of 0's or 1's can cause clock recovery problems.
| The solution as clock rates have increased is to just run all
| the data through a scrambler driven by a simple Linear
| Feedback Shifter.
| kasabali wrote:
| If you're talking about SED feature, no, it isn't widespread
| since it's regarded as an "enterprise" feature and only
| available in minority of drives (regardless of HDD or SSD).
| Client or OEM variants of same drives (otherwise identical)
| lack SED option most of the time and doesn't encrypt data by
| default.
| londons_explore wrote:
| The hardware is still there - they don't make a new asic
| for the consumer version
| kasabali wrote:
| doesn't mean it's active.
| Nextgrid wrote:
| "Active" with those systems just means the encryption key
| is now user-supplied instead of being stored on the
| controller/drive. The actual encryption is always active;
| which makes sense, if anything it means you have one less
| configuration to test.
| watersb wrote:
| The SD card on the camera was intact but encrypted. Decrypting
| the data required a key stored on a separate SOM board, but the
| SOM was damaged. The investigation team delivered the SOM and SD
| card to the camera manufacturer in Newfoundland, and they were
| able to decrypt the card.
|
| They found a couple of images, but No data with
| a timestamp after May 16th was found on the camera, so it is
| likely that none of the data recorded on the SD Card were of the
| accident voyage or dive.
|
| After all that work...
|
| If you're interested in data recovery, you will enjoy reading
| this report, about 10 pages, clearly written. The technical
| language mentioned they didn't see a LUKS header on the card so
| they figured it was a custom dm_crypt setup.
| cloudbonsai wrote:
| > No data with a timestamp after May 16th was found on the
| camera, so it is likely that none of the data recorded on the
| SD Card were of the accident voyage or dive.
|
| Evidently the camera data was recorded to an external SSD card
| in the mission computer when the accident occurred.
|
| The investigation team actually managed to salvage the PC as
| well:
|
| https://data.ntsb.gov/Docket/Document/docBLOB?ID=19169363&Fi...
|
| Sadly it turned into a compressed ball of metal...
| djmips wrote:
| That's a striking image! Thanks for sharing - that really
| hits home on the pressures involved.
| londons_explore wrote:
| Pretty sure tech exists to recover data from flash memory
| with cracked dies...
|
| I guess they decided it wasn't worth pursuing.
| dwohnitmok wrote:
| > Pretty sure tech exists to recover data from flash memory
| with cracked dies...
|
| If you have anymore on this would love to see any relevant
| materials.
| yawpitch wrote:
| You can just make out the heatsink fins of the three PCs
| there, stacked atop (and now kind of inside) each other.
|
| That truly is one of those "let God sort them out"
| situations.
| gattr wrote:
| From the report:
|
| > To conduct the CT scans, the large mass was evaluated by a
| third-party laboratory under NTSB supervision. This facility
| had a range of scanners with different power and energy
| levels and could scan large masses using a rotating table,
| avoiding the need to rotate the mass itself. Ultimately, the
| third-party laboratory attempted to image the large mass at a
| power as high as 320 kilovolts (kV). The scans conducted at
| 320 kV were not powerful enough to penetrate the object, and
| as a result, no internal structures or voids were visible,
| and no memory devices could be identified. The NTSB evaluated
| using another laboratory with higher power and energy CT scan
| devices, however, there was concern that increased CT scan
| energy could damage data stored on any surviving NVM chips.
| Consequently, higher-energy scans were not pursued.
|
| I'm no expert, but remember reading about neutron imaging
| ([1]). I'm curious if that was deemed unfeasible, too
| expensive, or having little chance of success? From
| Wikipedia:
|
| > X-rays are attenuated based on a material's density. Denser
| materials will stop more X-rays. With neutrons, a material's
| likelihood of attenuation of neutrons is not related to its
| density. Some light materials such as boron will absorb
| neutrons while hydrogen will generally scatter neutrons, and
| many commonly used metals allow most neutrons to pass through
| them.
|
| [1] https://en.wikipedia.org/wiki/Neutron_imaging#Neutron_rad
| iog...
| rozab wrote:
| What's with the entire dev board crammed in there? Is that...
| normal? What board is it?
| daemonologist wrote:
| It appears to be a Teensy 3.2
|
| The "carrier" that everything rides on within the housing is
| clearly FDM printed as well. I assume these cameras (rated to
| 6,000 meters) are rather low volume products.
| buildbot wrote:
| It honestly makes sense. You are paying for the pressure
| engineering, and can take advantage of an off the shelf
| camera system. Maybe use a special lens or filter or
| something but why bother customizing the software/hardware of
| the camera much.
|
| They probably should still know what it's doing though...
| analog31 wrote:
| I came here to say "that's definitely a Teensy 3.2"
|
| The black cable goes dangerously close to the pushbutton of
| death. ;-)
| duskwuff wrote:
| The small board on the left is unmistakably a Teensy 3.2:
|
| https://www.pjrc.com/store/teensy32.html
|
| As to what it's doing in there, I have no idea.
| djmips wrote:
| Well, I'll be darned! I wonder if Paul Stoffregen knows about
| that!
|
| edit: probably? It was posted at the Teensy forum about a
| month ago.
|
| https://forum.pjrc.com/index.php?threads/the-deepest-
| teensy....
| whalesalad wrote:
| Looks like a pi zero
| quamserena wrote:
| I have seen engineers slap Teensies on a PCB and call it a day,
| so it's definitely normal. It's faster than having to route
| your MCU, USB, debugger, etc. manually, so there isn't really a
| drawback as long as it physically fits there.
| 15155 wrote:
| > It's faster than having to route your MCU
|
| Common misconception. A handful of capacitors, SPI NOR flash,
| an inductor, and a crystal is way easier to place and route
| than a restrictive module that completely disables your
| ability to use SWD/JTAG on an otherwise excellent MCU.
| switknee wrote:
| Yup, if it works in your testing, why bother changing it?
| daemonologist wrote:
| Previous discussion (October 17th):
| https://news.ycombinator.com/item?id=45613898
|
| Also a good video from Scott Manley: https://youtu.be/qMUjCZ7MMWQ
| pseudolus wrote:
| There's a fascinating and redacted interview with an "anonymous"
| subject about the disaster. To say the least it's an unsuccessful
| attempt to hide the identity of the individual:
|
| "Q. So how did you get yourself started into submersible
| operations?
|
| A. Well, I'm sure you're familiar with my film Titanic. When I
| set down the path to make that film, the first thing that I did
| was arrange to be introduced to the head of the submersible
| program at the P.P. Shirshov Institute in Moscow, a guy named..."
|
| https://media.defense.gov/2025/Sep/17/2003800984/-1/-1/0/CG-...
| vlovich123 wrote:
| Let's hear from L Simpson. No, that's too specific. Let's hear
| from Lisa S.
| vlovich123 wrote:
| Took me forever to find the actual quote - ChatGPT and Gemini
| kept trying to gaslight me that it's not a real quote or that
| Willie said it to Bart until I gave the exact quote (at which
| point normal search engines were fine):
|
| > A certain agitator, for privacy's sake, let's call her Lisa
| S. No, that's too obvious, let's say L. Simpson.
|
| Lisa the Vegetarian
| edoceo wrote:
| When I grow up I'm going to Bovine University!
| maybelsyrup wrote:
| In the future, Frinkiac [0] is your friend
|
| [0] https://frinkiac.com/
| monkpit wrote:
| If you google "Lisa S L Simpson" it's the first thing that
| comes up... why make it harder with AI?
| lanyard-textile wrote:
| ... Quite ironically, Google results are AI... :)
| palmotea wrote:
| >> Took me forever to find the actual quote - ChatGPT and
| Gemini kept trying to gaslight me that it's not a real
| quote or that Willie said it to Bart until I gave the
| exact quote (at which point normal search engines were
| fine):
|
| > If you google "Lisa S L Simpson" it's the first thing
| that comes up... why make it harder with AI?
|
| Because AI is the future! His employer is probably
| requiring him use it first for everything. Only when it
| fails (and you can tell), may other ways to solve the
| problem be tried.
| sva_ wrote:
| I've recently randomly seen some younger guy running a
| basic calculation like 7*12 in chatgpt on his phone. It
| just had me in disbelief
| bmurray7jhu wrote:
| "I think the most dangerous part of our whole operation was
| these young software engineers puking over the railing in a
| high sea."
| cloudbonsai wrote:
| Among the interviews, one with the former engineering director
| was the most eye-opening for me.
|
| https://data.ntsb.gov/Docket/Document/docBLOB?ID=17236880&Fi...
|
| It appears that all the engineers -- system designer, material
| engineer and structural analyst -- thought that OceanGate CEO
| was going to kill himself: If you ever find
| <name-of-the-engineer>, he's not going to have a whole
| lot of nice to say. He was very frustrated with the
| company. (...) And I understand why. He thought
| Stockton was going to kill himself.
|
| And the director himself declined to dive on Titan when asked:
| Now, the question is, why wouldn't the engineer get inside
| his own vehicle? It was because of what I felt -- and I have a
| background in Navy diving in EOD operations. I knew firsthand
| that the operations group was not the right group for that
| role, and I told him as much, that I don't trust
| operations and who he has there.
| idontwantthis wrote:
| I read that the pilot was also basically suicidal. His wife
| had died, and he was completely fine with the danger because
| he would die doing what he loved, and he didn't really want
| to live anymore.
| djmips wrote:
| Wasn't the pilot Stockton Rush? His wife was alive. Who are
| you referring to? I tried to check your claim but I
| couldn't verify it.
| nagaiaida wrote:
| they're talking about nargeolet
|
| > Wreck expert Paul-Henri "P.H." Nargeolet, who was also
| onboard, told me he wasn't worried about what would
| happen if the structure of the Titan itself were damaged
| when at the bottom of the ocean. "Under that pressure,
| you'd be dead before you knew there was a problem." He
| said it with a smile.
|
| (as recounted by Arnie Weissmann, in Travel Weekly
| article published June 22, 2023)
| idontwantthis wrote:
| Yeah I got the roles of pilot and guide mixed
|
| https://www.newyorker.com/news/a-reporter-at-large/the-
| titan...
| netsharc wrote:
| There was only one other crew member in that vessel
| (well, actual crew and not paper "mission specialist").
| He was an older gentleman, and it's quite common for
| older people to have lost their spouse. Was that so hard
| to figure out?
| djmips wrote:
| yeah but he remarried
| bambax wrote:
| The number of stupid decisions that went in the design and
| construction of the Titan is astonishing. One of my favorites
| was that, after putting on the carbon fiber around the tube,
| they would sand imperfections to make the surface perfectly
| smooth, severing layers in the process! It shouldn't require
| an engineering degree from MIT to recognize this as ill-
| advised.
| lazide wrote:
| Even without that, the material is just wrong. It's strong
| in tension, not so much compression. Tends towards sudden
| brittle fractures. Doesn't like impacts, as it tends to
| have issues with delaminating.
|
| It's just not what you ever want as a sub hull. It's dumb.
|
| And weight is not even a huge issue for a sub!
| bambax wrote:
| Yes, using carbon fiber was also a very bad decision; it
| was known for a very long time that it was only good for
| single-use sub, because after the first dive it was too
| damaged to continue. In 2014, Virgin Oceanic, which had
| similar plans with similar technology, closed shop
| because it didn't make economic sense to build a new sub
| for each dive.
|
| But weight is absolutely an issue; the basic and tried-
| and-true metal sphere design allows for only three
| people. Since size and thickness grow exponentially,
| making a sphere for more than three people becomes more
| and more difficult. And it should also be possible to
| lift the vehicle with a crane.
|
| But if you want to carry paying passengers (like
| Oceangate did), having only two per dive is very
| limiting. That's why they went with a tube design, and
| carbon fiber to limit weight. But it couldn't work, and
| it didn't.
| schiffern wrote:
| >size and thickness grow exponentially
|
| It's a [reverse] pressure vessel, so it follows pressure
| vessel scaling. Mass scaling is linear with internal
| volume.
| FabHK wrote:
| It's funny how "literally" often means "figuratively"
| now, and "exponentially" means "polynomially".
| bambax wrote:
| Yep.
|
| https://books.google.com/ngrams/graph?content=exponential
| ly%...
| bambax wrote:
| Ok yes "exponentially" was hyperbolic. Mass scales
| linearly with volume, but volume is proportional to the
| cube of the radius (not linear).
|
| Also, in practice, small imperfections can have a
| disproportionate impact on the resistance of the sphere
| so design codes typically apply conservative reductions
| that can have a big impact on actual thickness
| requirements.
| wkat4242 wrote:
| Did this thing meet any design codes though? I doubt it.
| donavanm wrote:
| I read the report when it come out. From memory, no. It
| never had any components or certification for human
| pressure vessels. IIRC theres no existing regs for carbon
| fiber and it would have cost like $50M to do the design
| and test work. They did buy some things, like the
| viewport, from companies who _do_ certified parts, but
| instead opted for the same design minus any test certs to
| save money. The craft was never certified or inspected by
| the uscg. It did have a registration for a while, but
| they had to play find-a-new-district-sign-off shell games
| for a while, then... just stopped bothering.
| wkat4242 wrote:
| Thanks for the detailed answer! It doesn't suprise me at
| all.
| owenversteeg wrote:
| "Strong in tension, not compression" is a meme, and
| obviously wrong. It is certainly stronger in tension, but
| it is also remarkably strong in compression. That's why
| it's used - yes, in compression - in modern passenger
| aircraft. You don't even need to know that, though; the
| simple fact is that the Titan had a double-digit number
| of deep dives. If it was weak in compression it would not
| have survived diving to 3.7 kilometers deep or even a
| fraction of that depth _once_.
|
| That said, yes, it's a difficult material to use
| properly, and they were a bunch of cowboys slapping
| things together. It's no surprise that they missed
| several critical steps and created a sub doomed to fail.
|
| N.b. all of this was kickstarted by James Cameron saying
| that carbon fiber has "no strength in compression" in a
| New York Times "science" article, which the Times printed
| directly.
| lazide wrote:
| Aircraft fuselages are typically loaded in tension. It's
| a key part of the design.
|
| Carbon fiber compressive strength is only ~ 30-50% of
| it's tensile strength because of the way the fibers and
| the epoxy interact. When compressed, the carbon fibers
| don't do as much. [https://www.sciencedirect.com/science/
| article/abs/pii/S02638...]
|
| But don't believe me, actually read a useful paper on the
| subject.
|
| In fact, it's a major factor limiting it's wider use. As
| is it's fatigue behavior, which would probably also
| explain why it eventually imploded!
|
| I never followed James Cameron's interview, but it sounds
| like he knows what he is talking about!
| buildbot wrote:
| Speaking of which I heavily recommend reading interview
| the prime ancestor comment to this chain linked. It's
| really clear he knows what he is talking about.
| owenversteeg wrote:
| James Cameron certainly knows a lot about submarines, but
| if he says something factually incorrect then it's
| factually incorrect, period. Carbon fiber does not have
| "no strength in compression" and it is used in
| compression in countless applications, for example
| airplane wings. Again, the fact that the sub - built at
| absurdly low cost for its size, built by a bunch of
| cowboys that didn't know what they were doing - DID
| survive to 3.7 km deep on several occasions is proof
| sufficient. If CF had no compressive strength than the
| whole thing would have failed at a tiny fraction of that
| depth. If CF had no compressive strength then what kept
| the sub together during the successful dives? Hopes and
| dreams?
|
| I'm not here to defend the decision to use carbon fiber,
| and as I've said I completely agree that there are many
| issues with using it in this application. Delamination,
| water ingress, bonding the titanium to the carbon fiber,
| difficulty of manufacture including varying layer
| thickness and voids, sensitivity to impact, the list goes
| on. But _those_ are the issues, not the compressive
| strength.
| lazide wrote:
| Moved the goalposts again eh? While completely ignoring
| the cites and discussion? What, were you a major
| shareholder? Family member?
| franktankbank wrote:
| I don't like this interpretation of things. Its worthwhile
| to experiment and try things. They were basically mentally
| ill as a group and rejected genuine concern. Everyone wants
| to shit on the build but it was the human relations that
| killed it.
| nativeit wrote:
| Also, honestly, the build. That "genuine concern" they
| ignored was that the build was critically flawed. I don't
| think anyone here would have these takes if a small group
| of curious engineers tried their hand at a composite
| submersible, it was when they kept doing it after all the
| qualified engineers had said, "This is crazy, I'm out."
|
| The build was kind of dumb, and I'm hardly an engineer.
| It's common sense. Carbon fiber composites are
| interesting because they're strong relative to their
| weight. Remove either of those features and they become
| pointless.
|
| Who cares if a submarine is heavy?
| robot-wrangler wrote:
| Wow! Man, an insider with these kinds of concerns isn't
| exactly exonerating or excusing themselves with such a
| testimony. Whistle-blowing to any relevant authority as hard
| as possible seems like the bare minimum? And if there's no
| governing agency to pass the responsibility over to, I think
| you gotta quietly approach the first customer (or victim)
| with these concerns if not a newspaper
| bambax wrote:
| Cameron did several TV interviews about the Titan, why would
| they redact his name?
|
| He didn't mince his words either; he was extremely critical of
| the whole thing before and after the disaster.
| desert_rue wrote:
| Maybe it is policy. If you have three experts in the field
| and you redact the details for two of the interviews taken,
| you can't work it out that Bob was one of the two. Granted,
| they borked the redaction here.
| Nextgrid wrote:
| Same policy that "redacted" the brand of the SD card, even
| though anyone that would be able to do anything with that
| information would immediately recognize it as a SanDisk.
| Zak wrote:
| > _Removed SD card. The manufacturer of the camera had requested
| certain components of the device be redacted. Portions of this
| image have been redacted._
|
| And so it is, but anyone who has ever seen a Sandisk SD card
| knows what they're looking at. I can even tell it's not the
| fastest V90 speed.
|
| The things companies try ineffectually to keep out of public view
| are weird.
| vayup wrote:
| Especially when anyone can buy the product off the shelf,
| remove the casing to see what they are trying to redact in
| these images.
| JCM9 wrote:
| Amusing that the bits the "manufacturer asked to be redacted" in
| the images appear to be the identifiers for common off-the-shelf
| electronic components, including a standard memory card. Is that
| really super secret IP?
| rasz wrote:
| It is if you are a camera manufacturer. Another example
| https://www.cined.com/whats-inside-a-red-mini-mag-the-contro...
| gosub100 wrote:
| could be a PR / brand identity management thing. They dont want
| their slogan to be come "The official Storage Medium of Deadly
| Disasters".
| alhirzel wrote:
| Crazy that it's pretty much a 3D printed assembly internally, and
| the manufacturer didn't know how it worked. No way that would
| pass any kind of vibration test.
___________________________________________________________________
(page generated 2025-11-23 23:01 UTC)