Hey everyone, Solderpunk at some point mentioned a temporary spec freeze, unfreezing for early 2021, then permanently finalizing the spec. I have no idea if this is still the plan or not, but I still feel it would be a good idea to discuss: what modifications would be made to the spec in an "unfrozen" period, if any; what modifications would be made to the spec in its permanent finalization stage; and how companion specs and the like would be dealt with, both now and in the finalization stage. Firstly, how spec changes should be approached in an unfrozen period, if any of those pop up. We may be in one now, since Solderpunk updated the spec to fix schemes? But at any rate, I believe most would agree that the current state of debate is probably not the best in terms of actually coming to an agreement. Not that you'll ever reach 100% consensus, but most current debates seem pretty evenly divided which isn't conductive to actually choosing a side to reflect in the spec. I'm unsure how to remedy this, but I'm bringing it up. On what changes should actually be made, in my opinion the only changes that should be made at this point should be to fix glaring problems in the spec. I guess that creates another problem, because people can't even agree what a "glaring problem" is! Solderpunk's been pretty reasonable, so I'll leave it up to them to actually decide what's a problem and what's not, but it's a rule of thumb to say that things that "would be nice" shouldn't be included at this point (I'm saying this as someone who has a few would-be-nices of my own[a]). As a second rule of thumb, I'd say no breaking changes, even if they do fix a problem in the spec. Backwards compatibility is painful, but luckily we only have a year and a half to deal with as opposed to the decades some projects have to be compatible with, so hopefully it isn't as much of a hardship as it possibly could've been. Onto a permanent spec freeze, if such a thing would occur. I believe making the spec totally immutable would be arrogant on our part, because you can't pretend that it is 100% perfect. I'd say that no feature changes, and few to no major changes in general should be made. I'd say that there should only be three classes of changes in a finalized spec: technological upgrades, clarifications, and error corrections. Technological upgrades would be if a component of the stack has an upgrade or a replacement, particularly when there's security involved. To use TLS as an example, it would be removing TLSv2 support when TLSv3 reaches wide support. Clarifications would be just that, clarifications of the spec in areas that are unclear or create ambiguity. Error corrections would be fixing minor errors and edge cases that can be fixed without breaking anything, and add no new features. This is breaking so wouldn't count, but an example of error correction would be the most recent spec change that adds a mandatory scheme to requests. Finally, I'd like to address companion specs. Especially if the spec is permanently finalized, there will be companion specs popping up all over the place. This can be viewed as good, because it means that each spec is nice and unix-y, doing only one thing each. This creates the problem the web has though, where authors are expected to support an amorphous and constantly changing group of specs and results in huge applications that are impossible to maintain. Even if companion specs like Titan are fine now, it leaves a huge opening for the web-ification of gemini in the future WHEN (not if) FAANG-inspired malicious actors take an interest in it. There are a few ways to address this, from the hardliner approach of completely disallowing companions to the 100% inclusive approach of creating a dedicated RFC listing. Obviously a middle ground will have to be found, but a discussion on where exactly that may be is warranted. You don't want to cut out useful things like titan, but you also don't want to leave a huge extensibility window open. A long rambling of my thoughts, but there's some discussion points (that in hindsight should've been broken up into multiple emails) that IMO should be addressed before any firm decisions are made regarding the future of the spec. ~nytpu [a]: https://lists.orbitalfox.eu/archives/gemini/2020/003748.html -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
On Sat, Dec 19, 2020 at 11:52:18PM -0700, Alex // nytpu <alex at nytpu.com> wrote a message of 113 lines which said: > On what changes should actually be made, in my opinion the only > changes that should be made at this point should be to fix glaring > problems in the spec. I guess that creates another problem, because > people can't even agree what a "glaring problem" is! The lack of any mention of IDN and IRI in the spec (and how to handle them) is certainly a glaring problem. We are in 2020, we start a completely new system, internationalization should not be an option. > Solderpunk's been pretty reasonable, so I'll leave it up to them to > actually decide what's a problem and what's not, The way, I understand it, Gemini's governance is basically "Solderpunk decides". This has good properties (it allows to keep the spec consistent, and it avoids the committee effect) and bad ones, too (when Solderpunk is busy with his relocation). But I agree that there is no obvious alternative. > As a second rule of thumb, I'd say no breaking changes, even if they > do fix a problem in the spec. Backwards compatibility is painful, I disagree here. I don't think that backward compatibility should be a goal.
It was thus said that the Great Stephane Bortzmeyer once stated: > On Sat, Dec 19, 2020 at 11:52:18PM -0700, > Alex // nytpu <alex at nytpu.com> wrote > a message of 113 lines which said: > > > As a second rule of thumb, I'd say no breaking changes, even if they > > do fix a problem in the spec. Backwards compatibility is painful, > > I disagree here. I don't think that backward compatibility should be a > goal. I agree with Stephane (as much as I might have hemmed and hawed over supporting IDN/IDI). If we don't fix this now, it will be *years* before it's fixed. Gemini is still a young protocol. -spc
On Sun Dec 20, 2020 at 11:12 AM CET, Stephane Bortzmeyer wrote: > The way, I understand it, Gemini's governance is basically "Solderpunk > decides". This has good properties (it allows to keep the spec > consistent, and it avoids the committee effect) and bad ones, too > (when Solderpunk is busy with his relocation). But I agree that there > is no obvious alternative. This is, indeed, pretty much the model. I admit it is in many ways far from ideal (although so-called "benevolent dictatorship" has a long and not unsuccessful history in the FOSS world), although it's far from clear to me what else can work well with a project that's supposed to be small and simple with a clear, finite scope. This model is clearly not sustainable in the long term (I might get hit by a bus tomorrow), but I think this is okay because I don't view this as a long term project. This is a "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away" kind of project. I have no interest in regularly adding new features or upgrading parts of stack. So, there's no need for stable long-term governance because at some point, and hopefully not too far from now, things will be "done". More on that point shortly... Cheers, Solderpunk
On Sun Dec 20, 2020 at 7:52 AM CET, Alex // nytpu wrote: > Solderpunk at some point mentioned a temporary spec freeze, unfreezing > for early 2021, then permanently finalizing the spec. I have no idea if > this is still the plan or not, but I still feel it would be a good idea > to discuss: what modifications would be made to the spec in an > "unfrozen" period, if any; what modifications would be made to the spec > in its permanent finalization stage; and how companion specs and the > like would be dealt with, both now and in the finalization stage. To be honest, I don't at this point remember precisely what I said previously, but my hope is still to have this whole thing finalised in the first half of 2021, and even better in the first quarter. I'm not sure there's much value at this point to establishing an exact schedule with clearly demarcated frozen/unfrozen states. The permanent freeze on non-trivial new features I announced several months ago is, well, still in place because that's what permanent means. There are a few issues under consideration right now (the IRI/IDN issue, a desire for clarity on "streaming" responses, and some finicky point about URLs which I need to remind myself of), and I'm preparing to start finally addressing these things during my time off between Christmas and the New Year (expect me to finally offer some thoughts on the IRI/IDN thing in the new few days). I don't envision anything else being given serious consideration. > Onto a permanent spec freeze, if such a thing would occur. I believe > making the spec totally immutable would be arrogant on our part, because > you can't pretend that it is 100% perfect. Things don't need to be 100% perfect to be useful. I think it's arrogant to *aim* for perfection. I know it's very much going against the grain to declare than any kind of software project is "done"; I know that people nowadays explicitly avoid using or recommending software for the sole reason that it is no longer being actively developed. I honestly think this is all very strange and backwards. If, after an initial busy development period of a year or so, each new release of a program does not come out after a longer delay than the last one, it probably means either the program is poorly designed and each fix or improvement introduces more problems than it solves, so it's doomed to be unreliable and/or inefficient forever, or else the program's scope is too wide or too poorly defined, in which case it is doomed to expand forever, growing ever more complex and featureful until it inevitably becomes poorly designed and faces the same fate above. There's no reason that network protocols with humble aspirations should be any different. Things can be "finished" and remain useful as-is for decades. Perhaps not forever, but certainly for decades. Gopher is a great example here. RFC 1436 is coming up on 28 years old now. There are very few changes/extensions to that specification which are so widely used in Gopherspace today as to be considered basically mandatory. All those changes are themselves at least 20 years old at this point, and they're minor enough that if the RFC were updated to include them, it would likely not grow in length by more than 10%, and 90% of the lines would remain unchanged. Despite this fossilised status, Gopher remains useful, in use and well-loved today, and is in fact undergoing a small resurgence. It's proof that if you keep things simple enough, you can get close enough to "right" the first time, which is very much what I'd like Gemini to achieve. It's true Gemini is more complicated than Gopher - but it's also, I imagine, been designed by a larger group of people over a longer period of time than Gopher was, and at this point has received non-trivial real-world testing. All of which is to say that I really do want to attempt a permanent spec freeze. I suppose I reserve the right to change my mind if cold hard reality proves me wrong, but for now I don't really want to bother making plans for how to handle this. > Finally, I'd like to address companion specs. Especially if the spec is > permanently finalized, there will be companion specs popping up all over > the place. This can be viewed as good, because it means that each spec > is nice and unix-y, doing only one thing each. This creates the problem > the web has though, where authors are expected to support an amorphous > and constantly changing group of specs and results in huge applications > that are impossible to maintain. Even if companion specs like Titan are > fine now, it leaves a huge opening for the web-ification of gemini in > the future WHEN (not if) FAANG-inspired malicious actors take an > interest in it. There are a few ways to address this, from the hardliner > approach of completely disallowing companions to the 100% inclusive > approach of creating a dedicated RFC listing. Obviously a middle ground > will have to be found, but a discussion on where exactly that may be is > warranted. You don't want to cut out useful things like titan, but you > also don't want to leave a huge extensibility window open. I don't see how completely disallowing companion specs is really possible. I could refuse to host them or to bless them as "official", but if they're popular enough, people will implement them anyway. Our strongest possible defense here, IMHO, is keeping the core protocol so easy to implement that there is always likely to be a wide variety of clients in popular use. That way, companion protocols cannot gain traction unless multiple independent client developers all agree they are worth supporting. Anything contentious is doomed to never achieve more than minority support. The wider the variety of clients in use, the harder it is for individual actors to push divisive expansions. This is really a two-part defense strategy. There's a technical part, addressed through the spec itself, which is to make sure that client implementation remains as easy as possible, but also a cultural part. The cultural part is to cherish diversity and encourage a DIY ethic. Cheers, Solderpunk
On Sun, Dec 20, 2020 at 9:58 AM Solderpunk <solderpunk at posteo.net> wrote: Things don't need to be 100% perfect to be useful. I think it's > arrogant to *aim* for perfection. Author: "I know there are some mistakes in my book; after all, it is 777 pages long!" Editor: "If you know there are mistakes, why don't you _fix_ them?" I know it's very much going against > the grain to declare than any kind of software project is "done"; I know > that people nowadays explicitly avoid using or recommending software for > the sole reason that it is no longer being actively developed. > "Some software is abandoned; other software is merely finished." --me (If you don't care about companion protocols and Dioscuri, skip the rest.) > Our strongest possible defense here, IMHO, is keeping the core protocol so easy to implement that there is always likely to be a wide variety of > clients in popular use. That way, companion protocols cannot gain > traction unless multiple independent client developers all agree they > are worth supporting. As someone whose proposed extension protocol has probably made the most noise, I would point out that Dioscuri clients and servers will typically
> On Dec 20, 2020, at 11:12, Stephane Bortzmeyer <stephane at sources.org> wrote: > >> the 100% inclusive approach of creating a dedicated RFC listing. > > This approach seems reasonable. This is what the christian church did, > after all, write a canon, a list of approved texts > <https://en.wikipedia.org/wiki/Biblical_canon>. Dogmatism aside, this sounds like a great, pragmatic, way to organize the inevitable. Cat Herders https://www.youtube.com/watch?v=m_MaJDK3VNE
As I wrote to Solderpunk before I subscribed to this mailing list, specs should add something about input logging : There is not any information about input logging. I think a page asking for a sensitive information must not log the user input. For instance if the page "/sensitive" returns a 11 code if there is no input, then it must not log inputs when there is one. The problem is if an application needs a user password, then even if the password is well stored, it will remain in plain text in logs. It would be better to have this: ``` 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 Password: 14 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 30 / 6 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 text/gemini 27 ``` instead of this (this output comes from a test done with jetforce): ``` 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 Password: 14 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?secret_password" 30 / 6 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 text/gemini 27 ``` Logging normal Input and not sensitive input can be annoying. **It can be considered to not log any input as an easier way.** Then all input can be considered as sensitive + sensitive inputs needs to prevent shoulder surfers in addition. Also, sensitive inputs should not remain in the client history if there is one.
As I wrote to Solderpunk before I subscribed to this mailing list, specs should add something about input logging : There is not any information about input logging. I think a page asking for a sensitive information must not log the user input. For instance if the page "/sensitive" returns a 11 code if there is no input, then it must not log inputs when there is one. The problem is if an application needs a user password, then even if the password is well stored, it will remain in plain text in logs. It would be better to have this: ``` 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 Password: 14 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" 30 / 6 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 text/gemini 27 ``` instead of this (this output comes from a test done with jetforce): ``` 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" 11 Password: 14 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?secret_password" 30 / 6 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 text/gemini 27 ``` Logging normal Input and not sensitive input can be annoying. **It can be considered to not log any input as an easier way.** Then all input can be considered as sensitive + sensitive inputs needs to prevent shoulder surfers in addition. Also, sensitive inputs should not remain in the client history if there is one.
> On Dec 21, 2020, at 22:30, Simon <gemini at g-n.site> wrote: > > As I wrote to Solderpunk before I subscribed to this mailing list, specs should add something about input logging : Two points: - 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). - The gemini protocol is not well tailored to handle anything sensitive. Perhaps best to avoid creating such situation in the first place. 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". Also, it is quite common for a RFC to sport a "security consideration" section: Guidelines for Writing RFC Text on Security Considerations https://tools.ietf.org/html/rfc3552 Actually, it's mandatory. Hopefully, Gemini will mature into a proper set of RFCs, with syntax grammar, security considerations, and all. Until then, the FAQ may be another place to park such consideration. Finally, The National Institute of Standards and Technology has a rather comprehensive document on the matter: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf Perhaps a bit overwhelming at first sight, but then again, nothing is as trivial as it seems.
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
> 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.
> On Dec 22, 2020, at 08:42, Stephane Bortzmeyer <stephane at sources.org> wrote: > > Since one of the goals of Gemini is privacy While at it, has this assertion been validated in any ways? Is Gemini actually private in any meaningful way? Just sticking a 'TLS' sticker on it a calling it done seem cavalier. Again, a bit above my pay grade, but between the small size of the user base, more or less static IP addresses, unique TLS variations, not to mention long lived TLS client side certificates, all forming a nice and easy digital fingerprint, Gemini could be a privacy minefield in practice. Has someone the tooling and expertise to weight in one way or another?
On Tue, Dec 22, 2020 at 10:07:11AM +0100, Petite Abeille <petite.abeille at gmail.com> wrote a message of 23 lines which said: > > Since one of the goals of Gemini is privacy > > While at it, has this assertion been validated in any ways? It is a *goal*. It does not have to be "validated". I did not say this goal was reached. > Is Gemini actually private in any meaningful way? AFAIK, there was no serious security/privacy evaluation of Gemini yet.
> On Dec 22, 2020, at 10:54, Stephane Bortzmeyer <stephane at sources.org> wrote: > > On Tue, Dec 22, 2020 at 10:07:11AM +0100, > Petite Abeille <petite.abeille at gmail.com> wrote > a message of 23 lines which said: > >>> Since one of the goals of Gemini is privacy >> >> While at it, has this assertion been validated in any ways? > > It is a *goal*. It does not have to be "validated". I did not say this > goal was reached. Perhaps worthwhile validating such aspiration, practically speaking, in the field. Otherwise, it sounds like a lot of empty words. I do not volunteer, as I don't have the skills. Anyone with such skillset? > >> Is Gemini actually private in any meaningful way? > > AFAIK, there was no serious security/privacy evaluation of Gemini > yet. That would be a valuable insight. PSA: Anyone around the gemini space with such expertise?
On Tue, Dec 22, 2020 at 09:40:42AM +0100, Petite Abeille <petite.abeille at gmail.com> wrote a message of 91 lines which said: > > 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. When, it comes to logging, there is no such thing as a purely technical document. Since surveillance is a big issue and a big concern on the Internet, logging is always very political. > By the same account, avoid ARPANET and its decedents. A creation of > the United States Department of Defense. Completely unrelated. We do not talk about a tool (which may be used in different ways) but about recommendations from an US agency. > Let's not be overly childish. Then, wise grown-up, tell me how to reconcile the US view "personal data are free to use" with the GDPR view "personal data are like plutonium, handle with care".
> On Dec 22, 2020, at 18:30, Stephane Bortzmeyer <stephane at sources.org> wrote: > > Then, wise grown-up Surely a case of mistaken identity :P > , tell me how to reconcile the US view "personal > data are free to use" with the GDPR view "personal data are like > plutonium, handle with care". International Safe Harbor Privacy Principles https://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles But in practice, they don't. This is why you end up with a data center in Dallas vs one in Frankfurt. There are various other complications, industry specific, such as healthcare and finance to name but two. Not sure where this leaves California.
Alex // nytpu <alex at nytpu.com> writes:
> Finally, I'd like to address companion specs. Especially if the spec
> is permanently finalized, there will be companion specs popping up all
> over the place.
An article I'm procrastinating on writing deals with companion specs;
maybe I'll even get it out the door one day. The tldr; is that they
shouldn't exist. The use of HTTP and its companions to implement any
arbitrary application is an aberration, and it shouldn't be looked at as
the norm for new/smol protocols. Applications should define a public
protocol that meets their needs, and people should choose applications
using those protocols. Don't build a forum on top of Gemini: spin up an
NNTP server[1].
Jason McBrayer/GCU Prosthetic Conscience
[1]: I'm actually pondering working on a successor protocol to NNTP -
email me directly if interested.
--
+-----------------------------------------------------------+
| Jason F. McBrayer jmcbray at carcosa.net |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it. -- Dogen |
On 21-Dec-2020 20:00, Simon wrote: > As I wrote to Solderpunk before I subscribed to this mailing list, > specs should add something about input logging : > > There is not any information about input logging. I think a page > asking for a sensitive information must not log the user input. > > For instance if the page "/sensitive" returns a 11 code if there is no > input, then it must not log inputs when there is one. > > The problem is if an application needs a user password, then even if > the password is well stored, it will remain in plain text in logs. > > > It would be better to have this: > > ``` > 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" > 11 Password: 14 > 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" > 30 / 6 > 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 > text/gemini 27 > ``` > > instead of this (this output comes from a test done with jetforce): > > ``` > 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" > 11 Password: 14 > 127.0.0.1 [30/Nov/2020:11:10:21 +0100] > "gemini://localhost/password?secret_password" 30 / 6 > 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 > text/gemini 27 > ``` > > Logging normal Input and not sensitive input can be annoying. **It can > be considered to not log any input as an easier way.** Then all input > can be considered as sensitive + sensitive inputs needs to prevent > shoulder surfers in addition. > > Also, sensitive inputs should not remain in the client history if > there is one. Hello The general problem is we cannot know which are sensitive URLs and which are not. All parameterised gemini URLs are shareable and linkable - and like HTTP GET requests, persistable, somewhat-cacheable and promiscuous. That is the normal state of affairs and why the hyperlink powers the internet. So if I have a URL gemini://host/endpoint?foo - tell me, is foo sensitive or not? The answer is we dont know. I can link to this from another website. In my opinion it was a mistake to add the status 11 which lends a false sense of security. The URLs creates are in no way distinguishable from other URLs. Passing a password in a URL is a terrible choice. Obviously a server might have some heuristics about what is probably sensitive, some end points might be more sensitive, some not. But there is nothing intrinsic to any URL that will indicate this. It is in my opinion bad design to build your app to use a password or other sensitive info on the URL. - Luke -- ______________________________________ Orlando Lutes http://www.orlando-lutes.com
On 21-Dec-2020 20:00, Simon wrote: > As I wrote to Solderpunk before I subscribed to this mailing list, > specs should add something about input logging : > > There is not any information about input logging. I think a page > asking for a sensitive information must not log the user input. > > For instance if the page "/sensitive" returns a 11 code if there is no > input, then it must not log inputs when there is one. > > The problem is if an application needs a user password, then even if > the password is well stored, it will remain in plain text in logs. > > > It would be better to have this: > > ``` > 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" > 11 Password: 14 > 127.0.0.1 [30/Nov/2020:11:10:21 +0100] "gemini://localhost/password?" > 30 / 6 > 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 > text/gemini 27 > ``` > > instead of this (this output comes from a test done with jetforce): > > ``` > 127.0.0.1 [30/Nov/2020:11:10:15 +0100] "gemini://localhost/password" > 11 Password: 14 > 127.0.0.1 [30/Nov/2020:11:10:21 +0100] > "gemini://localhost/password?secret_password" 30 / 6 > 127.0.0.1 [30/Nov/2020:11:10:22 +0100] "gemini://localhost/" 20 > text/gemini 27 > ``` > > Logging normal Input and not sensitive input can be annoying. **It can > be considered to not log any input as an easier way.** Then all input > can be considered as sensitive + sensitive inputs needs to prevent > shoulder surfers in addition. > > Also, sensitive inputs should not remain in the client history if > there is one. Hello The general problem is we cannot know which are sensitive URLs and which are not. All parameterised gemini URLs are shareable and linkable - and like HTTP GET requests, persistable, somewhat-cacheable and promiscuous. That is the normal state of affairs and why the hyperlink powers the internet. So if I have a URL gemini://host/endpoint?foo - tell me, is foo sensitive or not? The answer is we dont know. I can link to this from another website. In my opinion it was a mistake to add the status 11 which lends a false sense of security. The URLs creates are in no way distinguishable from other URLs. Passing a password in a URL is a terrible choice. Obviously a server might have some heuristics about what is probably sensitive, some end points might be more sensitive, some not. But there is nothing intrinsic to any URL that will indicate this. It is in my opinion bad design to build your app to use a password or other sensitive info on the URL. - Luke
Maybe we should move this thread if it continues, since it is not spec but recommendation. And actually, reading again the solderpunk answer: he told me that it is going on good practice and not spec. ^^' On 12/22/20 7:35 PM, Luke Emmet wrote: > > On 21-Dec-2020 20:00, Simon wrote: >> **It can be considered to not log any input as an easier way.** Then all input >> can be considered as sensitive + sensitive inputs needs to prevent >> shoulder surfers in addition. >> >> Also, sensitive inputs should not remain in the client history if >> there is one. > > The general problem is we cannot know which are sensitive URLs and which > are not. Then we agree on that ! I just wanted to show that we are easily thinking gemini input as HTTP GET parameters, but they aren't, even if they are passed in the URL. The only way to not deal with this server side problem, would be to not log any input.
December 22, 2020 1:56 PM, "Simon" <gemini at g-n.site> wrote: > The only way to not deal with this server side problem, would be to not log any input. Or just don't bother. If someone's building an application that takes passwords as Gemini input, that's their prerogative, especially with client certs being a first class citizen in Gemini. Just my two cents, Robert "khuxkm" Miles
On Tue, Dec 22, 2020 at 01:28:30PM -0500, Jason McBrayer <jmcbray at carcosa.net> wrote a message of 25 lines which said: > An article I'm procrastinating on writing deals with companion > specs; maybe I'll even get it out the door one day. The tldr; is > that they shouldn't exist. The use of HTTP and its companions to > implement any arbitrary application is an aberration, But what about "side specifications" such as robots.txt?
> On Dec 22, 2020, at 20:42, Stephane Bortzmeyer <stephane at sources.org> wrote: > > But what about "side specifications" such as robots.txt? Or "Implementation Recommendation" (aka lesson learned, ~faq, etc )?, such as IMAP4 Implementation Recommendations https://tools.ietf.org/html/rfc2683
On 22-Dec-2020 18:56, Simon wrote: > >> The general problem is we cannot know which are sensitive URLs and >> which are not. > > Then we agree on that ! > > I just wanted to show that we are easily thinking gemini input as HTTP > GET parameters, but they aren't, even if they are passed in the URL. > The only way to not deal with this server side problem, would be to > not log any input. Except - au contraire - they are indeed very like HTTP GET parameters, ticking the same boxes just like HTTP [x] part of the URL syntax [x] linked to a client UI behaviour [x] opaque, server-specific semantics [x] replayable when the link is shared elsewhere [x] largely indistinguishable from other elements of the URL submitted to the server (e.g. host/foo/bar ~ host/foo?bar) I know the web is officially persona-non-grata round these parts, but URL semantics are more or less common when using them for a distributed hypertext system of webspace or geminispace Regards - Luke
---