From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Deprecate TLS1.0 support in emacs Date: Fri, 04 Aug 2017 15:50:30 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zibf5czd.fsf@lifelogs.com> References: <87o9sp7qok.fsf@gmail.com> <87zic9vk98.fsf@mouse> <87fue17mo5.fsf@gmail.com> <87tw2hvhob.fsf@mouse> <8760ex63hi.fsf@gmail.com> <87fue1v5lr.fsf@mouse> <87shi0tqh3.fsf@gmail.com> <87d18fwl66.fsf@gmail.com> <87tw1rihu0.fsf@mouse> <4037dc81-4245-6925-842a-2c84a5ba996d@cs.ucla.edu> <87pocfibky.fsf@mouse> <873798j2ij.fsf@mouse> <87h8xobg9p.fsf@lifelogs.com> <83lgmzyjon.fsf@gnu.org> <87y3qz79wr.fsf@lifelogs.com> <83vam3wfm7.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1501876291 22462 195.159.176.226 (4 Aug 2017 19:51:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 4 Aug 2017 19:51:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 04 21:51:27 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddid1-0005SO-OG for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2017 21:51:23 +0200 Original-Received: from localhost ([::1]:51728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddid8-0003S1-1B for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2017 15:51:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddicQ-0003Rl-Q1 for emacs-devel@gnu.org; Fri, 04 Aug 2017 15:50:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddicM-0005jC-Ob for emacs-devel@gnu.org; Fri, 04 Aug 2017 15:50:46 -0400 Original-Received: from [195.159.176.226] (port=33584 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddicM-0005iG-H3 for emacs-devel@gnu.org; Fri, 04 Aug 2017 15:50:42 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ddicD-0002t2-4Z for emacs-devel@gnu.org; Fri, 04 Aug 2017 21:50:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 76 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:8PtOo0EVsoH3Q1f7lv8WV3a0aEI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217305 Archived-At: On Fri, 04 Aug 2017 13:26:29 -0400 Stefan Monnier wrote: > On Fri, 04 Aug 2017 17:51:28 +0300 Eli Zaretskii 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 wrote: LI> Ted Zlatanov 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 wrote: MA> Ted Zlatanov 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 . ...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 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