Security Hole in Gemini Protocol?

Quick note

This post is tangential to a post I made a few weeks back.

I did see Alexey's response to this, and I think he made a valid point that an HTTP server could be kept simple. I guess I should have more clearly stated that I was talking about a fully compliant server, implementing every status code and minute detail of HTTP. That is my fault though. You sir, are right, given my original word choice.

On HTTP vs Gemini simplicity

The Potential Security Hole

Big Tech

Keeping in the vein of all the Gemini security discussions lately, I have thought of a potential way that Gemini could be exploited if Big Tech ever tried hard enough. I almost hesitated even to post this, for fear of Big Tech liking the idea and running with it, but I feel this is a conversation that needs to be had long before they even care about Gemini.

Specifically, an exception to this quote:

> In short, the Gemini protocol is so simple I think that it'll ultimately be impossible to be monetized with a high enough ROI to attract Big Tech. If I'm wrong there, then we can still have our own sandbox anyway after they break away.

Key phrase: high enough ROI. What enables the high ROI of 2022's web? Ads. How are the ads so lucrative? Demographic targeting. What is one way the web enables sites to know enough about you to target so well? Client side cookies.

Surveillance

Oh, silly Ainent. Gemini doesn't have cookies! No, but what is the one reliable way for you to cryptographically identify yourself to a Gemini server? Client certificates. Essentially unspoofable, as far as I understand it.

I can hear the counter argument: those are opt-in! It'd never work! Thing is, unless I have completely overlooked it, the opt-in nature of these is not required by the protocol itself.

Imagine a scenario where Big Tech does a massive marketing campaign in an attempt to mainstream the protocol. As part of their marketing, they could try to sell the idea of a Big Proprietary browser, or even add Gemini support directly into their existing web browser. Then they start a disinformation campaign to demonize the wide range of existing clients. Normies, naturally, would buy that without question, as they do. At that point, Big Tech could simply have their browser automatically generate a client certificate for every user and attach it to every request.

Couple this with some server side analytics aggregators, and we have the same privacy problems on Gemini that the web has.

Current Gemini Spec

To date, Gemini has 3 response codes that relate to client certificates:

60 CLIENT CERTIFICATE REQUIRED

61 CERTIFICATE NOT AUTHORIZED

62 CERTIFICATE NOT VALID

Gemini Specification

Notice that all of these codes are described in way that implies that the server is already expecting a client certificate for that request. What if there is a certificate attached when not expected? Unless I have missed or misinterpreted something, the spec does not account for this.

61 comes close, but that implies that a cert was indeed expected, it's just the wrong one.

Proposed Solution

Add 4th certificate status code, let's call it 63, to be returned in this scenario. It would not stop malicious or corporate servers from refusing ever to return this code, but it would at least allow users to see which sites are not trying to stalk them, because someone using Flashy Surveillance Browser would be shown this error anytime they visit an indie capsule.

Could this itself be exploited, though? I think so. Proprietary browsers could show a 'security warning' that the capsule they are attempting to access is ... insert scary corporate buzzword ... and that proceeding would be 'dangerous'. This, of course, would be total horseshit but the normies wouldn't know any better.

Closing

Does the spec already account for this, rendering my musings here moot? Can this proposed fix itself be further exploited in other ways? Is there a way to stop or mitigate the hypothetical 'security' warning?

Part of me says it is a bit too late in the game to be adding a brand new status code. On the other hand, we should be building technological barriers rendering it impossible to turn this space into that which we are avoiding.