💾 Archived View for gemi.dev › gemini-mailing-list › 000804.gmi captured on 2024-08-19 at 02:08:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Privacy appears to be essential for Gemini users. A lot of discussions revolve around TLS, TOFU and how to prevent man-in-the-middle (MITM) attacks. There may be other attacks simpler to set up. Let's take an example: Alice visits Bob's gemini capsule. Nathan is a young NSA analyst assigned to this emerging Gemini thing. We assume Nathan has access to the tcp stream between Alice and Bob. The stream is TLS-encrypted (with the most recent TLS crypto). What can Nathan do? Nathan quickly builds a gemini spider/indexer program and starts collecting for all Gemini sites the accessible files as any user could do. On whether Nathan's spider respects robots.txt, your guess is as good as mine. Nathan finds that Bob's capsule contains 3 files (this is just an example!) which are 1KB, 5KB and 100KB large. Now Nathan looks at Alice's encrypted traffic with Bob's server. Just looking at the response sizes, Nathan knows what file(s) Alice has accessed and their content (collected during the indexing phase). No crypto, no MITM involved. Of course, with lots of files in Bob's capsule, the matching is less perfect, but it still leaks lots of information regarding what Alice read. This is easier for Gemini than for https because Gemini documents are precisely simpler. No keep-alive (or maybe I missed some recent Gemini development?), each file is loaded in its own request-response transaction. What countermeasures could we propose? I can think of a few more or less practical approaches:: 1. make sure the same file is never served with the same size - add random white space at the end of gmi / txt / html files, add random comments to pics, zip files, etc. 2. or add lots of "decoy" files (with all sorts of sizes) to your capsule. It will make life more difficult for the attackers, ... but also for the legit indexers. 3. Adopt a "twitter-like" approach: serve only fixed-size content. Serve only 8 KB gmi pages and 32KB pics (didn't Solderpunk have an experiment with fixed size pics?) Do you consider that this type of attack is far-fetched? To set them up, an access to the network is required (to log Alice transactions) - so typically an ISP (or maybe a 3-letter agency :-) - maybe also corporate IT, for a targeted attack against an employee. Or do you think the Gemini/TLS privacy expectations should apply only to non-indexable exchanges (CGI, user input)? This is not to say that TLS does not protect against attacks. At the moment the most obvious threat I can see that is really blocked by TLS is not against privacy but against _integrity_, e.g. in the example above, Alice's or Bob's ISP _injecting_ advertisement in Bob's reponse. Has any server author designed some sort of countermeasure against length-based attacks? Has it been already discussed?
Hi! Phil Leblanc <philanc at gmail.com> wrote: > Now Nathan looks at Alice's encrypted traffic with Bob's server. Just > looking at the response sizes, Nathan knows what file(s) Alice has > accessed and their content (collected during the indexing phase). No > crypto, no MITM involved. > > Of course, with lots of files in Bob's capsule, the matching is less > perfect, but it still leaks lots of information regarding what Alice > read. Firstly, most Gemini documents are (intentionally) pretty tiny, fitting within maybe 1 or 2 KB. This is not so big an issue. > What countermeasures could we propose? I can think of a few more or > less practical approaches:: > > 1. make sure the same file is never served with the same size - add > random white space at the end of gmi / txt / html files, add random > comments to pics, zip files, etc. > > 2. or add lots of "decoy" files (with all sorts of sizes) to your > capsule. It will make life more difficult for the attackers, ... but > also for the legit indexers. > > 3. Adopt a "twitter-like" approach: serve only fixed-size content. > Serve only 8 KB gmi pages and 32KB pics (didn't Solderpunk have an > experiment with fixed size pics?) 1) and 2) are too complicated (particularly with Gemini's spirit of being able to implement all major features in an afternoon) and 3) is just not backward compatible. > Has any server author designed some sort of countermeasure against > length-based attacks? Has it been already discussed? Length-analysis prevention is not Gemini's job, it's the job of TLS. And TLS does provide a mechanism to defend against it - padding. This works better for smaller files as it is then harder to distinguish between files of similar sizes. I don't know how OpenSSL and other common TLS libraries handle padding (I've read the TLS 1.3 RFC, and it seems that currently clients and servers have to opt into using padding, and the amount of padding and how it varies is implementation-defined), but we can definitely look into it, and perhaps provide recommendations for it in the Best Practices document (as seems to be what's happening with close_notify(), IIRC). Note also that for larger files which can be more easily profiled by outsiders, there is no good solution. Even with HTTP and other protocols, attackers can clearly distinguish between a significant data transfer (and can roughly measure its size), even across multiple packets. In conclusion, it's not Gemini's responsibility to handle these kinds of attacks. Some have suggested Gemini over TOR as a solution to prevent the more invasive attacks, but I haven't seen much development on that front. ~aravk | ~nothien
On Mon, Mar 8, 2021 at 10:35 PM <nothien at uber.space> wrote: > > Firstly, most Gemini documents are (intentionally) pretty tiny, fitting > within maybe 1 or 2 KB. This is not so big an issue. hmmm, with some form of padding yes. But without padding, I am not so sure. > > What countermeasures could we propose? > 1) and 2) are too complicated (particularly with Gemini's spirit of > being able to implement all major features in an afternoon) and I have seen many time this argument about complexity. I find it a bit fallacious (no offense intended!). The client or server is "not complex" because 99% of the complexity (TLS) is assumed to be already implemented in a library available everywhere (eg. OpenSSL). We could say in the same way that a modern HTTP client is not complex - and is an afternoon project - because LibCurl is available everywhere :-) > 3) is just not backward compatible. My point is not about the protocol. Just what the capsule owner and server software could do. > > Has any server author designed some sort of countermeasure against > > length-based attacks? Has it been already discussed? > > Length-analysis prevention is not Gemini's job, it's the job of TLS. > And TLS does provide a mechanism to defend against it - padding. This > works better for smaller files as it is then harder to distinguish > between files of similar sizes. I don't know how OpenSSL and other > common TLS libraries handle padding (I've read the TLS 1.3 RFC, and it > seems that currently clients and servers have to opt into using padding, > and the amount of padding and how it varies is implementation-defined), > but we can definitely look into it, and perhaps provide recommendations > for it in the Best Practices document (as seems to be what's happening > with close_notify(), IIRC). I didn't know about TLS padding. Thanks for pointing it out. I will definitely look into it. Has anyone already used it in this sort of context? Cheers Phil
Hi Nothien, > Length-analysis prevention is not Gemini's job, it's the job of TLS. > And TLS does provide a mechanism to defend against it - padding. You are perfectly right. The new "record padding" mechanism added to TLS 1.3 [1] is almost perfect for the job. Of course it doesn't protect servers which serve few large files, but for the typical small gmi files, it is perfect. [1] https://tools.ietf.org/html/rfc8446#section-5.4 Regarding support, It is supported by OpenSSL: see option 'record_padding' [2] [2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html As TLS 1.3 is not yet mandatory for Gemini, and as several server owners may not be interested by this privacy issue, I guess that record padding may not be part of Gemini specification. But I think it should at least belong to a "best practices" document. A recommended value could be 4,096 (all served files padded during transport to the next multiple of 4KB). Servers serving high volume of very small files (typically 0 to 2KB) could use 1,024 instead. Thanks again for the suggestion Phil On Mon, Mar 8, 2021 at 11:32 PM Phil Leblanc <philanc at gmail.com> wrote: > > On Mon, Mar 8, 2021 at 10:35 PM <nothien at uber.space> wrote: > > > > Firstly, most Gemini documents are (intentionally) pretty tiny, fitting > > within maybe 1 or 2 KB. This is not so big an issue. > > hmmm, with some form of padding yes. But without padding, I am not so sure. > > > > What countermeasures could we propose? > > > 1) and 2) are too complicated (particularly with Gemini's spirit of > > being able to implement all major features in an afternoon) and > > I have seen many time this argument about complexity. I find it a bit > fallacious (no offense intended!). The client or server is "not > complex" because 99% of the complexity (TLS) is assumed to be already > implemented in a library available everywhere (eg. OpenSSL). We could > say in the same way that a modern HTTP client is not complex - and is > an afternoon project - because LibCurl is available everywhere :-) > > > 3) is just not backward compatible. > > My point is not about the protocol. Just what the capsule owner and > server software could do. > > > > Has any server author designed some sort of countermeasure against > > > length-based attacks? Has it been already discussed? > > > > Length-analysis prevention is not Gemini's job, it's the job of TLS. > > And TLS does provide a mechanism to defend against it - padding. This > > works better for smaller files as it is then harder to distinguish > > between files of similar sizes. I don't know how OpenSSL and other > > common TLS libraries handle padding (I've read the TLS 1.3 RFC, and it > > seems that currently clients and servers have to opt into using padding, > > and the amount of padding and how it varies is implementation-defined), > > but we can definitely look into it, and perhaps provide recommendations > > for it in the Best Practices document (as seems to be what's happening > > with close_notify(), IIRC). > > I didn't know about TLS padding. Thanks for pointing it out. I will > definitely look into it. > Has anyone already used it in this sort of context? > > Cheers > > Phil
On Mon, Mar 08, 2021 at 09:59:53PM +0000, Phil Leblanc <philanc at gmail.com> wrote a message of 64 lines which said: > Now Nathan looks at Alice's encrypted traffic with Bob's > server. Just looking at the response sizes, Nathan knows what > file(s) Alice has accessed and their content (collected during the > indexing phase). No crypto, no MITM involved. This attack is well known and, for HTTP, documented in many articles. A general view of the problem and of countermeasures is "Peek-a-Boo, I Still See You: Why Efficient Traffic Analysis Countermeasures Fail" <https://cise.ufl.edu/~teshrim/tmAnotherLook.pdf>. > What countermeasures could we propose? I can think of a few more or > less practical approaches:: 4. The client could obfuscate the traffic with many gratuitous requests. See the excellent book "Obfuscation" <https://mitpress.mit.edu/books/obfuscation>.
On Mon, Mar 08, 2021 at 11:35:19PM +0100, nothien at uber.space <nothien at uber.space> wrote a message of 60 lines which said: > Firstly, most Gemini documents are (intentionally) pretty tiny, > fitting within maybe 1 or 2 KB. Fact-checking <gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi>: 50% of the Gemtext resources are 1,099 bytes or less > Length-analysis prevention is not Gemini's job, it's the job of TLS. TLS cannot do it alone, and this is why it is opt-in. Padding without knowledge of the application is dangerous. > In conclusion, it's not Gemini's responsibility to handle these kinds of > attacks. I disagree. > Some have suggested Gemini over TOR as a solution to prevent the > more invasive attacks, but I haven't seen much development on that > front. Gemini already works over Tor. 1) You can use a "torified" client or simply run an unmodified client with a wrapper like torify. Note that many exit nodes connect only to 80 and 443 which may be a problem (less exit nodes => less anonymity). 2) You can easily configure a capsule to run under .onion <gemini://gemini.bortzmeyer.org/gemini/onion.gmi>
On Tue, Mar 9, 2021 at 7:53 AM Stephane Bortzmeyer <stephane at sources.org> wrote: > > This attack is well known and, for HTTP, documented in many > articles. A general view of the problem and of countermeasures is > "Peek-a-Boo, I Still See You: Why Efficient Traffic Analysis > Countermeasures Fail" > <https://cise.ufl.edu/~teshrim/tmAnotherLook.pdf>. I wasn't implying length attacks are new :-) (just gave an example for people less familiar with the subject). Thanks for the interesting "Peek-a-Boo" paper link (It also includes several interesting references). I think it addresses a different problem (traffic analysis of an encrypted stream - ie. what information can we extract from an encrypted tunnel traffic). Length attacks on Gemini traffic are _much_ simpler and more efficient since (1) the traffic is composed of independent TLS transactions with one request and one response, and (2) responses are documents which a publicly available on the Gemini server (except for CGI and client cert-authenticated traffic). > 4. The client could obfuscate the traffic with many gratuitous > requests. See the excellent book "Obfuscation" > <https://mitpress.mit.edu/books/obfuscation>. This approach depends on what are the attacker's objectives. If they want to establish that you have accessed a specific sensitive document, the fact that you also accessed many decoys doesn't matter much - except if you accessed _all_ files and claim that you are in fact just indexing the site. Thanks for the Obfuscation book reference. Will try to have a look. Cheers Phil
On Tue, Mar 9, 2021 at 7:58 AM Stephane Bortzmeyer <stephane at sources.org> wrote: > > On Mon, Mar 08, 2021 at 11:35:19PM +0100, > nothien at uber.space <nothien at uber.space> wrote > > Firstly, most Gemini documents are (intentionally) pretty tiny, > > fitting within maybe 1 or 2 KB. > > Fact-checking > <gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi>: > > 50% of the Gemtext resources are 1,099 bytes or less Your stats.gmi page is a great resource for this issue (among others). Very cool! Thanks for making it available. > > > Length-analysis prevention is not Gemini's job, it's the job of TLS. > > TLS cannot do it alone, and this is why it is opt-in. Padding without > knowledge of the application is dangerous. > Given your current stats, the record padding value I suggested previously (4,096) would be enough to almost eliminate the risk for more than 80% of pages and significantly reduce the risk for more than 90% of pages. -- and we can agree that the one 903,321 bytes document _will_ probably be catched whatever the record padding :-) > > In conclusion, it's not Gemini's responsibility to handle these kinds of > > attacks. > > I disagree. I agree with you disagreeing! :-) but I think Nothien means it is not the responsibility of the Gemini _protocol_ to handle these attacks. It should rather be the responsibility of Gemini capsule owners to configure reasonable record padding for the typical documents they publish. So I think record padding belongs more to a best practices document than to the spec. Just writing this, I am wondering... with TLS 1.3, can the _client_ request record padding for the server response? I will check. If it can, at least a client could take the initiative and protect itself even if the server does no padding, Cheers Phil
Phil Leblanc <philanc at gmail.com> wrote:
> Given your current stats, the record padding value I suggested
> previously (4,096) would be enough to almost eliminate the risk for
> more than 80% of pages and significantly reduce the risk for more than
> 90% of pages. -- and we can agree that the one 903,321 bytes document
> _will_ probably be catched whatever the record padding :-)
Do you mean "rounding up" (by adding padding) all sent data to 4,096
bytes? I agree, that should do quite well to hide most Gemini data.
> > > In conclusion, it's not Gemini's responsibility to handle these
> > > kinds of attacks.
> >
> > I disagree.
>
> I agree with you disagreeing! :-) but I think Nothien means it is not
> the responsibility of the Gemini _protocol_ to handle these attacks.
> It should rather be the responsibility of Gemini capsule owners to
> configure reasonable record padding for the typical documents they
> publish.
Yep, that's what I mean. Thank you putting that to words neatly.
> Just writing this, I am wondering... with TLS 1.3, can the _client_
> request record padding for the server response?
Reading the TLS 1.3 spec[1], it appears not. Oh well.
[1]: https://tools.ietf.org/html/rfc8446#section-5.4
P.S: I've been thinking about all the issues we've come across with TLS,
and I've been collecting ideas for a new transport security protocol. I
know ~spc's stance on crypto ("get it approved by the crypto community,
make an implementation, then we'll talk"), and I'm not saying we should
switch to a magic protocol that doesn't exist; but that we should at
least consider making a wishlist of sorts of all the things that we
would want out of a "good" transport security protocol (if you have any
such ideas, please share them with me). I'll put up my crypto wishlist
sometime soon.
~aravk | ~nothien
On Tue, Mar 9, 2021 at 6:36 PM <nothien at uber.space> wrote:
>
> Do you mean "rounding up" (by adding padding) all sent data to 4,096
> bytes? I agree, that should do quite well to hide most Gemini data.
>
Yes. When record padding is configured to a value X, all sent data is
padded (of course before stream encryption) up to the next multiple of
X. So with record_padding = 4096,
a 1.5KB file is padded to exactly 4,096 bytes. A 5 KB file is padded
to 8,192 bytes.
A nice mechanism which is well suited to typical Gemini files
(according to Stephane Bortzmeyer's stats, 80% of pages are below
13KB).
> > Just writing this, I am wondering... with TLS 1.3, can the _client_
> > request record padding for the server response?
>
> Reading the TLS 1.3 spec[1], it appears not. Oh well.
>
> [1]: https://tools.ietf.org/html/rfc8446#section-5.4
Section 5.4 concludes with "Later documents may define padding
selection algorithms or define a padding policy request mechanism
through TLS extensions or some other means"
"Later documents..." So I guess, yes we are not there yet.
> P.S: I've been thinking about all the issues we've come across with TLS,
> and I've been collecting ideas for a new transport security protocol. I
> know ~spc's stance on crypto ("get it approved by the crypto community,
> make an implementation, then we'll talk"),
I think Sean Conner's statement is rhetoric or tongue-in-cheek :-)
Whether one likes it or not, Gemini IS built upon TLS. Period. That
ship has sailed. So I understand Sean (and others) want to limit
entropy in the mailing list
> (...) making a wishlist of sorts of all the things that we
> would want out of a "good" transport security protocol (if you have any
> such ideas, please share them with me). I'll put up my crypto wishlist
> sometime soon.
I will be happy to have a look at what you publish and share ideas -
but probably not about this topic in this mailing list... :-)
Cheers,
Phil
It was thus said that the Great Phil Leblanc once stated:
> On Tue, Mar 9, 2021 at 6:36 PM <nothien at uber.space> wrote:
> >
> > P.S: I've been thinking about all the issues we've come across with TLS,
> > and I've been collecting ideas for a new transport security protocol. I
> > know ~spc's stance on crypto ("get it approved by the crypto community,
> > make an implementation, then we'll talk"),
>
> I think Sean Conner's statement is rhetoric or tongue-in-cheek :-)
> Whether one likes it or not, Gemini IS built upon TLS. Period. That
> ship has sailed. So I understand Sean (and others) want to limit
> entropy in the mailing list
>
It's not completely rhetorical---it's to just shut up those what want
others to do the work. But I mean it---present a working proof-of-concept
that has passed the crypto community and by all means, it'll be worth
talking about then (mostly about hose easy it is to implement across a
variety of languages). Until then, it's TLS.
-spc (We've already had one "proof-of-concept" alternative crypto, but it
was rejected by the person who did it for further study ... )
On Tue, Mar 09, 2021 at 07:36:37PM +0100,
nothien@uber.space <nothien@uber.space> wrote
a message of 41 lines which said:
> I've been collecting ideas for a new transport security protocol. I
> know ~spc's stance on crypto ("get it approved by the crypto
> community, make an implementation, then we'll talk"), and I'm not
> saying we should switch to a magic protocol that doesn't exist; but
> that we should at least consider making a wishlist of sorts of all
> the things that we would want out of a "good" transport security
> protocol (if you have any such ideas, please share them with me).
There are two kinds of people who design security protocols: geniuses
(who don't need my advice) and people who overstimate their abilities.
Seriously, designing a secure transport protocol is *hard*. I repeat,
HARD. There are are many traps. One of the most important is that
failures are not obvious. If you create a program to display images,
anyone, even not an expert, can see if the program works or not. If
you create a security protocol, even experts may not be able to tell
immediately that there is a vulnerability.
And I don't even mention implementation, which adds its own risks.
On 3/9/2021 4:54 PM, Sean Conner wrote:
> It was thus said that the Great Phil Leblanc once stated:
>> On Tue, Mar 9, 2021 at 6:36 PM <nothien@uber.space> wrote:
>>>
>>> P.S: I've been thinking about all the issues we've come across with TLS,
>>> and I've been collecting ideas for a new transport security protocol. I
>>> know ~spc's stance on crypto ("get it approved by the crypto community,
>>> make an implementation, then we'll talk"),
NaCl? ;) https://github.com/cipriancraciun/gemini-experiments
>>
>> I think Sean Conner's statement is rhetoric or tongue-in-cheek :-)
>> Whether one likes it or not, Gemini IS built upon TLS. Period. That
>> ship has sailed. So I understand Sean (and others) want to limit
>> entropy in the mailing list
>>
> It's not completely rhetorical---it's to just shut up those what want
> others to do the work. But I mean it---present a working proof-of-concept
> that has passed the crypto community and by all means, it'll be worth
> talking about then (mostly about hose easy it is to implement across a
> variety of languages). Until then, it's TLS.
>
> -spc (We've already had one "proof-of-concept" alternative crypto, but it
> was rejected by the person who did it for further study ... )
>
Yes we have. A little over a year ago. Ciprian Craciun wanted to, and
most enthusiastically, proposed that we replace TLS with NaCl. He even
wrote a proof of concept to support and test it (above), which in the
long run wasn't really a viable solution, at least for Gemini protocol.
I've seen a lot of other folks come in proposing truly extensible
integrations, but extensible is usually antithetical to Project Gemini's
aims.
Now that Gemini is experiencing Logarithmic growth it seems that many
well meaning folks are dropping onto the list and proposing changes to
the specifications that have not only already been hashed out by both
consensus, but also practical trial and error feasibility studies in
actual practice.
NaCl didn't fly because it's a wonderful thing to build a better web
connection with, and if one actually considers those notions, it
translates into a very narrow deployment capability - even TLS has not
been without its issues in Gemini, Sean was fortunate due to his use of
the particular libtls, and for some things, even using his own
libraries, while Python presented some interesting problems that I'm not
sure all have been resolved. Other languages... the same. Some
implementations fare better than others, but still, one can actually
write a client or a server that provides basic Gemini protocol
compliance in a weekend or two that includes TLS (at least in IPv4).
It's not a lot to ask that someone implement rather than postulate what
is possible, can the suggestion actually yield services that adhere to
the basic premise upon which Gemini is prefaced?
If Orange is the new black, then Gemini is the new *show me* state. It's
a very simple concept, 'Is this a realy proposal? Where's the beef? Show
everyone the money, and that can be introduced along with a discussion
backed by demonstrated feasibility.
But before even that, we're talking about a very young project. It's
certainly not too much to ask, and yes it should be prominently posted
somewhere, to please review the archives because much of what is being
bantered back and forth lately are very much reruns of what those who
have already implemented production services have wrestled with.
Ciprian kinda just up and disappeared last spring following his NaCl
proposal. He even advocated for a versioning system for Gemini protocol
that included current stable, past stable, and I guess tomorrow's latest
and greatest extensible.... Wait! That would make Gemini like HTTP. It
was a valid excercise in building a prototype for a better web, and
that's just not Gemini. Sadly, I get the feeling that there are a lot of
folks that are chomping at the bit to contribute something in the realm
of protocol design here, but we're not buildng a better web through
Gemini - we never were.
Rohan was just mentioning to me the other day that he would still like
to see just two things canonized in Gemini. Accessibility support that
triggers what I have referred to as *noise* alerts -ASCII art (In fact,
I've already begun implementing an interim solution), and compression.
Me too. I want those things for users and clients, respectively.
The problem with compression however, is that it has been stated several
times that Gemini is intended (expected, rather) to deliver mostly small
files, but not so ubiquitously so in my case. i.e., I've been a SCO
partner for many many years and I'm one of the only places I know of on
the net where you can freely download ISOs of SCO 5 and 6, the kewlest
part about that, and one reason I don't want webproxies on my lawn, is
because I make those archives available exlusively via Gemini (Maybe
Gopher too, I'll have to check lolz). Point being, Vger gets a couple of
folks downloading old SCO .iso's every month, and it seems to go fine
without compression. Would compression be nice? - you betcha! but at
1Gbps it's not really that big of a deal - at least for now.
At this juncture the spec is being finalized, the time for wonderful
ideas as to how to handshake and secure connections has pretty much
passed, and judging by the evidence (check GUS or LUPA, Geddit, Manisha,
medusae.space, Sloam and gmisub just to name a few), Gemini is off to a
great start and Solderpunk has, as recently as a week ago, acknowldeged
that his child has now gone off to college as a young adult.
By the way, neither of those two things (Accessibility or gzip
compression) have anything to do with, nor have any place in
discussions, for spec changes.
One thing I would really suggest here for folks climbing on board the
Gemini train with new ideas - use Gemini first. We have a LOT of
resources, including several archives of this mailing list which you can
search through. Much of what people suggest lately are more often than
not already hashed out in the archives, which are easily searchable from
within Gemini space.
Well, just my thoughts on the matter. If you build it (and it works)
they will come, or you can talk about it, but that won't *make it so*
Commander Data ;)
I hope that helps :)
Kindest regards,
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
On Wed, Mar 10, 2021, at 1:51 AM, Bradley D. Thornton wrote: > The problem with compression however, is that it has been stated several > times that Gemini is intended (expected, rather) to deliver mostly small > files, but not so ubiquitously so in my case. i.e., I've been a SCO > partner for many many years and I'm one of the only places I know of on > the net where you can freely download ISOs of SCO 5 and 6, the kewlest > part about that, and one reason I don't want webproxies on my lawn, is > because I make those archives available exlusively via Gemini (Maybe > Gopher too, I'll have to check lolz). Point being, Vger gets a couple of > folks downloading old SCO .iso's every month, and it seems to go fine > without compression. Would compression be nice? - you betcha! but at > 1Gbps it's not really that big of a deal - at least for now. If you want to transfer files over an uncommon protocol that most people can't use, have you considered (S)FTP? Chrome dropped FTP support in version 88 and version 89 is the current version. (Personally, I'm amused by how FTP has become _indie_ in the span of a year or two. NNTP and Gopher threw a great welcoming party.) Also: why would you want to burden Gemini-client implementers with having to handle transfer encodings when you can just gzip (or .xz, or whatever the new hotness is) for small numbers of largish files? That sounds like a lot of server-writer-hours (implementing it) and client-author-hours (also implementing it) and server-admin-hours (turning it on for some files and leaving it off for others) for a tiny handful of users who can get manifestly better compression ratios by using an external compression program. I'd much rather have three more good (or even passable) Gemini clients _for OSs I'll never use_ than to have my favorite clients and servers all using a transfer encoding like gzip or brotli.
On 3/10/2021 2:53 AM, Nathan Galt wrote: > On Wed, Mar 10, 2021, at 1:51 AM, Bradley D. Thornton wrote: >> ...the kewlest >> part about that, and one reason I don't want webproxies on my lawn, is >> because I make those archives available exlusively via Gemini (Maybe >> Gopher too, I'll have to check lolz) > > If you want to transfer files over an uncommon protocol that most people can't use, have you considered (S)FTP? Chrome dropped FTP support in version 88 and version 89 is the current version. FTP is ubiquitous. What would be the point? And why would you suggest SFTP, when the standard is anonymous FTP? Some of those resources: ftp://ftp.osuosl.org/pub/archlinux/iso/ ftp://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ ftp://sunsite.icm.edu.pl/pub/ (https://sunsite.icm.edu.pl/ - most links point to ftp://) ftp://slackware.cs.utah.edu/slackware/ ftp://ftp.swin.edu.au/ For webhosting customers, I require that they use SSH - SCP, SFTP - but but those SSH methods are intended for the manipulation of files, while anyone can browse and download from anonymous FTP or Gopher (or Gemini) Although it is *theoretically possible* to enable anonymous SFTP, how would you do it without incorporating PAM or letting someone who has never visited before to leave the password field blank? In anonymous FTP the password field by historical convention is your email address, or some/any email address, like... billg@microsoft.com, although browsers do it a bit differently. Now, you can surely enable FTPS, but then we're back to that whole garbage situation about whether this is explicit or implicit, and in deciding between these two control ports, are we going to be using TCP 21 (explicit) or 990 (implicit), and data on 989, in a range between 3000-3050, or port 20 (implicit & active)??? I even confuse myself when I try to remember how to firewall the clusterbucket that are the FTPS'es. Good ole anonymous FTP is well known (You say uncommon) and 20/21 work just fine. The only problems I've had with FTP during the past 40 years were due to acoustic couplers or shitty phone lines. Gopher satisfies this easily with a single connection over port 70. And Gemini does the same thing w/TLS over port 1965. That sounds like a winner to me. I probably should [not] mention that it appears as if gophers:// may be doing the same over port 70 as well in many cases, in the not too distant future, but I might get flamed for even bringing that up at this time. Since I have taken it upon myself to mention that, port 70 is already registered and I personally like the idea of using that particular port for both gopher:// and gophers://. You're welcome anytime to access Vger through SSH or Telnet though. I actually do support that too. > > (Personally, I'm amused by how FTP has become _indie_ in the span of a year or two. NNTP and Gopher threw a great welcoming party.) Nathan, pardon me, but I'm getting the sense that you're seeing things through the lens of a world where everything should occur within the confines of Faceplant and InstaSpam running inside of a JSRE (JavaScript Runtime Environment) - which is exactly what you've pointed out that Chrome versions >= v88 have now effectively become... Which is also one of the big reasons that Project Gemini was spawned. As far as NNTP and Gopher are concerned, both Usenet and Gopher are alive and well, and enjoying a significantly relevant level of usage and traffic. For that matter, so is FidoNet - I'm still running the same node number I've had for the past 30 years (1:102/127). With the exception of the Google JSRE, SFTP, Gemini, and Good ole anonymous FTP, everything else mentioned is indeed *retro*, although that doesn't make those facilities non-relevant or insignificant, and they're actually thriving more now than any of them were ten years ago. > > Also: why would you want to burden Gemini-client implementers with having to handle transfer encodings when you can just gzip (or .xz, or whatever the new hotness is) for small numbers of largish files? It works fine now, and just like there will be a substantially greater presence of Gopher over TLS in the future, people who develop Gemini server and client software will innovate as well (there's been an awful lot of that in the past six months alone). Such innovations are inevitable - changing the spec is not even relevant in that regard, nor is it necessary. Please do note however, that in each of those FTP archives I posted links to above .iso images are *not*, as you encourage, tarballed. Nor are many of the other resources. Another nice thing about Gemini, Gopher, and FTP, is that in many clients you can actually view of the file types you're browsing right inside the client. I understand Google affected some changes to that in their JSRE prior to dropping support for FTP, necessarily forcing an external application load? Doesn't matter, moot point now anyway lolz. If you go back and reread what I wrote in my previous post, I'm not asking anyone to write or develop anything - I was simply musing. Like I just said, this sort of file transfer of repo data over Gemini works fine right now as it is. On another note, I am *still* encouraging the authors of Gemini client software to work towards a consensus for the handling of preformatted text blocks that people who are blind might consider to be *noise* - that's kinda a big deal to me, and Devin posted again just today on that important topic. Final thought: I haven't used Chrome at all in many years. Mostly Firefox, or Chromium, and surfing FTP repos continues to work just fine in Vivaldi too. I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On Wed, 10 Mar 2021 02:53:27 -0800 "Nathan Galt" <mailinglists@ngalt.com> wrote: > I'd much rather have three more good (or even passable) Gemini > clients _for OSs I'll never use_ than to have my favorite clients and > servers all using a transfer encoding like gzip or brotli. I concur wholeheartedly.
---
Previous Thread: [users] So you have a new capsule. You should let these services know…
Next Thread: [users] New capsule from sunny Barcelona: gemini://bcn08012.ddns.net/