| ▲ | WarOnPrivacy 12 hours ago |
| If we wanted secure products, we wouldn't ban devices. We'd mandate they open their firmware to audits. |
|
| ▲ | clcaev 12 hours ago | parent | next [-] |
| It'd be great if open firmware could be commercially viable. Finding a business model is hard. The OpenWRT One [1] sponsored by the Software Conservancy [2] and manufactured by Banana Pi [3] works lovely. [1] https://openwrt.org/toh/openwrt/one [2] https://sfconservancy.org/activities/openwrt-one.html [3] https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-O... |
| |
| ▲ | hedora 7 hours ago | parent | next [-] | | The business model is simple: Sell nice hardware at a premium, then sponsor and upstream improvements to OpenWRT. If the software is an important differentiator (arguably, it is for things like Ubiquiti, but clearly it is not for most consumer routers), then release the patches under the Business Source License with a 3-5 year sunset back to BSD / Apache / GPL. | |
| ▲ | pocksuppet 9 hours ago | parent | prev | next [-] | | Open to audits doesn't mean free software, it just means visible source. The business model for selling routers with auditable firmware is selling routers. | | |
| ▲ | 0xbadcafebee 4 hours ago | parent [-] | | And the public doesn't have to audit it. The govt already audits/inspects/validates plenty of sensitive physical products, typically through 3rd party industry associations. You don't get to peek inside, but people signing NDAs do. Even if this wasn't done, at the very least they must publish their software testing procedures, the way UL, ETL, and CSA require to certify devices for the US power grid. (https://www.komaspec.com/about-us/blog/ul-etl-csa-certificat...) They can also do black box testing. But ideally they would actually inspect the software to ensure its design is correct. Otherwise vibe-coded apps with swiss cheese code will be running critical infrastructure and nobody will know until it's too late. |
| |
| ▲ | m01 3 hours ago | parent | prev | next [-] | | There's also Turris from cz.nic [1]. Technically they use a fork of OpenWRT with some convenience features like auto-updates, although it looks like you can run OpenWRT on (some of their routers?) if you wanted to [2]. [1] https://www.turris.com [2] https://openwrt.org/toh/turris/turris_omnia | |
| ▲ | bombcar 10 hours ago | parent | prev | next [-] | | Just declare that any router that can be flashed to OpenWRT without loss of functionality is allowed to be imported. | | |
| ▲ | JumpCrisscross 9 hours ago | parent [-] | | Requiring a one-click option to configure to open source would be a sensible across-the-board law. | | |
| ▲ | M95D 3 hours ago | parent [-] | | I think we all know that's never going to happen. | | |
| ▲ | JumpCrisscross 2 hours ago | parent [-] | | > we all know that's never going to happen Why? You'd need to get someone electorally useful involved. That, unfortunately, elimiates a lot of the nihilistic, holier-than-thou tech types. But that's pretty doable nowadays. You just need an electorally-relevant group of people on your side. | | |
|
|
| |
| ▲ | sophrosyne42 11 hours ago | parent | prev | next [-] | | Open firmware would become commercially viable when IP is abolished | | |
| ▲ | AshamedCaptain 11 hours ago | parent | next [-] | | How do you see firmware becoming more open without copyright exactly? | | |
| ▲ | amlib 10 hours ago | parent [-] | | Not prosecuting people trying to reverse engineer any kind of software would be a great start... |
| |
| ▲ | mindslight 10 hours ago | parent | prev [-] | | I'm no fan of imaginary property, but you're going to have to lay out your reasoning here. Firmware security is such crap precisely because most hardware manufacturers see it as nothing but a cost center they wish they could avoid. The difficulty of installing OpenWRT or Linux in general on hardware comes from that hardware not being documented, or not having straightforward APIs like BIOS/EFI. Or for some devices, community distributions that dubiously remix manufacturer-supplied binaries are available. But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well. | | |
| ▲ | M95D 2 hours ago | parent [-] | | > not having straightforward APIs like BIOS/EFI. Oh, no, not this again! > But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well. Care to demonstrate that? The reason OpenWrt abandoned most routers was 1) insufficient flash space in the kernel partition, or insufficient total flash space in no-USB, no-SPI routers, 2) unwillingness to repartition flash because it breaks compatibility with official firmware (as if anyone installing OpenWrt would care), 3) insufficient RAM to run newer kernels and, most importantly, 4) unwillingness to support older kernels like DD-WRT does. |
|
| |
| ▲ | 11 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | vetrom 11 hours ago | parent | prev | next [-] |
| You will first probably need Congress to legislate away the long standing prohibitions against offering (easily) user-modifiable RF devices on the market. Self ownership and full 'right to repair' has carve-outs in the FCC's regulations in the name of limiting unintentional broadcasting/radiation. Maybe a challenge to those would survive in the post-Chevron environment. I wouldn't expect any Congress in the last 25 years to pass a law which would go against the incumbent telecom lobbyist interests though, and I'd expect such a hole if it did hit case law, to get 'patched' fairly quickly. About the only way to really solve that would be to embarrass vendors enough to open their moats. |
| |
| ▲ | yjftsjthsd-h 9 hours ago | parent [-] | | I dunno, I'm pretty big on FOSS but I don't think you would need that to improve. Requiring that the firmware have its source code available to audit doesn't mean that users can replace it. AFAIK you could, today, with no legal changes, have a vendor release 100% of the code under eg. a MIT license while also making the device refuse to run firmware not signed with their keys. Researchers could poke at it to find bugs, and FCC regulations wouldn't be touched. (Note: IANAL, so feel free to point out if I'm wrong about that) (To be clear, I don't think that's good enough; at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help, but I think it's useful to point out that auditing code doesn't require being able to install it) | | |
| ▲ | kogepathic 5 hours ago | parent [-] | | > AFAIK you could, today, with no legal changes, have a vendor release 100% of the code under eg. a MIT license while also making the device refuse to run firmware not signed with their keys. This is already the case today with many embedded devices. They have secure boot enabled so even if the vendor releases the GPL source code (big if), you can't do anything because the device will only boot the vendor's signed firmware. > at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help This is already possible. The RF components frequently have a signed firmware blob that is verified on load. There is no reason but planned obsolescence and greed keeping the application processor locked to running the vendor's signed code. | | |
| ▲ | pabs3 4 hours ago | parent [-] | | > the device will only boot the vendor's signed firmware That sounds like what Software Freedom Conservancy would call a GPL violation: https://sfconservancy.org/blog/2021/mar/25/install-gplv2/
https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...
https://events19.linuxfoundation.org/wp-content/uploads/2017... | | |
| ▲ | kogepathic 3 hours ago | parent [-] | | > That sounds like what Software Freedom Conservancy would call a GPL violation Sure, it is. So what? Have you got 200k for lawyers and years of your life to spend in court fighting over it? I have personally contacted the SFC with ample evidence of deliberate and wilful GPL violations, such as providing a written offer for source code and then ignoring or flat out refusing requests for the source code. The SFC has acknowledged the vendors are violating the spirit and letter of the GPL. Nothing happens. The SFC is one organisation with limited resources, FOSS developers don't want to spend their time in court, they'd rather develop software. Vendors know 9 times out of 10 they will get away with the GPL violation scot-free. It's fine to put on your rose colored glasses and pretend GPL forces companies to release source code. Reality is, the vendors have a larger marketing budget than the entire SFC endowment and the vendor's legal team is happy to tar-pit requests ad infinitum. |
|
|
|
|
|
| ▲ | dmitrygr 12 hours ago | parent | prev [-] |
| problem is: how do you prove the firmware in the flash chip matches source? And I do not mean me, with a disassembler and a pi pico to read out the flash chip. I mean the 70-yaer-old corner shop owner that buys this router to provide free WiFi for customers? |
| |
| ▲ | WarOnPrivacy 12 hours ago | parent | next [-] | | > how do you prove the firmware in the flash chip matches source? Trusted, qualified independent experts: Ala Underwriters Laboratories. | | |
| ▲ | dmitrygr 12 hours ago | parent [-] | | One word for you: dieselgate https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal | | |
| ▲ | kelnos 5 hours ago | parent | next [-] | | A process not working on occasion doesn't mean the entire verification method is garbage. I get the desire to not have to trust a third party, but realistically, there isn't a way to function without doing so, outside of going out and living in the forest in a cabin you've built yourself, either doing without electricity, or with solar panels you've built yourself from raw materials. Human processes aren't like computers. They're messy. They fail sometimes. They need checks and balances. Sometimes those checks and balances don't work. Sometimes the checks only work well after the fact, and the people who were harmed aren't all made whole. That's life. We probably can't do much better. | |
| ▲ | actionfromafar 11 hours ago | parent | prev | next [-] | | Someone did go to jail, so there's at least that. | | |
| ▲ | dmitrygr 11 hours ago | parent [-] | | Yes. But a lot of people still got cars that were not as represented. So if we follow the same pattern, somebody will go to jail, but most routers will not be running verified or safe code. | | |
| ▲ | Snafuh 11 hours ago | parent | next [-] | | Do you apply the same scrutiny to the food you eat? Some trust has to be created through testing standards and the law, but generally we do believe what the label says in day to day life. | | |
| ▲ | dmitrygr 9 hours ago | parent [-] | | In so far as I cook myself? Yes | | |
| ▲ | kelnos 5 hours ago | parent [-] | | So you personally test your produce to ensure it's safe to eat, has no pesticides embedded in it that could harm you, etc.? You do that after every single trip to the grocery store or farmer's market? Every trip? You don't spot check, and assume/hope/trust that the ones you don't test are safe? |
|
| |
| ▲ | actionfromafar 11 hours ago | parent | prev [-] | | The routers thing? That's probably just a scam to get donations to the Trump Family Bunker/Ballroom in DC or other pet project. |
|
| |
| ▲ | KennyBlanken 8 hours ago | parent | prev [-] | | Friendly reminder that _all_ automakers - European, American, and Asian - had been doing this emissions cheating for decades. Detection of the car being on a rolling road, special button combos that trigger the emissions testing map, etc |
|
| |
| ▲ | gbin 12 hours ago | parent | prev | next [-] | | A trusted website that compiles it from source and a way for you to go to a webpage and flash from there automatically. The FPV community does that all the time with a set of websites for their ESC, flight controllers, radio, all open source. You can add signatures etc but just a trusted website goes a long way vs a random blob preinstalled | | |
| ▲ | dmitrygr 12 hours ago | parent [-] | | That proves that the one they checked, had the correct firmware. It does not prove that the one from the next batch that you bought did. We are all technical people here we and understand that there isn’t really an easy way to do this that a random non-technical person could actually understand and use. | | |
| ▲ | PickledHotdog 11 hours ago | parent [-] | | Isn't the person you're replying to suggesting people can update the firmware to the trusted version via a website? So it doesn't matter if you get one from 'the next batch' - provided you're on top of updating the firmware. | | |
| ▲ | dmitrygr 11 hours ago | parent [-] | | If only somebody could make a firmware that claims to have accepted the update, but then proceeds to not actually update itself. Read out the version string from the update and save it. Show that when asked what your version is. | | |
|
|
| |
| ▲ | zobzu 8 hours ago | parent | prev | next [-] | | not to mention even on the bananapi you gotta trust mediatek. | |
| ▲ | megous 11 hours ago | parent | prev [-] | | There's no solution to that other than having knowledge and researching the code/device yourself. You can pick apart modern Linux/busybox based IoTs fairly quickly, so effort needed is not really a huge issue. Maybe trusted community of people could do it for everyone, but there's currently all kinds of potential legal trouble brewing in that approach. Complete and public reverse engineering of every aspect of any device would have to be made completely legal, so that people could freely publish all artifacts extracted from a device and produced during reverse engineering and collaborate on them without any fear of repercussions. Also HW manufacturers would have to be prohibited from NDAing documentation for SoCs, etc. Side benefit would be that this would also serve as a documentation for freeing the device and developing alternative firmwares with modernized sw/reduced attack surface. | | |
| ▲ | dmitrygr 11 hours ago | parent [-] | | We are in violent agreement. And precisely because there is no simple solution to it, half-measures like what is proposed here do absolutely no good, and often times do harm. |
|
|