> On Dec 22, 2020, at 08:42, Stephane Bortzmeyer <stephane at sources.org> wrote: > > On Mon, Dec 21, 2020 at 11:10:46PM +0100, > Petite Abeille <petite.abeille at gmail.com> wrote > a message of 44 lines which said: > >> - Usually, a spec is not meant to mandate implementation >> details.. i.e. do that, don't do that... as it has no mean to >> enforce any of it... its role is rather to describe a normative >> interaction (the protocol) or format (text/gemini). > > In another way: the spec of a network protocol is here to allow > *interoperability*. Unilateral actions (such as logging) has no > influence on interoperability. Right. The specification should concern itself with interoperability. > >> - The gemini protocol is not well tailored to handle anything >> sensitive. > > Why? At least for privacy, it is certainly better than HTTPS. I'm not a security expert, so I will spare myself the embarrassment of articulating a cogent answer, but by "sensitive" I understood "secure". There are different aspects to security: data at rest vs data in transit vs data in use, etc. A threat model helps as well: https://blog.ivanristic.com/2009/09/ssl-threat-model.html In any case, all above my pay grade. Perhaps someone with actual expertise in this domain could help out. Privacy is something else altogether. > >> That said, Gemini could sport a set of recommendation and/or "best >> practices" in a companion document, such as "be mindful of what you >> log as it may contain sensitive information" and "consider using the >> underlying TLS mechanism for strong authentication". > > Good idea. A good example is RFC 8932. It is for DNS servers but its > method can be applied to Gemini servers easily. For instance, it > contains a very good and detailed discussion of IP addresses "anonymization". > > gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8932.txt Nice. > >> Guidelines for Writing RFC Text on Security Considerations >> https://tools.ietf.org/html/rfc3552 > > Or on the geminispace > > gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt Let's split the difference: https://portal.mozz.us/gemini/gemini.bortzmeyer.org/rfc-mirror/rfc3552.txt In general, would people prefer gemini links? or http ones? Accessibility is an issue. At this conjuncture, I do not have the proper tooling to systematically provide gemini links by default. > >> Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter: > > Since one of the goals of Gemini is privacy, I don't think that > relying on an US official document is a good idea. > This is a technical document, not a political pamphlet. Let's keep it that way. By the same account, avoid ARPANET and its decedents. A creation of the United States Department of Defense. Let's not be overly childish.
---
Previous in thread (11 of 25): 🗣️ Stephane Bortzmeyer (stephane (a) sources.org)
Next in thread (13 of 25): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)