> This still and video camera is rated to withstand depths up to 6,000m (19,685 feet, 3,281 fathoms)
Unlike the Titan sub...
Firefox Focus does work as an alternative.
Apple created a special system-level API for Safari Content Blockers. Apps like Firefox Focus, AdGuard, 1Blocker, Wipr can register filtering rules with Safari using this API. That’s why Focus can block ads/trackers inside Safari if you enable it under Safari
Didn’t this change recently?
the horror.
paying thousands of dollars just to be forbidden to block ads.
There are countless free and paid options on iOS too
Firefox Focus, Brave
AdGuard Pro, $9.99 once and you can use any blocklist you want (you can just copypaste from uBlock Origin if you wish) and it works system-wide with Safari
etc
Would note that air isn't the only substance in a phone that compresses under 38 MPa. (Batteries come to mind.)
Note that I would expect water to seep into a battery at this pressure and that will cause all kinds of issues - including chemical fires underwater. Just not crushed batteries.
> Why isn't a cellphone filled with epoxy?
Anyway, I wasn't disagreeing, just reasoning a bit further.
Typically the limiting factor on your phone is the screen breaking, your battery life getting too short, wear and tear on components like buttons or the charging port, and factory defects. Epoxy isn't going to help with any of those. The only thing it would help with is exposure to water, but if other parts of your phone like your screen aren't water proof, what's the point?
Epoxy adds weight and manufacturing cost. It introduces design challenges as you need to balance the thermal expansion of the various parts. It's an extra step that can go wrong, and makes repair of other defects far more difficult. What benefit is there for the typical consumer that outweighs these costs?
Phones these days are often more expensive than the chair and can be pretty inconvenient to replace, especially if you have nonrecent backups.
Filling the entire cell phone with epoxy wouldn’t help. The parts that break on drops are external like the screen.
This SD card was enclosed in a sealed metal container so it wasn’t exposed to water.
People hydromod digital quartz wristwatches by filling them with oil. This gives them truly absurd water resistances and even improves the readability of the screen somehow.
“I dropped my phone and all the oil leaked out making a mess”
Yeah that’s not going to happen my dude.
I figure I could probably put together a resilient fuze using off-the-shelf parts that's at least as good as a WW2 era one for <$100 (potted solid state parts are really frickin resilient to G forces). With some optimisations for mass production I think <$30 is doable. So I'm going to say an order of magnitude easier.
Of course factoring in today's markup on military parts and the failings of military procurement, that fuze will actually cost the tax payer $3000-$30000 + R&D.
* https://history.stackexchange.com/questions/75940/what-has-h...
It was also in casing already prepared for that type of environment
Until they're sold as supplemental hard drives (cough Transcend Jetdrive cough). Then they'll fail if you even look at them strangely.
Write an image to a smallish SD card using dd (to remove most of the blocks from wear-levelling circulation), mount without -noatime, and you should be able to get the lifespan down to a few hours!
https://data.ntsb.gov/Docket/Document/docBLOB?ID=18741602&Fi...
This was either outsourced or done by some junior engineer who was putting pieces together like it was another Raspberry Pi project that just needed to kind of work.
I'm mostly in the software space but in the past few years I've been doing a lot more embedded stuff, and the trend I notice is that companies are making great hardware, and then completely ruining its usefulness with bad software and firmware. It's kind of mind blowing to me because I always considered software to be the easy part of making a product, compared to, you know, etching microscopic patterns onto sand to make magical transistors appear in just the right way to do the task you want.
While I agree with your sentiment that there's a lot of poor software engineering in embedded space (especially in consumer-oriented novelty products, less so in established fields like industrial or telco), I can't but wonder what's wrong with Yocto? In my experience, it's quite the opposite: Yocto is the quickest path to get the firmware for a new device assembled, once you have climbed its pretty steep learning curve. I have built a few homebrew firmware build systems out of Debian and make/shell scripts (not my choice), you pretty quickly find yourself reinventing half of the stuff that Yocto does out of the box, but it's all bespoke, janky and hard to maintain. While with Yocto you just take the vendor's meta layer for BSP, put your application in another, and it bakes you a set of flashable images on the other end, complete with SDKs and other goodies for your dev workflow, reproducibly. It doesn't get significantly more sophisticated once you start to need kernel customizations, firmware updates with A/B partition layout, readonly rootfs, manage board- or customer-specific variants and other features that are very common in embedded systems but poorly or not at all supported in standard distros.
If you don’t already know anything about how to do these things in Linux Yocto is good for it. But if you try to swim against the current of the way the layer authors want you to do any of those things you will find it very challenging.
Take read-only root, for example. Usually it’s a one-line change in a config file plus an additional mount should you want an overlay in volatile memory. I don’t see how pulling in layers and config files does anything other than obscure how that works.
For a good example of what I hate about it, try building from Meta-Intel without graphics drivers.
It uses a Qualcomm Snapdragon 820 and they provide prebuilt Ubuntu Linaro distros for it, preconfigured for the board.
The camera manufacturer likely just tossed it straight in as configured and thus didn't know how the full disk encryption was setup.
This whole camera design looks like one of those 'we gave this project to some undergrad engineering students who've never designed a commercial product before and had no price target and thus it has a whole damn embedded linux system inside it for merely taking some HD video and stills triggered by some external wiring and saving them to an SD card'.
See also: almost any specialty medical electronic device ever manufactured.
[0] https://linuxgizmos.com/tiny-rugged-com-runs-linux-or-androi...
A person builds out their circuit using hardware they can solder/wire-up by hand on a workbench, maybe even with relatively-giant solderless breadboards, to prove the concept and the general design.
And a dev board can be great for spinning a few prototypes. It's quick to get started (code can begin being tested on-chip after just plugging in a USB cable), and to try different things and to make (and correct!) mistakes. (Blow up a Teensy? No worries; just grab another from the drawer, try not to make that same mistake again, and keep moving -- no esoteric soldering required)
But when the design is finished-enough and it becomes time to spin up custom-built PCBs for a final product that will be sold, a separate dev board like a Teensy tends to lose much of its initial charm.
Instead, it's more-typical just put the microcontroller IC plus whatever supporting hardware is necessary for the overall device's actual functions on the main board. Don't need USB, or an Ethernet PHY, an LED, a button, or a separate voltage regulator? Want more or less flash? When including the MCU on a board of one's own design instead of a kitchen-sink dev board, one is empowered to use exactly the parts that are required.
This can save a substantial amount of space and greatly improve the flexibility of the layout, while also improving mechanical and electrical robustness by having fewer connections between the MCU and the world around it. Plus, fewer parts tend to be less costly than more parts are.
(But again, it's not always done this way. This camera from the submarine is an example of one instance where the whole dev board was put inside of a finished product. Sometimes that's a good idea, and sometimes it isn't. I'm not attempting to suggest that it was or was not a good move in this instance.)
And I don't know when that camera was manufactured or designed.
But these days, it's possible to get even hobbyist-quantities of custom PCBs delivered with difficult-to-solder ICs installed from sources like JLCPCB.
(Depending on the features and functions wanted, it doesn't take a whole lot of extra parts to get an MCU to do its thing: There's not a ton of parts on a Teensy to begin with.)
In this context, all people are free to do whatever they want. It is beyond me to suggest that any person cannot do a thing.
I’m probably not as qualified as the person you replied to, but that’s my intuition as someone with a passing familiarity with electronics engineering (I have an associates degree in EE).
Perhaps disturbingly: I even know of one bit of critical public safety communications infrastructure that is is expensive, low production volume, and has a Raspberry Pi 3 embedded inside. I won't name names because that's getting a little too close to home for my liking, but I was quite surprised to find this inside of a very nice waterproof box with chonky, expensive, olive-colored milspec connectors to connect it up to the outside world.
Which, well: Yeah. There's a ton of good reasons not to do that. But building a whole Linux system on a custom board using individual parts is hard, so it can make sense to buy someone else's work instead.
Except... that's what the CM3 is designed to provide, including on-board eMMC instead of an SD card. I'd not have been surprised at all if there was a CM3 in there, but there is instead an entire Pi 3.
But MCUs, like on the Teensy, aren't like that. They aren't hard to integrate on a custom board like the Broadcom SoC on a Pi 3 or CM3 is.
The primary purpose of an MCU is not to be stuffed onto a dev board like a Teensy, but instead to be stuffed onto the board inside of a microwave oven or an air fryer or a fancy remote control and be easy to interface with other things and to program.
It really doesn't take much to get them going: Some require external ROM or flash, but a lot of them have internal flash memory and only need power and programming pins wired up to let them run code and do whatever IO is needed within a system.
This camera already had at least one very custom board inside. It could have integrated the MCU, as well, instead of the kitchen-sink Teensy.
Doing so is not just style points; it's quite often easier, cheaper, and more flexible.
This allows a person to use all of the IO pins on the MCU to do stuff with, instead of just the functions that the designer of a dev kit decided to build out through whatever interfaces they decided to include.
> See also: almost any specialty medical electronic device ever manufactured.
These are not design mistakes.
When building products in short runs and where the costs of part have little impact on your margins compared to R&D, it completely makes sense to go for a full computer rather than bother with embedded development where everything is more complicated. Medical also has to deal with certification which is a much more significant concern than saving on parts and will often reuse already certified components.
They’re not good at redacting.
But it speaks more to Oceangstrs negligence that this situation even existed: why wasn't any potential encryption keys escrowed ashore to ensure they could be recovered later? This shouldn't have even been an issue.
Oceangate should take the blame for a lot of things but probably not this.
> Somewhat disappointingly, the images and videos shared in the report were taken in the vicinity of the ROV shop at the Marine Institute, also in Newfoundland. The location was the logistical base for Titanic dive missions. No deep-sea shenanigans around the Titanic wreck were revealed.
Some key points:
1. The Camera+Card was encased in a separate enclosure made of titanium+sapphire, and did not seem to be exposed to extreme pressures.
2. The encryption was done via a variant of LUKS/dm-crypt, with the key stored on the NVRAM of a chip (Edited; not in TrustZone).
3. The recovery was done by transplanting the original chip onto a new working board. No manufacturer backdoors or other hidden mechanisms were used.
4. Interestingly, the camera vendor didn't seem to realize there was any encryption at all.
[0] https://data.ntsb.gov/Docket/Document/docBLOB?ID=18741602&Fi...
EDIT: The linked PDF has a photo, the camera literally opens up to access the SD card.
I’m not saying it’s impossible or I’m somehow immune to being tricked, but you would be surprised how easy it is to leave evidence of tampering through the simple act of trying to take an SD card, whether you swap it out or not. And people like me who handle them regularly would likely notice it in a split second. Maybe we won’t even catch the perpetrator, but it would not be written off as “oh interesting I guess it didn’t record,” if for no other reason then I would go straight into CYA mode and start looking for any hint that I didn’t make a mistake.
At that point if you have a basic security SoP in place and adhere to it you can start auditing.
Anywho again nothing is airtight and a determined individual could of course get past me. But you would be surprised how many hurdles they have to get over, and it certainly wouldn’t go unnoticed and be brushed off as a read/write quirk, that’s really all I’m saying
It was basically enabled by accident, and the only thing it prevented was recovery of files directly from the SD card when the camera was damaged.
It also makes bit flip errors a lot more obvious, which is another way of saying harder to ignore, so that can go either way.
Whereas if you image the disk and encrypt the image properly, that gives you all the great confidentially guarantees but no random access.
Ah, that's not true of "full disk encryption". It usually encrypts the disk blocks.
File-based encryption is stronger; you can use different protection classes on different files, you can use authenticated encryption, etc. iOS does it this way and I assume other systems have caught up, but don't know any in particular.
IIRC, the article stated that if the key(s) had been stored in the TrustZone then the data would have been irrecoverable.
Seems like the SD card of all things performed just fine, so it hardly seems like the weak point.
I wonder what the price of the enclosure was then. Feels a bit like click bait...
Instead, a pressure-proof deep sea camera module was found at the wreckage site. It’s less interesting that an expensive thing rated for ocean depths was intact at ocean depths.
Its like “missing child found after 4 days in Alaska temperatures!”
gasp! How did they survive!
“The child was on holiday in their grandparents’ holiday log cabin, with their grandparents, a log fire, food, water..”
Oh. Clickbait. Hiding the boring bit to make the story appear more of a tease.
I certainly did not read that implication into the title, so it's entirely possible that the author didn't mean it.
- thing survived ocean depths, unexpectedly.
Without either of those, what did you read into the title? "Part of wreckage found at wreckage site"? And you still clicked?
Very funny to see in what I assume is a million-dollar product.
Of course random arduino module and teensy used for product is amateur hour, even for low volume production. They must have crazy margins on that camera and producing custom board is very cheap.
It's expensive in time and expertise to do a custom board, and to debug a custom board. All to what, save 20$ on a bom which might not even be 1% of the profit per unit?
Far more efficient to just ship the dev board. They could have perhaps picked a better dev setup to start with, but if it looks stupid and it works...
Unless they are making literally less than 10 of those, custom board will be easier to manufacture than that mess of dev boards and more reliable than random wires and headers all over the place. Plus they can spend money where it makes sense, using better regulators etc.
Speaking as someone capable of designing the mechanical hardware and who is broadly electrically savvy but who is most definitely not an embedded engineer: I could bang out a few hundred hacked together dev boards in week, but doing a custom board would take me a few months. Starting with reading 'Prototyping PCBs for Dummies'.
Watch a few YT videos, copy-paste the reference schematics for all those boards, delete what you don't use and you are almost done :)
I guess the trick would be finding a way to securely attach the black box in a way that would ensure its release in a catastrophic disaster.
There is something slightly romantic about dying in such a way that his body turned to mist and floated away in the current. A bit like having your ashes spread at sea. With fewer steps.
Who didn't want to go and didn't feel safe, but who was pushed to come along by his father because it was his father's birthday.
if he was alone i would absolutely agree with you full stop.
but it looks like they may have been entirely underselling just how backyard amateur their company was just to get people to give them money.
i totally adore books and documentaries and tales of explorer types pushing their ideas to the limit but it quickly crosses a line when they:
a) downplay dangers to innocent people, and
b) refuse to understand their own ignorance and believe the people who have already literally done their idea are somehow “fools”
the person who is trying to “disrupt” but doesn’t have a deep understanding of the often very good reasons why an industry may do things a certain way is the fool. not the ones who already repeatedly make it work.
we need to encourage adventurousness but also wisdom.
Just guessing here? :)
[0]: https://en.wikipedia.org/wiki/Rescue_buoy_(submarine)
[1]: https://www.quora.com/Don%E2%80%99t-submarines-have-communic...
This is about camera hardware and how it survived. It provides no information or footage about the incident (in case you were looking for it like I was).
Tech users get upset when you make me do what you want instead of what the user wants.
Sincerely,
The Back Button
Completely killed one of my ports after 50gbs
This seems perfectly reasonable for camera data storage, and apparently a camera that's manually operated as well.
It'd be worrying if it was storing the binaries to operate the sub, but this is a decent quality SD card for camera storage.
Why are they crediting Scott Manley instead of just grabbing the images from the reports themselves? It sounds to me as if they wrote an article based on the video, and not based on the report. Very lazy journalism.
asimovDev•3mo ago
malux85•3mo ago
Configure your systems so they are in the configuration that is less likely to cause random disruption in the field.
3eb7988a1663•3mo ago
aucisson_masque•3mo ago
They might have forgot to remove or just didn't care.
mook•3mo ago