Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 04 Aug 2017 13:26:29 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

> On Fri, 04 Aug 2017 17:51:28 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
>> IMO, it isn't right to display notifications there from a program that
>> runs in the foreground.  Too far from user eyes, too.

SM> Agreed.  This functionality is for use when Emacs wants to notify the
SM> user about something happening elsewhere than where the user is
SM> currently focused.

I respectfully disagree. Notifications don't have an implicit user
attention scope. They are posted no matter where the user is focused,
typically in a globally shared area of the screen to make them easy to
notice and consistent in appearance.

On Fri, 04 Aug 2017 17:02:45 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I would suggest these possible actions:
>> 
>> * don't warn me about this site anymore and proceed (whitelist)
>> * don't warn me about TLS 1.0 issues for (dropdown: 1 day, 3 days, 1 month)
>> * don't warn me about this site for (dropdown: 1 day, 3 days, 1 month)
>> * proceed this once
>> * blacklist site as long as it uses TLS1.0; abort connection; never notify
>> * blacklist TLS1.0 globally; abort all such connections; never notify

LI> But this is approximately what the NSM does now...  Or do you mean that
LI> the message in the echo area should be clickable, and that would bring
LI> up the normal NSM dialogue?

That's what I mean, yeah :) We're just doing the user interaction in a
modeless transient window instead of a modal dialog that disrupts the
user experience. Is that possible?

On Fri, 04 Aug 2017 16:59:00 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Right. I would implement the fallback inside `notifications-notify' and
>> let the user customize that, so Emacs can have a central dispatcher for
>> general notifications (as opposed to log messages).

MA> Please not in `notifications-notify', this function has a defined
MA> scope. There are packages which provide a broader notification
MA> interface, like sauron <https://github.com/djcb/sauron/blob/master/README.org>.

...but nothing in Emacs does :) That's sort of where I was going.

Do we write our own? Could we use notifications.el and add new functions
there? Do we try to add sauron to the core?

On Fri, 04 Aug 2017 13:29:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> As for the other action (silence the warning) I wonder if it's really
SM> needed: if the mechanism is discreet enough, it's just as easy for the
SM> user to "filter it out as noise".

>> Sorry, I don't understand what you mean.

SM> if the user feels so bothered by the warning to want 6 different
SM> choices (with 3 additional sub-choices for some of them), then we
SM> already failed because the user is already annoyed.

Those choices I proposed would be in a modeless notification window, not
in a modal dialog. So there is much less friction and distraction.

SM> Instead I think that the warning should be just sufficiently visible
SM> that the user who's interested will notice it, but sufficiently
SM> unobtrusive that the user who doesn't care can just "filter out".

That's a good goal, and offering choices in a transient notification
window is in line with it.

Ted