Timeout handling

[wYhyzByH]

I love this app. But the annoying timeouts are a pain. As no response is given, the apps and browser are trying to fetch the blocked content, waiting for timeout, re-trying at least twice and often blocking the user interface in the meantime.
On firewalls it is common to send a TCP-reset or ICMP-unreachable (for UDP, ESP, and other protocols) to internal clients to prevent lengthy timeouts.
For ICMP I would suggest to send a type =3, code = 1 or 2 response.

Sending fake content is no good idea. It might break the app. But using standard IP protocol functionality can help to speed up the user experience and widen the acceptance of this app, e.g. to my wife.

For reference, you might want to have a look at:
https://kb.fortinet.com/kb/documentLink.do?externalID=FD36465
https://en.m.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_unreachable

[kasnder]

The idea with timeouts is to prevent apps from retrying to send requests right after failure, and thereby increase battery consumption.

I'd recommend excluding your browser from TC, and using an integrated tracking blocker for browsers instead. Those are more granular.

[wYhyzByH]

Thanks for your response.

The idea with timeouts is to prevent apps from retrying to send requests right after failure, and thereby increase battery consumption.

I disagree on the power consumption. If the user keeps the display on for 1 minute longer due to the app waiting for timeouts it consumes much more power then sending three packets that get dropped with a response and giving up within milliseconds.
A timeout will trigger a re-try the same way as sending a TCP-reset. An ICMP-UNREACHABLE should prevent retries.

I'd recommend excluding your browser from TC, and using an integrated tracking blocker for browsers instead. Those are more granular.

I agree, browser plugins would help, but does not solve the issue for apps.

[arkhi]

I was wondering the same thing; thanks @wYhyzByH for bringing that up.

I might be completely off‑topic, but as for browsers, wouldn’t sending an HTTP status matching the refusal work? Something like a 203 HTTP status or a 509 HTTP status, maybe?

[kasnder]

I was wondering the same thing; thanks @wYhyzByH for bringing that up.

I might be completely off‑topic, but as for browsers, wouldn’t sending an HTTP status matching the refusal work? Something like a 203 HTTP status or a 509 HTTP status, maybe?

That's a good idea, but browsers aren't really supported by TC. Better use a browser with an integrated tracker blocker. Gives much better results.

[arkhi]

I will look for browser tracker blocker, thanks.

Could specific HTTP status responses be useful for non‑browser HTTP requests?

[kasnder]

I will look for browser tracker blocker, thanks.

Could specific HTTP status responses be useful for non‑browser HTTP requests?

I'm sure that they potentially could! But the problem I see is that every tracker might handle this differently.