Cat's Arch

Privacy Policy

Tor | I2P

Last updated 2/11/26

Edit history

Beginning notes

I am not a lawyer, nor do I know any. I run this site and these services for fun so I'm not a business either.

This is intended to be an informal notice of how I handle privacy with my services for people who are interested and as fun exercise for myself to review and make those methods public.

Because of this it's not an exhaustive list and I'm only including things where there's something to specify. If I don't mention it here, I don't have it.

If you have questions then feel free to ask me about them! My contact info is in the footer.

^ Back to top ^

Important mentions

Both the data I collect during diagnostics and the non-identifying information collected during normal operations is never shared or sold, and never will be.

Identifying information collected during diagnostics will never be stored long term, at most one day. I don't want to have identifying information just lying around.

^ Back to top ^

Cookies

Normal operations

Cookies are only required for sites that have Anubis in front of it. Anubis uses two cookies that are used site-wide, meaning if you visit a service that has Anubis in front of it and then visit another service without Anubis you'll still send those cookies. The first cookie is valid for half an hour, this is used by Anubis to test that you accept cookies since a lot of bots don't. The second cookie lasts for a week and lets you bypass Anubis temporarily while it's stored.

Because I don't keep logs under normal circumstances, and when I do for diagnostics they don't they don't include cookies (see the logs section for more info), I can't use these to track you. However if you're concerned about these being used as an identifier then either see the note about bypassing Anubis below, or use a tool like Cookie AutoDelete to get rid of these after you leave the site. If you want to be more granular about what cookies you delete, only get rid of the techaro.lol-anubis-auth and techaro.lol-anubis-cookie-verification cookies.

Unfortunately these are required for Anubis to do it's job and the services behind it would be unusable for everyone without the protection it provides.

Anubis and it's cookies can be circumvented by accessing these through their onion service (Tor) or eepsite (I2P) links. See the list of services for those.

Some services can also use cookies to store user settings, these are completely optional.

During diagnostics

Nothing special is done with cookies during diagnostics.

^ Back to top ^

IPs

Normal operations

IPs are not logged during normal operations.

BaroMaster

When hosting a legacy Barotrauma server set to use BaroMaster, it's IP is temporarily stored as that's required to give it's connection info to clients. This is immediately removed when the legacy Barotrauma server is cleanly shut down, or upon the next request to BaroMaster when the respective legacy Barotrauma server hasn't checked in within 45 seconds.

This does not apply to normal clients, even those visting the BaroMaster page or using it with a legacy Barotrauma client. It only applies to legacy Barotrauma servers.

^ Back to top ^

During diagnostics

IPs mayed be temporarily stored in logs during diagnostics. As soon as I'm done diagnosing an issue they're deleted.

See logs for more info.


Logs

Normal operations

The webserver I use, NGINX, has all logs disabled[1] and any services that output data on what pages are being visited have logs disabled either through their configuration or in their systemd service with StandardOutput=null[2] and StandardError=null[3].

I do keep long term stats on things like how many requests each service has gotten, including the status code and what HTTP version was used. This isn't tied to any IPs or any information that could tell me who requested it. This data is made available to me by the NGINX virtual host traffic status module and logged by Telegraf into InfluxDB.

This helps me track how things are performing and pick up on scraping attempts without having to log any identifying information.

During diagnostics

In addition to the non-identifying information logged during normal use I also sometimes need to enable logs in NGINX or Anubis to help combat scraping, as finding counters to scrapers when I have no clue what I'm dealing with is near impossible.

As soon as I'm done diagnosing an issue logging is turned off and the log files are deleted.

^ Back to top ^

Notes about diagnostics

I never even wanted to even collect data for diagnostics, but unfortunately bad actors have made it no longer feasible for me to sit back and blind fire fixes since services will go offline under the pressure of their scraping. If you're one of those scapers, please stop.

Diagnostics are almost always a last ditch effort to try and figure out a solution to scraping. Because I can see request rates under normal circumstances I don't need to randomly start enabling seeing logs to get a guess I'm being scraped. Instead if I see a high request rate I use Anubis first, if that fails I add a few extra block blocking rules defined in NGINX on top of Anubis, and if that fails too then I finally check logs to see what's happening and try to figure out how to block the scrapers.

^ Back to top ^

Sources

^ Back to top ^