fruitcantfly

To share a chat via https://claude.ai/, you first have to click on the "Share" button in the top right corner of the chat window. On mobile you first have to click the ... button in the same location, before that button appears. You then have to click the "Create public link" button. That creates a link to that chat that allows anyone to view it.

However, each chat is identified by an UUID4 in the URL (e.g. https://claude.ai/share/01234567-890a-bcde-f012-34567890abcd)*. That means that the URL cannot be guessed even if you accidentally make a chat public, and search engines cant index it either. For anyone else to actually access the chat, you have share the URL with them.

While it is theoretically possible that somebody went through all those steps purely by accident, it seems is very, very unlikely to me

* Additionally, this public URL is different from the URL you use to access the chat, meaning that sharing your private URL by accident and later creating a shared URL does not allow anyone else to access the chat from the private URL

Even if you somehow didn't realize that search engines would index the stuff you share publicly on the internet, you should realize that if you create a link that gives anyone with that link access to something and share it in public, then you no longer have any control over who has access to whatever you shared.

I would expect that most people do realize this, and that the vast majority of chats that have been indexed do not include anything that the owner considers to be sensitive. But that doesn't make for as exciting an article

The author probably didn't know. I believe that the 1.4 build is only available via the bun self-updater as a "canary" release. It hasn't been officially released yet

It can't be quite that bad; they've been shipping the rust version of Bun with Claude Code since v2.1.181 (released June 18th), and I haven't seen an outcry over all related functionality breaking

Those can all be separate partitions on any Linux system. But defaults matter, and if the defaults are insecure then you can expect most systems to be insecure

XFS is the default filesystem for RHE, and while I believe that /tmp is a tmpfs on RHE and should therefore be safe, it is my understanding that /var/tmp needs to be accessible on boot and is therefore typically on the root FS. EDIT: Can confirm for the RHE server I have access to, that this is the case

Those root privileges being able to edit a root-owned file if it’s in a directory that allows writes by all users. How common is that?

The file doesn't need to be in a world-writable directory, there just needs to be a (world-)writable directory on the same partition, such as /tmp on the root partition. The attacker then uses a XFS specific feature (reflink) to create a clone of the target file (e.g. /etc/passwd) in the writable directory, and then they can modify the content of the target file via their clone due to the race-condition

The advisory has a more detailed description: https://cdn2.qualys.com/advisory/2026/07/22/RefluXFS.txt

Other git hosts are also getting scraped, and have had to implement counters because of it. For example, this is the kind of thing Codeberg shows crawlers. I've even seen people who self-host complaining about getting overloaded because of bots scraping their forge

For me, and a few other projects I checked, it only has non-GPL repos. But it also does not have everything that isn't GPL, despite the repos being much older than the cut-off date. But it does have repos without a license, which they are simply not allowed to copy.

I wonder if those repos have been deduplicated, and one of the forks (on some other person's account) is included instead. Unfortunately you can only search the first 5M records via the website, and I don't have time to play around with the API at the moment, so I could neither confirm nor deny that possibility

If nobody owns the code, then then nobody can enforce the terms of the license it was released under, and free software under the FSF definition becomes impossible. All you have is public domain.

For example, a company could take the Linux kernel, modify it and distribute it with their gadgets. And they could simply not release the modifications they've made, as is required by the GNU Public License. But nobody would be able to do anything about it. Currently, copyright laws allow the people who wrote the Linux kernel to sue the company for breaking the license and violating the authors' copyrights

That really ought to have been the default behavior. Opting out only takes one or two extra characters. Well, three or four if you don't habitually bracket your variable names, which you should probably be doing anyways

Neither of those terms seem problematic to me; a plain reading would be "mostly" means more than half of the code, and "tolerated" would mean that the ban is not enforced on such projects. Of course, if you are already operating under the assumption that Codeberg is acting in bad faith, then it doesn't matter what the terms of service says nor how they they might say that they interpret them.

It is, however, not surprising that their terms of service are subject to interpretation. That was already the case before they added these particular terms. For example, the Codeberg TOS already included a prohibition against "content that harms the reputation of Codeberg" before the recent changes. Codeberg simply added projects related to cryptocurrency as an example, when the ban was voted through. It is furthermore the case that most, if not all, terms of service are subject to interpretation. We are talking about documents describing human behavior, not machine code.

If this kind of thing is not acceptable to you, then your only real solution is to self-host