The official Bambu Lab company blog about its 3D printers, covering firmware updates, security and authorization changes, cloud outages and recalls.
Commenters cite it when debating Bambu's firmware authorization changes and cloud requirements, which many users distrust; one employee defends the products.
I’m not familiar with the 3D printing space, but seems like this reverse engineering was inspired by the companies move to clamp down on security of these devices. [1]
From what I understand, this new auth system would make third party integrations (ie, “OrcaSlicer”) obsolete and users would be limited to controlling the device via Bambu Connect. This update impacts users who control the device via HomeAssistant and “print farm management” users. I guess first party support for users with fleets of these printers is dogshit, thus the need for third party software.
Seems after 3 days of community feedback/outrage, the company is backtracking on the Bambu Connect only route. Instead offering a “Developer Mode” option in firmware which on the surface seems to be what the impacted users need. [2]
> In response, we’ve made the decision to implement an optional LAN mode feature, to provide advanced users with more control and flexibility.
> Standard Mode (Default): By default, LAN mode will include an authorization process that ensures robust security
> Developer Mode (Optional): For advanced users of the X1, P1, A1, and A1 Mini who prefer full control over their network security, an option will be available to leave the MQTT channel, live stream, and FTP open. This feature must be manually enabled on the printer, and users who select this option will assume full responsibility for securing their local network environment. Please note that Bambu Lab will not be able to…
I personally think the outrage I've seen on this issue is generally not justified.
In general people are just scared of change and on top of that are playing telephone on the details of the change, assuming the worst intentions from Bambu like they're trying to be the next HP.
I have seen a lot of misinformation on this topic, and I think that in that sense it's a good idea to read the actual announcement details to get a better read on Bambu's intentions: https://blog.bambulab.com/firmware-update-introducing-new-authorization-control-system-2/
A voice in Bambu's defense on this issue would say:
1. The new firmware isn't out, it's still in beta, and the new connect software is also in beta. This stuff isn't done and nobody has been forced to use it or even had it presented as an OTA update yet. The problems highlighted in this wiki page are very possibly problems that Bambu is aware of and intends to fix before release.
2. Bambu in their blog article stated that they are working on integration code so that third party slicers like Orca Slicer can more directly interface with Bambu Connect (see the FAQ section)
3. There are multiple statements on this blog page where Bambu acknowledges the workflow disruption and emphasizes the things they intend to do and do not intend to do, such as "It’s important to note that this update is not intended to restrict third-party software use. In fact, we’ve actively collaborated with third-party print farm management software…
I sorta get what you're saying, and the flowchart here (https://blog.bambulab.com/updates-and-third-party-integration-with-bambu-connect/) somewhat agrees.
But where I disagree is with that cert stuff.
1) That cert is on the /client/ side, not in the printer. It has nothing to do with printer functionality, only with talking to the printer.
2) Expired certs do not mean things automatically get rejected. Using and allowing expired or self-signed certs is routine in the IoT world where certs on devices can't readily be updated. But again, that cert isn't from the printer.
3) Expired certs, just like the self-signed certs that are so commonly used, still result in things being encrypted on the wire. And often that's the point.
It seems to me that someone found/exported the cert, and is trying to make all sorts of WHAT-IF or THIS-COULD-MEAN-THE-WORST claims but are lacking some significant understanding. Without understanding the architecture and the rest of the code, and perhaps seeing that cert be used, this is just an artifact found in the distributed beta application.
A lot of the distrust toward Bambu is because they originally announced cloud auth would be required even for printing locally in LAN mode, and only backpedalled on that when they saw the backlash.
I'm not sure why their entire domain has been excluded from archive.org but you can still see the original post for now: https://blog.bambulab.com/firmware-update-introducing-new-authorization-control-system-2/
--
Critical Operations That Require Authorization
The following printer operations will require authorization controls:
Binding and unbinding the printer.
Initiating remote video access.
Performing firmware upgrades.
Initiating a print job (via LAN or cloud mode).
Controlling motion system, temperature, fans, AMS settings, calibrations, etc.
> I'm not sure why their entire domain has been excluded from archive.org
So when they claim “we never said that” it is less easy to prove that to be an, erm, incorrect statement of truth.
It could be an accident due to over-doing scraper protection, but given the company's general behaviour of late I'm inclined to consider the negative interpretation more likely.
> but you can still see the original post for now: https://blog.bambulab.com/firmware-update-introducing-new-au...
I'd hazard a guess that that is not entirely the original post as it was before things erupted. There have been a couple of instances of materially changed posts.
From their post-mortem: https://blog.bambulab.com/cloud-temporary-outage-investigation
> The result was that the print job was successfully completed on the printer, but our cloud service believed it had not been done. When service resumed, the once-jammed job was resent, leading to the unexpected printing of an already finished job.
That's why you make message sends in a distributed system idempotent, unless you have a really excellent reason not to. Whatever generated the print job when the user pressed “print” should have generated a unique job id, and when the printer was resent the same job id it should just have replied “Done”.