W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2015

Re: Proposal: Showing the padlock icon on all secure origins

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 30 Nov 2015 12:07:05 +1000
To: timeless@gmail.com, "Simon Brown" <mail@simonandrewbrown.co.uk>, "Joel Weinberger" <jww@chromium.org>
Cc: public-webappsec@w3.org
Message-ID: <op.x8wuh3ngs7agh9@widsith.local>
On Tue, 24 Nov 2015 02:35:28 +1000, Joel Weinberger <jww@chromium.org>  

> I think this is a per user-agent decision as most (all?) iconography is.

Sort of...

> It is not mandated that a 'lock' icon is needed at all; that's just a
> convention that user agents have converged on. It's also notable that  
> some major browsers use the lock icon for additional purposes (see the
> UC Browser, for example, which if I'm not mistaken, also uses lock  
> iconography for HTTP pages that have been scanned for malware).

There was some very explicit work around EV certificates and how browsers  
represent them. Because if there is inconsistent iconography users can be  

...hence the discussion about changing the "broken security" icon usage  
 from mixed TLS / trasnmission in the clear to apply to pure transmission  
in the clear as well.

> That having been said, you might consider filing feature requests with
> various browser vendors, as I think your point about localhost has merit  
> in our particular context, and I'm guessing the other major user agents
> may feel similarly.



> --Joel
> On Mon, Nov 23, 2015 at 5:24 AM timeless <timeless@gmail.com> wrote:
>> I'm not sure localhost should be seen as secure. Historically, people
>> downloaded untrusted content and then were tricked into loading it.
>> Also, in the really olden days, people shared computers so many  
>> different
>> users would have writeable storage on a single localhost. In a  
>> university
>> setting, a couple would be pranksters -- untrustworthy. Their files  
>> could
>> be accessed via localhost, but doing so could be manifestly bad for you  
>> and
>> your data.
>> If you want to provision a CA and add it to your list and then issue
>> yourself a certificate for an alternative name for your host (I.e. other
>> than localhost), then I don't see a problem with you doing that.
>> On Nov 22, 2015 3:22 PM, "Simon Brown" <mail@simonandrewbrown.co.uk>
>> wrote:
>>> Currently most browsers only show the padlock icon on HTTPS sites, even
>>> though there are other secure origins, such as localhost. I propose  
>>> that
>>> browsers start showing the padlock icon for other secure origins,  
>>> providing
>>> there isn’t a security problem, such as an invalid certificate on a  
>>> HTTP
>>> site or content from an insecure origin. This would:
>>> 1. Make it easier for users to ascertain whether an origin is secure.
>>> Currently secure localhost and insecure HTTP have the same indicators.
>>> 2. Increase the perceived normality of the padlock signal, making
>>> insecure origins stand out more.
>>> 3. Make it more obvious to developers when they are able to use  
>>> features
>>> that are restricted to secure origins.
>>> https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
>>> 4. Make the transition to marking insecure origins as non-secure more
>>> straightforward.
>>> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 30 November 2015 11:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC