←back to thread

755 points MedadNewman | 1 comments | | HN request time: 0s | source
Show context
lxe ◴[] No.42891381[source]
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 ^
replies(2): >>42891427 #>>42891516 #
noman-land ◴[] No.42891427[source]
This is why javascript is so fun.
replies(1): >>42891685 #
dylan604 ◴[] No.42891685[source]
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.
replies(3): >>42892008 #>>42892324 #>>42893011 #
fmbb ◴[] No.42892324{3}[source]
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.

replies(1): >>42897155 #
1. ChocolateGod ◴[] No.42897155{4}[source]
> If users can break the censorship

Any user breaking the censorship likely knows already what the censor was blocking.