Can you link to some specific detail on that, because I keep seeing that claim, but without any technical info.

I have a P1S which currently can print completely isolated from the internet. Unfortunately (or maybe not?) the new firmware isn't available for my printer, so I can't dig into it myself yet.

But I'd really like to see some sort of "when I try to do X it tries to connect to Y" or "I used to be able to do X, and now Y is required as demonstrated here".

Something more than the current hearsay and pitchforks echo chamber.

From their blog post: https://blog.bambulab.com/firmware-update-introducing-new-au...

"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."

Now, PERHAPS, I can do that authentication locally... but given the plugin required for OrcaSlicer it doesn't seem likely

Yep -- I read that, but that doesn't spell out auth back to BBL's servers, just auth.

And keep in mind that OrcaSlicer already used Bambu Network Plugin to communicate with their printers. (It prompted you to download this on install of OrcaSlicer if you picked one of their printers.)

The move to Connect means that OrcaSlicer needs to send the print data to Connect via a protocol handler instead of to the plugin. Connect will then send it on to the printer itself, and from what I've seen it'll do that over LAN. (But I can't test because my printer doesn't support this yet.) I see this as akin to a print driver vs. printer-specific support built into an app. Not a bad thing at all, if done right.

The plugin already did (very minimal) auth via the Access Code and can do it with the printer and Bambu Network Plugin completely isolated from the internet. (I've done this.) So I'd like to know specifics of what's changing here.

what else would it be auth'ing against if not Bambu servers?

Perhaps some... other or better way of authenticating to the printer? Previously there was just a single, essentially fixed, numeric string that gave complete access to the printer, and communication was via TLS with a self-signed cert.

I don't want to hypothesize about what it could be doing, I want to see what it's actually doing (or see some actual info from folks about what they've seen) so I can decide if I'm comfortable with that or not.

The bambu cloud service has a very low value-add and they are trying to make it mandatory. the speculation is that they are trying to add a subscription model for print farms, which 3rd party slicers enable.

the printer itself?

"Operation Guide for Bambu Connect

Start by logging in to the Bambu Lab account or click Discover to find LAN mode printers."

https://wiki.bambulab.com/en/software/bambu-connect

At the very least - it looks like you'd need to log-in to the cloud account to print on the LAN, which really begs the question.... why?

> it looks like you'd need to log-in to the cloud account to print on the LAN

The text you quoted directly contradicts what you are saying. It says login OR discover to find LAN mode printers.

You’re right! Sorry obviously I was one coffee short of comprehension!

I don't have a definitive source readily available, but from talking to people who were investigating the technical aspects, connection between the printer and slicer software will be mutually authenticated using a certificate that will issued by Bambu Cloud, issued only to blessed 1st party software, and verified by the printer upon connection over the local network.

So your blessed Bambu Studio instance connects to Bambu Cloud and requests a certificate, the server issues the certificate to you (or not), and then Bambu Studio may use it to connect to the printer on your LAN.

The certificates have an expiration time of 1 year, meaning that the printer functionality would severely degraded (missing network connectivity), at most 1 year after they take the servers offline or stop issuing certificates for any reason.

Not a definitive source for what I said, but it contains some information: https://hackaday.com/2025/01/19/bambu-connects-authenticatio...

I sorta get what you're saying, and the flowchart here (https://blog.bambulab.com/updates-and-third-party-integratio...) 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.

> 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.

What do you mean, if my software can't talk to the printer then that affects printing functionality.

I mean that the extracted cert that's going around is from the client (Bambu Connect) side. Everything it would get used for is a function of the client and how it talks /to/ the printer.

Even if it is used to sign some communications, it doesn't matter if it's expired or not on the server side (the printer side), unless the server chooses not to accept it. And then updating it would be a matter of updating Connect; the client.

There's no reason -- other than hyperbole -- to infer that a certificate which expires on the client side will cause the printer to stop doing anything.

For a web-y example, think of how a website which needs a client cert for auth -- like lots of gov't stuff -- would handle a client cert expiring. It'd either accept it anyway, or reject it. But it wouldn't mean the website breaks. And thus claims of that client certificate's expiration being a killswitch for printers is simply wrong.