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.
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.
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.
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
Adapting to Bambu Connect means passing the print files to another app, and it's unclear if that app will work without a cloud account. Plus Orca does lose functionality like controlling the printer directly from the slicer, and one of the critiques of the new system is needing a separate app in the first place.
If you mean that OrcaSlicer will reimplement Bambu Connect protocols inside — I doubt that will happen, since Bambu Connect is not open source, so this would involve reverse engineering the protocols and potentially including Bambu Connect certificates.
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.
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?
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.
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.
I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you need to accept it.
Part of that is thinking about at what point the project becomes pointless as a meaningful BambuSlicer alternative.
Why would OrcaSlicer become pointless if it supports Bambu Connect? It also supports the Bambu network plugin.
Everything is going to be inferior to using BambuSlicer. That is Bambu's real intent.
What would Bambu's motivation be to do that? I don't think they would have built Bambu Connect if the goal is not to support third party slicers to directly send things to the printer. Note that most 3d printers on the market didn't or still don't have integration into slicers.
I generally agree with your view on OrcaSlicer. I think we have a difference on what is better for the users and the project itself. I think it is better for the users if the maintainers take a stand against Bambu's dictat.
Whatever Bambu does is whatever Bambu does, you need to accept it.
And maybe it is time to take your ball and go home.
What would Bambu's motivation be to do that?
What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.
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.
That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors .
Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call their server APIs to ensure only the Bank's mobile apps (or partners) can call their APIs.
In Bambu Labs' case, they've had many DDOS attacks and other issues with their security and so they're forcing a constraint on the approved software clients that can access their printers and/or cloud service via client authentication. BambuConnect being the catch all proxy software for most.
Bambu is forcing its customers to use its cloud offerings when many users want to use the machine on their LAN without the cloud guff. Many for security reasons. Bambu essentially tells its customers to pound sand, they are forced to use cloud. Now Bambu is claiming it has a cloud DDOS problem and therefore it is going to lock down what users can do further. I'm sorry, that's just silly. Let me connect to the printer locally, and your cloud DDOS problems go away.
The DDOS problem itself doesn't sound particularly compelling as a justification for this action, either. If every user action is authenticated, you know which users are abusing the system - throttle them or kick them out. Adding a TLS certificate for mutual authentication is going to reduce the DDOS overhead by a negligible amount.
forcing a constraint on the approved software clients
Which will do nothing against a determined DDOSer since they will always be able to extract the certificates from Bambu Connect, or BambuSlicer.
Finally, if the issue is airtight security for the on-prem printer and preventing a hacker external or internal to the LAN from exploiting them. Maybe Bambu can take a page from the Matter smart home specs. if they are out of ideas. These are solved problems. Cloud not necessary. Software lockdown not necessary.
ppl always get caught up on the x509. They're actually a good thing and are absolutely necessary to prevent mitm since they use self-signed certs.
BambuStudio also works that way.
The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.
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.
Comments
The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.
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.
That is obviously correct, but this is a meaningful improvement over what their initial plan was.
That doesn't seem obvious to me. It's not unthinkable their plan is:
- 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.
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.
Ah the classic door in the face technique
https://en.wikipedia.org/wiki/Door-in-the-face_technique
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.
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
Hmm, seems pretty clear that OrcaSlicer will eventually adapt to use Bambu Connect regardless, which will preserve active cloud connections.
Adapting to Bambu Connect means passing the print files to another app, and it's unclear if that app will work without a cloud account. Plus Orca does lose functionality like controlling the printer directly from the slicer, and one of the critiques of the new system is needing a separate app in the first place.
If you mean that OrcaSlicer will reimplement Bambu Connect protocols inside — I doubt that will happen, since Bambu Connect is not open source, so this would involve reverse engineering the protocols and potentially including Bambu Connect certificates.
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...
Why should I switch to "developer mode" to talk to a computer I own on my own network?
You don't need to. You can use their Bambu Connect client in LAN mode.
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.
Insecure for who? What's the threat vector?
I wouldn't call it more or less secure. You're just on your own and should expect this (internal) API to have breaking changes at any time.
But when you buy the printer you still need to give it internet access / connect via their app, right?
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.
I'm not sure why you would need to give it internet access. I think even the firmware updates work via SD card.
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.
Bambu Companion (unfortunately iPhone only) does more than Handy and works on LAN. Using it today in fact! https://www.youtube.com/watch?v=LZpDQN9zgUI
Would you be able to elaborate on the ones you’ve seen?
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.
The time was right to pull the switch.
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?
That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.
It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?
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.
How does it not address the concerns of people?
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.
Hum, the alternative is OrcaSlicer stops working with Bambu printers...
OrcaSlicer is a fork of Bambu's slicer. It defeats the whole impetus of the project to not support Bambu Lab printers.
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.
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.
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.
I understand your anger, but I don't think that properly describes the situation. As a maintainer of an open source project your users are who you are about. If your users want support for bambu connect, then you are likely to implement it. Whatever Bambu does is whatever Bambu does, you need to accept it.
Why would OrcaSlicer become pointless if it supports Bambu Connect? It also supports the Bambu network plugin.
What would Bambu's motivation be to do that? I don't think they would have built Bambu Connect if the goal is not to support third party slicers to directly send things to the printer. Note that most 3d printers on the market didn't or still don't have integration into slicers.
I generally agree with your view on OrcaSlicer. I think we have a difference on what is better for the users and the project itself. I think it is better for the users if the maintainers take a stand against Bambu's dictat.
And maybe it is time to take your ball and go home.
What is Bambu's motivation for being cloud first when it is not technically necessary? Why can't OrcaSlicer be a first class citizen like BambuSlicer? Instead it has to go through Bambu Connect which is inherently clunky and less featureful. It's simple. Control, and vendor lock-in. Possibly, Bambu sees this as a way to curtail print farm automation software from other vendors.
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.
Bambu Lab isn't being predatory. They're making a sensible change to their security.
But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.
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.
That's because the bank isn't generally using mutual TLS client authentication to verify your account details through your browser. You login with a password and other authentication factors .
Interestingly some banks do use x509 client authentication for corporate accounts or high net worth accounts but they expect you to know how to import the key to your browser. And almost all banking mobile apps use this to call their server APIs to ensure only the Bank's mobile apps (or partners) can call their APIs.
In Bambu Labs' case, they've had many DDOS attacks and other issues with their security and so they're forcing a constraint on the approved software clients that can access their printers and/or cloud service via client authentication. BambuConnect being the catch all proxy software for most.
None of this makes sense.
Bambu is forcing its customers to use its cloud offerings when many users want to use the machine on their LAN without the cloud guff. Many for security reasons. Bambu essentially tells its customers to pound sand, they are forced to use cloud. Now Bambu is claiming it has a cloud DDOS problem and therefore it is going to lock down what users can do further. I'm sorry, that's just silly. Let me connect to the printer locally, and your cloud DDOS problems go away.
The DDOS problem itself doesn't sound particularly compelling as a justification for this action, either. If every user action is authenticated, you know which users are abusing the system - throttle them or kick them out. Adding a TLS certificate for mutual authentication is going to reduce the DDOS overhead by a negligible amount.
Which will do nothing against a determined DDOSer since they will always be able to extract the certificates from Bambu Connect, or BambuSlicer.
Finally, if the issue is airtight security for the on-prem printer and preventing a hacker external or internal to the LAN from exploiting them. Maybe Bambu can take a page from the Matter smart home specs. if they are out of ideas. These are solved problems. Cloud not necessary. Software lockdown not necessary.
ppl always get caught up on the x509. They're actually a good thing and are absolutely necessary to prevent mitm since they use self-signed certs. BambuStudio also works that way.
The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.
Which is fine, no? Plenty of other good printers available.
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.