sbszllr

I commented it last time the post about Claude watermarking went viral and I'm going to say the same thing again:

"I've been working in the media and model IP space for quite many years. What this article misses a bit is the threat model for watermarking in general. Watermarking and fingerprinting have inherently weak security guarantees -- they rely a lot on security through obscurity, weak assumed adversaries to deliver. There are clear trade offs between true positives, false positives and maintaining the quality of the media. It's true for audio-visual media, models and their outputs alike. As much as I like to take shots at poor technical choices by corps and govs, this one is unjustified. Sure, inserting glyphs is bad but biased sampling is as good as it gets in 2026."

Since the announcement, there have been many people who don't seem to fully understand what a security guarantee is, what trade offs it might involve, or how popular the type of technological solution is in general (media watermarking is ubiquitous).

And naturally, there are challenges with how you will make sense of the score in your org, e.g. you wrote an email, and it's flagged as LLM-generated because you copied two generated/edited paragraphs.

Yeah, the article might disagree with watermarking as a matter of principle, comparing it to censorship. But the methodological arguments that I have read so far have been thin in these articles.

I've been working in the media and model IP space for quite many years. What this article misses a bit is the threat model for watermarking in general.

Watermarking and fingerprinting have inherently weak security guarantees -- they rely a lot on security through obscurity, weak assumed adversaries to deliver.

There are clear trade offs between true positives, false positives and maintaining the quality of the media. It's true for audio-visual media, models and their outputs alike.

As much as I like to take shots at poor technical choices by corps and govs, this one is unjustified. Sure, inserting glyphs is bad but biased sampling is as good as it gets in 2026.

EDIT: grammar

It's possible and even likely there's industrial espionage going on. But imo, you don't need that. I've worked in cutting edge industries, and even when you don't know what your competition is doing, there are usually only so many logical next steps.

It's interesting how OpenAI and Anthropic effectively mass dumped a bunch of similar features in the last two days.

I wonder what other features they're cooking right now.

Maybe it just shows my lack of tolerance for process/overhead.

As a fellow rebase enjoyer, I will do it occasionally for smaller PRs but to me, it becomes unwieldy for large ones.

Do you have any tips or aliases that makes it more workable?

Let's forget that this post is an ad. I feel like there is a use for LLMs that could help us do stacked PRs better.

Right now there are effectively three ways to do a PR:

- a bunch of small commits, some of them related to the feature, some fixes, some mixing both -> a PR with 'n' commits -> they don't really make sense as atomic commits, you have to review the entire PR to make the sense of it

- a squashed PR

- some uber principled reorganisation of commits that separates key implementation concerns into smaller commits (effectively stacked PRs but clean)

The last option would be desirable but it's unreasonable to expect anyone to do it by hand. So this is where <maybe> an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?

Daisy chaining finally supported.

I was thinking a similar thing when reading the article. Often, the validity of the input depends on the interaction between some of them.

Sure, we can follow the advice of creating types that represent only valid states but then we end up with `fn(a: A, b: B, c: C) transformed into `fn(abc: ValidABC)`

> We already had that disaster where pop-ups fly out "do you want to accept those cookies". That is just a usability nightmare. People are forced into extensions, just to stop wasting their time here.

You’re perpetuating a gross misunderstanding of the cookie law. What it states is different from how the advertisers implement malicious compliance to bias people, like yourself.

Websites that implement basic functional cookies do not need to display any popups. They’re permitted to do so. Any cookies that are essential to the functioning of the website within reason are permitted. In fact at no point a website should serve you a cookie popup unless you seek it out because analytics and advertising cookies are supposed to be opt in.

So many websites do two things, serve you a popup that has everything enabled which is a clear violation; or a popup that has only functional cookies selected but the biggest highlighted button allows all of them.

The law is fine. Malicious compliance is to blame. The EU has been slow to rectify it.

The quality and usefulness of it aside, the primary question is: are they still collecting chats for training data? If so, it limits how comfortable, and sometimes even permitted, people would with working on their yet-to-be-public work using this tool.

I agree that is performant enough for many applications, I work in the field. But it isn't performant enough to run large scale LLM inference with reasonable latency. Especially not when we compare the throughput numbers for a single-tenant inference inside a TEE vs batched non-private inference.

Interestingly enough, it is possible to do private inference in theory, e.g. via oblivious inference protocols but prohibitively slow in practice. You can also throw a model into a trusted execution environment. But again, too slow.

These are fair points but the weight of their impact is a misconception. Times and times again, lower capital and investment risk aversion are shown to be the limiting factors.

There's a lot of truth and real pain points in the article but others miss the point entirely. Two things that stand out to me in particular:

- C "standard" is quite flaky in practice, there are lots of un/underdefined things that compilers interpret quite liberally for the purpose of optimisations

- complaining about the syntax and symbols is unfair: rust offers all these semantics to represent the memory model of your codebase. The equivalent is not possible in C/C++, and when we try to do it, we're inventing our own constructs at the code level instead of relying on the syntax

I've been camera scanning 4x5 and I'm happy with the results. Take two offset photos and stitch them in post. Mind you, I scan with pixel shift for higher res.