c58217da5962643b47fbfc156ab92c65
Gemini is Not for Privacy
Creative Commons Attribution-No Derivative Works 4.0gemini://
offers as much privacy as https://
, but it's widely known that because of how the Web technically works the latter does not ensure IP addresses do not leak to all sorts of sites (or data brokers); while moving away from http://
did in fact limit the visibility/exposure to one's ISP/s (unless they buy data 'downstream') the lingering issue is that unless one uses anonymity-preserving software (such as Tor) one's movements in cyberspace are still clear for many parties to see; Gemini resolves or tries to tackle only the problem of cross-site linking/embedding/scripting
TO avoid busting any bubbles in the future, based on a false expectation or baseless hopes, Gemini is in general not a privacy tool. It does address a plethora of issues plaguing the World Wide Web, but neither the Web nor Gemini should be treated as privacy protection tools. Even if you outsource to the Linux Foundation (Let's Encrypt), in which case privacy is eroded even further.
This Gemini capsule does not log IP addresses or use any fingerprinting techniques to identify users across visits. When you connect to the server for the first time, your IP address will be mapped to a sequential ID (in memory). This mapping will be forgotten one hour after the last request from the IP is received. If, during this hour, you request the standard robots.txt file, your session will be marked as a bot - this is just to give a (very very rough) method of tracking human vs robot visitors, all requests will be treated the same.
In other words, a "session" in the list below represents a single IP address making requests with less than one hour between them.
If the server process is stopped or restarted unexpectedly (or is under very high load), some stats may be delayed or lost.
"Bad requests" are any requests that result in a 59 status code being returned. These are things like malformed URLs, attempted directory traversal attacks, misguided http requests etc. These indicate either a bug (in the server or the client) or malicious traffic. If I receive an exceptionally large number of these (and they aren't caused by bugs in the server code) then I may decide to start logging the source IPs specifically for these requests (with a view to blocking or rate-limiting repeat offenders). Hopefully that won't be necessary!