The goal would be to make the leaders care about security issues in the first place.

Right now, they can choose to spend less on engineering and then give the money saved to themselves to buy a bigger super yacht. The consequences of only using the cheapest possible labor and cutting every possible corner is that their routers get hacked easily. But this doesn't hurt the CEO in any way. They keep their super yacht. So why shouldn't they do it?

I've designed many devices that are like this. Bluetooth especially is quite cheap now and it often comes with hardware chosen for other reasons. It wouldn't save any money to remove it. And if there's no money to be saved, there's no option to do it.

I'm at a trade show right now where we've built a device, functioning prototypes at this point, with an unused BT interface. It's got a cell modem, which was intentional and is used. And there's wifi, which isn't really an intended user facing product feature but was very desirable for the development of the product. And there's bluetooth because it comes with the wifi module. I actually went to the trouble to lean down the system and the custom kernel config doesn't include bluetooth support. I imagine most engineers wouldn't bother with that. But the hardware is there. Antenna is even connected because it's the same port as the primary wifi antenna.

To me, the difference is that the ref doesn't know to the inch where the line is when he spots the ball. So he doesn't know which team he's giving it to. When they measure they know who will get it, but the chains are a very accurate and objective device. The chain crew has no power to influence the decision.

We understand that there's no way the ref can tell where the ball was to the inch when the runner went down or forward progress stopped. So really, it's "too close to call" and we'll just flip a coin to decide the outcome. If we let the ref look at flag on the side of the field and directly announce if the yardage was made, it might not be any less "accurate" than the current system.

But to me at least, there is very big difference between, "too close to know for sure, flip a coin," and "too close to know for sure, the ref arbitrarily picks a team to win."

It's all for speed. There's nothing in the press release about it making better calls. The only advantage described is that it can measure 10 yards faster than a chain crew can.

If anything, there is less show, since there is no chain crew to bring up and they won't have that close up shot of the ball and the stick, where we see if they made 1st down or not, that often comes after the measurement. And the 30 seconds of waiting they can fill with ad talk but the audience doesn't tune out since a critical call will be announced momentarily.

Now the offense will know they didn't make before they even get back to area the ball was spot at and will go directly off the field.

You mean like command 0x0003 in Analog Devices BLE controller? https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fanalog-devices-msdk.gi...

That's a write memory command. They gave it the wrong name. Must be part of a backdoor, being so weird and hidden with the wrong name. You should go write a click-bait article on it full of your made up crap.

And TI's 0xFC0A command is a Non-Volatile write. That means to flash.

If you had any experience actually using HCI commands or writing a BLE host, you'd know all BLE controllers have commands like this.

You aren't nearly as knowledgeable as you think you are. I doubt you've ever programmed any microcontroller on your own outside of a class room. Maybe, if you thought about what those with experience said instead of attacking them for not parroting your fantasy, you would learn something.

While this is entirely true, it's also true for most or all other BT devices. I've developed products with Nordic and ST chips that have BLE, in addition to Espressif, and both those companies' products also ship the BLE controller as a binary only component of the software stack. They are actually more obfuscated than Espressif's binary code. ST's is fully encrypted so you can't even disassemble it. Espressif's isn't encrypted and even has an unobfuscated symbol table in the library.

I'm not aware of any device on the market with a fully open source BLE controller.

The NimBLE project does have an open source controller, in addition to a host which is the part of NimBLE Espressif uses, but don't know of a chip on the market that uses NimBLE's controller.

What commands are so weird?
How about this one: 0xFC0A Write NVDS Parameter
Or maybe: 0xFC12 Read memory info

Here's a list of TI's CC13x2 Vendor Specific Commands: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fsoftware-dl.ti.com%2Fsim...
TI has better documentation than Espressif.

And in that list we see 0xFE82 UTIL_NV_Write and 0xFE87 UTIL_GetMemStats

I fail to see what is so strange about these vendor specific HCI commands. TI has some of the same ones in their controller.

That's not true. I've actually developed products that use ESP32s. I've even done some reverse engineering on those binary blobs to implement RF coexistence between BLE and another RF system, since none of the documented APIs support any of the necessary features.

FreeRTOS is open source and part of the code included in ESP-IDF. The controller is a task that runs under FreeRTOS. Though I think there is a mode where one dedicates a CPU core to the controller, on those ESP32 devices with two cores, and FreeRTOS doesn't manage the controller.

Depending on the ESP32 device, the controller code is either in the mask ROM and/or as a binary library file shipped with ESP-IDF. The older ESP32 appears to have more in the ROM while the newer chips like the ESP32-C6 have less ROM and use more libraries.

There's a performance issue with code in flash memory (which a library compiled into the FW would be), since the ESP doesn't have built in flash on the processor's data bus. It's an external SPI flash chip in all cases, which means possible long latencies when a cache miss causes the flash controller to need to read a block over SPI. Not something a timing critical part of the BLE controller can tolerate. The way around this is to copy the code that can't tolerate flash cache misses from flash into RAM, but there is very little RAM, especially on the OG ESP32. So they add ROM that doesn't have a cache miss issues to hold some of the code. ROM is much cheaper than RAM in a microcontroller.

No, bluedroid or nimble run as a task under the open source FreeRTOS kernel. They talk to the binary blob using a virtual HCI interface. It's not even a binary blob. They ship .a libraries that don't even have symbols stripped for the non-open-source code.

The HCI spec includes an OGF for vendor specific commands, 0x3f, which is what Espressif has used. I fail to see what is strange about vendor specific commands using an opcode set aside in the spec for purpose of adding said commands.

If the controller has some kind of RF triggered backdoor, there would be zero reason to create an HCI command to implement it. The controller code would just do the secret thing when triggered. You wouldn't add a customer facing command called "TriggerSecretBackdoor", which has no purpose other than to let customers activate the backdoor, if you wanted to add a backdoor that was secret from your customers.

No, the host won't do that. Unless the person who wrote it has chosen to do that. What you're missing is that the host is entirely open source. ESP-IDF has two choices, Bluedroid or NimBLE, neither of which is written by Espressif. When you make something with an esp32, you compile it from source.

It's certainly possible for the binary BLE controller to do things on its own. But the controller receives HCI commands from the host. That's what HCI stands for, host controller interface.

The host has full source. It's not even written by Espressif. You can use bluedroid or nimble.

So what would be the point of adding commands to let the host tell the controller to do things as part of a backdoor hidden in the controller? The controller doesn't use the HCI commands to do things. It acts on them when the host tells it to.

And if you actually know how to take a train across the Alps and give an answer, your answer will be down voted, because the rabid group-think echo box insists that one must buy a plane ticket to Rome and nothing else may be mentioned.

And think, those snowflakes in the Alps compute all those angles instantly! How long would it take a super computer to generate all those angles? Snowflake Supremancy!!

I think a difference would be if the lease payment is rent seeking or not.

The watch service involves actual work being done. Someone is spending time to do something of value and getting paid for that time. And there isn't evidence the manufacturers are intentionally designing watches to require service that doesn't need to be necessary. If anything, watches need less service than they used to, with shock absorbing jewel settings making broken balance staffs largely a thing of the past, alloy mainsprings that don't break or wear out they way old spring steel ones did, and the switch from natural lubricants to synthetics that don't dry out or spoil nearly as fast, if at all.

But if one has to pay each month to keep your mouse from getting remote disabled, then that's just extracting money without doing anything of value. Maybe if that monthly fee bought replacement switches. Or even firmware updates that are in some way useful. But probably it would be any of that. It's just, "pay us money because we figured out a way to take something away if you don't!"

I've found the project where someone is making money from them tend not to be as open.

I've been an open source contributor and maintainer for 30 years. I was a Linux Kernel subsystem maintainer for a few years (unpaid). I've been paid to work on open source projects too. So maybe I have some first hand experience here, from all sides.

If you are getting paid to do projects, contracting if you will, you must constantly be looking for new work to do. Every day you work puts you one day closer to having no more work. It is a demanding and never ending task to keep the pipeline full. I know this as well from decades of experience.

If an open source project lacks a feature, the maintainer almost certainly knows this already. They are also aware that someone may pay them to add this feature. It's a good way to get work. "One month retainer for general maintenance work, PR review, etc." is very hard to sell. And if you want to get paid, you must first sell. "Add new feature needed for something people want." That's a much easier sell.

If someone outside the project, not paid, submits work to add this feature that is missing, then the insider(s), those people paid to do work, can no longer sell this feature and get paid for it. The contributor has effectively taken their work.

I've found paid maintainers, or open source projects run for a profit by a group of insiders, are far less accepting of outside contributions that projects which are not this way.