[ANN] Gemini browser for iOS

[Peter Vernigorov]

Thanks. These responses and re-reading the spec clarified my initial
concern. Spec clearly states that transient certificates should not be
shared across domains. And there is no point using permanent certificates
across domains as it is assumed that these certificates have a special
meaning for specific domains.

I am still unclear as to what happens after a transient certificate has
been created. Should browser automatically use it for the page that
requested it and any other pages on that domain? I don’t see a good
solution here. Either certificate is sent only when server requests it,
which would double number of requests (assuming user stays in private
section of the site), or certificate is always sent, which adds overhead to
all requests. Should browser remember which pages need a certificate and
always use it for them?

And additionally, should browser ask user for every page that requires a
certificate if existing one can be used?

Thanks for replying to my earlier questions. I want to make sure that my
support for certificates doesn’t violate the spec or creates a bad user
experience.

On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote:

> On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:
>
> > Question about client certificates: not sure how other clients implement
> > this, but I was thinking of generating and using the same client cert for
> > all sites, and giving an option to create a cert for specific domain.
> Does
> > that make sense? Potential problem I see is that main certificate is
> > something user could be identified by across websites.
>
> It's not super clear to me what you're suggesting.
>
> If it's that the client generates a single self-signed client cert the
> first time it starts up and then just sends that cert to every single
> host as part of every single request: PLEASE DON'T DO THAT!  This is
> about as wrong an implementation of Gemini's idea of client certificates
> as possible.  The vast majority of URLs will not require or expect a
> client cert (which is why there's a way for servers to explicitly
> request one in the unusual circumstance it's needed), and any you send
> will just be ignored.  You will be needlessly increasing the TLS overhead
> (which is already pretty heavy relative to typical text/gemini payload
> sizes) for no gain.  Worse, admins of unrelated servers would be able to
> compare their logs and track you across Geminispace.
>
> If it's that you generate a single certificate the first time it starts
> up but only send it out in response to a status code of 62 that's a
> different matter (I assume it goes without saying you shouldn't ever use
> it in response to a status code of 61 because the behaviour for
> transient certs is extremely clearly specced and this would fly in the
> face of just about every part of it).  I still think it's the wrong
> thing to do, but it's slightly less disasterous than the first option.
>
> Client certificates should be handled in a very deliberate manner - the
> user needs make the clear decision to opt in, on their own terms, to
> being identified to some server(s).  It's an exceptional condition and
> should never be automated or hidden from the user for the sake of
> convenience.  Sharing a single certificate across domains isn't
> something anybody should ever do lightly.
>
> Cheers,
> Solderpunk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/597d8546/attachment.htm>