Don't know why you were initially downed (maybe some thought you were an impersonator), so vouched for your comment.
Happy to see you on here and great to hear that you'll address this. As mentioned in my comment, data export let's users get access as it stands, but any improvement in UX is always welcome. Maybe making Design accessible via API credits for occasional use might be something you could bring up too.
Thanks for your efforts as an in between the user base and Anthropic. Based on prior personal experience and purely looking in from the outside, I wouldn't be surprising if it can be very challenging and stressful to be in such a position, especially when one may not directly state or say what they think is best in a given situation, so thank you for dealing with a not always very pleasant position where the situation and information you are provided with can change without your say, yet you may be the one to that will be considered responsible in the eyes of the public for a decision you neither made nor could prevent.
WP was incredibly smooth and they were willing to reinvent UX from first principles in ways that'll to this day make me reach for Sailfish OS if I didn't need physical buttons, but I must bring up the desktop version of Windows from that day.
I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used.
> 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that.
I’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.
I never used 8 because I hate the UI. But I used 7 for a long time. I recall that 7 was blazingly fast on a 2GB notebook back in the early 2010x. But then that was already way beyond its minimum system requirement.
If you export your data [0] all your Claude Design chats are in a design_chats directory along with the code, even if your account currently has no access to Claude Design. It is .json, but converting that into usable code is easily done, either manually or by asking any fairly modern LLM via OpenCode. Just did it myself, it works. I will say that I'd still prefer if they allowed API use of Claude Design, it does have some niceties regarding the way follow up questions have been implemented that I feel make it worth it for very narrow UX experimentation but can't justify a whole sub at the moment, given I for the first time started experiencing regressions up to making Opus unusable via Claude Code with the Max subscription for the first time and the new pretrain in GPT-5.5 is very strong for very specific coding use cases. In fairness though, compaction and task adherence can be inferior compared to GPT-5.4 which did both better than any other model ever, so using both for their specific use cases is my go to.
Not feeling like commenting on every statement regarding SaaS and expectations, but I will say that some are mistaken/not considering the law and your rights by just telling you it is your fault and (at least) implying the data is lost. It can't be, think about it. Any temporary subscription cancellation/payment processing issue/bug on Anthropics part/etc. would mean permanent data loss. That'd be less than ideal, not least because Anthropic has in the past had trouble processing payments from verifiably covered accounts.
Users in consumer friendly area have the right to export and access their data, including data not exposed via any frontend or API if associated with their account. Doesn't matter whether they pay or not. Course, manual backups are always preferable. A provider could still have a data loss, but as long as they have the data, at least in my neck of the woods they have to give it to you. As it should be.
To end, I generally try not to comment on others comments or down outside of actual spam and bad faith, but if more than one comment already was helpful enough to tell OP that they should have exported/backed up, do we really need it repeated?
thanks for letting me know this exists for claude designs as well.
yeah.. anyway it will be my coding agent that will be reading these. and if needed, it can show me what they look like.
in the ideal world, I know all these things should be in place, but I was not sure, they had the bandwidth to implement all these before releasing these things into the wild. but i will use it to download my sessions.
as a dev, building the product is the fun part, implementing entitlements, payment gateway, rate limiting, usage calculation, billing, gdpr stuff, account creation, deletion, export, these are the boring parts. so I wasn't sure they would have implemented this part.
If I just build the software from their repo without any modifications, getting an identical result to what I can download via their website, would I be allowed to use the service? If not, why not? If yes, what if I made a modification? How much may I change and where was this ever codified? What about using an unmodified, prior version of the source code to build? Why would that not be ok?
Interesting question. In the first case, where you install your own build from unmodified source code, although AGPLv3.0 still allows discontinuing support, I see no explicit carve-out in the licence to restrict network access.
However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.
To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.
What they cannot do is prevent you from running your modifications on your hardware.
But they had no access control in the first place. If I built their repo without modifications, I automatically have access. I would need to make modifications not to get that access.
> [...] they can still refuse you access to their network.
Sure, they can and yes, AGPL doesn't give users right to just access services, I have said before that they may enforce their EULA upon individual users. They are however not doing that, they are harassing repo owners. Let me put it this way: If the network access were the issue, as you seem to think, why go after the dev hosting your code rather than the individual users that you claim improperly access your services.
> What they cannot do is prevent you from running your modifications on your hardware.
They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
That's why I was asking specifically regarding what level of code modifications is acceptable for them. Because they made this an issue not about using their servers but hosting code, regardless of how it's used.
> They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.
I agree. I think the argument they are going for is similar to that from Google against yt-dl, but unlike in that case, Bambu is obligated to allow this codebase.
Something I just thought of under the shower: A user can build the slicer from scratch and the UA is public on their repo [0]. If one is determined to do so, using the same deps, pinning the date, etc., they could create a deterministic build identical to what Bambu offers for download on their website.
Will using such a build be an issue for Bambu? If not, what degree of modification would be needed for them to view building with their publicly available UA as bypassing a security measure/improperly accessing their services? Where exactly is the line here? Does their EULA define what percentage of the source code may be modified to view using their UA as acceptable? If not, is this something that one could enforce if they wanted to?
Also, what about 10NES [1]? The courts found that reverse engineering such a measure would be lawful, the basis of much that came later with Phoenix, Compaq, etc. If reverse engineering is acceptable, why wouldn't using AGPL licensed code? In both cases, the required information was acquired 100% legally.
> ChromeOS has better security and performance than Ubuntu [...]
I'm going to need a citation on that, especially performance. Doubly so if Crostini is put into the mix.
> [...] updates things like peripheral firmware that Ubuntu isn't even aware of.
Like what? WiFi cards, etc.? Isn't that generally in kernel already? What kind of updates do you think are not done by Ubuntu or another Linux distro?
Last I tried ChromeOS was on the Pixel Slate way back when. A buggy, unstable, clearly not properly tested, unperformed mess that I would not wish upon my enemies. Glad to see it has improved to usable now, but that it is better than any other Linux distros, I can't say how considering even being on par with e.g. Fedora would have been a miracle not to long ago.
Happy to admit that purely on the UI/UX, ChromeOS is very solid in my opinion, arguably and subjectively the most consistent and user friendly designed desktop environment I know. Far more consistent than anything MSFT or Apple have provided in quite some time, everything looks like it should, placement is easy to grasp and reliable with a clear identity. Consistency wise, only Gnome can hold a candle to the strictness with which the ChromeOS team execute their vision, though there is the clear divergence in the Gnome team pushing new UX innovations and concepts even if they are controversial and may need to time to learn, whilst the ChromeOS team seems purely focused on the most clearly easy to master approach one can take.
> I'm going to need a citation on that, especially performance
Multiple reasons. ChromeOS ships an optimized, platform-specific kernel, built using LLVM with LTO and AutoFDO. No other distro even attempts this. The only one that has even considered it is CachyOS that offers optional LTO, or Gentoo, where you can DIY LTO, but neither supports FDO.
Another reason is that Chrome GPU acceleration actually works on ChromeOS. IPU webcams work, too. On Fedora, Arch, and others you'll be patching and rebuilding kernels to get IPU.
> Like what? WiFi cards, etc.? Isn't that generally in kernel already?
This is another aspect where the ecosystem is the advantage, not the technical details. Chromebook makers are required to furnish firmware updates. ChromeOS will update (silently, without user intervention or notice) everything in a Chromebook: SSD controllers, battery management, radios, touchpad, USB PD controllers, the Titan security chip, the CPU, whatever. This is very different from the situation on random Linux+hardware combinations where the only source for many of these updates, if they are available at all, would be to reboot to Windows.
> ChromeOS ships an optimized, platform-specific kernel, built using LLVM with LTO and AutoFDO.
Ok. How significant is the difference they gain from that? If this yields such major gains, there must be benchmarks showcasing it. At the same time, there must be reasons why something isn't widely adopted if it can provided tangible upsides. Would be very surprised if Clear Linux (rip) and similar in spirit distros didn't go far beyond those optimisations, if they can yield measurable benefits. Even then though, there are measurable performance tradeoffs for anything running via Crostini which I know for a fact any compile time optimisations won't make up.
> [...] where the ecosystem is the advantage, not the technical details. [...] SSD controllers, battery management, radios, touchpad, USB PD controllers, the Titan security chip, the CPU, whatever.
I just checked and I think you are confused. ChromeOS uses fwupd [0] for those things, literally the same toolset and even sources (LVFS) to e.g. Ubuntu [1]. There is no difference in ecosystem, there is no advantage for ChromeOS here. I have to also point out that these are not "silently, without user intervention or notice", Google says so themselves [2] (except for UEFI/firmware but that was the only one you excluded in that list). Fortunately too, you wouldn't want ChromeOS (or any OS really) to do such major changes silently for many good reasons.
The "technical details" are important here. They are the same, they are not automatic, they can't be superior one way or the other. It is really neat that these solutions are so robust and reliable users of ChromeOS can start to think they must be some special secret sauce, when in fact they are just FOSS solutions we have had for a while. Heck, even the verification/testing isn't unique to ChromeOS.
> [...] random Linux+hardware combinations where the only source for many of these updates, if they are available at all, would be to reboot to Windows.
This does both Chrome OS and the FOSS projects it is built around a disservice and is not true. And not just because I can tell more than one instance where using Windows on a newly released laptop during the early Renoir days yielded driver issues which were unresolvable because Windows Update found it necessary to force a faulty AMD driver onto my system every time I provided a network connection, even after I manually tried to suppress that specific update and had already installed the proper driver, all while Renoir support in the then current Linux kernel was flawless out of the box along with Wifi, touch screen, etc.
It is great if everything feels polished and I feel the UX is great on ChromeOS, which may lead someone to think it is better than alternatives even where it can't be. But in regard to updates, how could they be, they are literally using the same solution with the ChromeOS team being happy to give credit and admit such.
> when in fact they are just FOSS solutions we have had for a while. Heck, even the verification/testing isn't unique to ChromeOS.
You answered it yourself (last paragraph). The main point is everything is in FOSS but not packaged like chromeos.
I strongly want bluefin/silverblue/bazzite etc to succeed but even installation is PITA. UI is not really that polished. Whether or not great one like proper integration (a.k.a like Apple) like passkey in Google Chrome/Android etc.
- Installer of bluefin etc takes super long - issue with btrfs - no idea. Dev says upstream issue - not us.
- flatpak is still pain for normies - we wanted to deploy it to a large compter pool
- ecosystem is controlled by Google. So fewer failures with hardware.
- And polish (like you say). Why can't <distro> make it so that uefi etc is hidden?
- Normies expect sleep to work. This is still not perfect with distro (not their fault).
Many including me - want OS to be like an appliance. Just works.
Have you tried configuring secure boot - with - every single protection on Ubuntu /any distro?
Just google: Mathew Garrett On The State Of Boot Security
implement everything and comeback.
Maybe slate with android? If you disable android in ChromeOS it a dream to use. Everything just works.
And remember normal people (i.e outside USA) already have Android phone. They just login and use. All passkeys etc. synced and running. All these are a pain in fedora etc.
I have a hard time seeing how any Chromebook above $ 349,- could still survive in an post-MacBook Neo age.
Say what you want, a cheap Windows laptop at least has an edge on obscure software compatibility over MacOS and a notebook running any modern Linux distro gets the luxury of user control. ChromeOS meanwhile has neither. Paying more for worst in class software compatibility inferior build quality, design and restrictive lock-in sounds about as appealing as a chicken tartare from the value bin.
Prior to (again) getting a MacBook Pro, I wanted to make a high end Laptop (ASUS ProArt P16, about € 3500,- back then) work with Fedora, but purely on a basis of build quality and input feel, it was unusably poor. That trackpad deserves a place in hell and if that (or likely a worse one given cost cutting) is what the Asus and Acer models get, competing with the Neo is a cruel joke.
HP and especially Lenovo fare better, I can at least live with those though a Neos input is nicer if we compare their current devices at the same price, so unless Google is willing to heavily subsidise a brand that, let's be honest, is unlikely to garner any loyalty, I can't see them being overly competitive either, given the software limits of ChromeOS.
> I have a hard time seeing how any Chromebook above $ 349,- could still survive in an post-MacBook Neo age.
I doubt there's enough of a market for the use case alone, but nice Chromebooks are perfect for travelling internationally - you can reset them before border crossings and quickly restore them after passing through border crossings where anybody is liable to ask for access to your devices.
Never thought of it, but conceptually, I could see the appeal for very privacy minded folks and those with heightened security requirements. Course, it's a question of thread profile whether one trusts Google and case dependent whether one can actually expect free and unrestricted access to a VPN for set up once they are in the country in question. Plus, you could just do this with any OS or laptop really, just use Tails or some other live distro. In any case, as you said, likely a small target market.
The trust venn diagrams I think aren't quite as bad as you describe - there are a ton of people with gmail accounts who implicitly start from a position of trust with Google, but I'd wager a lot of them wouldn't trust "border guard from a random country" to have unrestricted access to their personal gmail. They don't really need to care about VPNs either once across the border, https access to gmail.com is all they need.
> ChromeOS meanwhile has the worst compatibility off all four
ChromeOS can run desktop Linux software and Android software, so it definitely isnt worse than Mac. Its probably even better than Windows. Of course, if you need Mac/Windows software, Web/Android/Linux alternatives might not exist or might be worse. But the devices are hardly lacking software compatibility.
No, ChromeOS cannot. You can only run Linux applications via Crostini. Heavily sandboxed and restricted to limited hardware access, that is not software compatible by any reasonable measure. If that counts, my MacBook is compatible with all software ever made via UTM. Also, lest we forget ISA. If these Googlebooks are arm64, that restricts software compatibility further still as Crostini doesn't translate between arm64 and x86_64, so we are going from poor, limited support, to worse.
For reference:
> Cameras aren't yet supported.
> Android devices are supported over USB, but other devices aren't yet supported.
> Android Emulators aren't yet supported.
> Hardware acceleration isn't yet supported, including GPU and video decode.
> ChromeVox is supported for the default Terminal app, but not yet for other Linux apps.
If diluting your stock is a magical infinite money glitch, why doesn't Cohen just buy Nvidia? Heck, I think GOOG is now the most valuable, why not both? Throw TSLA in while you are at it and AMZN, I am sure there is some synergistic potential.
Alright I'll bite - go back to late 2020 and look at the stock market, then do some reading about the meme stock topic you wanna mock. Then measure your S&P 500 and valued stocks compared to who 'owns' them and who gets to value them. Then, if you're still with us, come back and try this thread again.
Techies like us get caught up in mechanism all the time in discussions like this.
But, though there are some explicit laws where that’s how it works, that’s not generally how the legal system works. If I have a private server, and I don’t give you permission to access it - or, even better, tell you not to, it doesn’t really matter how I secure it. If you access it, you’re in the wrong.
To give a physical analogy, it doesn’t matter how I’ve secured my house. Even if the door is open, you’re not allowed to just waltz in (or, to take it a bit further, come in and start using my stuff).
In general, I agree with you. However, to extend your analogy a bit further, so that it applies to _this_ situation: suppose you buy said house. When the former owner hands over the keys, you copy them. Then, one day, you enter the house using the copied key. The former owner can't really be all that upset, can they?
1. You bought the house.
2. They gave you a key, which implies that you have permission to use it.
3. Is the problem really the _copy_ of the key?
With no authentication it's a "gates down" scenario and it's assumed that if you put your server on the open internet you intend people to connect to it.
With authentication it's "gates up" and then "without authorization" from CFAA kicks in. I think it's unlikely that a user agent string creates a "gates up" situation, especially not if it's from code granted under a permissive license.
I have a mailbox in a multi family home. The keys are numbered and standardized. There are identical mailboxes out there that have the same key as me. In fact, I had to buy a replacement key since the original key broke and I just had to tell the manufacturer which number my mailbox had.
My neighbor could in theory buy the key to my mailbox, but it would be illegal for him to actually open my mailbox and read my mail.
If I build their slicer, not modifying any line of code, then accessed using that binary, would that be acceptable? If not, why not, considering it is identical to what is on their website?
If I made any changes prior to building, would it still be acceptable? And if not, where is the line? What is the legal basis, any precedent? How much of the code may I modify before I cross an invisible threshold and somehow "bypass" an "authentication" (neither fit UA anyways, either for law or other purposes unless one can provide any evidence that it ever has).
Even if that’s correct, Bambu has a right to then press charges on the users, but can’t really complain about the guy simply copying AGPL software to make it work. He’s not the one doing the illegal part.
Bambu clearly didn’t want to press charges on their users, though, so they weaponized the law to try and prevent this, and it’s causing them issues.
In any case, we’re not in some “only the laws matter” reality, we’re also have ethics and morals to consider, in which case Bambu is clearly in the wrong. If they want to secure their servers, they should do it properly rather than using legal threats.
"Press charges" - as if this were some Simple Assault. The CFAA isn't something one "chooses" to levy or not, these are crimes against the United States of America and it is solely up to the discretion of a US Attorney to prosecute.
A US Attorney prosecuting anyone on behalf of Chinese business interests isn't a good look politically, though, and that's often a factor.
That is how I (a non-lawyer) understand it as well, but I wonder if it's so simple when you combine it with the GPLness of it all. Like, releasing something under the (A)GPL is a license to use and modify the code how you see fit, and that goes "virally" through the forks. This fork is just using their own GPL-licensed code, and it seems unreasonable (for some definition of "unreasonable") to limit forks in this way. I think it's plausible you can make an argument that if you make this kind of restriction in your GPL codebase, you're violating the GPL license of the original ("upstream") authors.
Spoofing a User-Agent by itself is not illegal. Browsers, curl, bots, monitoring tools, and privacy tools do this constantly for legitimate reasons.
The legal risk comes from why you are doing it and what protections you are bypassing.
If you are doing it specifically to bypass Bambu's authorized access, then it is very likely to fall afoul of the Computer Fraud and Abuse Act. The mechanism (spoofing the UA) is entirely incidental to the motivation (bypass authorized access), which is what the law cares about.
weev got convicted for something pretty similar to this. His conviction was vacated, but he did spend time in prison for unauthorized access to an AT&T server that only required a specific user agent and a guessable numeric device ID number.
At least in the US, the law against unauthorized access to a computer system has no requirements for how good the security has to be. If you should reasonably know you're not supposed to be using it, that's potentially enough to make it illegal.
I checked and in that case [0] specifically, the court specifically doubted that such access was violating any applicable laws. Course, it got vacated before that could be properly addressed and this seems to be specific to NJ so if someone knows a broader case, happy to read up, but to me this makes the argument stronger that there is no reason to just presume such a "bypass" (if that counts, many of us have "bypassed" a lot via reading robots.txt, etc. in our youth) is inherently illegal. Again, happy to read if someone can provide a source saying something else. If Bambu want to argue EULA, go ahead, but let us not give these entities the ability to just wish something illegal because they simply dislike it, when there is no evidence it is.
Am currently somewhat into the topic of UAs for a personal project (not connected to Bambu printers), so am honestly interested for any tangible information, I just dislike us assuming something illegal because a corporate entity views it in a negative light.
[0] https://www2.ca3.uscourts.gov/opinarch/131816p.pdf ("We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code- or password-based barrier to access. See State v. Riley, 988 A.2d 1252, 1267 (N.J. Super. Ct. Law Div. 2009). Although we need not resolve whether Auernheimer’s conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based
barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT&T unintentionally published.")
There was more than one court involved. He was convicted. Then he appealed and the appeals court vacated the conviction. So from one perspective, "the law" as a whole decided that he wasn't guilty. From another perspective, he still got involuntary lodging courtesy of the state.
I don't think courts basically ever settle narrow technical questions like that. Any court decision would carry with it particular baggage based on the rest of the specifics, so I don't think it would have established a clear precedent either way.
The funny part here is it seems Bambu is more exposed to a libel suit than the developer is for... checks notes clicking 'Fork' on Bambu's github. Since the moment he did that, his software was supposedly in breach of Bambu's...expectations.
Thanks, would have been surprised, was mainly asking because OP was mentioning legal concerns. This may be a case for their EULA, sure, but I would have been surprised if there was any legal precedent or grounding for such a statement.
Happy to see you on here and great to hear that you'll address this. As mentioned in my comment, data export let's users get access as it stands, but any improvement in UX is always welcome. Maybe making Design accessible via API credits for occasional use might be something you could bring up too.
Thanks for your efforts as an in between the user base and Anthropic. Based on prior personal experience and purely looking in from the outside, I wouldn't be surprising if it can be very challenging and stressful to be in such a position, especially when one may not directly state or say what they think is best in a given situation, so thank you for dealing with a not always very pleasant position where the situation and information you are provided with can change without your say, yet you may be the one to that will be considered responsible in the eyes of the public for a decision you neither made nor could prevent.
reply