💾 Archived View for rawtext.club › ~sloum › geminilist › 006020.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Stephane Bortzmeyer stephane at sources.org
Tue Mar 9 07:54:00 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 withoutknowledge 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 clientwith a wrapper like torify. Note that many exit nodes connect only to80 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>