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

I think this is a per user-agent decision as most (all?) iconography is. 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).

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
>>
>