tl;dr: “Fuck You, we’re right, but here’s a crumb from the table” but in PR-speak.
There’ll be a Lan-Mode (still requiring Bambu Connect), and a Dev-Mode (which will continue MQTT, live steam and FTP).
The Writing continues to be on the wall.
Actually, isn’t this the optimal outcome? The new “security” features are now optional for those who want them. Everyone else can choose developer mode, has all the old features and is responsible for securing their network. We could argue if opt-in or opt-out is better but I see the argument for having “security” features enabled by default.
I don’t see it this way, for multiple reasons.
If my understanding is correct, they are (imho) misleading if not lying in this post, when they say:these claims are entirely false:
Bambu Lab will remotely disable your printer (“brick” it).
Firmware updates will block your printer’s ability to printBut they integrate a certificate which has a validity date.
Once that update is on, you’re kind of locked to their releases. Yes they now, after the backlash have realized that they are putting up the walls a bit too quick. But I do not see anything in there that says “we were wrong to do it this way” - which they are.
There is little reason to - by default - put the cloud inbetween your PC and your Printer, which may sit 2m or less apart. That never makes anything more secure.
Trying to play the devil’s advocate here, and I am really interested in your takes on this (I’m not affiliated with Bambu, and I am shocked about the whole development as well, having bought a P1S recently):
Bambu currently has printers reachable on LAN and Cloud without much of security. This has one major downside for them and for the customers: if some malware is spread via whatever means, which then identifies whether it can see a Bambu printer on its LAN, it could send random GCode commands to brick the printer and/or waste energy and filament. I don’t think you could set the printer ablaze with this, but you could definitely destroy the printer. If this happens to a lot of printers at the same time, customers wouldn’t be happy.
So Bambu needs to somehow secure their interfaces in a way that malware cannot exploit easily, while at the same time allowing non-Bambu software to talk to the interface. Their idea seems to be, that Bambu Connect can proxy your requests to the printer, and (hopefully) verify the commands being sent are innocent enough. This will protect their userbase and themselves from financial harm.
A loud group of users now complain, rightfully, that this will brick their workflows. Also, this will open the doors for Bambu to e.g. move to a subscription model or remove support for non-Bambu filament. Looking at the workflow: They now claimed to allow a local “dev mode”, which basically disables security, but allows skilled users to use their established workflows. They then don’t want to offer too much support for this, which in my opinion is okay. This is similar to how unlocking your Android phone (if done via official means) would void some part of your warranty (not fully, and not for the hardware I think).
As for the potential subscription model, filament support, etc.: They can and would do this regardless, if they want to. This is always a risk for customers buying a closed-source product. I still bought one, because they are supposed to be the easiest to use and setup for people new to 3d printing, and so far I tend to agree. Would I be happy about open source firmware? Yes, absolutely. But we might not get that, and I was aware of the when buying the printer. I can still hope that some security professionals cleverer than me will figure out a way to install custom firmware at some point, but there is no guarantee (just an increased chance, now that they alienated their users – some hacker might accept this as a challenge).
Please contradict me and discuss with me, I want to understand if there is anything wrong with my logic.
The Security argument doesn’t hold water when you’re pushed toward the cloud use for transmitting data over your own network cable would suffice.
Define APIs and API keys (local and cloud).
Instant safe communication, local and/or cloud.
