Gemini privacy

[Phil Leblanc]

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