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.
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.
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.
Stay with me here, you could just implement some public key signing with the printer and include it in the setup in the slicer. Then set it on the printer to only except said public key commands. Problem solved, no cloud. No malware talking to your printer. No EULA roofy, just utter bullshit another company wants to force users into there cloud account.
Hm… like some „press button in printer now to initiate key exchange“? Sounds like a good idea, and pretty straightforward. I like it.
If your LAN is not secure, you have other problems. Also, the way most printers secure this is through a login and/or a token that you need to provide to your slicer to allow it to communicate.
And this is WHY so many of us do not want printers (or basically any device) exposed to “The Cloud” without it being opt-in. Because even if this IS “security” related? Bambu is not a cybersecurity company. Just look at the endless shitstorms that is qnap for why that is a problem.
LAN is already secure. And the solution for Cloud/WAN is to make that opt-in.
You are SO close. Yes, this DOES give Bambu a LOT more control over what commands can be sent to a printer. No, that is not about security.
It is about controlling The Models.
A couple years back there was the big NFT rush and folk were making arguments about it being used to protect (corporate) IP. We were immediately laughed out because people are stupid.
But imagine if every single printer had a module that analyzed what you were trying to print. And if something in the database were detected, it would refuse to print without confirming you have a license.
But nah, that would be impossible. I mean, it isn’t like Twitch and Youtube can do exactly that to detect music and even video…
But hey, keep on keeping on with the caping for corporations leading the way to fuck over the industry because you like their logo or whatever.
Like I said, I’m just playing devils advocate to understand the full picture better.
The LAN being secure might not be an issue for you and me, but the average user might not be so skilled. Though I understand your point that LAN security should not be Bambu‘s concern.
Regarding your NFT argument: I agree this is a valid concern, especially with the proxy being able to see everything sent to the printer. Though I hope the dev mode they promised would be enough to avoid that for now.
The devil doesn’t need you to defend it. So not going to speculate on why you are so eager.
And, again: if your LAN is compromised then someone sending a Ding Ding to your printer is the least of your worries. You might as well argue they are trying to protect you in the event someone breaks into your house.
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.
But don’t they currently allow local connections and also use them if the printer is running in cloud mode? I would assume if the printer can be “seen” by your machine locally, Bambu Studio would connect locally for some of its data transfer? Regardless of printer configuration (LAN only or Cloud) it still has its local ports open, which currently can be used by e.g. Home Assistant without any cloud connection. This is nice, but at the same time can be a security risk, as any local malware might also send commands. So a way to secure the local connections is definitely needed.
API keys would be nice for any type of connection, but it’s something they’d need to implement, including a way to request/revoke them from either your Bambu account (cloud again, not preferred by the open source community) or directly from the printer (might be a hassle to use with the P1S’ small screen). Instead they decided to go full-throttle by using some form of certificate authentication, possibly using per-device and per-account certs in the future, that might be generated locally and signed by their endpoints using your Bambu account.