KiwiFlare

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Mobile, VPN through Netherlands, Safari.

1. This morning with the new "cryptographic" kiwiflare message, it would just loop endlessly. One kiwi tab open. I cleared browser data for kiwifarms, re-logged in, and now appear to be accessing fine so far, no delays or loops, straight to page.

2. Generally speaking, since KF was knocked offline last fall, on mobile I've only been able to access using Netherlands-routed VPN or (sometimes) VPN-less with a US IP. US/Japan -routed VPN only hangs. Nvm. That was still true as of the weekend, but I tested just now with US VPN before complaining, and naturally it finally succeeded. Leaving this comment only in case it provides any useful general bits of info for you as to how the setup has behaved. To test, turned off Neth, turned on US, opened a new (second) kiwi tab, same browser, and fyi not even a flash of the flare page, went straight to page. Was able to repeat. I also tested via Japan and it was slower to show and load, but I did get to the homepage; also no observable flare page.

Hope that's useful but either way, "you're doing amazing, sweetie." No, really - thanks.
 
Nvm. That was still true as of the weekend, but I tested just now with US VPN before complaining, and naturally it finally succeeded. Leaving this comment only in case it provides any useful general bits of info for you as to how the setup has behaved. To test, turned off Neth, turned on US, opened a new (second) kiwi tab, same browser, and fyi not even a flash of the flare page, went straight to page. Was able to repeat. I also tested via Japan and it was slower to show and load, but I did get to the homepage; also no observable flare page.
Are you using OpenDNS with your VPN by any chance?
 
infinite cycling of kiwiflare tests, saying work accepted then reloading and challenging me again on mobile. can't get through. one tab, swiss domestic ip and no extensions. ios if that's important <3
 
Issue with brave on mobile, turned off shield and closed all taps and still can’t get through. Getting the same endless loop with no access in between. Using Netherland vpn and safari is fine
 
Flare appears quite often on mobile, even so that I start to feel myself kiwiflarephobic because DDoS protection seem to pozload my VPN riddled internet neghole, period.

(... okay it's actually not appears that often and I've made this commentary just to appear in random.txt and site's header messages.)
 
This update was the first one that actually fixed the looping/recurring interloper screens for me. Thx jersh
 
infinite cycling of kiwiflare tests, saying work accepted then reloading and challenging me again on mobile. can't get through. one tab, swiss domestic ip and no extensions. ios if that's important <3
Issue with brave on mobile, turned off shield and closed all taps and still can’t get through. Getting the same endless loop with no access in between. Using Netherland vpn and safari is fine
Can you guys figure out how to go into the Developer Console with CTRL+SHIFT+I (as in Ivan) and then go to Application -> Cookies -> and DEL the sssg_clearance one?

I honestly can't figure out what the issue could be. It's the most simple thing in the world. When you see "work accepted" that means the KiwiFlare returned an OK with a set-cookie header and that should be the end of it.

VPNs and public networks will not impact this because it's token based and not IP baed.
 
did not send me a verification email from KiwiFarms. Is there a problem? I checked my email and I didn't receive anything.
 
Mobile
VPN through Netherlands or USA
Safari
One tab open

Just an endless loop of Kiwiflare. Turning off VPN doesn’t solve it, nor closing/reopening Safari or restarting phone.

Brave browser works fine, with Kiwiflare between screens half of the time.
 
Kiwiflare passes challenge verification, hangs on loading with:
ERR_HTTP2_SERVER_REFUSED_STREAM
It loads every time I click on something.
Tried the following countries: USA/Worst Korea and Worst China (ROK and ROC).
Time out on route in GTT in the US.
In Korea/China it seems to be timeout with Korea telecom/Chunghwa Telecom to the west coast.

Onionsite unaffected aside from "Response is not JSON".
 
  • Like
Reactions: Dona Morte
I'm sort of wondering if there's a time desynchronization problem at play. I'm not sure if there's anything in the code that would be using the browsers time and causing problems if it differs from server time. Obviously Date.now is UTC milliseconds but if the user's clock is somehow wrong.

But then again I haven't even seen a double Kiwiflare since the most recent changes.
 
  • Thunk-Provoking
Reactions: Vecr
Mobile
VPN through Netherlands or USA
Safari
One tab open

Just an endless loop of Kiwiflare. Turning off VPN doesn’t solve it, nor closing/reopening Safari or restarting phone.

Brave browser works fine, with Kiwiflare between screens half of the time.
Do you have some type of aggressive cookie blocking going on?
 
I honestly can't figure out what the issue could be. It's the most simple thing in the world. When you see "work accepted" that means the KiwiFlare returned an OK with a set-cookie header and that should be the end of it.

VPNs and public networks will not impact this because it's token based and not IP baed.
Whats the validation process for the cookie? i.e is it some signed data, or does it get used as a key for a database lookup?

If its the latter, what's the write concern of that database? Some databases will return from the write function before it's actually committed to disk, or perhaps youre facing a replication delay where that data is trying to be fetched on a different servers but hasn't replicated over yet.
 
Whats the validation process for the cookie? i.e is it some signed data, or does it get used as a key for a database lookup?

If its the latter, what's the write concern of that database? Some databases will return from the write function before it's actually committed to disk, or perhaps youre facing a replication delay where that data is trying to be fetched on a different servers but hasn't replicated over yet.
It's a UUID that's the session token. The database is absolutely not the issue, the 3 second wait is designed to eliminate that. There is a 0% chance that the 1mcg write time is causing the problem.

I'm sort of wondering if there's a time desynchronization problem at play. I'm not sure if there's anything in the code that would be using the browsers time and causing problems if it differs from server time. Obviously Date.now is UTC milliseconds but if the user's clock is somehow wrong.

But then again I haven't even seen a double Kiwiflare since the most recent changes.
If that was the issue, KiwiFlare's API would reject the solution and you would see red dots with an error.
 
I cannot, following your exact instructions.

The issue you're encountering has been fixed. I specifically adjusted the throttling so that initial loads would not inherently surpass the authorization token.

The only thing I can imagine is that I didn't deploy this update on a specific service, so I am going to go ahead and manually rebuild and redeploy the latest code on every frontend.

This message was posted after the redeploy. If you're STILL encountering this issue, let me know.
While the previous patch didn't fix this particular issue, the current one does.
However, the issue still happens intermittently on mobile browsers, but I'm unable to spot any patterns as of now.
- Changing between VPN endpoints doesn't help.
- 1 tab open only.
- No extensions, tried various browsers to the same effect.
- Site loads, but skimming through pages triggers the challenge again after ~3 pages. Happens much less on threads without chat.
- Letting it sit for 1-2 minutes after solving the challenge before browsing fixes the issue.

In any case would it be a good idea to place additional info on the footer the KiwiFlare page, such as:
The reason for issuing the challenge (no clearance received vs the invalid/rate-limited token that was received), to better reason at which end the process is failing,
And the node ID handling the request, to spot patterns with flaky mobile networks constantly changing routes.

This would be helpful for mobile devices which lack the dev tools to check if the correct cookie has been actually sent, or has been over-aggressively cleared due to memory/privacy concerns.
 
Last edited:
  • Thunk-Provoking
Reactions: Vecr
I've updated KiwiFlare. You may notice a second step where it actually verifies the session to make 100% sure it's actually available.

I've also (hopefully) improved logic for checking bad sessions so fewer legitimate sessions get thrown out.
 
I've made an update to KiwiFlare and I am hoping that sessions are now more stable. If you encounter challenge cycles, please let me know.

If you are reporting an issue, I need as much detail as possible, and at least the following:
  • What country is your endpoint? This means where you're connecting from - either domestic IP or VPN.
  • How many Kiwi Farms tabs do you have open when this occurs?
  • Do you have any extensions that could potentially block cookies?
  • Does the browser infinitely re-challenge you without loading the site, or is it loading the site once between challenges?
Hi Josh! I'm unable to connect over a domestic IP from the US. I can reliably connect over VPN in the Netherlands. It's only one taberooni trying to get to the front page on my laptop. This domestic IP is through Lumen who likes to be a little bitch and not play nice. It sucks, because my background tabs don't like to cooperate with the VPN due to the location switch. The only extension I have is an ad blocker, but I whitelisted the Farms. I know when Lumen isn't getting along with KiwiFlare/KiwiFarms I just get a slow load page and receive a cannot be loaded screen. There is no KiwiFlare challenge at all. I know then I have to turn on my VPN to get on or the site is completely down because of server issues or a possibly an attack.
 
Hi Josh! I'm unable to connect over a domestic IP from the US.
1683210568036.png

 
Back