Bug 7599

Summary: No icons for lock/security (status context) in Icon Naming Specification
Product: tango Reporter: Luca Ferretti <elle.uca>
Component: defaultAssignee: Jakub Steiner <jimmac>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: CVS   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Luca Ferretti 2006-07-22 16:18:22 UTC 
I'm tryin to make Epiphany Icon Naming Spec compliant (port from old legacy
named icons to new). There are 3 stock icons could be useful to have in I.N.S.

 Ephy internal name   |    Gnome-icon-theme legacy icons
---------------------------------------------------------
 STOCK_LOCK_INSECURE  |   "stock_lock-open"
 STOCK_LOCK_SECURE    |   "stock_lock"
 STOCK_LOCK_BROKEN    |   "stock_lock-broken"

My suggestion is to add 3 named icons to I.N.S.

  status/security-secure
  status/security-insecure
  status/security-broken

Using a closed padlock, an open padlock and a broken padlok as images
Comment 1 Rodney Dawes 2006-07-24 12:24:02 UTC 
The locks are inappropriate for the context in which they are used in Epiphany
and Firefox. Especially when the same image is also used in other contexts, such
as for authentication and actually locking things together, such as layers in
images and such. We need a better metaphor for this. Also, what is the
functional difference between broken and secure?
Comment 2 Luca Ferretti 2006-07-27 08:07:05 UTC 
(In reply to comment #1)
> We need a better metaphor for this.

This is related to icon theme implementation, isn't it?

What about propbosed "named icons"? Do you need are appropriate for I.N.S. or
applications could/should provide needed icons for security by themself?

> Also, what is the functional difference between broken and secure?

I don't know exactly how it's used in ephy, but on web browsing side I suppose that:
  * security-insecure is for plain http:// sites
    (someone could listen you, no security for your data)
  * security-secure is for https:// sites
    (safe channel between you and the server)
  * security-broken for https:// sites with broken stuff
    (a safe channel is available, but web browser can't trust it)

Switching to Evolution(GnuPG/PGP), I think that a reasonable usage is: 
  * security-secure: message(data) is signed and sign is valid
    (authentic message)
  * security-insecure: message(data) is unsigned
    (no guarantee that it's authentic)
  * security-broken: invalid signature
    (fake message or altered in transit)

So broken is for "places" where sign/encription is available but the application
can trust or verify it.

The same secure/insecure/broken schema could be applied to wireless networks
managers and IM/Chat connections.

Of course secure/insecure/broken is just a suggestion. You could find a better name.

PS I'm going on vacation. See you on september :-)
Comment 3 Rodney Dawes 2006-08-02 10:18:43 UTC 
security-high, security-medium, and security-low are now in the spec.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.