Messages about checking security appear misleading but maybe not

[dpk]

Is your feature request related to a problem? Please describe.

At least some of the time Anubis shows the message ‘Please wait a moment while we ensure the security of your connection.’ (translation string connection_security)

Is there something Anubis is actually doing that has to do with checking the security of the connection? There are other translation messages which seem to imply that a security check can fail (js_context_not_secure and js_context_not_secure_msg) but with a grep through the source, I wasn’t able to find anywhere where these are actually used. The connection_security message looks to appear in connection with the meta refresh challenge.

At Codeberg we’re concerned that this message is potentially misleading our users about what we’re using their CPU time and network resources for. We would prefer to be honest to our users, but I’m not sure about what actually happens here and whether something relevant to checking ‘security’ is actually going on. If there is nothing related to checking connection security here, as there doesn’t appear to be, I think this message should be changed to reflect what’s actually going on.

Solution you would like.

???

Describe alternatives you have considered.

No response

Additional context

No response

[Xe]

Hi,

Is there something Anubis is actually doing that has to do with checking the security of the connection?

Based on the presence of this message, I am assuming that you are using the meta refresh challenge.

Yes, there are a number of checks going on when that page is reloaded. They are all server side. You can confirm by the lack of a <script> tag in the page body.

The biggest things the server is checking is:

1. The client supporting gzip encoding (challenge pages are served at gzip level 1).
2. A client that is claiming to be a browser is in fact a browser by respecting the meta refresh directive.
3. The client waits for at least 75% of the time they are told to.

Due to the fact that browsers only support waiting for single digit seconds (IE: no millisecond waits like with the preact challenge) and out of an abundance of caution, the HTML template adds one to the amount of seconds the client is supposed to wait. I am looking at using JS to implement something more exact but I have not had the time to implement it at this time.

There are some more subtle checks in the works (ensuring that clients fetch the CSS, etc), but they haven't been stable enough to PR yet.

For very understandable reasons, this has not been documented very loudly.

Hope this helps.

[dpk]

So what is being checked at this stage has nothing to do with the security of the connection, but is just another way of warding off AI scrapers?

Would you accept a PR to change the message displayed in this case?

[eternal-flame-AD]

The client supporting gzip encoding (challenge pages are served at gzip level 1).

This is simply not true or some regression you failed to catch or some configuration that is not default. This obtains a plaintext challenge both in my lab and codeberg.org .

> curl -v --http1.1 -H "Accept: text/html" -H "user-agent: ChallengePlz/0.0.1 (NotAMozilla)" localhost:8923

* Host localhost:8923 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8923...
* Established connection to localhost (::1 port 8923) from ::1 port 38482 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: localhost:8923
> Accept: text/html
> user-agent: ChallengePlz/0.0.1 (NotAMozilla)
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Cache-Control: no-store
< Content-Type: text/html; charset=utf-8
< Refresh: 2; url=/.within.website/x/cmd/anubis/api/pass-challenge?challenge=e2ce04028e033790dd6b350daa2016731c87c1bb43dea8229b64e11d02ed1298a8e57389b1a0fcc3c980e74dad7816da97a02ffc543b5ae515220c1ecb30a144&id=019a899f-0488-752f-a585-f93eec648a48&redir=%2F
< Set-Cookie: techaro.lol-anubis-auth=; Path=/; Expires=Sat, 15 Nov 2025 22:23:51 GMT; Max-Age=0; Secure; SameSite=None
< Set-Cookie: techaro.lol-anubis-cookie-verification=019a899f-0488-752f-a585-f93eec648a48; Path=/; Expires=Sat, 15 Nov 2025 22:54:51 GMT; Secure; SameSite=None
< Date: Sat, 15 Nov 2025 22:24:51 GMT
< Transfer-Encoding: chunked
< 

Also it's 80% not 75%.

anubis/lib/challenge/metarefresh/metarefresh.go

Line 52 in 6c8629e

wantTime := in.Challenge.IssuedAt.Add(time.Duration(in.Rule.Challenge.Difficulty) * 800 * time.Millisecond)

[eternal-flame-AD]

Okay, this is the real logic , first off 1/64 failure rate is just a writeoff for any large scale scraping team who have proxy reliability problems and almost certainly have retry logic anyways. A defense that works for 1.5% of the time is just practically no defense.

Secondly, if you want to really get around of this property check 100% not a behavioral check, you can simply submit -H "Accept-Encoding: yesisupportgzip".

anubis/lib/http.go

Lines 215 to 219 in 6c8629e

	if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") && randomChance(64) {
	lg.Error("client was given a challenge but does not in fact support gzip compression")
	s.respondWithError(w, r, localizer.T("client_error_browser"), "")
	return
	}

But seriously .. this amount of engineering just hoping the scraper does not support gzip? If I were the scraper I would already support it because most residential proxies are billed by bandwidth not # of requests.

[dpk]

But seriously .. this amount of engineering just hoping the scraper does not support gzip? If I were the scraper I would already support it because most residential proxies are billed by bandwidth not # of requests.

Some scrapers (including Facebook’s) have turned off gzip compression in order to avoid being served zip bombs.

[Xe]

So what is being checked at this stage has nothing to do with the security of the connection, but is just another way of warding off AI scrapers?

This message is intentionally vague and intentionally phrased like other security products. Explaining the server side logic in detail is out of scope for a message that will be displayed to nontechnical users.

Would you accept a PR to change the message displayed in this case?

As long as it is reasonable and does not leak implementation details that will be ossified in translations.