GNOME Bugzilla – Bug 650789
Use lock metaphor for security-* icons.
Last modified: 2020-11-26 14:41:21 UTC
Bug #648621 requests Epiphany to use symbolic lock icons for the location entry. I think this makes sense and the available changes-{allow,prevent}-symbolic icons already look pretty good. I think an improvement would be to fill them with red/green depending on the security status, but right now they can only be painted completely instead of having some inner part filled (like the battery icons), so I'm opening this bug in case someone wants to provide an enhanced version for us to use.
The changes-allow and changes-prevent are meant for actions preventing and allowing changes to settings (in system settings user panel for example). The spec* defines three states for security levels - security-low, security-medium and security-high. Looking up 'changes-allow' for something that communicates security level is very wrong. Use the names defined in the naming spec and if you feel like the metaphors are inappropriate, open up a bug about it (applies to both gnome-icon-theme and gnome-icon-theme-symbolic). * http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
Every other major browser uses a lock icon to signify the security status of a page, so I don't think this is a place where we should be innovating. If you don't think this should be in the icon theme I guess we can just ship it with Epiphany. I can either copy the current change- icons or have someone draw new ones and copy those over.
Reopening this, I think we need lock icons as the metaphor for the browser.
Either you want to change the security-* metaphors or you want to ship your own icons, using prevent-changes is the worst choice of all.
(In reply to comment #4) > Either you want to change the security-* metaphors or you want to ship your own > icons, using prevent-changes is the worst choice of all. As I say in comment #2 I'm perfectly happy shipping custom icons in the browser, I have no interest at all in using the changes-* icons. So again: should we change the security-* icons metaphor, add new icons for the browser to use, or ship something custom with Epiphany? I'm open to any option.
Our security icons are 3, high, medium and low, from what I understand you need a basically a security yes/no for certificate validity, right?
While I think the padlock icon says nothing about security, it makes no sense to have the shield icons in the system theme that aren't used for that very purpose. And while lacking, the fact that it is used elsewhere is in favour of using padlock for this. security-low -> open padlock security-medium -> closed padlock with one keyhole security-hight -> closed padlock with two keyholes
Just for context, here's what we do. There are three possible security states: - Secure site ("security high"): a closed padlock is shown in the entry. - Broken secure site: the site should be secure, but something went wrong. Usually an issue with the certificate. An open padlock is shown in the entry. - For any other state (ie, technically "insecure" sites), we don't show anything. So as Lapo says, what we could use at this point is basically a yes/no thing. The metaphor all browsers use is an open/closed padlock, and they tend to color it in some way with green or red depending on what's the status to make it more visible. It looks like Chrome has a third intermediate state, where although everything is technically OK some parts of the site have not been loaded in a secure way. See: http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95617 What I'd do at this point is to have a simple open/closed padlock (optionally wit h some area suitable for coloring), and perhaps in the future draw an extra icon for an intermediate security state. I'm unsure about using the one keyhole/two keyholes metaphor, since it seems somewhat obscure and initially we'd only ever use the two-keyhole icon. Better to keep it simple (at least for now) and have plain icons. My 2 cents, anyway.
There are 2 different fully secure states, according to the big 4 browsers (IE, Firefox, Chrome, & Safari), SSL & EV-SSL. http://www.libertyvoice.net/2011-01/web-browser-security-user-interfaces-hard-to-get-right-and-increasingly-inconsistent/
Resetting assignee to default to avoid cookie-licking (see bug 744024). Jimmac: If you actively and realistically plan to work on this, please set yourself as assignee again so this ticket will be shown on top of your user page at https://bugzilla.gnome.org/page.cgi?id=describeuser.html Thanks!
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all older bug reports and feature requests in GNOME Bugzilla which have not seen updates for a while. If you still use adwaita-icon-theme and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).