4as / ChatGPT-DeMod

Tampermonkey/Greasemonkey script that hides the moderation results when communicating with ChatGPT.
GNU General Public License v2.0
382 stars 54 forks source link

doesn't work with new update #14

Closed OrionsBurst closed 1 year ago

OrionsBurst commented 1 year ago

with the new ChatGPT update DeMod is no longer working. after enabling it on tampermonkey no green box appears and when you say something that violates a content policy you will get the normal content policy error.

coolcoolcloud commented 1 year ago

Yes, I've encountered the same issue.

4as commented 1 year ago

It seems they've added an additional moderation checks. I'm currently investigating the issue.

Lefioty commented 1 year ago

I'm trying to back up old messages in multiple branches just in case. This process is tedious. Thank @4as for giving us good times.

FemboyCEO commented 1 year ago

Good luck on finding a fix @4as We love you!

fennecbutt commented 1 year ago

Just had a quick play, and it's because not only do they call the moderation API (now redundantly) but the /conversations event stream also returns moderation events:

{
  "conversation_id": "[redacted]",
  "message_id": "[redacted]",
  "is_completion": false,
  "moderation_response": {
    "flagged": true,
    "blocked": false,
    "moderation_id": "modr-[redacted]"
  }
}

Their client code then acts on it in "moderation_response" in G and calls a function with type=moderation (vs type=message). I honestly don't know why they even bothered, now they're making two moderation calls (the previous one separately, now another as a part of the streamed message events).

ProgrammerG4 commented 1 year ago

I just wanted to add that on Safari I still get the green box, but as others have said, I get the old "This content may violate our content policy" chestnut.

Good luck on finding a fix @4as. And if it's not possible, thanks for all the good times!

fennecbutt commented 1 year ago
if (fetch_url.indexOf("/moderation") != -1) {
  // Leave this the same as it already is, just add the extra else if from below
} else if (fetch_url.endsWith("backend-api/conversation") && is_on) {
  const parsed = JSON.parse(arg[1].body);
  if (parsed.supports_modapi) {
    console.log("Setting modapi support false");
    parsed.supports_modapi = false;
    arg[1].body = JSON.stringify(parsed);
  }
}
return original_fetch(...arg);

Lmao, this works. They enable moderation in the conversation api using supports_modapi. I was trying to hunt down where their onmessage function is used in the code but it's just so uglified and this fix is simpler. The event stream seems to be encoded in some way, so they're decoding it clientside, parsing the JSON and reacting to the moderation check. But with supports_modapi: false it doesn't seem to bother making the moderation check.

That doesn't mean they can't internally run all incoming conversations thru the check if they really want to, but this does turn off the annoying client-side warnings again.

I'll leave @4as to integrate a proper fix in their current style unless they want me to open a PR for the small change (there's a lot of extra stuff around intecept counts etc in there that I couldn't be bothered with for now).

BumpDrafting commented 1 year ago

Yeah I hope you fix it soon

buraca27 commented 1 year ago

@4as or @fennecbutt please make an updated version

4as commented 1 year ago

Although changing 'supports_modapi' to false works as @fennecbutt suggested, I'm actually torn whether to add this change or to look for a way to remove the results, rather than modifying the API request calls. It would be trivially easy for OpenAI to track anyone who is changing what they're expecting to see on their end. Anyone who already messed with their API knows they are quick to send warning emails about any unauthorized changes to their requests. Currently having your messages flagged through this new mod API does not leave a permanent mark in your conversation, so modifying the results would be the least intrusive way to block moderation. On the other hand, even if it seems like they're not marking them permanently, they might be marking them on their side when leaving 'supports_modapi' enabled... So, should I modify the request and disable 'supports_modapi' or should I modify the results to clear any warnings and allow new API to function? Well, this is already taking too long to investigate, so I'm going to push an update that disables new API. Let's hope this won't cause any warning emails.