[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network security manager

From: Ted Zlatanov
Subject: Re: Network security manager
Date: Wed, 19 Nov 2014 06:17:59 -0500
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

On Wed, 19 Nov 2014 09:37:08 +0100 Lars Magne Ingebrigtsen <address@hidden> 

LMI> Ted Zlatanov <address@hidden> writes:

>> http://www.w3.org/TR/wsc-ui/#indicators and
>> http://www.w3.org/TR/wsc-ui/#Robustness are the W3C recommendations on
>> this topic.  To summarize (but please please please read the document,
>> it's quite good):
>> * show identity signal in a consistent visual position where web content
>> can't obscure it

LMI> Sure, eww should display TLS markers and stuff, but that's kinda
LMI> orthogonal to the issue I was discussing, which is how (and whether) to
LMI> query the user when running in an asynchronous context.   >"?

I mean that EWW's visual indicators of identity and trust should be
global. Then you don't interrupt the user (they get cranky!) but show
them a visual indicator that something requires their attention. I can't
think of a better place that works in graphical and text modes and has
the precedent of embedded infobar-style buttons than the modeline.

Furthermore, I think it would make sense to use the same indicators for
GnuTLS connections in general (whatever NSM handles), not just EWW. I
couldn't find UI recommendations for mail clients, but from experience
with a few they treat encryption problems as a high-priority dialog and
interrupt the user experience until you say "OK, trust XYZ." Which is,
again, not ideal for Emacs so we should find a nicer way to indicate
problems without interrupting.

I also mean that those indicators should not be solely implied by "the
image looks broken" because that's displaying the indicator in the
content where it can be obscured and the location varies.

>> As I said, there is much more in the document. Of course, Emacs is not
>> just a web browser, so we must adapt rather than blindly adopt these
>> guidelines, but I hope we don't ignore them. Should I make a list of
>> concrete recommendations for EWW and Emacs in general based on that
>> document?

LMI> Yeah, that would be nice.  File it as an enhancement bug report so that
LMI> we don't forget.

All right.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]