Most active commenters
  • dylan604(4)

←back to thread

Bypass DeepSeek censorship by speaking in hex

(substack.com)
755 points MedadNewman | 14 comments | 31 Jan 25 19:41 UTC | HN request time: 0.419s | source | bottom
Show context
lxe ◴[31 Jan 25 20:13 UTC] 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 ◴[31 Jan 25 20:17 UTC] No.42891427[source]▶
This is why javascript is so fun.
replies(1): >>42891685 #
dylan604 ◴[31 Jan 25 20:39 UTC] 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 #
atomicnumber3 ◴[31 Jan 25 21:07 UTC] No.42892008[source]▶
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.

replies(2): >>42892065 #>>42896679 #
1. teeth-gnasher ◴[31 Jan 25 21:11 UTC] No.42892065[source]▶
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?
replies(2): >>42892120 #>>42912330 #
2. dylan604 ◴[31 Jan 25 21:16 UTC] No.42892120[source]▶
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.

replies(2): >>42892455 #>>42896690 #
3. noman-land ◴[31 Jan 25 21:40 UTC] No.42892455[source]▶
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.

replies(1): >>42892731 #
4. dylan604 ◴[31 Jan 25 22:03 UTC] No.42892731{3}[source]▶
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

replies(2): >>42893031 #>>42899883 #
5. stevage ◴[31 Jan 25 22:26 UTC] No.42893031{4}[source]▶
Sometimes you do calculate prices client side. But you double check them server side.
replies(1): >>42893448 #
6. dylan604 ◴[31 Jan 25 23:05 UTC] No.42893448{5}[source]▶
That just feels like a "you're holding it wrong" type of thing, especially seeing how JS is held in such high regard for its floating point math accuracy.
replies(3): >>42893740 #>>42896737 #>>42897629 #
7. stevage ◴[31 Jan 25 23:33 UTC] No.42893740{6}[source]▶
Is that sacrcasm? Not sure what your point is.
8. wiseowise ◴[01 Feb 25 07:54 UTC] No.42896690[source]▶
Oh, wow. So you’re one of those. Disregard what I said in previous comment.
9. wiseowise ◴[01 Feb 25 08:07 UTC] No.42896737{6}[source]▶
Both Java and JS adhere to IEEE 754, what’s your point?

Sure it doesn’t have BigDecimal, but you’re not going to write HFT in JS either.

replies(1): >>42908403 #
10. wayvey ◴[01 Feb 25 11:35 UTC] No.42897629{6}[source]▶
Ints should be used for currency calculations most of the time
11. DonHopkins ◴[01 Feb 25 17:06 UTC] No.42899883{4}[source]▶
Jesus, you sound like the X11 fanatics I used to debate with about NeWS, long before anyone had envisioned Google Maps or coined the term AJAX for what we'd been doing with PostScript since the 1980's.

The NeWS window system was like AJAX, but with: 1) PostScript code instead of JavaScript code 2) PostScript graphics instead of DHTML graphics, and 3) PostScript data instead of XML data.

https://en.wikipedia.org/wiki/NeWS

NeWS – Network Extensible Window System (wikipedia.org) 86 points by stevewilhelm on April 12, 2016 | hide | past | favorite | 76 comments

https://news.ycombinator.com/item?id=11477565

ScriptX and the World Wide Web: “Link Globally, Interact Locally” (1995)

https://donhopkins.medium.com/scriptx-and-the-world-wide-web...

PizzaTool was a NeWS front-end entirely written in PostScript for ordering pizzas, that had a price optimizer which would immediately figure out the least expensive combination of pizza style + extra toppings for the pizza you wanted. (i.e. ordering an "Tony's Gourmet + Clams" was less expensive than ordering a plain pizza plus all the individual toppings.)

Source code:

https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt

Of course the untrusted front-end client side user input was sent via FAX to the back-end "server side" humans at Tony & Alba's Pizza, who validated the input before making the pizza, because performing input validation and price calculation and optimization in the back end end via FAX would have been terribly inefficient. (This was in 1990, long before every pizzaria was on the internet, and you could order pizzas online, kids!)

https://donhopkins.medium.com/the-story-of-sun-microsystems-...

Computers and networks are fast enough (especially now 35 years later) that it's ok to perform input validation twice, once in the front-end to make the user experience tolerably fast, and again in the back-end to prevent fraud. This is not rocket science, nor a new idea! It also helps if the client and server are implemented in the same language (i.e. JavaScript today), so you can use the exact same code and data for modeling and validation on both ends.

12. vitus ◴[02 Feb 25 13:11 UTC] No.42908403{7}[source]▶
Actually...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

13. atomicnumber3 ◴[02 Feb 25 22:06 UTC] No.42912330[source]▶
Did I say anything about access control? There's a big difference between "this has to happen server side for security reasons" and "this has to happen server side because our UI/client language is so hapless that it can't handle any amount of additional processing".
replies(1): >>42944191 #
14. teeth-gnasher ◴[05 Feb 25 05:24 UTC] No.42944191[source]▶
The entire thread is about access control…

JS is perfectly powerful, if you don’t know how to use it that’s a good learning opportunity.