> What I am asking for: publish a basic GitHub repo with the hardware specs and connection protocols. Let the community build their own apps on top of it.
This concept works fine for the author's example of a kitchen scale, but fails when the device in question is something like a router that has secure boot with one key burned into e-fuses.
In that case we need both open software and a requirement that the manufacturer escrow signing keys with someone so that after EOL any software can be run.
Forcing the release of signing keys would be a security disaster. The first person to grab the expired domain for the auto update server for a IoT device now gets a free botnet.
The only real way to make devices securely re-usable with custom firmware requires some explicit steps and action to signal that the user wants to run 3rd-party firmware: A specific button press sequence is enough. You need to require the user to do something explicit to acknowledge that 3rd-party software is being installed, though.
Forcing vendors to release their security mechanisms to the public and allow anyone to sign firmware as the company is not what you want, though.
Embedded devices that go on the internet by (to update) themselves are an anti-pattern.
I run a bunch of stuff using Home Assistant via the Zigbee integration - the Zigbee host on the local server gets to decide where to install updates from - which was the security mechanism for most most software for most of history.
Get your stuff from a reputable source. Signage keys are nice, but they don't work as the sole security measure in an unsound supply chain.
ROM bootloader loads a second stage bootloader (e.g. [1]). The ROM bootloader verifies that the second stage loader is signed with keys fused into the MCU. The second stage bootloader in turn verifies application images shipped by the vendor, using a different set of keys.
When the vendor discontinues support for the device, they make available to their customers an optional update to the second stage bootloader that allows any application image to run, not just images signed by the vendor. This updated second stage loader is signed with the keypair fused into the MCU, and so it will run as per normal. They ideally make it so this update can only be installed with some sort of local interaction with the device, not automatically over the air.
Devices in the field running ordinary OEM firmware continue to be protected from malicious OTA updates. Customers who wish to unlock their devices also have the means to do so.
This is very technically straightforward to implement, but it needs to be considered when the device is designed. Regulations would be required to make sure that happens.
That does sound better, but haven't you just made the unlocked seconds stage bootloader functionally equivalent to secure boot keys?
Instead of [get released SB keys] -> [boot arbitrary payloads]
It becomes [get unlocked second stage bootloader] -> [boot arbitrary payloads]
Although, I guess that the details matter in terms of the process used to supply OTAs and second stage bootloaders. If changing to the unlocked bootloader requires physical access (or some such thing), then I could see that working.
Secure boot is desirable for a lot of reasons including design protection (stopping your product being cloned), supply chain security, preventing malicious updates etc.
The question is one of how you can hand control to the user without endangering your legitimate commercial interests as well as the security of the rest of the fleet, exactly how you tackle that will depend on the product.
> Forcing the release of signing keys would be a security disaster. The first person to grab the expired domain for the auto update server for a IoT device now gets a free botnet.
Have you seen the state of embedded device security? It is already an unmitigated disaster.
Since you bring up botnets, there are far more exploited security vulnerabilities because a vendor EOLed support (or went bankrupt) and their firmware contained bugs that cannot be fixed because a signed firmware is required, or the source code was not provided than because their signing keys were leaked and someone is distributing malicious updates.
> Forcing vendors to release their security mechanisms to the public and allow anyone to sign firmware as the company is not what you want, though.
Yes, it is what I want. I am perfectly aware of the potential downsides and what I am proposing is worth it. The product is already EOL. In our current era of enshittification, vendor pinky promises to implement a user-bypass in their signed boot chain is not good enough. Look at the Other OS controversy on the PS3 if you want an example of this in practice, or Samsung removing bootloader unlocking in their One UI 8.0 update.
> The only real way to make devices securely re-usable with custom firmware requires some explicit steps and action to signal that the user wants to run 3rd-party firmware: A specific button press sequence is enough. You need to require the user to do something explicit to acknowledge that 3rd-party software is being installed, though.
The vendor has implemented an internal pad on the laser-welded, weather sealed, IP-rated smart watch that must be shorted to disable secure boot. Opening the device to access this will essentially destroy it, but we preserved the vendor's secure boot signing keys so missioned accomplished!
But you can still do both. Put a key into escrow that unlocks the device fully, but the key can only be used if the device is physically manipulated. This could mean holding down a button as it boots ups to put it into “enter the unlock key” mode. The mode is useless until the key is published and the key is useless without physical access to the device. And you don’t need to open anything. This could be a purely software thing. As long as you can somehow externally communicate with the device via a button, Bluetooth, Ethernet, etc. you can create a system that would allow this. Hell, you could use a magnet to trigger it.
I agree that devices shouldn’t be locked by the manufacturer AND I think that silently unlocking all devices all at once could do harm.
Locked bootloader should just be competely forbidden, even for brand new devices. Hardware and phone owners have the right to make any change they see fit on their device, no matter if the manufacturer thinks it's ok or not.
I agree with you fully on this. Unfortunately, the odds are stacked very unfavorably against us. It's not just the manufacturers who resort to these underhanded profiteering tactics. Even the regulatory agencies are for locking down the firmware.
Their argument is that an unlocked firmware would allow us to override regulatory restrictions like the RF output power or the IMEI number. That argument has some merit. However, my opinion is that such restrictions should be implemented as hardware interlocks that are unchangeable through software. Thus, we would be free to change the software as we like. Sadly, both the manufacturers and the regulatory agencies tend to completely ignore that solution, so that they can retain their excess control.
I always found this claim completely bogus, you can always do something illegal with your phone, there's no way to prevent everything with software.
This is the goal of law enforcement and justice in general and in this argument, a hardware manufacturer is substituting this role, when we say that, we can see the overreach. Manufacturers aren't public entities able to make such decisions.
There are security reasons to use locked bootloaders.
But I do agree that we should be able to unlock and relock the bootloader. That's one of the reasons GrapheneOS supports the Google Pixel, for instance. The security model relies on the locked bootloader.
I meant it's part of the Android security model. That's what makes Android more secure than Desktop OSes, for instance. A locked bootloader is a great way to make sure that the base system hasn't been tampered with, e.g. by malware.
It is desirable for anyone who doesn't want malware.
I mean yeah sure, third party apps on android have a strong security model but what's the point when GrapheneOS is the only rom making updates on time, the play store runs as admin and manufacturer apps and driver can do whatever they want?
The OS is borked even before you install even a single of these highly sandboxed third party apps.
While in theory that model sounds great, in practice the security is worse than your average Linux distribution and the only people which managed to make it work is the GrapheneOS non-profit representing less that 0.1% of the devices.
(And ironically the only secure Android rom doesn't fully pass Play Integrity)
Well the secure boot is about the OS itself. Of course... you have to trust the OS. Including all the firmwares that are embedded into it and make your hardware run.
I don't know if there is much value in arguments like "in theory that's great, but in practice I don't trust anyone other than X so anything that is not X is worse".
> Well the secure boot is about the OS itself. Of course... you have to trust the OS.
So we're back to square one then, it's pointless because you can't trust mobile OS like you can with desktop OS.
Before talking about secure boot, Android needs a way to attest what's in the OS we're saying we are booting...
I'm not even sure Google themselves are fully aware of what's inside specific models.
> I don't know if there is much value in arguments like "in theory that's great, but in practice I don't trust anyone other than X so anything that is not X is worse".
I would rephrase it as why attesting that we have an unknown and outdated OS is valuable to the phone owner?
I'm really not sure what you are talking about. When I run GrapheneOS, "the OS" is open source. It includes some binary blobs, just like my desktop Linux.
> I would rephrase it as why attesting that we have an unknown and outdated OS is valuable to the phone owner?
I am not sure if you're genuinely not understanding what the secure boot does, or if you're just venting about the situation with mobile phones.
The secure boot is there to attest that the OS running on your phone is coming from the manufacturer and has not been tampered with by a malware. If you don't trust the manufacturer or if the manufacturer doesn't update the OS frequently enough, then I guess you should look for another manufacturer. GrapheneOS is pretty much up-to-date.
I'm talking about your average Android, not GrapheneOS which is atypical and represent pretty much nothing worldwide.
> you don't trust the manufacturer or if the manufacturer doesn't update the OS frequently enough, then I guess you should look for another manufacturer.
The only manufacturers in the world publishing device trees nowadays must be Fairphone and OnePlus because even Google stopped releasing them with the last Pixel. So here you go, you I gave you the entire list of manufacturers (two) for which to my knowledge secure boot provides some value to the phone owner (some others might exist), I'm willing to include GrapheneOS as a third case where it makes sense even if it's not the stock OS.
And the only rom in the world being updated on time is also GrapheneOS (yes, even Pixels still have delays)
> So here you go, you I gave you the entire list of manufacturers (two) for which to my knowledge secure boot provides some value to the phone owner
You say correct things, but you make wrong conclusions. Secure boot does provide value to the phone owner, period. Not against the manufacturer, but there is pretty much nothing consumers can do against the manufacturer except trusting it.
This is very much not an option on most embedded devices. They allow one key to be burned once.
IIRC, a certain Marvell SoC datasheet says multiple key slots are supported, but the boot ROM only supports reading the first entry (so really, only one key is supported).
> She would see 'sign up now for 20% off!' and smile! like it positively hit her like she just won the lottery
If you intend to purchase an item from the merchant anyway, why would you pass on 20% off?
I sign up for newsletters to get a discount then immediately unsubscribe. If merchants are going to offer a discount for me to input my email, copy the code they email me, and GMail unsubscribe why would I turn that down?
> If you intend to purchase an item from the merchant anyway, why would you pass on 20% off?
Most discounts I run into seem to be based on incredibly inflated pricess to begin with. If a shop offers me a 20% discount on something it is often cheaper to buy it somewhere else.
When I subscribe to these I've usually already found that either they are the only shop to carry that product, or are already the cheapest. The 10% discount is just an extra at that point.
LOL yes I had a friend who would buy stuff because it was on sale and talk about how much money he "saved." I would always ask "do you have more or less money now?"
Because once they have your email and can link it to your identity via your purchase details they’re going to sell that list to some marketer sleazeball and you’ll get spam from other sources until the end of time?
This is true. I get arguments or indignation every time I say it, but spam is a solved problem, and has been for at least 20 years (thanks Paul!).
If you get more than "insignificantly little" spam in your inbox, you are using the wrong mail provider.
My email address is on every spam list under the sun. I get 600 spam messages per day[0], but only a few per week hit my inbox.
[0] It was 600/day before I made a small change to my mail configuration. Now it's only about 50/day which is few enough that, every month or so, I actually check for false positives. I occasionally see a low-value marketing list message that isn't technically spam in the sense of being entirely unsolicited, but content-wise it's not differentiable. Zero legitimate personal messages. I can live with this.
I've signed up for plenty of these lists with per-site emails, and it's very rare for me to end up getting email from anyone but the list I signed up for. Might be different when shopping on international sites (though I doubt it's worse in the EU), but in the US, sites generally don't sell your email. More likely they'll leak it accidentally.
Hard no on giving Jolla a cent. Jolla rug-pulled [1] people who crowd-funded [2] their tablet in 2014.
Jolla used the crowd-funding campaign to butter up VCs for their next funding round [3] and then decided the Asian LLC handling the crowdfunding would go bankrupt, leaving backers with no tablets and most with no refund. [4]
The real kicker was that the tablets were ALREADY manufactured by their ODM, Jolla just never paid them. Took backers money and stiffed their manufacturing partner too. For a while after the campaign folded you could buy Jolla branded tablets (running Android, it was just an ODM model they flashed Sailfish on) on eBay or Taobao [5]. I just checked and there's a Jolla Tablet listed on eBay right now. [6]
10 years later, it looks like they're trying the same thing. Maybe they think the internet has forgotten, but I have zero interest in supporting their next hardware rug-pull endeavour.
As someone that's contributed to the Jolla tablet foundraiser, I mostly got refunded when they canceled it. It took a long time, it was not directly the money I contributed, but I wasn't left with nothing, and I don't feel like I've been cheated. YMMV, of course, it sounds like you're talking from experience.
> leaving backers with no tablets and most with no refund.
I'm pretty sure we eventually all got refunds after they got the Russian cash. My refund came a couple years later iirc, with a check for half the amount coming a few months before the check for the second half.
AFAIR, I got refunded the whole tablet price in the end - I think half the price immediately, and the other half a few years later. It doesn't mean others were refunded too, of course. It was long time ago, though, so I may have mixed something up.
afaik the tablet was in development hell for much of 2015, by the time it was ready it was no longer profitable and Jolla couldn't afford to buy more than about 600 units without going bust.
IIRC they were negotiating a startup funding round that failed, so they ended unexpectedly up not having enough money to run the company let alone pay for the tablet manufacturing. Even remember hearing about the manufacturers selling the units with Android by the time they secured at least some funding for the company, so there was really nothing to salvage.
Or it might have just been their excuse back then - if you have some newer details of how it actually all went down with the tablet, please do share! :-)
I remember they had success with a prototype on I think Mobile World Congress, even winning some price. But when they wanted to start manufacturing the screen was EoL and they had to redesign the board for a different screen. This forward pushed the delivery date, resulting in the new manufacturing start coinciding with the funding round failure.
> Pick any app you want and search for it. Ideally it has a pretty unique name and not just a dictionary wod. What will you see? The first result will always be an ad for a completely different app.
This is also the case on the Play Store. Google *always* places the ad above the actual result, even if you search by the app ID (e.g. org.videolan.vlc)
> The problem is that if everyone hops jobs every 9-18 months, it’s not worth training up juniors because the employer will never get to benefit.
It is absolutely worth hiring and training juniors. The quality of your onboarding process and documentation will improve. Not only that but a junior will ask questions that senior engineers take for granted, such as "why are we doing X this way?" which can lead to improvements that your existing engineers might not have considered.
Finally, if junior engineers are joining your organisation and leaving every 9-18 months, you need to take a serious look at your career progression ladder and compensation. I have seen way too many companies that have an arbitrary "you cannot receive a promotion in the first X months" HR policy which is just asinine. You know who doesn't have this stupid policy? The company your junior just accepted an offer from.
If your organisation doesn't have the tools and processes to up skill junior engineers into seniors, then it doesn't have professional development for senior engineers and is just a career dead end.
Xperia 5 IV owner here, don't give Sony any of your money.
Their support is garbage: 1 Android version and only 3 years of security updates for a phone that cost nearly $1000. Google and Samsung offer 5+ years on their flagship phones.
The cameras are held back by incompetent software; the camera app does not even rotate for a left handed mode (they only need to rotate text and icons). Their camera app behaves like a point and shoot camera from 2004, and you have to treat it like that or your photos will be a blurry, underexposed mess. The cameras are technically fine, but the software implementation is truly terrible.
Yes, the phone has a headphone jack and micro SD slot, but those aren't worth it when everything else sucks. Sony is far, far behind other major Android manufacturers when it comes to software quality and support.
I gleefully gave Sony money for the 5 IV in late 2022. The phone stops receiving all updates next month (September 2025). Custom ROMs (e.g. LineageOS) are nonexistent because Sony has such an insignificant market share.
I'm writing this from my own Xperia 5 I device, and I can corroborate some of your complaints.
Most of the frustrations can be resolved by liberal use of third-party apps from F-Droid. Lawnchair and the Fossify suite make the basic experience quite reasonable, because the system UI components are thankfully not too heavily modified, only the system apps. With apps such as DAVx⁵ and Fennec it's really very useable.
Unfortunately the locked bootloader (which is completely illegal of course) is a big frustration and the main reason why you can't get custom ROMs running on it. I don't think it's about market share; some less popular brands have better community support because their manufacturers don't build artificial barriers to modifications. For security, this puts Sony's phones right down in my estimation and I too would not recommend them for this reason alone.
> To my knowledge, any switch OEM producing Broadcom-based gear will get their NDAs and silicon access revoked if they so much as dream about making devices with non-Broadcom silicon.
Cisco Meraki did; their low end switches are Marvell and their "high end" switches (MS420, MS425, MS450, MS350, MS355) were all Broadcom based. Were because about a year ago they announced the End of Sale of all Broadcom based switches.
Everything above the low end stuff is now Cisco Catalyst. (Although one can argue everything from Meraki is low end apart from their prices)
> Marvell and Microchip are fighting for the scraps
Realtek also. Lots of smaller L2 managed switches based on the RTL93xx series. [1]
But I am not seriously comparing Realtek to Tofino, that's like comparing Hot wheels to the actual car.
I have a 12th Gen Intel Framework from work. I cannot recommend Framework as a brand.
Yes, they are repairable. That is where the list of Pros ends for me. Perhaps the only unique selling point is being able to upgrade the motherboard later, but...
The screen, keyboard, touchpad, and IO are all inferior to a ThinkPad.
You can only ever have 4 ports, which is considerably less than your average PC laptop of similar dimensions and weight will have.
ThinkPads and other corporate-tier machines are dirt cheap used after 3-4 years, and finding spare parts for them is usually a non-issue as long as you don't mind eBay. Lenovo will happily sell you parts for a few years after the laptop is released, although availability and pricing are not great.
Framework had a partnership to only sell Western Digital SSDs when I ordered mine, and it later came to light that WD had serious firmware issues with these models resulting in sudden data loss. [1]
Additionally, the 12th Gen model has received ONE firmware update in over a year since release. [2] While Framework have committed to delivering more frequent firmware updates, they don't have a good track record there. No LVFS support either, so you have to burn a USB stick to update.
Prior to the firmware update, I've had the laptop completely discharge the battery while powered off, refuse to power up until being connected to a charger for ~15 minutes, and then display a large error saying the screen and battery were not connected (they were).
Even after the firmware update, I still have issues with phantom battery drain when the laptop is completely powered off.
I have the exact opposite experience of this person. My 12th gen framework had been great. I've replaced the keyboard after spilling water on it, the hinges, and they even replaced my power adapter because the right angle USB was flaky. Repairs have been a breeze... I had ThinkPads for over 20 years, probably 7 of them. Their era is over, sorry but the last good ThinkPad was the 220. Fwiw, I tried to buy a ThinkPad before my framework, their site said it was available in two weeks. Three months later, after no reply, my order was canceled due to some US law that automatically triggers if you cannot deliver in a reasonable time frame. Got the framework in three days. Wish I got the AMD one, but whatever I can upgrade later.
Totally agree on older Lenovos. The last truly great laptop I owned was a Lenovo T530. It felt like it was built out of recycled Soviet era tanks, was completely modular, swapped out the CD ROM and replaced it with another hard drive, upgrading ram was a breeze, etc.
It was a bit on the chunkier side, but that thing hummed on for a decade of constant usage with not a single problem.
I love mine and have had it for a few years now and upgraded it's motherboard from 11th gen to 12th gen i7, and successfully easily replaced the keyboard after a coffee spill, upgraded the battery to a new slightly higher capacity one when the original battery puffed up.
And this is all true. I love mine but frankly I have to admit I make excuses for it. It's almost really good. It has a lot of really good qualities, and lot of bad qualities that erase the good.
That 11th gen motherboard I replaced? I bought their official extwrnal case, (and some ram and a wifi card with antennas from a local microcenter to make it functional) to make it into a stand alone computer, even though I have essentially no use for it. Well it's a good thing I have no use for it because a bios update bricked it.
They don't put out enough updates to actually fix problems and so problems just remain for the entire life of the thing, and the few updates they have put out are complete and utter dumpster fires that break in a dozen different ways.
That battery I replaced? It was only about 2 1/2 years old. Why did a brand new battery go all explody in only 2 1/2 years? I have 10 even 15 year old laptops with pouch cells inside that never puffed up. Maybe longer even. They no longer hold a charge but they never puffed up.
My screen never looked 100% good. It has uneven lighting and uneven color, and is overall a bit pink. I have tried to correct the pink with color profiles in X but never got it to look like the neighboring external monitors. But a profile can't fix uneven color or uneven lighting anyway. Luckily I just don't care that much since I use larger better external monitors for most things and I don't do any art work. But that is really a ridiculous thing to have to just accept when most other brands just have good looking screens.
Battery life is garbage. Do every possible trick you can in either linux or windows, get 4 hours.
Why do I even say I love it?
I don't know. As far as I can tell, I should not say that. I love the idea. I love the sales pitch.
The sales pitch is repairability right?
My daily driver before the Framework was a X1Carbon 5th gen. About a year after I got the Framework I decided to refurbish the thinkpad because it was still awesome. I got a new battery, cpu cooler, and usb port all pretty easily (though frim ebay and aliexpress not from Lenovo), and they were all easy to install. The machine came apart all with screws just like The Framework. The Framework just makes it official with help and documents, but actually I've never even looked at a single one of those qr code instruction links. I'm sure they're nice, and I'd preferr if Lenovo did the same thing, but in fact I don't actually need instructions for things that are screwed together and don't have obtuse hidden land mines where something will be destroyed by doing the obvious thing.
The lenovo repair was essentially exactly as easy even though it was totally unsupported by lenovo themselves.
But that X1 Carbon is 50x better to use. Way tougher. Screen is even. Keyboard is way better. Actual mouse buttons (something I personally value highly, I hate huge touch pads with no buttons like Apple and Framework has).
I don't know if a current X1 Carbon is as easy to work on as one as old as 5th gen, so this comparison may no longer be valid.
> Both MacOS and Windows offer that without all constraints and privacy negligent services from Google/Alphabet.
As yes, Windows, the famously privacy respecting OS. [1] [2]
Apple has also been hard at work developing new ways to gatekeep users from running their own software. [3] macOS updates are also widely known to be small, quick to install, and never leave the computer unbootable. [4] /s
I, like the author, have had Chromebooks for many years. They are, bar none, the most easy to use and secure by default computer I have ever used.
Chromebooks are cheap and are supported for longer than any Windows/macOS release and the update process is utterly seamless and without issue.
It has all but removed IT support requests from my elderly relatives. The worst thing they can do is install a sketchy Chrome extension, but that's painless to remove compared to malware.
The author has a good point but I am surprised they neglected to mention the most important aspect for any aspiring appliance maker:
The BSD license
Yes, thanks to the magic of the BSD license you can ship an appliance that is nothing more than a vanilla BSD and some hacky scripts and never have to worry about your customers demanding to see how much jank you have shoved into the box.
As a user, that is precisely the main drawback of the bsds (as much as I love them, especially OpenBSD). If I'm using a bsd in some third-party computer, some icky middleman may have changed stuff in the system for which I'm not allowed to see the patches. If the license was GPL, I would have the right to see these changes!
Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
> Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
Indeed, I don't consider the BSD license a good thing from a user's perspective. Companies love BSD/MIT licensed software though.
Has nothing to do with the licence, if you need a lawyer (GPL) to see the magic changes in your appliance, you should probably not trust that vendor.
Also, if the appliance vendor has put in some binary blob/module, you have no right to see that either (only the changes to the kernel). In the end, it really doesn't matter.
> Has nothing to do with the licence, if you need a lawyer (GPL) to see the magic changes in your appliance, you should probably not trust that vendor.
Of course! But trust is unnecessary with code in hand.
But there's plenty of jank in e.g. Android phones. And of course anything the vendor doesn't feel like open sourcing they can just cram into something like 'google play services' to keep it closed source.
And vendors who want to TiVo-ize Linux can do it just fine, thanks to the Linux kernel embracing the TPM.
>every software/firmware using custom Risc-V instructions is tivoized
I disagree. Tivoization means using hardware restrictions unrelated to the core functionality of the hardware to make it difficult to run modified code. The original Tivo checked digital signatures in the bootloader. This isn't core functionality, because it could be deleted without harming anything.
Merely writing software for unique hardware doesn't count as Tivoization. It's very common for software written for older machines to only run on that exact machine, and nobody calls it Tivoization. There has to be some feature added specifically for the purpose of restricting user freedom.
TiVoization is about the inability to patch a system you bought to run different software. The TiVo boxes would refuse to run the proprietary TiVo software that did the whole magic if they detected a modified version of any of the system software, this is what annoyed RMS and led to the GPLv3. It's nothing like custom instructions.
This concept works fine for the author's example of a kitchen scale, but fails when the device in question is something like a router that has secure boot with one key burned into e-fuses.
In that case we need both open software and a requirement that the manufacturer escrow signing keys with someone so that after EOL any software can be run.