Comment by lxe
3 months ago
You can also intercept the xhr response which would still stop generation, but the UI won't update, revelaing the thoughts that lead to the content filter:
const filter = t => t?.split('\n').filter(l => !l.includes('content_filter')).join('\n');
['response', 'responseText'].forEach(prop => {
const orig = Object.getOwnPropertyDescriptor(XMLHttpRequest.prototype, prop);
Object.defineProperty(XMLHttpRequest.prototype, prop, {
get: function() { return filter(orig.get.call(this)); }
});
});
Paste the above in the browser console ^
insane that this is client-side.
It’s because they want to show the output live rather than nothing for a minute. But that means once the censor system detects something, you have to send out a request to delete the previously displayed content.
This doesn’t matter because censoring the system isn’t that important, they just want to avoid news articles about how their system generated something bad.
Gemini does this too. There was a clip of what it does when you ask it for examples of Google's unethical behavior... the kids call this "watching it get lobotomized in real time."
2 replies →
Ern, in DeepSeek’s case, it’s not “news articles” that they’d be most concerned about.
5 replies →
yea but i think the point is they can still filter it server side before streaming it
2 replies →
Not really if you understand how China works.
DeepSeek software developers are not the ones who want to censor anything. There is just a universal threat from getting shut down by the government if the model starts spitting out a bunch of sensitive stuff, so any business in China needs to be proactive about voluntarily censoring things that are likely to be sensitive, if they want to stay in business.
If your censorship implementation is good enough for 99.9% of people to get censored, you're good. A client-side implementation is good enough until/unless a lot of people start exploiting it, in which case you should put effort and proactively do something else to restore it to 99.9%, e.g. move it to the backend. If the government sees that you are being proactive about it, you'll still be fine. At that point, maybe you will still find 0.1% of people bypassing censorship with some highly obscure and difficult jailbreak, but that probably doesn't matter. If that difficult jailbreak becomes widely known, then be proactive again.
A very good example of the Chinese mindset of Chabuduo (差不多): 'close/good enough'. "If it's good enough to keep the authorities off our backs, it's good enough for us."
This. What makes this extra "funny" is that it implies that at least every business that builds something that can move information around must be knowledgeable about tianenman square and other chinese atrocities. Or else they would not be able to censor relevant questions. I have been to China a bunch of times and generally, they know what horrible things the Chinese gov did. They either say something like: "Yeah well, we live in a dictatorship, but it's not that bad" Or: "Yeah, the government is fucked up, but look at the government of the USA! We don't start wars in other countries and put in puppet governments." And there are so many good counters to both these arguments.
11 replies →
I don't know how it wouldn't be - it can't retract things already sent to the client. (The alternative is to moderate every chunk server side before sending it back, like Gemini does.)
ChatGPT had basically ALL of their prompt filtering client-side for a while, at a separate API endpoint, so as long as you blocked that endpoint you could basically ignore the content filters. (You would still get refusals from the model sometimes, but this was in the heyday of jailbreaks, and once you got a model going it would usually see that context and be willing to continue basically anything.)
Perhaps a case of subversion by following the letter but not the spirit of an order?
Lots of us have seen way worse hah
Such as client side control of prices when placing an order
Client-side because it reacts to local cookies?
2 replies →
more like hilarious
This is better than lobotomizing a transformer
This is why javascript is so fun.
It's precisely why I'm a such an advocate of server side everything. JS is fun to update the DOM (which is what it was designed for), but manipulating data client side in JS is absolutely bat shit crazy.
The last ten years of my career is basically all about manipulating data client side in JS. It works really well. In most cases I don't even need a server.
Obviously it isn't appropriate for all scenarios though.
In this case it is not bat shit. It is rather smart to offload this useless feature in the client.
The requirements are probably that normal users should not see “bad content”. If users can break the censorship it is maybe not the chat operators fault. They made an effort to “protect” the user.
1 reply →
I wish js (and, really, "html/css/js/browser as a desktop application engine) wasn't so bad. I was born into a clan writing desktop apps in Swing, and while I know why the browser won, Swing (and all the other non-browser desktop app frameworks/toolkits) are just such a fundamentally better paradigm for handling data. It lets you pick what happens client-side and server-side based more on what intrinsically makes sense (let clients handle "view"-layer processing, let servers own distributed application state coordination).
In JS-land, you're right. You should basically do as little as is humanly possible in the view layer, which imo leads to a proliferation of extra network calls and weirdly-shaped backend responses.
17 replies →