9 ms·

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:

by lxe 2y 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 ^

noman-land 2y ago
This is why javascript is so fun.
- dylan604 2y ago
  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.
  - atomicnumber3 2y ago
    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.
    - teeth-gnasher 2y ago
      The need to manage data access on the server does not go away when you stop using javascript. Is there something specifically about Swing that somehow provides proper access control, or is it simply the case that it is slightly more work to circumvent the front end when it doesn’t ship with built in dev tools?
      - dylan604 2y ago
        The built-in dev tools is the key thing. If there was no way for the client to manipulate things, it wouldn't be too far off from other local apps. Reversing is always going to be a threat vector, but the low bar to entry of using the dev tools makes it a non-starter for me. If using Ghirdra was as simple as using the dev tools, the software industry would collapse.
        noman-land 2y ago
        The built in dev tools are fundamental to an open web. If you don't want someone to look at something in their own possession then don't send it to them in the first place. Obfuscating it is rude and is false security anyway. The grand rule is don't trust the client. People break this rule and then try to paper over it with obfuscation, blame, and tightening their control.
        dylan604 2y ago
        That's not what I said nor meant, but sure, jump to that conclusion. You wouldn't run a shopping cart app where the item counts and totals were calculated client-side. You get the item id and quantity, and have the server do that. Just like if you were censoring something, you wouldn't send the client the unredacted data and then let the UI make the edits. No obfuscation is needed for any of that. Open web has nothing to do with any of this
        stevage 2y ago
        Sometimes you do calculate prices client side. But you double check them server side.
    - wiseowise 2y ago
      > 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. No, by a large margin no. Java is a hostile language to prototype programs at which JS excels. Awful styling, walls of code just to get sane defaults (https://docs.oracle.com/javase/tutorial/uiswing/dnd/together.html https://docs.oracle.com/javase/tutorial/uiswing/dnd/together..., seriously?).
      - homebrewer 2y ago
        Swing is decades old at this point, its shortcomings have nothing to do with Java. JavaFX does not require this much boilerplate. https://docs.oracle.com/javase/8/javafx/get-started-tutorial/fxml_tutorial.htm https://docs.oracle.com/javase/8/javafx/get-started-tutorial...
      - atomicnumber3 2y ago
        "And all the other desktop app frameworks." I refer to Qt and and the other desktop frameworks too. Having an actual language and runtime where the UI toolkit is just that, a toolkit. Don't focus on Swing, that's just what I'm familiar with.
  - fmbb 2y ago
    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.
    - ChocolateGod 2y ago
      > If users can break the censorship Any user breaking the censorship likely knows already what the censor was blocking.
  - stevage 2y ago
    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.
tills13 2y ago
insane that this is client-side.
- atq2119 2y ago
  Perhaps a case of subversion by following the letter but not the spirit of an order?
- LordDragonfang 2y ago
  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.)
- KTibow 2y ago
  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.)
- Ancalagon 2y ago
  more like hilarious
- dheera 2y ago
  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.

by lxe 2y ago

noman-land 2y ago

This is why javascript is so fun.

dylan604 2y ago
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.
- atomicnumber3 2y ago
  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.
  - teeth-gnasher 2y ago
    The need to manage data access on the server does not go away when you stop using javascript. Is there something specifically about Swing that somehow provides proper access control, or is it simply the case that it is slightly more work to circumvent the front end when it doesn’t ship with built in dev tools?
    - dylan604 2y ago
      The built-in dev tools is the key thing. If there was no way for the client to manipulate things, it wouldn't be too far off from other local apps. Reversing is always going to be a threat vector, but the low bar to entry of using the dev tools makes it a non-starter for me. If using Ghirdra was as simple as using the dev tools, the software industry would collapse.
      - noman-land 2y ago
        The built in dev tools are fundamental to an open web. If you don't want someone to look at something in their own possession then don't send it to them in the first place. Obfuscating it is rude and is false security anyway. The grand rule is don't trust the client. People break this rule and then try to paper over it with obfuscation, blame, and tightening their control.
        dylan604 2y ago
        That's not what I said nor meant, but sure, jump to that conclusion. You wouldn't run a shopping cart app where the item counts and totals were calculated client-side. You get the item id and quantity, and have the server do that. Just like if you were censoring something, you wouldn't send the client the unredacted data and then let the UI make the edits. No obfuscation is needed for any of that. Open web has nothing to do with any of this
        stevage 2y ago
        Sometimes you do calculate prices client side. But you double check them server side.
  - wiseowise 2y ago
    > 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. No, by a large margin no. Java is a hostile language to prototype programs at which JS excels. Awful styling, walls of code just to get sane defaults (https://docs.oracle.com/javase/tutorial/uiswing/dnd/together.html https://docs.oracle.com/javase/tutorial/uiswing/dnd/together..., seriously?).
    - homebrewer 2y ago
      Swing is decades old at this point, its shortcomings have nothing to do with Java. JavaFX does not require this much boilerplate. https://docs.oracle.com/javase/8/javafx/get-started-tutorial/fxml_tutorial.htm https://docs.oracle.com/javase/8/javafx/get-started-tutorial...
    - atomicnumber3 2y ago
      "And all the other desktop app frameworks." I refer to Qt and and the other desktop frameworks too. Having an actual language and runtime where the UI toolkit is just that, a toolkit. Don't focus on Swing, that's just what I'm familiar with.
- fmbb 2y ago
  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.
  - ChocolateGod 2y ago
    > If users can break the censorship Any user breaking the censorship likely knows already what the censor was blocking.
- stevage 2y ago
  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.

tills13 2y ago

insane that this is client-side.

atq2119 2y ago
Perhaps a case of subversion by following the letter but not the spirit of an order?
LordDragonfang 2y ago
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.)
KTibow 2y ago
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.)
Ancalagon 2y ago
more like hilarious
dheera 2y ago
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.