What the eff Is Gemini?
gem.ajroach42.com
gem.ajroach42.com
See also a longer form writeup of similar issues: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...
My response the last time your post was here: https://news.ycombinator.com/item?id=30067400#30068447
The first one is obvious: Gemini is supposed to be simple and not evolutive. TLS fits neither points.
The second one is more philosophical
From the article: "The big deal is that the modern internet sucks. It started as something to share knowledge, and quickly became a platform for survielance and exploitation". Gemini was created in reaction to that.
Now, think of what https really is for, what drove its adoption, and why the modern web needs it. And that's e-commerce! The biggest use case by far is so that you can safely send your credit card number to pay for stuff. In the early days, that's almost exclusively what it was used for. Google for instance strongly pushes for https everywhere, what do you think it is for? Your privacy or for commercial transactions?
Now, think about how to keep the commercial activity that lead to the modern web out of your little community. Ban encryption, do not mandate it! No encryption means no credit card numbers, no passwords, no accounts, no access control, you will get something that it hardly exploitable, and therefore less likely to be tainted by the "modern web". If you just want to share knowledge, there is no point hiding it with encryption.
But what about privacy? Well, you achieve that simply by not putting private information on a public network. And if you really want privacy, for example because you are about to share or browse sensitive or illegal data, then TLS is quite limited. There are networks that are explicitly designed for that use case, such as FreeNet, these are a much better option than using an encryption scheme that was primarily designed to facilitate e-commerce.
But what about shielding my behavior from snooping? Like my DNS queries, the web sites I visit.
I would also like to be able to identify myself and have others do so, with some assurance that nobody is impersonating me or them.
These are cases where I do want to, and must, put private (meta-)information on the public network.
And also, why would you want to identify yourself? AFAIK, Gemini is very limited in term of uploading: there are no forms or PUT requests. The only reason I can think of would be access control, but that's something I would rather not have.
On the server side, TLS only guarantees you that you are on the right server, but not that it is the right content, that part would be better served by something like a PGP block. Another advantage of using these kinds of digital signatures is that it wouldn't force additional complexity. It is just text: the server don't have to care about that, verification can be made client-side.
No, it's keeping the ISPs from spying on, blocking, and adding advertising to any and all data they can get into.
> Well, you achieve that simply by not putting private information on a public network.
You have no idea what information will become sensitive in a few years.
"If you're not doing anything wrong, you have nothing to hide" fails because I don't know what I'll eventually need to hide.
As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks. But if you want a technical solution to still be able to post what you think is or may be sensitive in the future, then, TLS is probably not the right solution. Hacker News uses TLS for instance, and it won't help me at all if one of my comments gets me some unwanted attention, I am sure my username alone is enough to get back to me for someone with enough motivation.
They can block it or they can let it through unmodified. They can't keyword-filter it and add advertisements to it.
> it is limited in term of spying prevention (metadata are still available)
Granted. However, "Your customer connected to this IP address" is much less marketable than "Your customer is reading information about stew recipes" and much less actionable than "Your customer is reading information about encryption and is therefore a traitor" and so on.
> it does prevent tampering by ISPs, but I think that part would be more effectively achieved with digital signatures (ex: PGP blocks) that not only prevents tampering by ISPs, but also by someone who controls the server or by forgers.
Digital signatures only guarantee that the data is from who it says it's from (which Gemini doesn't enforce because it specifies TOFU) and that hasn't been modified. They don't protect against spying, for advertising or any other reason. They also still rely on a cryptographic library, which undermines your point about how Gemini shouldn't be burdened with the complexity of TLS or SSL.
> As for information you share that will become sensitive, yes sure, but if you think that, don't publish anything at all on public networks.
Here, I'm not talking about what I post but what I access and read. It seems like you want to give everyone the ability to snoop on who uses the library and for what, and I have a hard time not attributing nasty motives to something like that.
Transport encryption just shrinks the number of people at the party of eating the pie of your personal data. The pie still gets eaten, just by different people. And still without your consent. And absolutely nothing is done about it.
The only tangible benefit I see from this “encryption everywhere” (which by the way mostly got triggered in the industry by Snowden files) is three letter agencies being forced to be more creative when dealing with mass-vacuumed data. Undeniably a good thing, but far from total hallelujah.
If a Gemini server I connect to somehow has tracking, yes, that will track me. However, the threat I'm talking about is ISPs tracking me, which TLS protects against. It's interesting that people seem to be unwilling to see that even as a topic, and keep veering off into other discussions.
Could you supply some references about the issue which would document the ISPs tracking the users and selling their data ?
I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
How big is really the problem we are paying all this worldwide complexity tax for ?
How big is the problem we're paying the complexity tax of envelopes for letters for?
Certain things should be expected, culturally, and it should be a big deal if that expectation is breached. It should not be breached casually, and there should be a distinct boundary which must be penetrated in order to breach that expectation. Privacy in communication is one of those things.
Only encrypting the "sensitive" stuff marks you out as someone who we should keep an eye on, since you do things you encrypt, you're more "sensitive" than normal, upstanding people, eh? What are you hiding? How long will we have to keep you at the station to get the real answer out of you?
Also, if most traffic isn't encrypted, it's easier for ISPs to get various ideas. It's also easier for the courts to get ideas about expectations of privacy, which is an important concept under the law: Is unencrypted traffic in plain view? Why not? It isn't encrypted. Is it prima facie evidence of wrongdoing to encrypt traffic, if most traffic isn't encrypted? Why not? Why do you go to the trouble?
Finally:
> I remember of only one case of some operator in the US injecting some html, which promptly caused a massive shitstorm and they stopped. In my ~30 years of internet use, I have never seen the ISP messing up my internet connection, other than the captive portals (which now simply block me when they expire).
Given the massive uptake of HTTPS, I think I can come up with an explanation of why this is, and a prediction of what would change were HTTPS to be dropped.
So let me share what I know on why the encryption everywhere skyrocketed, and hopefully it is useful for anyone. It’s long and has some detours, to convey my point (which is outside the simple “encryption is good”/“encryption is bad” dichotomy) better.
In 2014 Snowden released the famous papers about the NSA snooping.
Following that, the IAB (the Internet Architecture Board in IETF, not to be confused with Interactive Advertising Bureau), prepared a statement here: https://www.iab.org/2014/11/14/iab-statement-on-internet-con... - which specifically mentions https://www.rfc-editor.org/rfc/rfc7258 also quickly prepared during that IETF meeting.
“Let’s encrypt”, although pre-existing, was publicly announced at the same time: https://en.m.wikipedia.org/wiki/Let%27s_Encrypt
And due to its simplicity and being free of charge you can see the stats counting up pretty happily, and it is the reason behind the current abundance of TLS: https://letsencrypt.org/stats/
In parallel, the above mentioned statement also helped ensure the http/2 and later being fully encrypted with very little being exposed. However, I return to this later in (X).
This is the factual real reason behind: the widespread agency surveillance, the revelations of which was the straw that broke the camel’s back.
There were always “evil ISPs mangling the traffic”, but they were never enough a big deal (because as I said - it’s just few disjointed industry anecdotes, and you haven’t given any factual references otherwise).
With the stated goal of encryption in transit being a barrier against the state pervasive mass surveillance - it arguably was a successful measure and I am willing to say the complexity is worth the goal.
It still doesn’t change the fact that the endpoints (and due to complicated nature of HTML/JS/CSS - much more than your expected endpoints) have the full access to your data under the encryption.
So my viewpoint is your OPSEC should not change on whether there is transport encryption or not - there were and they are the actors collecting your data; they are just different. If you specifically become an object of interest for the government, your data will be copied and analyzed. And the endpoints will be subpoenaed for the decrypted data/metadata. Pretending now things on the web are magically “secure” without these caveats is not responsible towards the users who don’t know better. Even the TOR, which is strictly stronger measure than a simple transport security, has caveats: https://tor.stackexchange.com/questions/7339/what-metadata-d...
(And I am not sure whether a simple img src on an .onion site to a non-onion source will leak your real IP these days but it was a valid attack vector at some point).
In that regard it can be argued that if your OPSEC is “trust as if all the data you send is being monitored by all possible adversaries”, then absence or presence of the encryption doesn’t matter much, and it is what the proponents of “no encryption” are saying.
(X) there is a reason involving the “evil ISP sniffing the traffic”, which http/2, formerly known as QUIC, tackled: and this is about the protocol evolution. The early internet protocols were fairly easy to snoop and man-in-the-middle with, and this gave the grounds for two kinds of devices:
1) “tcp protocol optimizers” for connections with crappy UX like satellite (huge RTT)
2) bandwidth policers. Pervasive use of poorly written p2p file-sharing apps by the internet users clogged the pipes for the ISPs, and made the more “polite” TCP traffic used by the vast majority of the users perform much worse - so it was a question of their service continuity to do something.
Since then, LEDBAT working group at IETF has tackled that at the protocol level, but something had to be done “in the moment”, and there were companies who made a good money on selling these kinds of boxes.
These both were a fairly widespread practice probably all the way before 2010, and made it almost impossible to do any modifications to plaintext internet protocols without breaking some faulty assumptions by the deployed middle boxes and thus making said evolutions impossible to deploy. (A small, much more obvious example is the widespread usage of transport-leaves NATs prevented the deployment of SCTP at internet scale until (too late) when it got UDP encapsulation…)
So, while technically it is the “ISP meddling with the traffic”, it was done for a completely different set of reasons. (As for the ISPs doing Lawful Intercept - it didn’t go anywhere with the advent of the encryption, see https://en.m.wikipedia.org/wiki/Communications_Assistance_fo...)
(Edit: formatting).
I think what the author meant by this is that there can be code embedded on an HTML/JS page that sends data to third parties, tracking you. HTML/JS also has cookies and numerous other features that can be used to track you.
Gemini has none of this - you ask a server for a Gemini document, you get a document, there are no cookies or JS-style embedded code involved.
> But what about privacy? Well, you achieve that simply by not putting private information on a public network.
Gemini supports client-side certificates - so you can "privatize" your capsule or a portion thereof if you want.
Gemini could have a really cool niche as a protocol which supports a lot of weird and wonderful systems, allowing them to be more useful and fostering a community interested in that stuff, but the TLS requirement completely prevents that.
I'd love to write a Gemini client for System 6 for example, but that just isn't feasible.
I guess my problem is partly that Gemini isn't useful to me, but even more broadly I don't understand who it's really useful for at all.
To give an example, thanks to its simplicity the IRC protocol was used for a lot of weird and creative things besides chatting. On the top of my head: bootstrapping P2P networks, controlling botnets or as a generic pubsub broker.
I suggested using "insecure-gemini" as the URI scheme name for the non-TLS variant of Gemini.
You could have TLS and non-TLS service on the same port number, since I think that it can be distinguished from the first byte received from the client. However, TLS service programs that I have checked do not seem to have this capability.
Sorry no links, I just read about it when I was semi-active in Gemini but never bothered to follow up.
> What Gemini is doing, is saying “we don’t need no videos, images, stylesheets, nor JavaScripts, because we want to have a lightweight web experience, so we throw all that crap out!”. Fine, sounds great. But why does it require a new protocol for that? Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
[0]: https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst...
> Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
- So Google/Microsoft doesn't ruin it.
- So you don't need to rely on huge applications basically emulating operating system functionality at this point with millions of LOC and opportunities for vulnerabilities just to publish some text or links.
- So you don't need to really rely on any application at all. `openssl s_connect` will get Gemini pages in a text file just fine if/as needed.
- Gemini's line format is easy to parse for scripts.
Google/Microsoft/etc are already shifting away from the web as we know it to HTTP/3. Once their money making properties are all QUIC/udp based it won't be long before they start depreciating tcp HTTP/1.1 support "for security" reasons. And from a megacorp/institutional/for-profit point of view that makes perfect sense.
>So you don't need to really rely on any application at all. So you don't need to rely on huge applications. Gemini's line format is easy to parse for scripts.
HTTP/1.1 can serve these same functions as Gemini with immeasurably broader support. As the commercial web switches to HTTP/3 the demographic left will reflect these aspirations.
It does not have to have immeasurably broader support or use standard protocols. Gemini's protocol is orders of magnitude simpler than any version of HTTP ever was and gemtext is far simpler than any version of HTML. Not everyone has to like it. Installing a gemini client is such a low barrier anyway for those that want to try one.
So ... because TCP-based HTTP/1.1 might be deprecated on major browsers in the future ... then it's great that Gemini has it's own browsers (optional), application-level protocol, and port, and that it doesn't currently depend on existing HTTP infrastructure?
"Just use HTTP" is something I've thought about, and the idea does have merit. Python includes an HTTP server, so for getting a site up in less than a minute, it's a thought.
I'm not sure how easy it is for a browser to recognise and render new content type. I imagine it's quite difficult.
I guess I have something in mind like "gopher, but fixed".
some comments
- Gemini don't want to fix the Web, it wants to be something else entirely
- Gemini is deadly simple, so simple that anybody with basic programming skills can write a client for it or a server. Even if nobody will use them, it's still a good exercise and you can implement the full standard not a limited subset of dubious usefulness because basically no web site will render correctly
- Gemini makes search engines an affordable problem space again
- Gemini is not trackable client side, but not necessarily ad free, just a different kinds of unobtrusive ads (I sketched some ideas)
- Gemini is very old school, it doesn't allow anything that's modern and flashy and that's its atrentgh, a subset of HTML will always be rendered on the usual big 3 browsers, it takes too much discipline to not abuse of it
- the protocol is what makes Gemini independent, by the virtue of not being subject to any external "standard committee" 100% controlled by the usual suspects
- Gemini is not cool, and that's great for some like me
HTTP is messy, but does have some helpful features, such as the "Content-Length" response header (if it is known; it might not always be known but if it is then it would be helpful to include it), and range requests.
I also have idea how you could serve files in any format and be able to specify a response header to interpret it (and/or linking to alternative representations, perhaps using the existing "Link" header) if the client software does not already have that capability. (The end user should also be able to configure their own interpreters, which override those specified by the server, if any.) In this way, you can use Gemini files, as well as various picture formats, audio/video codecs, etc.
But I love the small, human-scale web idea and I'm glad there continues to excitement around Gemini.
My take
Kinder: an updated Gopher
Snarkier: a technical solution to a social problem
I have a capsule hosted privately on my desktop, for speedier access. The SDF site often runs slowly.
Setting up the whole TLS security stuff is a chore, mind and will likely take awhile if/when I upgrade my system.
One thing I do have is a proxy server that serves gemtext files as gophermaps. It's a pretty simple perl script, and I've ironed out most of the bugs. That took a little while, because there were a lot of corner cases to get right.
There's an alternative protocol called Spartan, which is very very similar to Gemini, but without TLS. I wrote a little Spartan server in Go, so when I want to get an internal site up quickly, I can just "go run sss.go" and bam, there we are. I think there's also another protocol, called Mercury, that is Gemini without the TLS. I haven't heard much about it, though.
I guess ultimately it doesn’t matter, Gopher has more content, more services, and more users.
You mean like Lynx?
I don't get it. Why can't you just realize "I am not interested in Gopher" and move on?
I would say the name is rather unfortunate in the sense that any search will lead you first to the NASA program and zodiac signs.
I don't have any problems with TLS; one probably already has OpenSSL around. More or less TLS is too big (in popularity) to fail - there are smaller implementations like BearSSL too. If it really is an issue, one has a perfectly fine protocol removing the TLS wrapper; it won't be Gemini though.
gemini is a simple easy to understand protocol.
simpler then http? a specification of which I can put in this comment?
http: a bunch of newline separated key=value pairs followed by a double newline everything else is the content.
The philosophy of Gemini seems to be that it's not enough that people can create Gemini's austere's experience with the web, but that everyone must be forced to conform. I guess "punk" has lost all of it's meaning.
One thing I like about smolweb stuff, including Gemini, is that they really aren’t being gatekeepers. Sure, they have strong opinions (and they encode them in protocols) but it comes off like a DM trying to make a good campaign.
Alternatively, use the flying spaghetti codebase monster duopoly, also known as Chromium and Firefox.
Being satisfied with expressing oneself within technological limitations has never been "punk."
Punk is pushing a system to its bleeding edge, breaking it, undermining it, using it in ways it was never intended for and not giving a damn about keeping things tidy. The web in all its hypercomplex madness and ugliness is far more punk than Gemini is even capable of being. Gemini doesn't even allow site authors control over the design or layout of their content - that's entirely implemented by the browser.
Punk is rebellion against authority and systems of control, while Gemini is rebellion against freedom and the imposition of control for the sake of ascetic minimalism. Punk is anarchy, while Gemini is orthodoxy. It gets points for being anticapitalist, though.
Of course not. End users should have control of their experience. Why should someone else get to control what my software does on my machine? Why should some designer somewhere be the authority? I'm going to pick the fonts and colors and styles I want.
Seems like a pretty punk-rebellious attitude to me.
For the same reason someone else gets to control the layout of a magazine you buy. The browser is yours, but the page you're accessing is not. It is the creative expression of someone else, why should they not have the right to express themselves freely? Why are you insisting on absolute creative freedom and editorial control over other people's property?
I mean, ignore javascript entirely. Why should someone publishing to Gemini not be able to set the background and font on their site? Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
>Seems like a pretty punk-rebellious attitude to me.
You're view is literally rebelling against other people's freedom because what they do might not suit your tastes, and you don't feel others should have the right to violate your sense of aesthetics. Wanting to control everything isn't punk, it's textbook authoritarianism.
But I doubt we're going to see eye to eye on this.
It does seem unlikely - our perspectives are so different! - but it's an interesting conversation. Thank you for engaging.
You seem to be conflating the concepts of property ownership and copyright. We're not disagreeing about the idea of controlling other people's property, but about whose property it is.
The magazine example is a good one: the publisher owns the masters, and retains the copyright, but the copy of the magazine - the physical object I bought - is no longer the publisher's property, but mine, to do with as I please. If I want to mark it up, cut it up, or dust off my decades-obsolete paste-up skills and entirely redo its layout, that's my right as the owner of that copy of the magazine.
The same is true on the web. The original page, on the server you own, certainly is your property: but when I visit your site, and my browser downloads a copy of the page, that new copy, stored and processed on my computer, belongs to me. You retain the copyright, but you do not own the copy, and I am free to munge its bits in any fashion that suits me, because I own it.
> Why should someone publishing to Gemini not be able to set the background and font on their site?
It would be contrary to the purpose of the medium. It's like complaining that a haiku magazine won't publish your sonnet, or a podcast site won't host your videos; that might well be a fine thing to do, but this is not the place for it.
> Gemini doesn't even allow even the tiny bit of individualism offered by the old web.
Yeah, it's maybe less like the old web and more like "what if the old plain-text Internet, and the BBS scene before it, had developed into a hypertext medium?"
This is a webdev's idea of what HTTP is
I got around that in my (deactivated) site with some ascii art and unicode glyphs.
Most capsules are quite distinct with regards to these elements.
IMO, I'd much rather have a web that is anticommunist. The gatekeepers today act quite a bit like a politburo and the "content" that is allowed feels a bit like Pravda's editors were involved.
You realize one of the goals of capitalism is to replace all public services with private, for-profit ones?
The only things I think are worth paying for digitally are art, games (which I guess are art), and services. But I'm not paying a license for a text editor, for example. Running proprietary code feels... subpar and janky, I guess?