Video download link | md5sum c58217da5962643b47fbfc156ab92c65 Gemini is Not for Privacy Creative Commons Attribution-No Derivative Works 4.0

Summary: gemini:// 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.

In the video above I show Billsmugs' capsule, which boasts an extensive photography collection, albeit also tracks access with caveats stated clearly upfront. To quote:

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!

In our case, logs are only used for DDOS protection and mitigation (some days we get over 30,000 requests, most of them from bots). The code we developed for it is Free software and AGPLv3-licensed (in our Git repository). ⬆