[Spec] Spec (un)freezes and the spec's future

[Luke Emmet]

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