> In particular, Gemini strives for simplicity of client implementation. Modern web browsers are so complicated that they can only be developed by very large and expensive projects. This naturally leads to a very small number of near-monopoly browsers, which stiffles innovation and diversity and allows the developers of these browsers to dictate the direction in which the web evolves.
...
> Experiments
suggest that a very basic interactive client takes more like a minimum of 100 lines of code, and a comfortable fit and moderate feature completeness need more like 200 lines. But Gemini still seems to be in the ballpark of these goals.
...
> Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based
"supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol.
It seems to me these goals could be achieved while retaining browser compatibility. Just define a strict, automatically verifiable subset of the modern web stack. This could be privacy-friendly, and support easy implementation, while making it enormously more approachable, no?
How does their transport protocol stack up against HTTPS/TLS? Is there unnecessary complexity that can be avoided by reinventing the wheel here?
I agree it would be nicer to have a subset of HTTP and HTML/CSS (not sure if JS could ever be made safe) but as cookies show, the simple fact that headers exist in HTTP and can be extended, makes it a privacy-problematic protocol from the start.
The transport protocol used by Gemini is protected via TLS, just like HTTPS. It has the great advantage that the only way for a user to identify itself is by using mutual TLS, which is basically the only 100% secure way to do it (the fact that it's impossible to use mutual TLS on the web tells a lot about the incentives going on there). Gemini absolutely does not re-invent the wheel here.
> In particular, Gemini strives for simplicity of client implementation. Modern web browsers are so complicated that they can only be developed by very large and expensive projects. This naturally leads to a very small number of near-monopoly browsers, which stiffles innovation and diversity and allows the developers of these browsers to dictate the direction in which the web evolves.
...
> Experiments suggest that a very basic interactive client takes more like a minimum of 100 lines of code, and a comfortable fit and moderate feature completeness need more like 200 lines. But Gemini still seems to be in the ballpark of these goals.
...
> Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol.