💾 Archived View for vigrey.com › privacy.gmi captured on 2024-05-10 at 10:38:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
IMPORTANT: THIS IS NOT A LEGAL DOCUMENT. I AM NOT MAKING PROMISES. I'M JUST VOLUNTARILY STATING WHAT I'M DOING ON THIS HTTP/GEMINI SERVER IN GOOD FAITH FOR THE SAKE OF TRANSPARENCY.
Every request over the IP (Internet Protocol) contains the source IP address of the request. That's part of how the Internet is able to work in the first place. This means that all TCP/IP requests to the HTTP and Gemini versions of this site will include your IP address.
For visits to vigrey.com and www.vigrey.com, I do not store any of those IP addresses and do not physically look at the IP addresses. If you were to ask me to find a single IP address that has visited the site, I would only be able to point you to IP addresses that I have control of, because I already know those IP addresses and know that I visit my own site.
For visits to live.vigrey.com (my livestream server), the user's IP address (remote address) and user-agent string are used to determine if the user has valid access to my livestreams. This information is stored in RAM on a proxy I wrote to protect my Owncast server but is not intentionally written to disk. It is possible that this memory can be written to swap space, although isn't done intentionally. I do not know the IP addresses (remote addresses) or user-agent strings of anyone who visits my livestreams, whether they have access or not, and I went out of my way to write the proxy server in a way that makes it very impractical for me to learn the IP addresses (remote addresses) or user-agent strings of any visitors. With that said, the Owncast software might end up showing me viewer/chatter information like user-agent strings and IP addresses via the admin page, although I have not yet had either show up so far. Considering I have not looked through the source code of Owncast, I do not know if it will end up showing me that information.
While my HTTP/Gemini server is written from scratch, I use Nginx in a proxy layer so the site server can run on localhost ports as a non-root user. Nginx also handles TLS for the HTTP part of the site's server.
I set the "access_log" directive to "off" in the http section of my nginx.conf file. The "access_log" directive does not apply to stream servers (which I am using to proxy gemini requests from the outside internet to the localhost ports I am running them on) at the time of writing this. The "access_log" directive currently only works in the http section of nginx.conf with the version of Nginx I am using, so placing it in the stream server sections won't do anything at the moment as the stream server sections aren't able to collect access log data. The stream server sections are used for Gemini server support currently. This all means that the access log data is not stored on the harddrive.
I set the "error_log" path to "/dev/null" in my nginx.conf file. I also set a symbolic link from "/dev/null" to "/var/log/nginx/error.log" to prevent Nginx from writing any potential error data there. This means I am unable to see the error log data and the error log data is not stored on the harddrive.
Currently I do not track or store how many times a page or resource was requested. At some point in the future, I may want to add a "hit counter" to show how many views a particular page has gotten, but I haven't decided one way or another on that yet. If I do decide to track how many requests happen to pages, I will be sure to update this page. This page and others would have a hit counter on it as well, at least for the HTTP version of the site.
Every HTTP request includes some information, including whether the request method was a "GET", "POST", "DELETE", etc... request. This also includes data about the browser called the "User-Agent". For instance, the User-Agent of Chrome version 110 on Windows 10 64-bit edition is "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36".
I do not track or store the User-Agent of requests. With that said, I do have Nginx analyze the User-Agent of requests to determine if the User-Agent starts with the following Regular Expression pattern to return an HTTP 403 error.
(http\.rb\/\S+\s\(Mastodon|Pleroma\s|Akkoma\s|Misskey\/|gotosocial)
The reason for this is to prevent link previews on Mastodon/Pleroma/Akkoma/Misskey/GoToSocial from causing too much stress on this server.
The HTTP version of vigrey.com and www.vigrey.com do not use Javascript, although there is the chance that individual pages might use Javascript if the page exists ONLY in the HTTP version of the site and not the Gemini version of the site. Any page that uses Javascript will explicitly mention at the top of the page that Javascript is used.
An example of what might be stated at the top of a page would be something like "IMPORTANT NOTICE: Javascript is used on this page"
live.vigrey.com uses Javascript only if the visitor has access to see livestreams.