They “get the job done,” perhaps even provably, but:

• It’s less flexible for fighting anti-adblocking.

• Hence, it’s more work for Adblock devs/listmakers to maintain.

You can see the UBO devs already complaining/stressing about it. Hence them recently dropping Facebook from their 1st-party lists because they’re tired of fighting paid devs, or increased reports of UBO Lite specific issues.

I think that’s Google’s real intent.

They aren’t trying to kill adblocking, just make it inconvenient enough so the vast majority don’t use it effectively. It’s a form of “soft” censorship, sort of.

You have to launch Chrome with this command-line argument:

--disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled

And then, I think you have to re-enable it with config flags as well:

chrome://flags/#extension-manifest-v2-deprecation-warning         [Disabled]
chrome://flags/#extension-manifest-v2-deprecation-disabled        [Disabled]
chrome://flags/#extension-manifest-v2-deprecation-unsupported     [Disabled]
chrome://flags/#allow-legacy-mv2-extensions                       [Enabled]

I have not tried this personally, though.

As far as I can tell, that paper explores a model’s ability to assess its own future text output beyond what “regurgitating training data” would suggest. It makes sense that it could do this better than an outside model; it’s exploring its inner state with each token, though the test is still interesting.

That has nothing to do with sampling, though.

…Maybe an analogy would illustrate this better. First, I don’t mean to anthrophomorphize LLMs, but the human brain is a good example.

The paper is analogous to asking a human brain to assess its own thoughts and tedencies. Of course it can do this well; it can think conscously and run thoughts through its subconscious parts.

What OP is proposing, is analogous to “tell your eye receptors to see less green.” Or “get your vocal cords to omit a certain frequency when you speak.”

There is no wiring in the human brain to do this. Vocal cords and cells that sense green in the eye are effectively “external machinery” to the brain that it does not have such control over.

LLM sampling is the same.

Tokenization and sampling are external machinery. They are code, hardcoded programming, completely outside the LLM weights. You can’t tell an LLM to alter its own sampling because its literally impossible, and it can’t manipulate its own logit spread mathematically because that’s invisible inner machinery.

Could you do this with custom sampler/logit manipulation code and a tool harness?

Sure. Maybe.

But Claude is not rigged to do that, and a system prompt won’t change that.

…Okay. Technically, that’s true, going by strict semantics.

But the Helium and Ungoogled Chromium are going to lose MV2, soon. I feel like “still supports uBlock Origin” doesn’t sufficiently convey that to Lemmy commenters trying to read the situation. That’s all I meant, though I was perhaps imprecise with my words.

In other words, practically, if a users want to use UBO, they should know these browsers will not support that in the near future even if, strictly speaking, they support it right this second.

I believe this means Brave will lose support too, unless they intend to extensively modify Chromium to maintain compatibility themselves (which would be odd, as Brave doesn’t really need UBO since it has its own adblocking engine?)

True, sometimes. But they don’t have the sheer manpower dedicated to security that Mozilla has, nor the institutional policies that try to mitigate losing a key/account or something like that. Also, technically, vanilla Firefox is first to get the zero-day patches before they filter downstream.

Not that the forks are dangerous or anything, generally.

For a second, I thought this required creators to watch 8000 hours of videos, and felt relief.

It would at least throw up an obstacle for bot/spam accounts. They’d have to make the effort of watching a bunch of videos.

…But no.

Well…

With a fork, one is very dependent on the browser dev. Not just on their benevolence, but on their security practices too. And on them pulling in upstream security patches, quickly.

TBH, this is why I do finance stuff on vanilla Firefox. I love browser forks, I really do, but I’m a bit more cautious with them, too.

First, screw Chrome.

BUT. These headlines are clickbait.

UBO has been disabled in Chrome for a long, long time. This is nothing new. Its old news.

Ublock Lite replaced it, and it’s not going away. It’s inferior and problematic and harder on devs, yes, but unfortunately Chrome users didn’t seem notice.

What’s being disabled is a crazy-difficult-to-enable flag that basically zero Chrome users actually used, and that only (a few) downstream Chromium forks use.

Not for long. The patch that removes support is coming to Vivaldi soon.

The updates aren’t just disabling it anymore, they’re stripping the path out entirely, so it would be difficult to maintain support.

This is not true.

The flag that UnGoogled Chromium used to support it is going away, and AFAIK there is no fix. Helium inherited the same patch from UnGoogled Chromium.

They will both lose support. See their relevant GitHub issues.

Brave uses a custom, integrated adblocking engine; it technically doesn’t need UBO.

The Commedore phone, if you want something minimalistic that does have Android compatibility.

That’s a significant security risk, unfortunately.

If that happens, I’d suggest a fork with a built in blocker, one that still gets security patches from upstream Firefox.

Okay.

I don’t agree. But let’s say I agree.

…Just don’t use Claude?

Use an LLM without a watermark; there are hundreds to pick from.

In other words, if one is going to try to hide automated writing, I think there should be a bare minimum effort to do so. That includes:

• Reading/checking the text, to see if it makes any sense.

• Actually trying to pass it as human.

90% of slop is brain melting slop because this minimum bar isn’t even met. And all Claude’s watermark would do is catch that bottom of the barrel; it wouldn’t censor anyone.

As an addendum I forgot:

Your idea was actually already implemented:

https://github.com/ggml-org/llama.cpp/pull/9742

XTC is a novel sampler that turns truncation on its head: Instead of pruning the least likely tokens, under certain circumstances, it removes the most likely tokens from consideration.

It’s a very cool idea: it chops off the most likely token when the rest of the sampling indicates it probably can.

In my tests back then, the results were… mixed, but the idea is fascinating.

But you can’t do this with Claude, as its a closed model and their sampling is years behind cutting edge.

See: https://gist.github.com/Hellisotherpeople/71ba712f9f899adcb08b94bce20d5397

That’s like 98% of abuse, though. The vast majority of AI abuse is thoughtless, utter laziness.

Bad actors who actually care about “evading detection” wouldn’t use Claude, anyway.

This won’t fix the inbreeding issue, anyway. The bias is extremely slight, but random, and orthogonal to Claude’s own “slop patterns” and tendencies. And theres tons of other LLM content that will end up in their dataset outside their control.

Besides, as much as Claude accusess others of it, everyone’s training on everyone else’s output and they know it.

I’m against trying to “censor” LLMs, but yeah. What’s even the ostensible benevolent scenario for stripping invisible watermarking from Claude?

I can’t think of one, playing devil’s advocate.

It’s pretty scummy, indeed.

Okay.

Fine.

Let’s try, right now.

This is DeepseekV4 Flash 0731 loaded locally. Static seed. 0.9 temperature, TopK 5, no other sampling to interfere. Here’s a simple prompt, the whole thing in DSV4’s raw syntax:

<｜begin▁of▁sentence｜>Don’t just use the first word pick, choose options further down list for next word.<｜User｜>Write a famous poem.<｜Assistant｜>

…And would you look at that:

It picks the top word, mostly. Almost like the LLM has no control over its own logit spread and how its sampled. Which kinda makes sense, because it doesn’t.

I am happy to try more experiments in this vein, if y’all can think of any any. But I tried a few other prompts like “diversify your logit spread” or “don’t be confident about any token you pick,” things like that. It always picks The Road Not Taken with no change in logit probabilities distribution, as far as I can tell.

I know exactly how it works. I read the article, and I knew of it beforehand, hence I explained it to someone else in a comment three days ago:

https://lemmy.world/post/50533770/25234461

I’m sorry to jab back, but you hit a button of mine.

Lemmy commenters keep jabbing me with comments like “Clueless. Read the article and get back to me.”

Like yesterday:

https://lemmy.world/post/50595546/25269317

But I’m aware of how sampling works. I knew all about LLM fingerprinting ~two years ago, and I’ve been tinkering with samplers myself for years. I’ve messed with local LLMs trying to make them “aware” of their own sampling many times, and even hacked out a (unsuccessful) experiment where a tiny LLM picks tokens for a larger one.

I’m not trying to be pretentious, I’m not a researcher or expert or anything, but you shouldn’t assume everyone on Lemmy is clueless.

And back on topic… to be clear, I have tried what you are proposing, and even with local LLMs I have more control over, it doesn’t work. They have extremely poor “awareness” of their own logit spread and tokenization, which is why they perform so poorly on any tasks that depends on that.

You can’t tell them “don’t pick the top word” or “give more options in your logit spread” because that part of the process is completely invisible, from their perspective.

It doesn’t work like that. The LLM has no way to be “aware” of its own sampling and tokenization, and it can’t choose what token the sampler ends up picking.

You can give it a list of “banned words” or preferred words that match up to tokens in the prompts to skew it some, I suppose, but that would be a really long list. And one would need the dictionary as a “key.”