People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network.
Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely.
Moving to Mutual TLS via a controlled client like Bambu Connect is a pretty industry standard approach to secure, authenticated communication that doesn't require an internet connection, it is done with digital signatures offline.... and thus it can be done over a LAN. It's how many web APIs inside a corporate network are secured. It's how web browsers are secured. Microsoft, Mozilla, Google, Apple, etc. all send you revised certs/keys regularly in your OS or browser patches. Client authentication via x.509 cert signature or subject verification isn't super common on the public web but it does happen a lot with mobile apps or thick client apps, or some websites, e.g. SAP's many websites often use it to verify you're a customer.
- You can't print from Office you need to export to a PDF
- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.
- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!
I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.
Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.
I clearly don't understand what kind of security are we talking about in this particular case of using a 3D printer. A protection from what – someone comes to my home, connects to my wifi with my password, and then – prints a huge cube to waste all my filaments? Where's the real threat here?
The way things are going, I doubt that 3D printers with always-on requirements and without hardware kill switches for phone-home connectivity are going to be very interesting to any corporations interested in keeping business secrets or staying compliant with data privacy regulations.
It's much more likely that Bambu is doing these moves to control their hobbyist userbase more tightly and make things easier for them, as they've seen other consumer electronics companies get away with similar moves.
It's a risky game however - this is going to land them on ban lists for West-based gov or edu installations even faster than DJI.
Moving to mTLS authentication is going to get Bambu on a ban list? That's incredibly hyperbolic.
Though, if you're right, between the Huwaei ban, DJI ban and the TikTok ban, it's becoming clearer the U.S. no longer really believes in a free market if it doesn't own the market. There may be legitimate reasons to enact a ban, but it sure looks convenient that they're banning all the tech that is that is clearly superior to U.S-owned alternatives.
That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 client authentication with Mutual TLS.
If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
I didn't say "inherently" or "fundamentally" insecure in my post. I said "generally". Generally, it's hard to deploy MQTT in a secure way, as it has many options that are insecure. In particular, you'll want to use mTLS, which itself is tricky to deploy due to the need for client cert verification. MQTT without mTLS is also prone to DDOS with less widely known techniques for mitigation than HTTPS.
The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.
Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.
Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.
Misconfiguration of services, does not constitute an error in the protocol itself.
This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
You could already talk freely to the MQTT on the printer and it was already secured with a unique password. This feels like making it a second class feature that could disappear at a future point.
I don't really see what having a "developer mode" offers here beyond the existing solution. The current mqtt is already locked down with a unique password and AFAIK the endpoint was read-only anyway.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
Developer mode is just "how it works today" mode. It's insecure, and uses private APIs, and thus shouldn't be used, but people will anyway, so they're listening to their customers.
> Developer mode is just "how it works today" mode.
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
They’ve suffered real brand damage. Any of the changes (original, or these) seem like they would win over unconvinced potential customers, yet they’ve actively turned some away.
Didn't we hear this tune from Sony in the Playstation 3 days with Developer mode and then it slowly faded away after a couple years of application/product releases...
You do not need to give it internet access for LAN mode to function, but you lose a LOT of features that the cloud app and mobile app give you. For example, you can no longer do anything with the camera in LAN mode, even from the official Bambu Studio app. So no timelapses or ability to check in on it from even just elsewhere in my house.
There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.
They just introduced firmware updates via SD card in the most recent released version, prior to that you had to put the printer online and associate it with an account to get firmware updates.
But yes today there is no need to use their cloud services unless you want to control the printer with their phone app. And the printer works totally fine completely isolated from the internet.
The now aborted proposed update would have required using a binary shim from bambu with an embedded 1 year lifetime SSL cert to speak the the printer at all, even when in lan mode.
The main concern that was raised was that you couldn't send print jobs from other slicers anymore, and this article explains why this isn't the case in the section titled "How Bambu Connect Works", taking OrcaSlicer as an example.
Judging by the PR thread in OrcaSlicer's GitHub repo, not all users are happy with the proposed fix, requiring users to install Bambu Connect on their computers (which currently doesn't run on Linux, IIRC?) to be able to use the new OrcaSlicer to Bambu workflow... https://github.com/SoftFever/OrcaSlicer/pull/8103
Tellingly, this pull request is coming from a Bambu Lab employee. I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change.
Orca is used for a number of other printers too — and don't forget Bambu Slicer is a fork of Prusa Slicer is a fork of Slic3r... it's open source forks all the way down that rabbit hole!
You mean Bambu Lab broke compatibility with OrcaSlicer and every other slicer out there.
I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
I'm guessing most of OrcaSlicer's users are using bambu printers and if they upgrade to the firmware that requires bambu connect it's quite likely that the OrcaSlicer maintainers will have some interest in keeping the slicer working.
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
> I'm guessing most of OrcaSlicer's users are using bambu printers and if they upgrade to the firmware that requires bambu connect it's quite likely that the OrcaSlicer maintainers will have some interest in keeping the slicer working.
Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
> The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
The OrcaSlicer maintainers probably have the most leverage (what little there may be) on Bambu Lab. I think that is why Bambu Lab is keen to offer the PR on GitHub. The maintainers should exercise whatever leverage they have while they still can.
> But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
OrcaSlicer is sponsored by Qidi and BigTree Tech. If anything, Bambu Lab is taking them for a ride, like it is taking the rest of the open source community for a ride.
It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.
If this were about security, it wouldn't matter what piece of software was implementing the well documented security protocol. BambuSlicer, or OrcaSlicer, it would be all the same because the underlying protocol would be the security guarantee. This is rudimentary security tradecraft.
Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure. More realistically, Bambu Lab is introducing vendor lock-in under the pretext of security. Vendor lock-in is what this change actually achieves.
Controlling the software lifecycle of a client library or executable, to be able to update its x509 certs as part of an upgrade cycle, is ... not security through obscurity. It's pretty standard practice, especially if your customer base knows very little about maintianing certs/keys.
It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs.
There's no real vendor lock-in here beyond the usual conspiracy "Bambu Lab is better therefore they're evil unless they give it all away for free to their competition", that's a pile of nonsense. Orca Slicer and 3rd party slicers will continue to work with the new approach if they can work out the details of the PR that uses Bambu Connect.
Somehow you can securely access your bank account with any browser of your choosing, and not a bank provided browser, but 3D printers need obscure proprietary security protocols to be secure. That doesn't make sense.
Um no? First, Bambu is the best, by far. Secondly, Orca Slicer is a fork of Bambu Studio and the vast majority of its users are Bambu customers that want extra features.
Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.
Their primary competitive advantage right now the AMS bundle being very competitively priced.
These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money off their ecosystem.
who cares if Panda Touch/BigTreeTech was making money off the ecosystem? it did nothing more than sell more bambu printers. It's not net-zero--money for BigTreeTech is not coming out of Bambu's pockets; I seriously doubt it was net-negative for Bambu.
Because the writing on the wall is that this was always meant to be a subscription based, continual revenue stream for Bamboo Labs. They are just edging that direction.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
Having 2nd and 3rd party support only make an ecosystem more robust.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.
To me this whole thing feels like they're trying to pass audit to sell Bambu printers to corporations that require secure communications. Mutual TLS with client certs is nearly universal, which is what they're trying to do with Bambu Connect. On the other hand, MQTT isn't a very secure protocol, plus the printer also uses FTP which is mostly banned on corporate networks these days.
I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS).
I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?
Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.
I don't think their MQTT was over TLS traditionally (maybe they added this), it used to be that you just sent a message over unauthenticated MQTT and FTP'd your 3MF; the FTP had a password but that also was sent in the clear. https://github.com/darkorb/bambu-ftp-and-print
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
People have been using MQTT with TLS for years[1][2][3]. Long before the company and line of printers existed. It's not really an excuse to say "well they didn't use it" -- they should have simply offered people the necessary configuration options to enable it.
The play here is obviously that they want 3rd party services to use Bambu Connect instead of direct protocol integration. They will make Connect easy and direct too much work. That is what all the Panda talk was about. That way, when Bambu inevitably changes the model ( eg. Subscription ), we will have to pay to get access to the ecosystem. But Bambu will be able to claim that it is not them. We still support developer mode they will say, it is the evil third parties that do not.
We need to make sure that dev mode becomes the de facto default. Don’t fall for connect.
I am surprised that the use of a messaging queue through MQTT is considered a misuse of their technology when in reality it appears that the other application just was using an internal API that could change without notice. I also could see how certificate based authentication could be viewed by some as a time based expiration on the firmware.
Yeah that's a huge bummer if so, I've got both a HA automation that shows the printer status without needing to have an app installed and I've got a secondary filtration system that's fully automated which would be a PITA if I had to manage manually.
Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.
Bambu lab printers are truly awesome in terms of what they can do for a very reasonable price. Having said that, I have never upgraded mine nor have I ever connected it to the internet and never will. Nor will I update it. If it takes me 15 minutes to get an ssh client running on an esp8266 that can connect to an
poorly secured server and execute shell commands, there is no way I'm letting a proprietary chinese hardware and software anywhere near my home network. But this is just a side hobby of mine, so I can live with carrying around an SD card. But I can see how something like that can be a major blow to business owners. I am not entirely sure if this blog post is just a response or sneaky backpedaling from bambu labs after the backlash they received over the last few days.
We were about to to buy a Bambu Lab printer but then learnt there will be new printers coming out in Q1 so naturally wanted to wait.
I need to educate myself on this a bit more on this issue, but it feels like the rest of the printer industry is just catching up with the X1C (looking at Creality K2 Plus)..
Do I wait for next-gen printers from Bambu Labs which I imagine will be quite revolutionary, or do I buy we buy a Creality K2 Plus, which basically is a X1C.
I bought a miku baby monitor specifically because they were the only manufacturer that had the feature I wanted that promised to never charge monthly fees to use it.
Well then they went bankrupt and a company bought them, forced an over the air update that disabled every feature that made the thing worth buying (for $399), and sent out a letter demanding monthly payment to reenable the “advanced” features.
Market forces won’t fix this. Recurring revenue is just too tempting. It also doesn’t matter how well intentioned a company is, the moment they go out of business, someone will buy their assets and force monthly fees on their former customers.
Seems like the maker community, esp. YouTube influencers, uniformly recommend bambu. Curious-- do folks here have other recommendations? Equivalent quality, speed, maybe even price, but more committed to free software?
If you want a more trustworthy review, check out Maker Muse' recent review on current-crop bedslingers. Interestingly, unlike the standard influencer talking points, they came to the conclusion that the Prusa is easiest to set up and operate (while not being negative on Bambu).
I tend to trust Maker Muse because he's over the years repeatedly shown screenshots of emails by compannies trying to bribe, pressure or threaten him, which gave me some faith that he's generally refused these advances.
Generally speaking, no. Prusa comes close - they're dedicated to community and OSS, and are quality parts... but are almost 2x the price and tend to be missing comparable features.
The other competition doesn't quite have the UX and quality of Bambu Lab. That's changing slowly, but it's reality today IMO.
The challenge is that the 3d Printing community is maturing from a hobbyist/tinker phase into a consumer phase with Bambu Lab leading the way. Bambu Lab has mostly threaded the needle by balancing proprietary UX with practical ability to tinker, swap parts, etc.
But as with most hobby communities, if someone doesn't understand a motivation of a change, they immediately ascribe it to a conspiracy.
Bambu Lab wanting to improve printer security is an obvious thing to anyone who has dealt with corporate network security in the past... today it is effectively an insecure toy that would only be deployed on black holed lab networks. They're trying to make it more modern via Mutual TLS authenticated file transfer rather than a cobbled together mix of FTP and MQTT.
Prusa does not have an equivalent printer to the P1S/X1C. Even their Mk4s is twice the price of an A1 and is missing some basic features that come standard on all Bambu Lab printers (such as a camera).
I'm pretty pissed that they baited and switched me--I bought a bambu printer on holiday sale under the previous terms, and they are now going to change the terms. Feels fraudulent.
Uh-huh. So exactly what threat or threats is the "security upgrade" meant to address, what alternatives were considered, and where the heck is the "security" in sticking a barely obfuscated private key in a publicly distributed binary?
The security threat is real, they got ddos attempt to their mqtt service last year from 3rd party apps.
The fix is not good though, distributing private key.
I genuinely don't understand how these changes could possibly protect them from ddos though — their cloud APIs are still public, and the Bambu Connect app has to do stuff there as well. What could've changed with the proposed changes?
Meanwhile Jeff Geerling already put a video out on his second channel that he won’t recommend a bambu lab printer anymore although he was happy with his printer. And this update didn’t convince him to change his mind.
“Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
There is little I find more hilarious than the "<talking head> has put out a video on their <youtube/tiktok/facebook> that says <thing>" comment reply.
I summarise all these replies in my head as "Influencer I've never heard of influences"
Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely.
Moving to Mutual TLS via a controlled client like Bambu Connect is a pretty industry standard approach to secure, authenticated communication that doesn't require an internet connection, it is done with digital signatures offline.... and thus it can be done over a LAN. It's how many web APIs inside a corporate network are secured. It's how web browsers are secured. Microsoft, Mozilla, Google, Apple, etc. all send you revised certs/keys regularly in your OS or browser patches. Client authentication via x.509 cert signature or subject verification isn't super common on the public web but it does happen a lot with mobile apps or thick client apps, or some websites, e.g. SAP's many websites often use it to verify you're a customer.
- You can't print from Office you need to export to a PDF
- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.
- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!
I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.
Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.
It's much more likely that Bambu is doing these moves to control their hobbyist userbase more tightly and make things easier for them, as they've seen other consumer electronics companies get away with similar moves.
It's a risky game however - this is going to land them on ban lists for West-based gov or edu installations even faster than DJI.
Though, if you're right, between the Huwaei ban, DJI ban and the TikTok ban, it's becoming clearer the U.S. no longer really believes in a free market if it doesn't own the market. There may be legitimate reasons to enact a ban, but it sure looks convenient that they're banning all the tech that is that is clearly superior to U.S-owned alternatives.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.h...
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.
Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.
Misconfiguration of services, does not constitute an error in the protocol itself.
This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
- Want to introduce x, but we are worried what our userbase thinks.
- Introduce something way more ridiculous y that subsumes x.
- Rollback y but not x because of backlash.
Now they look like a company that listens to their users and they got what they wanted.
https://en.wikipedia.org/wiki/Door-in-the-face_technique
Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.
There's also other limitations of it in features I don't really use, for example IIRC the RFID stuff they do with their print spools stops working.
But yes today there is no need to use their cloud services unless you want to control the printer with their phone app. And the printer works totally fine completely isolated from the internet.
The now aborted proposed update would have required using a binary shim from bambu with an embedded 1 year lifetime SSL cert to speak the the printer at all, even when in lan mode.
How does it not address the concerns of people?
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Yes. That's where the maintainers need to decide if they are Bambu Lab's lackeys or if they have a say in their beloved project. Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
> The alternative is that users have to manually use bambu connect and that seems inferior to what the PR enables.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
The OrcaSlicer maintainers probably have the most leverage (what little there may be) on Bambu Lab. I think that is why Bambu Lab is keen to offer the PR on GitHub. The maintainers should exercise whatever leverage they have while they still can.
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
Bambu Lab is introducing something else. Most charitably, it could be described as security through obscurity, which is never secure. More realistically, Bambu Lab is introducing vendor lock-in under the pretext of security. Vendor lock-in is what this change actually achieves.
It's about a vendor trying to control an experience for its users balancing its UX and maintenance costs.
There's no real vendor lock-in here beyond the usual conspiracy "Bambu Lab is better therefore they're evil unless they give it all away for free to their competition", that's a pile of nonsense. Orca Slicer and 3rd party slicers will continue to work with the new approach if they can work out the details of the PR that uses Bambu Connect.
Which is fine, no? Plenty of other good printers available.
Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.
Their primary competitive advantage right now the AMS bundle being very competitively priced.
Whether or not it’s simply greed or that they didn’t make as much selling the printers as they had thought. The next step to closing an API and killing 3rd party interactions is almost always so they can introduce some form of continuous monetization scheme.
That was always something that rubbed me the wrong way with Bamboo Labs. They threw an absolutely obscene amount of money at influencers. Essentially buying a ringing endorsement from nearly the whole hobbyist community and made their brand a household name.
The time was right to pull the switch.
This whole kerfuffle only sours me to them. I like the printer but the desktop software quality is low and features in LAN mode are not available for what one can only think of as a shity move to Hoover up data for the enshitification
Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.
From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)
In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.
Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?
Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.
From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.
I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?
Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
[1]: https://mosquitto.org/blog/2018/05/version-1-5-released/ [2]: https://forums.raspberrypi.com/viewtopic.php?t=287326 [3]: https://esp32.com/viewtopic.php?t=9747
They use an online MQTT server instead of the local one for the following functions: initiating printing, heating the nozzle, and heating the heatbed. (see https://www.allaboutbambu.com/2024/06/14/p1p-p1s-new-firmwar...)
On https://forum.bambulab.com/t/bambu-lab-mqtt-limitations/8344... you can see their MQTT server got DDOSed by some faulty 3rd party "client".
I don't think it's so much about security of the users as much as it is about their own.
In lan mode it doesn't use anything remote and works just fine completely isolated.
> you can see their MQTT server got DDOSed by some faulty 3rd party "client"
Right, when you use 'cloud mode' then bambu controls the printer, and your own control has to go through them.
We need to make sure that dev mode becomes the de facto default. Don’t fall for connect.
BambuLab new firmware to cut access to third-party API and tools
https://news.ycombinator.com/item?id=42760491
Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.
I need to educate myself on this a bit more on this issue, but it feels like the rest of the printer industry is just catching up with the X1C (looking at Creality K2 Plus)..
Do I wait for next-gen printers from Bambu Labs which I imagine will be quite revolutionary, or do I buy we buy a Creality K2 Plus, which basically is a X1C.
I bought a miku baby monitor specifically because they were the only manufacturer that had the feature I wanted that promised to never charge monthly fees to use it.
Well then they went bankrupt and a company bought them, forced an over the air update that disabled every feature that made the thing worth buying (for $399), and sent out a letter demanding monthly payment to reenable the “advanced” features.
Market forces won’t fix this. Recurring revenue is just too tempting. It also doesn’t matter how well intentioned a company is, the moment they go out of business, someone will buy their assets and force monthly fees on their former customers.
I tend to trust Maker Muse because he's over the years repeatedly shown screenshots of emails by compannies trying to bribe, pressure or threaten him, which gave me some faith that he's generally refused these advances.
The other competition doesn't quite have the UX and quality of Bambu Lab. That's changing slowly, but it's reality today IMO.
The challenge is that the 3d Printing community is maturing from a hobbyist/tinker phase into a consumer phase with Bambu Lab leading the way. Bambu Lab has mostly threaded the needle by balancing proprietary UX with practical ability to tinker, swap parts, etc.
But as with most hobby communities, if someone doesn't understand a motivation of a change, they immediately ascribe it to a conspiracy.
Bambu Lab wanting to improve printer security is an obvious thing to anyone who has dealt with corporate network security in the past... today it is effectively an insecure toy that would only be deployed on black holed lab networks. They're trying to make it more modern via Mutual TLS authenticated file transfer rather than a cobbled together mix of FTP and MQTT.
Meanwhile, trust continues to be eroded.
“Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
Local first, everything that should likely run locally should be enabled.
You can’t use the desktop software to see the contents of the SD card, you have to enable cloud access.
I own two Bambu printers, great hardware, and ok software. No longer recommending them.
I summarise all these replies in my head as "Influencer I've never heard of influences"
I agree with your re: Developer mode though.
Says even then you have to use their app and cloud service to set up the printer.